[Essay][Review] Epilogue of the first SW project led by me.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

+++ 내가 Lead했던 첫번째 SW Project가 끝났다... 이 경험을 보존하기 위해 Review를 적어본다. +++

Project인원 : 나를 포함해서 3명
프로젝트 기간 : 약 4개월..
규모 : 한 10,000 라인 정도 되나??

내 관점에서 보기에, 다른 두명의 Programming능력 수준은 기대 이하였다.(아니면, 나 자신이 그들의 능력을 보지 못할 정도로 미숙했을 수도...)
Programming 경험이 많지 않은 사람과 같이 일하면서 크게 문제가 되었던 점들은 아래와 같았다.

+ 기본적으로... Code의 Stability가 떨어진다. (많은 Bug를 내포하고 있다. 일정이 짧아서 그럴수도 있지만, 일단 돌아가는 코드만 만들고 Program의 구조는 신경쓰지 않는다.)

+ SW design의 중요성을 전혀 인식하지 못한다. (이게 가장 큰 문제다!!!) SW design의 중요성을 모르고, 상호간 Interface간 정의의 중요성을 모르기 때문에, 여기에 큰 관심을 기울이지 않는다. 아무리 이게 중요하다고 이야기해도 전혀 반응하지 않는다.(소 귀에 경읽기??) 이번 프로젝트의 경우, Interface에 대한 communication을 초반에 상당히 강조했음에도, 결국 Integration단계에서, 그들이 전혀 Interface의 중요성을 인지하지 못했고 또, 관심조차 기울이지 않았음을 알게 되었다. 그들은 자신의 module과 연결될 다른 모듈의 동작 방식으로, 모듈 작성자와 communication하지 않고, 자기 나름대로 상상해서 API를 정했다. 결국 Integration단계에서, 문제가 발생했다..

+ Code re-factoring을 하지 않는다.... 내 개인적인 생각으로는, 그들은 자신이 짠 코드를 버릴 줄 모른다. 첫번째 짠 코드보다는 두번째 짠 코드의 질이 좋을 수 밖에 없다. 그리고 필요한 경우, 첫번째 짠 코드의 전체를 버릴 수도 있어야 한다. 그런데, 어설픈 구조로 짠 코드를 벗어나지 못해, bug를 양산할 가능성이 있는 불안한 코드에 땜질하는 형태로 project를 진행시키고 있고, 그게 Project를 빨리 그리고, 완성도 높게 끝낼수 있는 길이라고 생각한다. 이는 결국, SW design을 모르는 것과 어찌보면 그 맥을 가치하는데 - 보통 re-factoring은 design이 좋지 않은 경우 수행되어 진다. - 자신의 코드의 design이 좋지 않다는 사실을 인지하지 못하므로, re-factoring을 해야한다는 사실 자체를 모른다.

그럼 이런 경우 어떻게 이를 극복해야 하는가?
궁극적으로는 같이 일하는 사람의 능력을 향상시키는 것이 가장 중요하겠지만, 당장 일을하기 위해서는 결국 SW design과 Interface, API등을 모두 정의한 상태에서 상당한 수준까지 design을 구체화 한다음, 나머지 부분을 채워 넣으라는 방식으로 일을 할당했다.
(결국 이렇게라도 일을 시켜야, 생산성을 이끌어 낼 수 있었다.)

반성
+ 사람마다 능력과 경험이 다르고 일하는 방식이 다르다. "내가 아는 것은 다른 사람도 알 것이다."라는 전제 자체가 잘못 되었으므로, co-work에 어려움이 있었다. 사람들간의 차이를 알고, 상황에 맞게 생산성을 이끌어낼 수 있는 방법을 찾는 노력을 기울이지 않았다.