일정계획 수립
프로젝트를 하면
WBS( Work Break-down Structure )를 기반으로
각 단계별로 개발자는 일정을 수립하게 된다.
분석/설계 단계에서는 WBS상 Task를 중심으로 진행하므로
디테일한 일정을 수립하지는 않지만
개발단계 이후부터는 일별 일정을 계획 및 관리한다.
이 일정을 기준으로 성과 및 진척률을 측정하는 것이다.
설계 단계에서 개발할 대상 모수를 산정하고
각 담당자별 개발일정 계획을 수립한다.
모수가 많은 경우 일별 일정을, 모수가 많지 않을 경우 주별 일정을 잡는다.
( 적은 경우는 많지 않으므로, 대부분 일별 일정 수립 - 주별은 주간보고 기준 )
현재 하고 있는 프로젝트가 통합테스트 1차를 진행하고 있다.
고객사에서 테스트에 합류하면서, 결함 및 결함을 가장한 개선사항과
있으면 안되는 추가 요건들이 나오기 시작했다. ( 항상 어디나 이렇다.. )
통합테스트를 하는건지 요구사항을 받아 개발을 하는건지...
WBS상 Task가 무의미할 때가 종종 있다. 현재도 그렇다.
옆에 특급이면서 수행사 직원인 개발자분이 있다.
결함과 (편의성을 위한) 개선 요건들이 주루룩 나왔다.
갯수로는 쫌 많은데..( 한 20개 정도? )
잘은 모르지만, 대충보니 2~3일정도면 해결 될 듯 해 보였다.
그런데, 담당자가 쉽지 않다고 하니 PM이 일정계획을 수립해 보라고 했다.
1. 통테기간 내 할 수 있는 것과
2. 오픈 후 안정화 기간에 할 수 있는 것
3. 철수 후 IT부서에 인계하고 갈 것을 정의하고
각각의 예정일 등의 일정계획을 수립해서 달라고 했다.
고객사에서도 일정확인을 위해 요청했는데...
담당 개발자가 일정을 못 짠다.
본인이 다 개발한 것인데...
간단히 화면 Layout 위치를 바꾸는것도
'해봐서 안될지도 모르고... 한번에 대면 좋은데...'
'개발된 거 확인도 해야되고, 영향도도 봐야 하고...'
....
여러가지로 말을 돌리며, 일정 수립을 안한다.
PM이 금일 오후에 보고를 해야 하니, 생각하는 일정을 수립해 달라고 해도
'될지 않될지 모르겠다'는 식이다.
그런데, 정말! 어려운 개발건도 없다.
쉽게는 글자 문구를 바꾸는 것, 화면에 보이는 부분을 감추는 것,
그리드 항목을 유동적으로 Hidden 시키는 것, 위치를 변경하는 것
조회조건 항목 하나 추가하는 것 등 이다. ( 결함은 고쳐야 하는 거고.. )
그나마 반나절 정도 걸리겠다 싶었던 건...
다른 화면의 (이것도 본인이 개발한) 그리드의 항목 일부를
현재 화면의 Grid에 붙여서 정보를 보여 달라는 내용이었다.
쿼리에서 해당 테이블 Join해서 조회하고, I/O 추가해서 화면 적용하면 된다.
본인이 개발한 화면의 정보이니 분석도 필요 없고, 반나절이면 충분할 듯 하다.
( 거래 하나 만드는데, 분석/설계가 필요없으면 2~3시간이면 된다. )
공수는 차치하고라도 자신이 생각한 일정은 수립해야할 텐데...
나름 20년 넘게 개발한 특급개발자가 일정을 처음 수립해보는 것도 아닌데..
답답하다... 너프하게라도 잡았으면, 이래저래 그런가보다 하고 넘어가는데
일정 자체 수립을 못하겠다고 말하고, 끝까지 어물쩍거리며 버티는 이유는 뭔지..
새삼 내가 PM이 아니고, 우리팀 개발자가 아니라서 다행이다.
그랬다면... 한 바탕 싸우지 않았을까? ㅋ
최소한 다른 사람한테 피해는 주지말고...
밥값은 좀 하면서 살았으면 좋겠다.ㅋ
끝.
'프로젝트 > 프로젝트 일지' 카테고리의 다른 글
[잡설] 심리의 벽 (1) | 2024.10.25 |
---|---|
[잡설] 시장 경제 : 공급과 수요의 법칙 (0) | 2024.01.19 |
오라클 통계정보를 아시나요? (0) | 2023.12.13 |
사육 (0) | 2023.07.31 |
[Q&A] <작성중> 웹 환경에서 파일의 유형 체크하려면...? (0) | 2022.08.17 |