1. 프로젝트가
서쪽으로 간 까닭은
아꿈사 박종석

2. 12. 시스템 개발 레밍 주기
프로세스를 도입하고, 프로세스에서 하라고 하는 대로 맹목적으로 따른다.

3. 프로세스는 자기 조직에 맞게
변경해서 사용해야 한다.
• CMMI, SPICE, ISO9000, V-모델, RUP 등
– 팀에 필요한 역할과 구성원, 팀이 수행할
활동, 팀이 생성할 결과물을 미리 지정
– 많은 프로세스 모델들이 따라야 할 표준을
제시하면서, 각 조직에 맞도록 조율해서
사용하라고 한다

4. 각 조직이 어떤 점에서 다른가요?
• 조직 구성
• 프로젝트 종류
• 회사 분위기
• 구성원들의 특성
• 등등..

5. 하지만, 그냥 표준대로 사용한다
왜?
• 괜히 나서서 비난의 표적이 될 필요 없다
– 표준에서 제시하는 단계를 제거하게 되는 경우
프로젝트 실패의 화살이 나에게 돌아온다
–  시도와 실패를 용인해 주는 문화가 있다면..
• 바빠 죽겠어서 조율할 시간도 없다
–  프로세스가 제대로 되어 있지 않으니 바쁘고 바쁘니
프로세스를 조율 할 시간도 없다

6. 하지만, 그냥 표준대로 사용한다
또.. 왜?
• 어떻게 바꿀지 잘 모르겠다
• 단지 대외용으로 CMMI 레벨을 따는 것이
목적이다
–  이런 경우 어쩔 수 없다. 걍 나오는 게 답

7. 19. 영화 평론가
• 마치 영화 평론가 같은 팀원이 있다
– 아무 조치도 취할 수가 없는 시기에 프로젝트의
잘못에 대해서 비판을 가한다
– 프로젝트에 대한 책임감이 없다
– 그러면서 자기는 예리한 관찰자로 보여지고
있다는 것에 만족감을 갖는다
– 프로젝트는 망해도 자신은 괜찮다고 생각한다
• 자신의 예리한 관찰로 프로젝트의 실패를
예견하였으므로.. 즉, 자신은 능력자이므로

8. 프로젝트 비평가 vs 영화 평론가
• 프로젝트의 성공에 기여하는 비평인지
여부에 달려 있다
• 프로젝트 비평가 반드시 필요하다
– 프로젝트가 잘못된 방향으로 가는 것을 감지
– 프로젝트 성공에 기여

9. 목표 분리 패턴
• 프로젝트 구성원들이, 프로젝트의 성공이
아닌 자기들만의 목표를 가진 경우
나타난다
– 그들은 프로젝트의 성공과 관계없이 그들의
목표를 달성할 수 있다
– 이런 프로젝트가 과연…

10. 영화 평론가가 하는 말이 옳다면?
• 프로젝트 중에는 이런 행위를 용인해서는
안 된다
– 영화 제작자가 아닌 평론가를 늘린다
• 프로젝트가 종료된 이후에는 고려할 가치가
있다
– 그렇다고 이들에게 좋은 평가를 주라는 것은
아니다
– 그들은 프로젝트 성공 여부에 따라 평가되어야
한다

11. 22. 소비에트 스타일
• 고객이 요구하는 모든 기능을 넣었지만
• 고객이 싫어해서 망한다

12. 디퍼런스
• 제품의 경쟁이 치열할 수록 모두가 같은
기능을 가지게 된다
• 고객이 요구하는 기능은 결국, 다른 제품..
경쟁사에서 보던 기능
• 모두가 가진 기능을 삭제하면서, 새로운
가치를 제시하거나, 특정 부분을
부각시킨다면 차별화에 성공

13. 기능보다 비 기능이 더 매혹적이다
• 많은 기능을 제공하면 고객들이 좋아할
것이다?
– 제품 구매에는 이성보다 감정에 더 많이
좌우된다
• 걍 맘에 들어서 샀어!
• 비 기능?
– 매력적인 모양새, 사용하기 쉬운
디자인, 용량, 배터리 수명, 작은 크기

14. 비 기능 요구사항을 잡아내는 법?
• 어렵지 않아요
– 주요 서비스 품질을 하나씩 짚어주는 템플릿이
이미 존재한다

15. 비 기능 요구사항은 처음부터 고려
되야 한다
• 프로젝트 초반부터 프로토타입을 활용한
피드백을 얻어라

16. 36. 사이다 하우스 규칙
1. 술을 마셨다면 분쇄기나 압착기는
운전하지 마시오
2. 침대에서 담배를 피우거나 양초를
사용하지 마시오
3. 술을 마셨다면 지붕에 올라가지
마시오. 특히 밤에 조심하시오
4. 지붕에 올라 갈 때 술을 가져가지
마시오

17. 규칙은 깨라고 있는 거야
• 사이다 하우스에 살지도 않는 사람이 만든
규칙 따위
• 지붕에서의 한잔은 일꾼들의 일상이다
• 비 현실적인 규칙은 무시

18. 사이다 하우스 규칙을 정하는 조직
• 프로세스 개선 그룹, 표준 제정 그룹, 품질
부서 등이 업무 프로세스를 정한다
– 그들은 실제로 그 방식대로 일하는 사람들이
아니다
– 종종 이론에만 치우치고, 현실을 고려하지
못한다
– 완벽한 프로세스를 만드는 것이 목적
• 모든 가능성에 대해 철저히 대응하는 프로세스
• 업무를 수행하는 사람들을 고려하지 않는다
– 귀찮아!!!

19. 프로세스를 제안자가 같은
프로젝트의 팀원인 경우 가장 좋다
• 아니면, 적어도…

20. 45.뉴스 세탁
• 팀 리더
– 1월까지는 불가능 합니다.
• 프로젝트 관리자
– 1월까지는 조금 무리입니다.
• 상위 프로그램 관리자
– 1월까지는 다소 어렵지만….
• CIO
– 1월까지 충분합니다.

21. 나쁜 소식은 위로 갈 수록 없어진다
• 실제 일하는 사람들은 문제를 가장 잘 안다
• 윗 선으로 보고가 올라가는 과정에서
문제가 걸러져서 없어진다

22. 경악
• 막판에 보고를 받는 관리자는 경악한다
– 어제까지는 문제 없다면서!!!

23. 어쩌다 저렇게 까지…
• 두려움
– 관리자는 나쁜 소식에 혐오감을 가진다
– 관리자는 나쁜 소식을 전하는 사람에게도
혐오감을 가진다
• 불가능하다고 어떻게 확신하죠?
– 괜히 투덜이나 겁쟁이로 보일까봐, 문제가
명확해 질 때까지 가만히 있는다

24. 해결책
• 나쁜 소식은 즉시 알려달라고 관리자가
공언
• 나쁜 소식을 들었을 때
– 팀 전체를 격려하고 복구 계획을 세우고
추진한다
• 이러한 태도는 조직의 분위기를 결정한다
– 복구된 이후에는 문제의 원인을 파악한다