일일 보고서가 개발자의 생산성을 떨어 뜨릴 수 있습니까? [닫은]

또 다른 질문으로 , 개발자들이 왜 일일 스크럼을 좋아하지 않는지 물었습니다 . 우리는 개발자들과 이야기를 나누었고, 매일 스크럼을 유지하지 않기로 결정했습니다. 개발자와 직접 상담 한 결과입니다.

다른 한편으로, 우리는 매일 개발자를 조정하거나 주요 성과 지표와 같은 작업 진행 상황을보고 조치를 일찍 취하는 등 일상적인 스크럼의 좋은 부분을 잃고 싶지 않습니다.

일일 스크럼의 대안으로 개발자에게 다음과 같은 조건으로 일일 보고서를 제공하도록 요청하고 있습니다.

1. 특정 형식을 따를 필요가 없습니다. 각각의 모든 형식이 허용됩니다.
2. 작업이 완료되지 않더라도 진행 정도를 듣고 싶습니다.
3. 각 작업에 소요 된 시간을 언급 할 필요는 없습니다.
4. 개발 장애 및 조정 요구 사항을 언급해야합니다.
5. 일일 보고서에 집착 할 필요가 없습니다. 그렇게 엄격하지는 않습니다.

이것이 생산성을 떨어 뜨릴 수 있다고 생각하십니까? 매일보고 한 경험이 있습니까? 우리가 미세 관리 하지 않는 것을 확신 할 수 있도록 어떤 제안이 있습니까?

일일 스크럼의 대안으로 개발자에게 다음과 같은 조건으로 일일 보고서를 제공하도록 요청하고 있습니다.

정말 끔찍한 생각입니다.

이것이 생산성을 떨어 뜨릴 수 있다고 생각하십니까?

예.

왜? 회의에서 구두로 발표하는 것은 글을 쓰는 사람 과 n 명의 사람이 보고서를 한 번의 활동으로 "읽는"것입니다. 말하기와 듣기. 끝났어요. 질문에 바로 대답했습니다.

보고서를 작성하는 것은 질문이 있기 때문에 시간 낭비이며 (a) 질문이 있고 (b) 실제로 읽지 않은 사람들과 보고서를 검토해야합니다.

일일 보고서를 읽을 수 없습니다. 이들은 소음 내로 빠르게 전환됩니다.

"매일 보고서에 집착 할 필요가 없습니다". 어떤 경우에 왜 그런가요?

우리가 미세 관리하지 않는 것을 확신 할 수 있도록 어떤 제안이 있습니까?

예. 매일 일어나십시오. 몇 분이 걸리며 완료되었습니다.

매일 일 어설 수있는 시간이 몇 분 (15? 분) 이상 걸리는 경우 세부 정보가 너무 많이 공유되므로 해당 세부 정보에 대해 별도의 회의를 예약해야합니다. 매일 일 어설 수 있습니다. 2 분 요약 후, 다른 모든 것은 아마도 전체 팀이 아니라 세부 사항 일 수 있으며 후속 회의에 참여해야합니다. 회의는 그 날의 다음 사람의 초점으로 넘어갑니다.

나는 과거에는 이것을했지만 아침에는 반대로 끝났습니다. 작성하는 데 일반적으로 5 분도 걸리지 않았으므로 개발자의 생산성이 어떻게 저하 될지 알 수 없습니다. 아침에하는 것에 대한 좋은 점은 하루 종일 당신이 무엇을 할 것인지 생각하게했다는 것입니다.

그 말을 ...

우리는 그것이 전보다 더 많은 시간이라는 것을 알았습니다. 전날에 한 일과 그 날에 할 일을 의사 소통하는 가장 효과적인 방법은 아닙니다. 왜? 사람들은 일반적으로 읽지 않았습니다. 일정이 잡힌 Outlook 작업이므로 모든 사람이 매일 발송했지만,지도 또는 관리팀이 아닌 다른 사람들이 모두보고 싶거나 전혀보고 싶었습니다.

우리는 사람들이 서로 귀를 기울이는 경향이 있기 때문에 매일 서있는 자세를 취하는 것이 훨씬 더 가치있는 것으로 나타났습니다. 또한, 오해가 있었다면, 그 다음에 플러시 될 것이며, 이는 일상적인 상태 이메일에 회신하여 다른 질문을하는 사람보다 발생하기 더 쉽습니다.

모든 정직에서, 누군가가 제약없이보고 할 수있게하는 것은 방정식의 자유 주의적 측면에 너무 미미한 것 같습니다. 내가 일하는 곳에서 우리는 원을 그리며 각 개발자는 다음을 제공합니다.

1. 전날에 한 일. 모든 작은 세부 사항이 아니라 전체입니다.
   • 위의 사항이 완료되지 않은 경우 완료하지 못한 경우 완료하는 데 걸리는 시간과 시간이 걸립니다.
   • 위의 작업이 완료되면 다음 작업, 필요한 작업 및 시간이 걸립니다.
