'WBS'에 해당되는 글 1건

  1. 2009/08/28 글뻥 애자일 경험담 7

애자일 경험담 7

Developer 2009/08/28 22:39
오늘 할이야기는 근무 시간에 대한 이야기이다.
이는 WBS라는 전근대적인 Tool과도 직결되는 이야기이다.
일전에 한번은 개발팀내에서 얼마나 성과를 내는 일에 투자하는지 내 스스로 기록해보았었다.
회사에 나와서 내가 얼마나 주어진 일을 마치는데 투자하는지 스스로 체크해본것이다.

8시 40분~50분 : 출근해서 놋북키고 업무 준비
9시 ~ 9시 10분 : 그룹방송 시청
9시 10분 ~ 10시 : 전날 온 메일 확인 및 커피 뽑아오거나 화장실, 중요내용 체크, 오늘 할 일 정리
10시 ~ 10시 10~20분 : 업무보고 오늘 할 범위 상위관리자와 협의
10시 30분 ~ 11시 : 오늘 할일에 대한 사전 조사 및 어떻게 작성할것인지에 대한 구상
11시 ~ 11시 40분 : 약 40분간 보고서 또는 코드 또는 사업계획서 또는 기타 문서 작성 (40분)
11시 50분정도 ~ 1시 : 점심먹고 쉼
1시 ~ 2시 정도 : 다시 일하는 모드로 체인지하는 시간
2시 ~ 5시 40분정도까지 : 2~3번의 담배 피고 커피마시는 시간 1시간여를 제외한 2시간 30~40분동안 업무집중 (2시간 30분)
5시 40~50분 ~ 7시 : 저녁
7시 ~ 9시 정도 : 밀린 업무 질주 모드 (2시간)
퇴근전 30분 : 마무리 모드로 메일보낼것들 오늘 산출물 보고하고 메일들 답장 쓰고...
9시 30분 ~ 10시 : 퇴근

결과적으로 실재로 내가 부여받은 일을 하는 시간은 하루 일과중 4시간~5시간이 최대치였다.

어떤가? 스스로는 다르다고 생각하는가?
다음은 인크루트와 엠브레인 2군데서 2007년 3월부터 4월까지 직장인 2,036명의 설문 결과였다.
조사결과가 충격적이었다. 일일 평균 업무 집중 시간은 고작 2시간 30분인것으로 나타난 것이다.

스카우트에서는 2007년 5월 직장인 555명을 대상으로 조사한 결과는 이런 결과와 아주 비슷하다.
야근 횟수는 '거의 매일'이라고 응답한 직장인이 30.45%로 가장 많았고, '주 2~3회'가 27.75%, '주 3~4회'는 18.02%였다. 그 외 '월 1~2회 이하' 9.91%, '주 1회' 9.55%, '전혀 없음' 4.32% 순 인것이었고 야근시간은 하루 '평균 2시간~3시간'이라고 응답한 비율이 34.84%로 가장 많았고, '평균 3시간~4시간'도 32.96%나 되었다. '4시간 이상'을 야근한다는 직장인도 21.47%로 조사되었다. 반면 '2시간 미만'은 10.73%였다.

즉, 나는 9시에서 10시에 퇴근하는 32.96%에 속하는 직장인이었던 것이다.

그런데 우리 프로젝트 팀의 WBS는 어떠한가?
하루 근무 8시간을 전재로 계획을 수립한다.

즉, 하나의 업무를 시작하고 끝내는데 8시간이나 주어지는데 왜 못하냐는 것이다.
이 전제 자체가 틀렸다는 것이다.
대한민국 직장인의 업무 집중시간이 고작 2시간 30분인데 이때 회의라도 껴있어보라.
회의 사전 준비에 들어가는 시간 30분 정도에다가 1시간쯤 회의하고 녹초가 되서 나오며 담배한대 피며 회의 참석자들과 회의 결과에 대한 정리하고 회의록 작성하면 2시간 30분정도가 걸린다.
한마디로 하루에 회의 1번하면 끝나는 정도의 집중도 밖에 없는 인간에게 WBS계획은 로봇이 되라고 이야기 하고 있는 것이다.

그러니 매일매일 야근을 밥먹듯이 하는 것이다.

그래서 우리는 고객과 합의하에 WBS를 잡을때 TASK위주로 잡지 않았다.
즉, 언제부터 언제까지 무슨일을 한다라는 TASK가 아니라 언제부터 언제까지 무슨 산출물을 제출한다라는 Product로 설정하였다.

