관리자로서 예, 팀이 작업 표를 작성하도록합니다. 다음은 중단을 최소화하기 위해 구현 된 방법에 대한 이유와 몇 가지 참고 사항입니다.

1. 사업으로서 우리의 작업의 대부분은 시간과 재료를 기준으로 수행됩니다. 작업 표가 없으면 분명히 작동하지 않습니다. 우리는 10 명의 고객과 다양한 프로젝트 및 제품을 보유하고 있지만 직원이나 고객을 풀 타임으로 헌신 할만큼 크지 않기 때문에 시간이 오래 걸리는 방법을 찾아야합니다. 이것이 팀을 관리하는 것이 사실이 아니더라도 시간과 소요량을 이해해야합니다. mailroom 사람들이 사용하는 오래된 앱이 가치보다 지원하는 데 더 많은 시간이 걸리고 있다고 생각하십니까? 판매량을 두 배로 늘린 새로운 웹 사이트에서 기능 X에 얼마나 많은 작업을했는지 묻는 사람은 어떻습니까? 또는 개발자가 다른 사람을 모집해야한다고 말하면 정당화를 위해 그들이하는 일을 분석해야합니까?

2. 멘토링, 일반적인 기술 토론, 지원, 회의 등을 포함한 모든 합리적인 “비업무”범주가 있습니다.

3. 버그 수정 – 버그 별보다는 전체 프로젝트에 대한 시간을 기록합니다. 이것은 버그를 수정하는 데 하루를 보내고, 7.5 시간 동안 버그를 수정하면 프로젝트를 완료하게됩니다. 수정 한 13 개의 버그로 어떻게 나누어 졌는지 알아볼 필요가 없습니다.

4. 우리가 그것들을 구현했을 때 나는 그들이 정확했던 한 아무도 그들의 작업 표에있는 것에 대해 불이익을받지 않을 것이라고 약속했다. 따라서 수익성이나 이용률 또는 기타 다른 것에 근거한 리뷰는 입력되지 않습니다. 이것은 왜곡에 대한 인센티브가 없다는 것을 의미합니다.

5. 정확히 말하자면 대략 의미합니다. 사람들은 커피를 마시거나 화장실에 갈 때 일어나는 일에 대해 너무 많은 시간을 소비하지 않아도됩니다. 기본적으로 하루 동안 작업 한 각 항목의 패드에 메모를 작성하면 하루가 끝날 무렵에는 작업 한 시간에 걸쳐 대략적으로 세분화됩니다. 최대 5 분 이상 걸리지 않아야합니다.

6. 내가보기에 마음에 들지 않으면 (예를 들어 누군가가 작업 X에 너무 오랜 시간을 보냈다면) 조사는 작업 표와 관련이있는 것보다 X를 더 빠르게 만들기 위해 할 수있는 일에 대한 것입니다.

7. 당신이 무언가를하는데 걸린 시간을 아는 것은 추정치를 향상시키는 좋은 방법입니다.

많은 프로그래머들 사이의 작업 표 방지 느낌은 다음 두 가지에서 비롯된 것 같습니다. (1) 완료하는 데 너무 오래 걸리고 실제로 필요한 것보다 더 많은 정보를 요구하며 거짓말과 왜곡을 장려하여 정보가 가치가 없으며, (2) ) 개발자에게 약간의 불편을 초래하는 모든 일을 해결해야한다는 느낌.

첫 번째는 공정하지만 이러한 문제가없는 방식으로 수행 할 수 있는 작업 표의 전체 아이디어가 아니라 구현 및 누군가가 첨부 한 규칙을 비난해야 합니다. 두 번째는 비현실적입니다. 회사 내부와 외부에서 프로젝트에 관련된 많은 당사자가 있으며, 각 당사자는 많은 요구를 가지고 있습니다. 그렇습니다. 프로그래머의 생산성을 높이기 위해 최선을 다하고 싶지만 다른 당사자의 요구와 균형을 이루어야합니다.

답변