2. 차단제. Bar에 의존하는 Foo에서 작업 중이고 Bar가 완료되지 않은 경우이를 명확하게해야합니다.

모든 사람이 따라야 할 일반 스키마를 설정하면 주어진 보고서를 쉽게 처리 할 수 ​​있습니다. 모든 사람이 일일 보고서가 포함 된 전자 메일을받을 수 있도록 몇 가지 방법을 쉽게 설정할 수 있으므로 모든 사람이 진행 상황을 확인할 수 있습니다.

IMO 모든 유형의 일일 회의 / 보고서는 솔직히 말하면 소액 관리에 악영향을 미치기 때문에 생산성을 떨어 뜨립니다. 예, 저는 Scrum 등을 알고 있으며 짧은 상태 업데이트 ( "프로젝트 X는 어떻습니까?")라면 나쁘지 않습니다. 전문 개발자가 탭을 유지 하는 것을 모욕 . 저수준에서 우리; 시간표를 사용하여 하루에 8 시간 동안 사무실에 있는지 확인하거나 벽이 없는지 확인하여 사람들의 컴퓨터를 감시하여 주어진 시간에 어떤 창을 열 었는지 확인할 수 있습니다.

모든 사람이 제대로 작동하는지 확인하기 위해 탭을 유지해야하는 경우, 해당 탭을 신뢰할 수 없다는 의미입니다. 당신이 그들을 믿지 않으면 걱정하는 것보다 더 큰 문제가 직장에서 있습니다.

우리 팀은 약 1 년 동안 스크럼을 수행해 왔습니다. 그 전에 우리는 일주일에 두 번의 회의를 가졌으며,이 기간 동안 각 팀원은 지난 2, 3 일 동안 자신의 활동에 대해보고했습니다. 각 회의는 30 분에서 1 시간 동안 지속되었습니다. 정보를 교환하고 업무를 조정해야하는 경우 동료들에게 가서 이야기를 나누었습니다 (물론 여전히 그렇습니다).

우리가 스크럼을하고있는 지금 우리는 하루에 한 번의 회의 (15 분만 지속되지만)가 너무 많다는 인상을 종종받습니다. 종종 일부 회원들의 보고서는 "어제 이후로 새로운 것은 없다"로 요약됩니다. 우리는 종종 주당 2 회의 회의 스키마가 더 효과적이라는 인상을 받았습니다.

