Responsibility #2 : Estimation of Schedules

CTO가 할일 이전에 TD가 할일을 더 이야기 하고자 한다.



TD가 할 일중에 하나는, 기획의 요구사항을 듣고,그것을 'make it done'하기 위해서,

계획을 잡는 일일 것이다.



우선순위는 기획의 요구사항을 따르되,

개발의 우선순위는 다를 수 있다.

왜냐하면, 업무를 분해(decomposition)하다보면, dependent task들을 미리 해 놓아야 하기 때문이다.

그런 일들에는 library 구축, tool 구축, framework 구축등이 포함될 수 있다.

아무리 TDD에 Agile한 환경이 효율적이라고 하지만, 먼저 해야 할일은 먼저 해야 할 일인 것이다.

이렇게 일을 늘여놓다보면, 목표 시간에 일정을 소화할 수 없게 된다.

여기서, 그러한 dependent task를 살펴보면, 그 TD의 성향을 파악할 수 있다.

1) 고집스럽게 선수 과제를 먼저 하는 사람

2) 선수 과제를 무시하고, 스케쥴을 밀어부치는 사람

3) 기획을 수정하여 일을 줄이는 사람

4) 기획의 의도를 파악하고 일을 줄이는 사람 

5) 필수 선수 과제를 최소화하여, 스케쥴을 다시 잡는 사람



6) 선수 과제를 부분적으로 외부에 의존하거나, 도입하는 사람

7) 100중에 70~80 정도를 소화하는 프레임워크 전체를 도입하는 사람





어떤 TD가 가장 유능한 사람일까?



1번의 경우, 매우 위험하다. 미션이 실패하면, 책임을 피할 수 없다. 하지만 성공할 경우에, 이후 달콤한 개발 속도가 약속될 수 있다. 그러나, 개발팀이 할 수 있는 능력이 될 경우에 할 수 있는 방법이라고 생각한다. 그렇지 않으면, 개발팀은 잦은 야근으로 조기에 지쳐버릴 수 있다. 오만과 교만의 댓가를 받게 될 수 있다.

2번의 경우, 어떻게든 되겠지 하는 경우이다.

하나님이 편들어지시지 않는한 매우 피곤한 여정이 기다리고 있을 것이다. 결과물이 잘 나오긴 하지만, 역시 개발팀의 수많은 삽질의 결과였을 가능성이 매우 높다. 이렇게 할 것이라면, TD가 왜 필요할까?

3번의 경우, 기획에 리스크를 떠 넘기는 경우이다.

기획자는 선택의 폭이 좁아진다. "해보고 안되면 내리지." 하는 방법을 쓸 수 없다. 유능한 기획자가 없는 한 매우 위험한 방법이다.

4번의 경우, 기획자와 긴밀한 유대관계가 필수이다.

게다가 기획 내용에 대한 파악 능력이 필요하다. 기획 의도를 지키면서, 개발 시간을 단축할 수만 있다면, 얼마나 좋겠는가? 하지만, 기획자는 다시 기획을 해야 할 것이다. 또한, 자칫 밋밋한 개발이 되어 소비자에게 어필할 수 없게 될 수 있다.

5,6,7번의 경우 어떻게 하느냐에 따라서 다르겠지만,

그 방향은 현재의 개발팀의 역량과 자신의 역량에 비추어 잘 선택하여야 할 것이다.

나는 5,6,7번을 모두 선택하는 편이다. 7번을 선택할 수 있는 상황은 게임개발에서는 많지 않다. 그리고 있다해도 50~60% 정도 커버하는 수준일 것이다. 그래도, 웹 개발에서는 많은 편이다. 다른 프레임워크를 선택하게 되면, 교육 기간과 적응기간이 꼭 필요할 것이다.



5,6,7번을 할 경우, 리스케쥴링은 다음과 같은 방법으로 해야 할 것이다.

처음에는 Goal Driven으로 Top-Down식으로 일을 분해하면서 일정을 만들었을 것이다.

이제는 Objective Due Day 를 기준으로 Task의 일정을 봐야 한다.

그렇게 되면, 첫 일정이 아마도 과거로 되어 있을 것이다.;;;;

과거에 했어야 할 일들을 어떻게 테스트가 된 상태로 프로젝트에 도입할까?

부분 부분 오픈소소를 이용하고, 과거에 했던 일들에서 가져오고, 어떤 것들을 나중에 하기로 하고 포기하고....

그래도 안되면 그때서야 기획자와 협의를 해야 할 것이다.

그래도 안되면, 야근을 할 수 밖에 없을 것이다. 외주를 줘서라도 일정을 소화시켜야 할 것이다.

이러한 상황이 팀내외에서 공유되는 것이 바람직하다. 리스크에 대해서 모두 알고 있는 편이 문제 해결에 도움이 된다.