직장에서 "20 % 시간"소개 [닫기]

20 %의 시간은 그것의 직원들이 흥미 것으로 프로젝트를 진행 그들의 시간의 20 %를 소비 할 수 있도록 고용주의 문화 - 그것은 새로운 응용 프로그램을 발명하거나 기존 프로세스를 개선 할 수있다 등 어떤 사람들은 수 스컹크 등이 알고 그러나 그 용어는 당신에게 무언가 (또는 완전히 다른) 것을 의미하지 않을 수도 있습니다.

회사에서 스 sk 크 작업의 20 %에서 나온 훌륭한 제품에 대한 문서화 된 사례가 많이 있습니다. 윈 / 윈 상황처럼 보인다. 회사는 잠재적으로 훌륭한 새로운 제품이나 응용 프로그램을 얻게되며 개발자는 자신의 창조적 인 힘을 발휘하고 혁신 할 수 있습니다.

나는 이전 고용주에서 성공하지 못한 20 % / Skunk의 형태를 소개하려고 여러 차례 시도했습니다.

경영진에게 어떻게 정당화 할 수 있습니까? 이런 종류의 작업 배치에 접근하는 "올바른"방법은 무엇입니까?

20 % 시간의 주된 이유는 용량 활용률을 100 %가 아니라 80 %로 유지하는 것입니다.

소프트웨어 개발 조직은 기능 요청을 개발 된 기능으로 변환하는 시스템으로 생각할 수 있습니다. 큐잉 이론을 사용하여 동작을 모델링 할 수 있습니다 .

이론

시스템이 요청하는 것보다 빨리 요청이 도착하면 대기합니다. 도착이 느리면 대기열 크기가 줄어 듭니다. 도착 및 서비스 프로세스는 무작위이므로 큐 크기는 시간에 따라 무작위로 변경됩니다.

수학적으로 기울어 진 것은이 "무작위성"에 대해 묻을 수 있습니다. 확률 분포가 있어야하므로 큐 크기는 평균적으로 얼마입니까? 수학 (대기열 이론)은 그에 대한 해답을 가지고 있습니다 : 도착과 서비스 과정이 모두 Markov라면 N = rho ^ 2 / (1-rho).

rho는 서비스 및 도착 비율의 비율과 동일한 활용 계수입니다. 프로세스가 Markov가 아닌 경우 수학은 더 복잡하지만 결론을 변경하지는 않습니다.

이 함수를 플로팅하면 사용률이 최대 0.8 인 동안 평균 큐 길이가 낮게 유지 되고 급격히 증가하여 무한대로 이동 함을 알 수 있습니다. 컴퓨터의 CPU에 대해 생각하면 직관적으로 이해할 수 있습니다. 사용률이 100 %에 도달하면 컴퓨터가 응답하지 않게됩니다.

연습

소프트웨어 개발의 경제성은 소프트웨어 회사가 대기열이 높은 대기열 상태에있을 때 큰 비용이 발생하도록합니다. 여기에는 누락 된 시장 기회, 더 이상 사용되지 않는 제품, 늦은 프로젝트 및 수요를 예상하는 기능을 구축함으로써 발생하는 폐기물이 포함됩니다.

따라서 20 %의 시간은 경제 성과 최적화 문제에 대한 과학적 답변입니다. 본질적으로 시스템의 응답 성을 유지하는 것은 느슨합니다.

몇 가지 실용적인 결론은 즉시 따릅니다.

• 20 %의 시간을 고려하고 비용 회계 (개발자 시간은 X이지만 회사가 감당할 수없는 경우)를하고 있다면 잘못하고있는 것입니다.
• 매주 금요일에 20 %를 할당하면 잘못하고 있습니다
• 20 % 시간 프로젝트 제안서 제출 / 검토 / 승인 시스템을 설정하는 경우, 잘못하고 있습니다
• 작업 표를 작성하는 경우 잘못하고 있습니다
• 혁신을 동기 부여 자로 20 % 시간 동안 사용하고 있다면 잘못하고있는 것입니다. 신제품은 20 % 프로젝트에서 나왔지만 요점은 아닙니다. 핵심 시간 동안 회사가 혁신을 할 수 없다면 문제입니다!
• 20 % 시간은 창의성에 관한 것이 아닙니다. 20 %의 시간으로 창의력을 발휘할 것이라고 말하지 말고 핵심 시간 동안 이미 창의력이 부족한 이유를 물어보십시오.

