첫발도 떼지 못하는 애자일 그 멀고도 험한길

최근 프로젝트 관리에 아주 조금씩 관심이 생기면서

내가 진행하는 업무 방식에 심각한 문제가 있슴을 감지하였다

그리고 흔히 그려보는 프로젝트 계획(WBS)에서 가장 중요한 것은 일정이라는 점을 알게 되었다

 

일정에 대해 생각하고 다른 사람의 포스팅을 통해 다음과 같은 일반적인 WBS에 내가 생각지 못한 부분이 많다는 것을 알게 되었다
이하의 링크와 내용은 작성하신 분의 허락없이 긁어왔다 

http://www.wolfpack.pe.kr/352?category=1

+ 요구분석 (총 10일 / 2주)
   +- 1차인터뷰 2일
   +- 1차요구정리 1일
   +- 2차인터뷰 2일
   +- 2차요구정리 1일
   +- 요구사항명세서작업 1일
   +- 요구사항정의서작업 1일
   +- 요구사항분석발표 1일
+ 설계 (총 10일 / 2주)
   +- 프로세스정의서 1일
   +- 프로세스명세서 1일
   +- 인터페이스정의 1일
   +- CRUD정의서 2일
   +- Entity정의서 2일
   +- 테이블정의서 2일
   +- DB정의서/명세서 1일
   +- 화면설계서 10일 (병행)
+ 개발 (총 20일 / 4주)
   +- 열심히 개발 20일
   +- 단위테스트 20일 (병행)
+ 통합 (총 2일)
   +- 알파오픈
+ 테스트 (총 10일 / 2주)
   +- 통합시험/성능시험 3일
   +- 통합시험/성능시험개선 2일
   +- 인수시험 5일
   +- 인수시험개선 5일 (인수시험병행)
+ 전환 (총 3일)
   +- 상용데이터전환 2일
   +- 상용오픈/비상대기 1일
+기타
   +- 주간보고 1주마다 1회
   +- 월간보고 매월말 1회

이 WBS에서 놓치고 있는 부분은 다음과 같다

1. 개발팀원간의 목표공유 (주간/월간회의만 가지고 될까?)
2. 고객과의 목표공유 (주간/월간보고만으로 가능할까?)
3. 재작업시간은 어디에?
4. 매뉴얼 작업 등의 문서작업은 언제하나요?
5. 고객에게 넘기기전에 개발팀원들끼리 리뷰하는 시간은 어디에?
6. 테스트 결과에 따른 품질완성도를 100%에 가깝다고 보고 있다.
7. 결정적으로 의사결정 시간이 없다!!!
8. 기타 등등등한 잔업들은 어디에?
--> 결국 밤새도 안되는 이상한 일정이 되고 만다.

이것은 제대로 된 일정을 산출해 내는 방법을 찾지 못해서 발생한 오류였었다 (위기 관리 프로세스가 필요한 이유라고나 할까... 정말 위험 천만한 상황이 매일 발생한다)

다음으로 너무나 자세한 일정을 계획하다보니 생기는 오류다
TASK 위주의 업무 진행은 스스로 지키지 못하면 결과물이 나오지 않는 것이었다

게다가 동시진행 하는 일이 빈번할 수 밖에 없는데 이에 대한 일정 산출은 부정확 할 수 밖에 없었다
결국 TASK 를 뭉뚱그려 하나의 결과물(Product) 로 만들어 내는게 더 효율적인 계획이라는 걸 짐작케 하는 포스팅을 읽게 되었다

http://www.wolfpack.pe.kr/363?category=1

-이전 생략-
*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
-이하 생략-

* Product위주의 Milestone
2009. 5. 10 사무실 설정/개발서버기동/개발방법 교육
2009. 5. 20 요구사항분석용 Prototype제출
2009. 5. 24 요구분석설계용 USE CASE제출
-이하 생략-

그리고 Product 위주로 계획했을때 이 Product를 만들어내기 위해 스스로 또는 팀원 각자가 자신의 일정을 관리하는 변화된 방식

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

그리고 다음으로 이에 대한 생각을 확장하고 있는데

이건 아마도 내가 생각하고 고민해야 할 게 아니라 팀장님이 생각해 보셔야 할 문제인 듯 싶다

팀원들 각자의 역량이 모두 다르고 업무 스타일도 다르고 성격도 다르고 심지어 음식 취향도 다르다

이들을 데리고 일을 할 때 가장 중요한 것은 서로 다른 팀원들이 자신의 역량을 100% 발휘할 수 있게 세심하게 살펴봐주는 일이다

어떻게?

그건 그때 그때 다르므로 그래서 고민해야 할 부분이다

관련된 포스팅은 다음과 같다

http://www.wolfpack.pe.kr/399?category=1

첫째, 프로젝트 투입 초반 2주 정도 본 프로젝트 이전에 프로토 타잎을 만들면서 팀원을 관찰하고 머리속에 정리하라. (이때 반드시 주의할 점은 누구누구를 비교하지 말고 어떤 기대치없이 접근해야 한다는 것이다.)
둘째, Pair로 사수, 부사수 개념으로 그룹핑하고 사수에게 업무를 할당해보자.
셋째, 이렇게 만들어진 팀이 무너지지 않도록 지속적인 관심과 감사, 그리고 감정코치해보자.
넷째, 마지막으로 해야 할 일은 매일 잠자기전 오늘 있었던 팀원들과의 일을 회상해보자.

 

혼자 일할 때와 함께 일할 때의 가장 큰 차이점은 같이 일 할 사람이 항상 바뀐다는 것이다

그래서 위의 분석적인 추론과 더불어 그냥 단순한 마인드로 다시 정리해 보면

첫술에 배부를 수 없다

경험의 가치를 제대로 알아야 한다

그리고 이전에 경험했던 프로젝트의 수순대로 현재 프로젝트가 진행될거란 생각을 버려야 한다