조엘따라하기 #3

조엘따라하기 #3

이 번글이 조엘따라하기의 마지막이 될 것 같습니다.

지난 #1번 글에서는 일정관리의 필요성에 대해서 설명을 드렸고, 2번 글에서는 일정관리의 방법에 대하여 말씀을 드렸고 , 오늘은 마지막으로 지난글에서 설명드린 Time_Table을 사용하게 되면 어떤 장점들이 있는 지 설명을 해보겠습니다.

관리라는 것은 아주 일반적으로 말씀드려서 안정된 상태에 대하여 어떤 변화를 주기 위한 또는 그러한 변화에 대한 대응 방안을 마련하는 것이라고 할 수 있습니다.

전략 경영에서는 이렇게 정의 하더군요. Operation 을 Strategy 에 맞추는 모든 활동이 Management.

관리자는 지각 체크하는 사람이 아니란 것이죠. ^^;

Time_Table은 프로젝트 일정에는 많은 변수가 있으므로 이러한 변수들을 한번에 모아서 총량 개념으로 관리하는 것이라고 할 수 있는데 Time_Table을 이용하면 프로젝트 일정은 최초 예측치로부터 정해집니다.

처음에는 이 최초 예측치는 현재 예측치와 동일하지만 몇가지 단계를 진행하게 되면 이 최초 예측치와는 다른 현재 예측치가 나타나게 됩니다. 즉 변화가 발생하는 것이지요. 이럴 때 Time_Table을 이용하면 첫번째 장점인 "정확한" 관리가 가능합니다.

예를 들겠습니다.

분석 단계가 완료되었는데 몇가지 이유로 3주의 기간이 더 들어간 상태로 완료가 되었습니다. 즉 SRS ( Software Requirement Spec. ) 작성이 최초 예측 일정보다 현재 예측 일정이 3주가 많아 졌다는 것입니다. PM은 어떻게 해야 될까요.

대부분의 PM이라면 분석 단계에서 3주가 지연된 상태라면 직감적으로 일정에 대한 어떤 변화가 올 지는 알게 될 것입니다.

하지만 이 단계에서는 직감의 수준이지 대안을 마련할 수 있는 정량화가 어렵습니다. 그래서 그냥 다음 단계로 넘어가서 보자는 경우도 생기게 됩니다. 하지만 이렇게 되면 초기에 간단히 해결 할 수 있는 문제를 발견하지 못하고 일을 크게 키우는 경우가 발생 할 수 있습니다. 역설적으로 PM이

리스크를 키우게 되는 셈입니다.

Time_Table의 경우는 어떻게 하나요,

먼저 분석 단계에 대한 결과가 다음 단계들에 어떠한 영향을 미치는 지 Table을 이용하여 파악합니다.

분석 이후의 설계 단계가 늘어날 수 도 있고 , 구현 단계가 줄어들 수도 있습니다. 개발자, PM이 모여 현재 시점에서 향후의 예측치를 모두 업데이트 해야 합니다. 그리고 다시 현재 예측치에 기반한 일정을 산출합니다. 이 일정이 프로젝트 일정과 어떻게 되는 지 비교를 합니다.

결과에 따라서 3주의 지연이 발생 할 수 도 있고, 아니면 더 길어 질 수 도 있습니다. 그렇지 않으면 분석기간은 늘었지만 다른 기간이 줄어들어 일정이 줄어 들 수도 있습니다.

만일 이번 경우의 예에서처럼 3주의 분석기간 지연 후에 다시 예측을 해보니 설계에서 4주, 구현에서 2주의 추가적인 지연이 예상되었습니다. 다른 조치가 없다면 전체 일정이 3 + 4 + 2 = 11 주의 전체 일정 지연이 예상된다는 것입니다. 프로젝트 관계자들이 모여 대책을 위한 협의를 진행해야 합니다.

설계 이후의 단계에서 개발자를 늘리는 방법등이 고려 될 것입니다. ( 이 부분은 "설계를 고정하여 변수를 줄여라" 편을 참조해 주시기 바랍니다. )

여기서 보시면 "현재 상태로는 11주 지연예상 , 일정 준수를 위해서는 개발자 00명이 어떻게 지원 되어야 한다"는 내용이 있습니다.

이러한 내용을 가지고 대책을 세우는 것과 직감적으로 대처하는 것은 시간이 지날 수록 비교 할 수 없는 차이가 나게 됩니다.

두번째 장점으로는 개발의 효율성을 높일 수 있습니다. 어찌 보면 이 장점이 가장 중요한 점일 수도 있겠습니다.

개발자간의 업무처리 속도 차이는 분명히 있는 것 같습니다. 어떤 자료를 보면 20배 까지도 된다 라고도 하는데 무슨 기준인지는 잘 알 지 못하겠습니다. 다만 이런 속도의 차이는 무시하고 최초 업무 배분을 고집하게 되면 전체적인 효율이 떨어지게 됩니다.

프로젝트 진행중에 Time_Table 상에서 속도가 나는 개발자를 확인해 볼 수 있는데 , 이런 경우 현재의 속도를 기준으로 현재 예측치를 다시 업데이트 해 줍니다. 그리고 남은 시간을 이용하여 Critical Patrh 상의 다른 업무을 지정하여 맡길 수가 있을 것입니다.

단, 이런 것이 가능하기 위해서는 반드시 개발자간의 업무 연관성이 없도록 업무를 배분 할 필요가 있고 이를 위해서는 프래임워크 적용과 같은 SW 개발상의 테크닉을 적용 할 필요가 있습니다.

세번째는 프로젝트 진행중과 후에 개발자의 평가에 활용 할 수 있다는 점입니다.

프로젝트가 잘못 되어도 원인을 제대로 찾지 못하거나 엉뚱한 이유를 찾으려는 경우가 허다한데 , 인사관리의 관점에서 보면 실무적으로 중요한 점이 아닐 수 없습니다.

Time_Table을 이용하면 프로젝트 중간에 개발자간의 업무처리 상태를 확인 할 수 있습니다. 지속적으로 잘해내는 사람이 있는가 하면 들쭉날쭉하는 경우도 있고 기대에 미치지 못하는 경우도 있습니다.

이러한 개발자 평가는 프로젝트 종료 후에 최종적으로 산출하여 다음 프로젝트에 반영 할 수도 있고 개인 평가에 활용할 수 도 있을 것입니다.

관리측면에서 본다면 이러한 객관적인 사실 기준의 평가가 개발자들이 느끼기에도 공정하다고 생각 할 것입니다. 평가가 주관적이라면 이에 불만을 가지게 될 것이고 향후 프로젝트에 마이너스 요인이 될 가능성이 많기 때문입니다.

평가에 활용 될 수 있는 지표는 조직에 맞게 개발이 필요한데 , 예를들면 Time_Table상의 마일스톤 준수율과 일정 준수율 될 수 있을 것이고 , 계획대비 ( 최초예측치 ) 수행업무의 양도 성과 평가의 좋은 지표가 될 것으로 보입니다.

이상으로 "조엘따라하기" 편을 모두 마치도록 하겠습니다.

SW 개발 프로젝트 관리자는 프로젝트 변화 요인들에 대한 향후 대책을 세울 수 있어야 한다.