주석의 질문에 대한 답변

Dan , 당신은 그 권리를 가지고 많은 사람들이 저지른 실수를 정확하게 묘사했습니다. 사용률은 출력 변수이므로 선택할 수 없습니다. 두 프로세스의 특성 비율이므로 프로세스가 그대로 있기 때문입니다. 조직은 두 프로세스 모두에 영향을 미칩니다. 기능과 요구를 일치시키는 것은 소프트웨어 개발 지식이 요구하는 어려운 문제 중 하나입니다. 활용은 조직에서이 문제가 얼마나 잘 해결되었는지를 나타내는 지표 중 하나입니다. 린 이니셔티브가 진행되고 가치 흐름에서 폐기물을 제거함에 따라 여유가 발생합니다. 그러나 20 %의 시간을 요구하면 사용 가능한 용량이 적은 동일한 사용률 트랩을 얻게됩니다.

김 , 그것은 여전히 ​​부분적으로 문화적인 것입니다. 내가 생각할 수있는 가장 가까운 문화 참조는 소위 Marshall Change of Organizational 변경 의 시너지 수준입니다 . 성공적인 린 변환이 끝날 때 나타나거나 처음부터 마른 조직에 존재합니다. ( Bob Marshall 백서 (PDF)에 대한 링크는 다음과 같습니다 .)

참조

위의 논리는 소프트웨어 엔지니어링 문헌에서 잘 지원됩니다. Mary와 Tom Poppendieck 는 2006 년 Lean 소프트웨어 개발 구현 에서이를 암시했습니다 . Donald Reinertsen은 자신의 2009 년 책 "제품 개발 흐름 원칙 (3 장)"에서 공식과 그래프를 통해이 주제에 대해 철저한 치료를 제공합니다.

이 답변을 쓴지 14 개월 만 에 훨씬 더 나은 답변을 찾았습니다 .

그런 작업이 공식적으로 인정 된 곳에서는 일하지 않았습니다. 그러나 나의 대화와이 연습에 대해 배우려고 시도한 결과, 나는 이것이 대부분 "20 % 시간"이 아닌 것을 발견했습니다.

• 그것은 실제로 문화이지 정책이 아닙니다.
• 고위 경영진에 의해 결정될 수 없습니다
• 개발자위원회가 설립 할 수 없습니다
• 32 시간이 아니고 8 시간이 아닙니다

" Skunkworks "는 20 % 시간과 다릅니다. 20 %의 시간은 개발자가 스스로 작업 할 내용을 선택하는 시간입니다. Skunkworks는 완전히 다릅니다. 스 unk 크 웍스 프로젝트는 상위 경영진에보고되지 않은 팀 (종종 파편 전문가 팀)이 수행 한 고가의 고비용 프로젝트이며, 관리 방향없이 프로젝트를 진행하는 방법을 스스로 결정합니다. . 이러한 프로젝트는 종종 무언가를 달성하기위한 전술적 또는 사업 적 필요에 의해 동기를 부여 받지만 예산을위한 여지가 없습니다. 무언가 를해야 한다면 , 예산이 삭감됩니다.

20 %의 시간을 구현 한 개발 팀을 관리했습니다. 또는 어쨌든 시도했습니다. 나는 상사의 승인을 받았으므로 문제가되지 않았습니다. 문제는 팀이 너무 작고 너무 전문적이라는 것이 었습니다. 즉각적인 개입이 필요한 문제가 생길 때마다 20 %의 시간이 걸렸습니다. 이것은 매우 자주 일어났다.