또 다른 단점은 일일 회의가 계획된 중단이라는 점입니다 (예 : Paul Graham의 기사 참조) , 요점 1 ) : 방해가 올 것임을 알고 있기 때문에 회의 전에 어려운 일을 시작하지 않을 것입니다 (매일 회의는 일을 시작한 후 1 시간 30 분이 지나야합니다.

마지막으로, 초기 피드백에는 이점이 있지만 ( "아, 그 문제에 대해 작업 중입니다, 우리는 그것을 논의해야합니다!"), 아이디어를 이미 마음에 정리 한 경우에만 토론을 시작하는 것이 더 효과적입니다 구체적인 질문이 있으며 토론 할 준비가 된 것 같습니다. 대신, 일일 보고서는 불필요하고 구조화되지 않은 많은 브레인 스토밍을 빠르게 일으킬 수 있습니다. 따라서 너무 일찍 조심하십시오 피드백에 . 혼동을 일으키고 속도를 늦출 수 있습니다.

따라서 경우에 따라 일일 보고서에서 생산성이 저하되었습니다. 평균적으로 나는 그들이 우리의 일을 더 효과적으로 만들었다는 느낌이 없습니다.

최신 정보

나는 몇 년 전에 내 원래의 답변을 썼고 그 동안 팀을 전환했습니다. 현재 팀에서 필요에 따라 즉석 상태 업데이트가 필요할 때 매일 회의를하고 있습니다. 따라서 매일 그러한 회의를 가질 수는 있지만 아무도 요청하지 않으면 회의를 열 수 없습니다. 매주 회고 회의가 있습니다. 이것은 기본적으로 이전의 민첩하지 않은 팀에서 처음 사용했던 방식과 매우 유사합니다. 고정 된 주별 모임과 나머지 주중에 추가 주문형 모임.

당신이 정말로 원하는 것이 거친 상태이고 장애물을 기록하는 가장 좋은 방법은 짧은 "일별 상태 이메일"을 요청하는 것입니다. 너무 강조하거나 포함하지 않아야 할 목록을 만들면 최소한 일부 개발자가 요구 사항을 충족시키기 위해 추가 시간을 소비하게됩니다. 그 대신 간단한 이메일을 요청하십시오. 하루 종일 일이 생기면 "오, 이메일을 끝까지 넣으십시오"라고 말하고 정말로 긴 이메일을 받으면 "매일 그렇게 자세하게 설명 할 필요는 없습니다"라고 언급하십시오.

모든 회의 또는 보고서 의 목적 , 특히 매일 모든 사람이 수행 하는 목적 을 명확하게하는 것이 매우 도움이됩니다 . 그 이유는 다음과 같습니다.

우리는 매일 개발자를 조정할 기회를 얻는 것과 같이 매일 스크럼의 좋은 부분을 잃고 싶지 않습니다.

좌표 개발자 란 무엇을 의미 합니까? 어떤 종류의 작업이 조정되어야하며 필요할 때 개발자와 관리자가 임시 조정하지 않습니까? 조정이 필요한 작업을 식별하고 그러한 경우에만 의사 소통 할 수있는 방법이 있습니까?

또는 핵심 성과 지표와 같은 작업 진행 상황을보고 조기 조치를 취할 수 있습니다.

사이트 응답 시간 또는 중요한 버그 수와 같은 많은 좋은 KPI를 기계적으로 측정 할 수 있으므로 개발자에게 비용을 부과 할 필요가 없습니다.

직장에서 몇 가지 다른 형식으로 매일 보고서를 작성해야했습니다. 일반적으로 일일 보고서는 개발자 자체가 아닌 관리자에게만 가치를 부여하는 경향이 있다고 생각합니다. 관리자는 각 프로젝트의 전체 상태와 각 직원의 작업 부하를 짧은 시간 안에 알 수 있기 때문에 일일 보고서의 이점을 얻을 수 있지만 대부분의 개발자는 서로의 상태 보고서를 읽는 것을 귀찮게하지 않습니다.

그러나 일일 보고서의 형식을 적용하지 않으면 관리자와 동료 개발자 모두가 보고서를 읽고 처리하기가 어려워 져 개발자 시간 손실 문제가 악화됩니다.

개발자를위한 일일 보고서를 진행하기로 결정한 경우 전자 메일 보고서 대신 내부 위키를 사용하는 것이 좋습니다. 이렇게하면 사람들의받은 편지함을 스팸하지 않고 모든 사람의 일상 상태 기록을 유지할 수 있습니다.

Agile 메소드를 사용자 정의하여 사용자에게 적합하도록하는 것이 좋습니다.

따라서, 매일의 보고서는, 이것이 매일의 회의보다 훨씬 나쁘지 않다고 말하고 있습니다. 그것은 여전히 ​​똑같은 "내가하고있는 일을 말해"접근 방식입니다.

대안은 다음과 같습니다. 각 개발자에게 상태를 물어볼 때 이러한 '폴링'기술을 사용하는 대신 '푸시'기술을 사용하십시오. 개발자가보고 할 것이 많지 않다면보고하지 않아도되지만 모든 문제와 진행 상황을보고해야합니다. 따라서 모듈을 완성하면 완료된 모든 팀에게, SCM에서, 문서를 찾을 수있는 곳, 그 내용, 작동 방식 및 / 또는 사용 방법에 대한 간략한 요약을 전자 메일로 보내야합니다. 그것. 문제가있는 경우 팀에 이메일을 보내 조언, 도움 또는 팁을 요청해야합니다. (예, 오늘날 우리가 겪고있는 미세 관리없이 팀이 잘 소통 한 예전처럼)

이것이 훨씬 생산적이고 건설적이라는 것을 알게 될 것입니다. 당신은 그들을 위해 무의미한 보고서를 얻지 못하고 모든 사람들이 동료에게 자신의 작업에 대해 알리기를 원할 때보 다 동기 부여 된 팀을 얻게됩니다.

또한 매일 순위를 보고서로 바꾸는 것은 나쁜 생각이라는 데 동의합니다. 매일 일어나서 아이디어와 문제를 발성하기에 좋은 곳입니다. 이것이 내가 좋은 오래된 화이트 보드 (Jira + Greenhopper와 함께 사용)를 좋아하는 이유 중 하나입니다. 화이트 보드는 그룹이 정보를 공유하고 정보를 공유하고, 모든 것이 있으며, 모든 것을 볼 수 있고, 모든 사람들이 자신이 작업 한 스티커를 움직이고 바꾸는 곳이기도합니다.

다른 도구에서이 정보를 추출 할 수 있습니까?

• 현재 무엇을하고 있습니까? 내가 할당 한 티켓.
• 당신의 진도는 무엇입니까? 1 일보다 긴 티켓의 경우 티켓의 주석을 참조하거나 지점의 메시지를 커밋하십시오. 티켓이 더 짧습니다. 아마 내일은 끝났을 것입니다.
• 일반적인 진도는 무엇입니까? 오픈 / 클로즈드 티켓 비율 참조
• 무엇을 정리해야합니까? 티켓은 당신이 상태로 다시 할당받을 필요 피드백 , 그리고 모든 팀의 IRC, 캠프 파이어 룸, 무엇에 대해 논의했다.

더 구체적인 답변이 필요한 경우에는 특정 보고서가 필요하지만 보고서가 없으면 그 자체가 끝 부분처럼 보입니다.