Tag Archives: 회고(回顧)

회고(回顧)

회고(回顧)

 아이러니하게도 현재가 ‘구현’ 단계임에도 불구하고, 업무에 대하여 내가 알고 있는 것은 상식 + 약 20%의 정보다. 내 미비한 경력(대학 제외 10년)의 노파심으로는 이 정도의 정보(data 아님)를 토대로 하여 program을 ‘구현’을 한다는 것은 꽤나 위험도가 크다고 생각한다. 나만의 杞憂일까?

 이에 대한 회사의 임시방편이 AS-IS source 분석이다. 업무를 거의 모르는 상황에서 source code 분석을 통하여, 逆으로 업무를 분석하고 있다. 이 정도만으로도 program이 원활히 돌아갈까? 개발 완료가 1달 반 남은 상황에서?

 잠시 대학 수업 또는 정보처리기사를 취득했던 당시로 회귀해보자.
‘분석’ 단계에서는 고객과의 ‘인터뷰’, ‘현황분석(AS-IS)’을 통하여 ‘요구사항정의’를 도출하고, 이를 토대로 ‘업무기능분해’, ‘인터페이스정의’ 그리고 ‘프로세스 목록’과 ‘프로세스 정의서’를 생산한다. 그 후, ‘설계’ 단계에서 ‘프로그램 목록’, ‘프로그램 설계서’ 또는 ‘화면 설계서’, ‘인터페이스 설계서’를 작성… 어쩌고 저쩌고. 너무 고지식하고 원론적일까? 그렇다고 완벽하게 하자는 게 아니다. 약 60% 정도는 되야 하는 게 아닐까 하는 것이다. から가 아니고. Agile 하자는 것도 아니고.

 짧은 소견으로는 업무를 파트별로 분할하여 각각의 개발자들에게 업무 분장 후, ‘분석/설계/구현/전개’의 일련의 과정을 일임해야 한다고 생각한다. 이점은 각 단계를 거치면서 담당자들이 업무에 대한 이해도가 높아지고, 이것은 고객이 원하는 바에 program을 근접시켜, 결과적으로 project의 위험도를 낮춘다는데 있다(더군다나 현 project는 고객이 요구사항을 뒤집을 가능성이 희박하다. 그냥 AS-IS 잘 파악해서 구현하면 되는 것이다!).

 허나 이것이 여의치 않다면, 또는 마음에 들지 않는다면(생각은 다양함으로), 애초에 기획자/설계자가 업무를 ‘분석/설계’하여, 이것을 토대로 개발자들이 program을 ‘구현’ 해야 한다고 생각한다. 지금처럼 ‘구현’ 단계에서 ‘분석/설계’와 ‘구현’의 합체(?)를 시도한다는 건 너무나 위험한 발상이 아닐까? 이에 더해 ‘프로그램 설계서’까지 개발자에게 맡기려고 한다니. 이건 또 무엇일까? :P 그럼 아에 초반부터 파트별로 업무를 분장 할 것이지!

누구를 헐뜯고 욕하자는 게 아니다.

다만, 상황이 이렇게 되었으니 teamwork 깨트리지 말고 그냥 좀 해라.
이건 아니라는 것이다. 반성 없는 진행은 또 이와 같은 결과를 나을 뿐이다.

언젠가 이모든 경험이 도움이 될 것이라고 자위 해본다. :(

お終い。