또한 내 개발자 중 일부가 방향이 불안정하다는 것을 알았습니다. "프로그래밍 관련이라면 원하는대로 작업하라"고했지만 "아무것도"받아들이는 데 여전히 어려움이있었습니다. 그들은 일부 프로젝트가 다른 프로젝트보다 낫다고 생각했기 때문에 필연적으로 주 제품의 저수준 구현 요청에 대해 작업했습니다. 나는 그들이 분기하고 성장하기를 원했지만 대신 그들은 그들의 주요 전문 지식을 깊이 파고 들었다.

나는 다시 할 것이지만, 나는 주요 제품에 대한 작업을 명시 적으로 금지하고 시작하기 위해 선택할 수있는 몇 가지 아이디어로 시작할 수 있습니다.

20 % 정책을 구현 한 신생 기업을 위해 일하고 있습니다. 이것은 나의 첫번째 고용주이며, 그가 면접에서 그것을 제기했을 때, 나는 대부분의 다른 고용주들이 한 시간을 "폐기"하지 않기 위해 정말로 놀랐습니다.

창업 당시 신생 기업에 합류했으며 거의 ​​1 년 동안 유일한 개발자였습니다. 기본적으로 몇 가지로 20 %를 소비했습니다.

• 랜덤 오픈 소스 프로젝트의 버그보고 / 수정 – 이것은 Github 에서 흥미로운 프로젝트를 수행 하고 문서의 오타를 수정하는 것만 큼 ​​작을 수 있습니다 .
• 재미를 위해 프로그래밍 문제와 같은 오픈 소스 "재료"작성
• 회의 및 스프린트로 이동 – 몇 개의 나방마다 프로젝트를 진행할 수있는 스프린트 (일부는 메인 앱에서 사용하고 일부는 사용하지 않을 수 있음)에 참여하여 경험을 얻습니다. 당사 앱과 개발자를 컨퍼런스에 보내는 다른 회사에서 개발 한 앱에서 사용하는 라이브러리가 몇 개 있으므로 회사에 직접적인 혜택으로 볼 수 있습니다.
• 새로운 기술을 배우십시오 – 우리가 회사에서 그것을 사용하지 않더라도 Go를 배웠습니다 . 이것은 특히 고용주가 권장합니다. 최근에 나는 스탠포드 무료 온라인 수업 중 일부를 따르고 있습니다.

시간은 정확하게 측정되지 않으며 32 + 8 시간이 아니며 때로는 20 %를 줄일 시간이 충분하지 않을 때해야 할 일이 있습니다. 다른 시간에는 여분의 시간이 더 있습니다.

저는 원격으로 일하고 있으며 37signal의 캠프 파이어 채팅을 사용하여 서로의 현재 상태를 통신하고 느슨하게 추적합니다.이 시간은 "근무 시간"으로 추적됩니다. 채팅에 로그온하여 동료가 사용할 수 있습니다. 지금 우리 프로젝트에서 일하고 있지 않다는 것이 분명합니다.

나의 작은 경험으로부터, 많은 프로젝트들이 실제로 이런 방식으로 시작되었습니다. 우리는 새로운 프로젝트를 수행 할 수있는 자유 시간과 대역폭을 가졌으며, 함께 모여 부서에 대한 잠재적 멋진 / 앞으로 생각 아이디어를 생각해 냈습니다. 여가 시간에 우리는 프로토 타입을 개발했고 일단 정교하게 다듬어 상위 레벨로 제시했으며 대개 이점을 보았습니다.

상위 레벨은 그들이 볼 때 원하는 것을 알고 있지만 그들이 볼 때까지 필요 / 원한다는 것을 알지 못하는 것 같습니다. 프로토 타이핑을 통해 자체 프로젝트를 만들어 제안한 다음 승인을 마치면 더 많은 시간을 투자하여 완료 할 수있었습니다.