-이전 생략-
*TASK위주의 WBS (편의를 위해 담당자 및 휴일 제외)
프로젝트준비 2009. 5. 1 ~ 10
    +- 프로젝트 사무실준비 2009. 5. 1 ~ 3
    +- 프로젝트 사무실 사무가구 설치 2009. 5. 4
    +- 프로젝트 사무실 랜 설치 2009. 5. 5
    +- 프로젝트 사무실 좌석 배정 2009. 5. 5
    +- 프로젝트 사무실 입주 2009. 5. 6
    +- 개발서버 기동 2009. 5. 6
    +- 개발환경 설명 / 방법 공유 및 교육 2009. 5. 7 ~ 5. 10
요구사항분석
    +- 요구사항 협의 2009. 5. 11 
    +- 요구사항 정의 2009. 5. 12~14
    +- 요구사항 명세작성 2009. 5. 15 ~ 2009. 5. 20
-이하 생략-

이렇게 작성된 TASK의 문제는 전근대적인 관리 방법에서 이런 TASK를 프로젝트 진척도로 설정된다는것에 문제가 있다. 다시말해 TASK가 100개 있었는데 프로젝트 준비가 계획대로 아주 잘 진행됐다고 치면 벌써 8%의 진척을 보이는 것이다!
프로젝트 산출물은 아무것도 하지 않았는데 어떻게 8%라는 경이적인 진척율을 보이는 것인가?

따라서, 위와 다르게 우리가 작성한 계획서는 이런식이었다.
* Product위주의 Milestone
2009. 5. 10 사무실 설정/개발서버기동/개발방법 교육
2009. 5. 20 요구사항분석용 Prototype제출
2009. 5. 24 요구분석설계용 USE CASE제출
-이하 생략-

결과적으로 이렇게 작성된 Milestone위주의 일정계획은 정확하게 현재 내가 어디에 있는지 파악할 수 있도록하고 관련 TASK는 "성과평과 계획 및 결과 보고서"라는 Wiki에 그때 그때 Milestone에 따른 합의를 하였다.

합의과정을 통해 우리가 어느 시점에 있는지 자연스럽게 고객과 개발팀원이 인식할 수 있게 되었고 업무의 산출물을 작성할때도 작성이 완료된 팀원은 일찍 퇴근시키는 정책을 사용했다.
결과적으로 어떻게 해서든 일찍 퇴근하려는 팀원들이 하나둘씩 나타나며 업무의 진척은 빠른속도로 진행되었다.

회고해보면 빨리 자신의 업무를 마치는 팀원들의 업무방식은 이런식이었다.

1. 오전에 출근하자마자 불타는 모드로 돌입 (후에 물어보니 버스타고 오는 시간에 오늘 무슨일을 해야할지 그려본다고 하였다.)
2. 기본 템플릿 작성 및 초안 작성 오전중에 완료
3. 점심먹고 관련 약 30분간의 짧은 회의 소집 (담당자에게는 그에 합당하는 권한을 부여하는 것이 중요)
4. 프로젝터로 자신이 한 초안에 대한 Review 및 다른 사람의 아이디어, 결함 발견
5. inspection 회의록 작성후 자신이 작성한 문서 완료보고
6. 오후 2시 ~ 3시 퇴근

이런 식의 업무에 팀원들이 하나둘씩 1주~2주 사이에 나타나자 그들을 중심으로 2명~3명 단위로 묶어서 그룹별로 과제를 부여하였다.
그룹별로 업무를 부여 받은 사람들은 더 일찍 퇴근하는 방법에 대해 따른다. (이미 그런 방법으로 일찍 퇴근하는 선구자들에 대해 존경심이 충만해진 상태)
물론 처음에는 나이, 경력 등을 들거나 의견이 달라 퇴근 시간이 늦어지는 경향이 있지만 그룹별 퇴근 일찍하기 경쟁이 붙기 시작하면 서로 산출물을 빨리 내놓고 사라졌다.
(물론 이 순간에도 야근하는 그룹은 생기기 마련)

그때 부터는 프로젝트 진척이 굉장히 빨리 이루어진다. 내일 빨리 퇴근하기위해 오늘 일을 다 해버리는 경우도 생기도 했었다.



2009/08/28 22:39 2009/08/28 22:39