프로젝트에서 개발자가 할 일 : 분석/설계

프로젝트에서 개발자가 할 일 : 분석/설계

 

프로젝트 규모에 따라 컨설팅 단계가 있는 프로젝트도 있고, 바로 분석/설계단계로 들어가는 프로젝트가 있습니다. 컨설팅 단계가 있다 하더라도 개발자와는 좀 먼~ 이야기 이므로, 생략하도록 하겠습니다.

 

예전에는 명확히 '설계자'라는 Role이 존재하였으나, 요즘은 수행사에서 경계를 모호히하여 진행을 하고 있습니다. (여러가지로 마음에 안듭니다.) 역량이 안되는 개발자에게 맡기기도 하고, 제대로된 대우를 해주지 않고 막무가내로 일을 시키기도 합니다. 이부분은 스킵...

 

설계자로 합류했던 개발자로 합류했던.. 현실은 둘다 해야 하는 상황입니다. 그러므로 굳이 두 Role을 구분하지는 않도록 하겠습니다.

 

분석/설계단계의 주요 역활은 "As-Is 시스템에 대한 분석과 업무요건을 적용하기 위한 설계"를 하는 단계입니다. 그런데, 이 기간에 찍어야내야 하는 산출물이 너~무나도 많습니다. 개발을 위한 분석이 아니라 산출물을 위한 분석을 하면 대~충 기간이 다 지나갑니다.

 

설계자가 이 기간동안 가장 주의깊게 확인할 부분은 1) 개발 가능 여부와 2) 타팀(업무)와의 연관관계, 즉 영향도 분석 및 사전 협의입니다. 여러 이유로 개발에 어려움이 있는 요구사항이라면 이 시점에 고객과 협의하여 요구사항을 일부 변경하거나 구현 가능한 형태(범위)로 조정해야 합니다. 시간이 지날수록 변경이 어렵거나 변경시 관계가 악화될 수 있습니다. 그리고, 업무협조나 지원이 필요한 유관부서가 있다면, 사전에 내용을 전달하고 협조요청을 해 둬야 합니다. 서로 바쁜 사람들이다보니 닥쳐서 일을 처리하려면 많은 어려움이 있습니다. 미리미리 주기적인 연락과 협의가 필요합니다.

 

개발자는 개발할 시스템 환경을 빠르게 적응해야 합니다. 현재 프로세스를 이해하고, 개발 표준을 숙지해야 하며 개발할 주요 업무를 시뮬레이션 해봐야 합니다. 또한 기술적 이슈나 협업이 필요한 업무들은 사전 기술검토 및 일정에 대한 체크로 해야합니다. 설계자 또는 관리자가 '시키는데로만 하면 되지' 라고 수동적인 입장은 어려 이슈를 만들 수 있습니다. 많은 개발자들이 이 부분에 있어 상당히 수동적이고 스스로 개발자가 아닌 코더이기를 자처합니다. 하물며 경력이 10년이상인 고급개발자들도 동일한 생각과 태도를 취합니다.  스스로가 개발자임을 자각하고 좀 더 프로페셔널한 생각과 자세를 취한다면 프로젝트도 본인에게도 좀 더 좋은 결과가 있을 것 같습니다.

 

끝으로, 분석/설계단계가 끝나기 전.. 개발을 들어가기 전에 개발에 대한 환경 및 사전 교육이 이뤄져야 합니다. 신시스템의 경우, 이 기간에 선도개발도 완료되어야 합니다. 개발 단계에 들어가서 준비하면 기본적으로 1~2개월을 방황하게 되고, 뒤늦은 표준적용 및 개발가이드로 리웤이 많아집니다. 이는 퀄리티의 저하를 가져오는 주요 원인이 됩니다.

 

개발자도 이 기간에는 (본인들이 개발해야 할 환경이므로)적극적인 자세로 참여해줘야 합니다. 관리자나 설계자에게만 맡기면 표준이 산으로 가는 경우도 많이 있습니다. 개발하며 계속 뜯어 고쳐야 하는 문제들이 야기됩니다. 시스템적인 환경으로 디테일한 부분이 표준을 적용하기 어려운 부분도 많고 예외사항도 많기 때문입니다. 무엇보다 개발의 효율을 고려하지 않고 개발 후의 관리의 효율에 너무 편향되어 개발 공수를 상당히 늘리는 경우들을 보게 됩니다.

 

분석/설계단계는 개발자가 할 일(내 일)이 아니다. 라고 생각하는 개발자들에게 전하고 싶은 말은 어찌됐던 이 단계에 돈을 받고 일을하기 위해 프로젝트에 참여했으니 밥값은 하자! 라는 말씀드리고 싶습니다. 또한 수행사도 Role에 맞는 사람을 채용하기 일에 대한 합당한 대우를 해줘야 합니다. 엄연히 Role과 몸값이 다름에도 개발자를 뽑고 설계/관리까지 모두 다 시키려는 행태를 너무 자주 접하게 됩니다.

 

The End