프로젝트 M을 논하다 – 4. 프로젝트 M을 다시 한다면
목차
4. 프로세스 M을 다시 한다면
프로젝트 M을 다시 한다면
프로젝트는 쇼부1다
- 염진섭
일정과 인력과 예산이 절대적으로 부족한 프로젝트에 참여하도록 회사에서 강요한다면 할 수 있는 일은? 퇴사
처음부터 극단적으로 퇴사를 고려해선 안 되겠지만, 무리한 프로젝트에 참여하는 것은 결코 바람직한 일이 아니다. Trouble 프로젝트에 참여하면서 죽을 고생을 다했다는 사람을 흔히 보곤 한다. 아니 일상적으로 본다. 그리고 아주 가끔은 너무나도 과중한 스트레스로 자살을 했다는 소식도 접한다.(PDA의 효시격인 애플의 Newton개발자가 스트레스로 자살을 했다는 얘기는 잘 알려진 얘기중의 하나다). 과연 그 프로젝트가 가정의 행복과 개인의 건강을 해쳐가면서 때로는 목숨을 바쳐가면서까지 수행해야 할 만큼 가치로운 것인가? 우리가 무슨 항일독립운동을 하고 있나?
정말 스트레스로 인해 자살에 대한 충동이 생긴다면 자살말고도 우리에겐 선택의 여지가 있다. 퇴사
|
2000년에 프로젝트를 할 때 정말 죽어 버릴 생각을 했었어. 사고는 맨날 터지지, 고객은 잡아먹을 듯이 덤비지… 정말 죽고 싶더라구. 정말 회사 가기가 싫었던 어느 날 아침. 와이프가 말하더군 "힘들면 회사 그만 둬" 그제서야 갑자기 광명이 비치는 듯 했어. 내가 무슨 죄를 지은 것도 아니고, 다들 실패하는 그런 프로젝트를 하고 있을 뿐이야. 정 안되면 퇴사 해야겠어. 죽기는 왜 죽어? 누구 좋으라구? ㅎㅎ - H 팀장과의 대화 중에서 |
요든2은 문제 프로젝트가 생기는 이유와 문제 프로젝트에 참여하는 이유를 다음과 같이 정리하였다.
|
문제 프로젝트가 생기는 이유 |
문제 프로젝트에 참여하는 이유 |
|
|
프로젝트 시작시점에 경영층 또는 영업팀과 프로젝트 관리자가 일정과 인력, 예산을 갖고 협상을 하는 경우가 종종 있다. 얼마나 웃기는 일인가? 소프트웨어 개발사내에서도 협상만 잘하면 부족한 인력과 예산으로도 프로젝트가 가능하다고 생각하는 건 아닌가? 예산과 일정은 프로젝트 관리자와 결단코 협상할 수 있는 것이 아니다.
프로젝트M를 다시 시작한다면? 글쎄?
동일한 환경으로 다시 시작하라고 한다면 결코 다시 참여하고 싶지는 않다.
그러나 환경의 변경이 허락된다면, 한번쯤 다시 시도하고 싶다.(이것이 문제 프로젝트에 참여하는 에베레스트 증후군인가?)
프로젝트 예측
프로젝트를 예측하는 할 때, 흔히 시장에서 말하는 기준을 Study할 필요가 있다. 프로젝트를 하고자 하는 개발 도구와 적용되는 분야에서 개발할 때는 어느 정도의 MM가 소요되는 지에 대해서 최소 2명 이상의 전문가와 상의해야 한다. 물론 이러한 전문가는 프로젝트와 무관한 사람일수록 좋다.
PowerBuilder 기술 지원인력에게 들은 얘기로는 개발, 테스트 기간동안 한 사람이 12본 정도를 만든다고 한다. 분석설계 단계 이후 나온 프로젝트 본수를 계획되었던 투입인력으로 나누면 25본정도를 개발했어야 했다. 그러나 실제 개발된 본수를 실 투입인력으로 나누면 12.6본 정도를 개발했다.
긍정적이고, "하면 된다"는 식의 해병대식의 프로젝트 예측은 프로젝트가 망하는 초석이다. 과연 프로젝트 수주를 하는 것이 목표인지, 프로젝트를 성공적으로 끝내 적절한 이윤을 남기는 것이 목적인지 명확히 해야 한다.
인력관리
개발 인력선정
프리랜서와 함께 일할 경우 그 사람의 근무태도 및 능력에 대해서 소위 Reputation Check를 해야 한다.
개발인력이 프로젝트에 적합하지 않다고 생각할 때는 최대한 빨리 프로젝트에서 빼도록 해야 한다. 적합하지 않은 인물로 인해 프로젝트는 복구가 불가능하게 된다. 프로젝트가 복구가 불가능 하게 되었을 때야 그 때 인력을 뺄 것을 하고 후회하게 된다.
팀 빌딩
프로젝트팀원과는 인간적으로 가까워지도록 노력해야 한다. 그 사람들이 겪고 있는 어려움이 무엇인지 등을 파악하도록 노력해야 한다. 결국 팀웍이 프로젝트를 좌우하게 되며, 사기가 떨어진 프로젝트팀은 사분오열되어 프로젝트를 마칠 수 없게 한다. 단순히 관리하고 있다는 느낌을 주어서는 안 된다. 그 소속이 어떻게 되었든, 프로젝트 팀원과는 함께 그 운명을 같이 함을 명심토록 한다.
요구사항 관리
요구사항에 대한 관리는 항상 중요하다. 고객의 요구가 어떻게 변화했는 지에 대한 관리가 이뤄지지 않으면 프로젝트 종료 시 굉장히 힘들 게 된다. 요구사항 관리의 중요성을 개발자에게 항상 주지를 시켜야 한다.
고객의 요구사항이 일원화된 창구를 통해 접수되지 않는다면 개발자에게 요구사항을 관리할 수 있는 Excel 시트를 나눠주고 항상 기록하도록 하고 정기적으로 이러한 요구사항 점검시트를 통합하여 관리토록 한다. 이것을 통해 고객이 얼마나 변덕스러웠으며 우리에게 얼마나 많은 시련을 주었는지를 증명토록 한다.
위험관리
항시 위험을 조사하고 관리해야 한다. 식별된 각각의 위험들이 발생될 확률과 발생시 비용에 대한 것을 평가하고 위험이 발생했을 때를 감지하는 다양한 방법을 마련해 둬야 한다.
개발자들이 관리자에게 위험을 익명으로 알릴 수 있는 방법을 만들어 두어야 한다. 개발자들은 프로그램이 지연되고 있다고 얘기하기가 어렵다. 그러나 이러한 보고의 지연이 더 큰 재앙을 만들기가 쉽다. 익명으로 게시판에 올리거나 혹은 동일한 아이디와 패스워드를 개발자들에게 분배하여 메일을 쓰도록 한다. 메신저나 가능한 모든 통신 수단을 통해 개발자와 대화할 수 있는 채널을 만들어야 한다.
이것이 어렵다면 개발자들과 차를 마신다 던지, 혹은 함께 식사를 한다 던지 해서 쉽게 얘기할 수 있는 분위기를 만들어야 한다.
고객 관리
실무진과는 항상 끈끈한 유대관계를 갖도록 해야 한다. 가족사항 이라던지 주거 등을 파악해 관리하고서 인간적으로 친해질 수 있는 방안을 모색해야 한다.
고객사의 고위층과 실무진들과 회의를 하게 되면 그 전에 실무진과 회의에 대한 내용을 미리 협의하도록 한다. 회의 때 이런저런 얘기가 나와서 우리 쪽이 논리에서 밀리면 안 된다.
고객은 불가근불가원[不可近不可遠]이다. 너무 가까이 하게 되면 그들의 끊임없는 요구를 들어줘야 하며, 너무 멀리하게 되면 사소한 문제로도 마찰을 빚게 된다.
프로젝트 초기에는 좀 까칠할 필요가 있다. 계약서 상의 Scope을 벗어나는 업무라 던지 하는 것에 대해서는 분명히 짚고 넘어가야 한다. 고객과의 거리를 좁혔다가 넓혔다가 하는 것을 조절해야 한다. ? 사실 이것이 기술이다 - 처음엔 무엇이든지 해 줄 것처럼 얘기하다가 나중에 못해준다고 하면 고객의 불만은 엄청나다. 반대로 처음에는 못하겠다고 하다가 요구사항 1, 2개 정도를 들어주면 고객은 대단히 만족해 한다.
프로젝트 초기에 고객과의 관계를 우려해서 문제가 있는 데도 숨기거나, 업무 범위 밖의 일을 하기 시작하면, 프로젝트 무덤의 첫 삽을 뜨는 것이다. 프로젝트의 문제점을 고객과 서로 공유하고 PM이 속이는 것이 없음을 보여주는 것이 중요하다. 상호간에 신뢰가 쌓이면 프로젝트는 훨씬 수월하게 갈 수 있다.
프로젝트가 망하게 되면 고객 또한 피해를 본다는 사실을 인지해야 한다.
고객을 무서워해서는 안 된다. 싸울 때는 과감히 싸워야 한다. 싸우는 것을 두려워하지 말자.
|
07.04 본사쪽 프로젝트가 막바지에 다다르면서 잔여업무에 대한 정리회의가 있었다. 회의가 끝나고 회계부 I차장이 기분이 상해서 돌아갔다. 정보팀 담당자, "계열사쪽은 처음부터 이슈가 많아서 그러려니 하시던 데, 본사쪽은 프로젝트 내내 요구사항을 잘 들어주시다가 막바지에 안 들어주신다고 하니까 많이 속상하신 가 봐요" |
동료검토
개발이 시작된 후 2주 혹은 1개월이 지나면 반드시 동료검토를 해야 한다. 동료검토는 복잡하고 특별한 격식을 갖출 필요는 없다. 단지 개발자의 소스코드를 보고서 개발이 시작되기 전에 서로 약속했던 코딩 Rule과 부합하는 지를 확인하는 자리를 마련하는 것이다.
때로는 개발자들에게 싫은 소리를 좀 해야 하기 때문에 주로 주니어 개발자를 시작으로 해서 모든 개발자의 소스코드를 동료검토를 하도록 한다. 이러한 자리가 개발자의 소스코드 품질을 성토하는 자리가 되어서는 안되지만 코딩 Rule을 전혀 지키지 않고 개발된 소스에 대해서는 따끔하게 한마디 해줘야 한다.
|
프로젝트가 끝날 때쯤 중급 개발자의 소스를 본 경우가 있었는 데 소스코드가 코딩 Rule과 전혀 다르게 개발된 것을 보고서 개발자에게 물었다. "왜 소스코드가 코딩룰과 전혀 달라요?" "저는 이게 편하거든요" |
고급 같은 초급 엔지니어를 볼 때가 있는 반면, 초급 같은 중급 엔지니어를 볼 때도 있다. 당연하게 개발될 것이라고 봤던 것을 전혀 엉뚱한 방식으로 개발하는 경우도 흔하다. 개발초기에 이러한 것을 짚고 넘어갈 수 있도록 개발자들 서로간에 공감대를 형성할 수 있는 자리를 마련토록 한다.
예광탄3 개발
2006년 7월에 개발을 시작해서 로그인 화면을 처음 볼 수 있었던 시기가 8월 말경이었다. 2달 동안 개발팀에서 단위 모듈을 개발하는 작업을 계속 진행해 왔었지만 8월말이 되어서야 겨우 WAS 서버에 올려볼 수 있었다. 그제서야 통합 시에 어떤 문제가 발생할 수 있는가에 대해서 진지한 얘기를 시작할 수 있었고 결국 일부는 모듈을 수정 보완해야 했다. 수정보완 작업을 하는 데 2주를 까먹어야 했다.
예광탄 개발은 개별적인 기능을 개발하고 난 후에 나중에 통합해서 보겠다는 것이 아닌, 개발 초기에 하나의 간단한 기능을 갖는 시스템을 구성하여 개발이 진행될 때마다 하나씩 붙여가면서 개발하겠다는 개념이다. (이것을 지속적 통합으로 봐야 할지에 대해서는 확신이 없어서 우선은 예광탄으로 바라 본다. )
분석설계가 끝나고 개발이 시작되면 반드시 예광탄시스템을 구축하고 누구나 시스템에 접속해서 테스트가 가능하도록 해야 한다. 개발의 진척상황을 투명하게 바라볼 수 있어야 한다. 개발자의 컴퓨터 속에서만 돌아가는 프로그램은 그 완성도를 파악할 수가 없으며, 프로젝트의 상태를 진단할 수 없게 한다.
예광탄 시스템의 구축
설계단계 혹은 개발초기에 예광탄 시스템을 구축하여 기술적인 문제점을 점검해야 한다. 이 예광탄 시스템은 다음과 같은 기능을 갖도록 한다.
1. 로그인 과정
2. 실제 업무에 들어가기 위한 메뉴체계
3. DB와 연결되는 간단한 업무
4. 타 시스템과의 인터페이스 연결
5. 사용자의 대표적인 PC등에서 테스트
사용자의 OS 및 해상도에 대한 문제점을 간과해선 안 된다. Windows의 버전 문제로 인해 돌아가던 게 안 돌아가거나 혹은 작업줄(TaskBar)에 의한 화면사이즈가 변경될 수 있다. 만약 예광탄 시스템의 구축 시 문제점이 발견된다면 이를 조속한 시기에 해결해야 한다.
개발 산출물에 대한 Tailoring
고객과 협의하여 반드시 필수적인 요소만 하도록 한다. 개발산출물은 그다지 유용하지 않은 게 많다. 개발자에게 실제적으로 필요한 산출물에 대해서 확인토록 해야 한다. 개발에서 필요치 않은 것으로 판단되는 산출물을 작성하는 것은 개발자에게 짐만 지워줄 뿐이다.
기술적인 유의점
운영장비와 개발장비의 성능차에 대한 고려
운영장비와 개발장비가 서로 다르고 성능차이가 있는 경우는 시스템 오픈시에 문제가 될 수 있다. 운영장비와 유사한 성능의 개발장비를 사용하는 것이 가장 좋다. 성능이 좋은 개발장비에서 성능이 나쁜 운영장비로 이전하는 경우라면 최악의 상황을 초래한다. 즉 개발 당시에는 성능에 대한 이슈를 전혀 느끼지 못하다가 막상 오픈 직전에 시스템을 운영장비로 이관한 상태에서 성능의 이슈가 부각되면서 성능튜닝으로 인해 굉장히 많은 시간을 소요하게 되며 이로 인해 오픈을 하지 못할 수 도 있다. 반대의 경우도 비슷한 상황 ? 성능이 나쁜 개발장비에서 성능이 좋은 운영장비로 이전할 때도 ?을 맞이 할 수 있는 데 이 경우, 개발자들은 개발장비에서 성능이 안 나오는 것을 성능 좋은 운영장비에서 프로그램을 돌리면 성능이 좋아질 것으로 판단하기 쉽다.
만약 서버가 Virtualization을 지원한다면 가상화 서버에 대한 리소스 조정을 통해서 하도록 한다. 개발서버에 대한 임대도 고려할 필요가 있다.
또한 사용자의 PC환경, 네트워크 상황에 대해서 파악하고 있어야 하며 테스트를 위해서 사용자 PC환경 및 사용 네트워크 환경을 구비해 두어야 한다.
Application 로그
서버 로그는 개발 초기에 어떤 방식으로 로그를 남길 것인지 표준을 정해야 한다. 개발언어별 특성이 있겠으나 다음과 같은 형식이 이상적이다.
날짜 : 구분 : Random 값 : 사용자IP : 세션ID : 업무명 : 함수명 : 이 함수를 부Caller : 기타
여기서 Random 값을 앞에 두는 것은 서로 다른 세션에서 같은 함수를 Call 하는 경우, 이것을 이를 구별하기 위함이다. 사용자가 메뉴를 누를 때마다 로그를 넣는 것도 좋다. 로그 또한 에러로 나오는 지 단순히 정보를 전달하기 위함인지를 구분 필드로써 분명히 하도록 한다.
SQL 로그
SQL은 반드시 서버쪽에 WAS 또는 Web 서버에 로그를 남겨서 튜닝이 가능토록 한다. 로그를 남길 때는 어떤 프로그램에 실행시킨 어떤 SQL이 얼마만큼의 시간이 걸리는 지 파악할 수 있도록 한다. 즉
- SQL을 돌리기 직전의 시간 + SQL을 실행시킨 프로그램명
- SQL문장
- SQL을 돌리기 직후의 시간 + SQL을 실행시킨 프로그램명
의 형식으로 하여 어떤 프로그램이 실행시킨 SQL이 속도지연을 일으키는 지 파악토록 하다.
SQL을 실행시키는 모듈은 반드시 공통모듈을 통해서 정의되어야 하며 개발이 완료된 후에는 로그를 빼기 쉽도록 해야 한다.
SQL 작성
Table Creation 방법 / SQL 사용법 등에 대한 교육을 개발초기에 개발자에게 실시하여야 한다. SQL Tuning 방법 / Execution Plan 보는 거 / DB 이관방법 / Table 생성시의 옵션등 4시간 정도의 교육과정을 갖고 GuideLine을 정확히 제시하여야 한다. 그리고 제시된 Guide Line를 정상적으로 수행하는 지 모니터링 해야 한다.
고가용성(HA) 구성에 대한 점검
개발 초기, 고가용성 구성을 위한 개발 점검을 하도록 한다. WAS서버의 특성, 또는 N/W의 특성에 맞춰 개발이 이뤄져야 한다. 이러한 점검이 없이 개발이 진행되다 보면 나중에 큰 낭패를 보게 된다.
기술지원
기술지원인력에 대한 비상연락망이 구축되어야 한다. 개발하는 Tool/WAS/Web/DB 서버에 대한 기술지원인력은 프로젝트 팀원내에 상주가 바람직 하지만 그렇지 않은 경우에는 비상연락망을 구축하고 위급상황 발생시 바로 뛰어올 수 있는 체제를 갖추어야 한다. 특히 시스템의 오픈 전후에는 이러한 체계를 갖추도록 한다.
또한 프로젝트 팀원중에는 기술력이 출중한 인물이 있어 기술을 리드할 수 있도록 한다
솔루션을 사용하게 되는 경우
벤더에게 그 솔루션을 통해서 해서는 안되는 것, 제약조건에 대한 가이드를 받아두고 이점을 개발자에게 숙지시키고 점검해야 한다. 해서는 안 되는 것, 제약조건에 대한 것을 인지하지 못한 체 개발막바지에 가서 문제가 생기면 벤더를 부르게 되는 데 이 경우 벤더에서 와서 하는 말은
"어~ 이런 거 쓰면 안 되는 데... "
그 때 가선 늦다. 가이드 라인을 받고는 벤더에게 이 점 이외의 문제로 발생하는 문제에 대해선 책임을 져 줄 것을 요청해 둔다. 가이드 라인에 따른 샘플을 반드시 받아두고 이를 기반으로 프로젝트의 프로토타입을 만들기 시작한다. 개발이 어느 정도 이뤄진 시점 또는 예광탄 시스템을 완료한 시점에서 솔루션 벤더에게 소스를 한번 점검해 줄 것을 요청하여 점검하는 시간을 갖도록 한다
테스트
테스트할 때는 되도록 테스트팀이 개발자와 직접적으로 접촉하지 않는 것이 좋다. 자칫 잘못하면 Test팀이 개발팀을 야단치는 형식이 되기 쉬우며 관련된 커뮤니케이션을 어떻게 할 것인지가 무척 중요하다. 테스트 방법에 대해서만 커뮤니케이션을 하고, 테스트 결과에 대해서는 커뮤니케이션을 자제토록 한다.
테스트팀이 투입되어 테스트를 잘 할 수 있도록 테스트 케이스 등을 미리 잘 만들어 두었어야 한다. 테스트 케이스가 없으니 지원인력이 지원하기가 어렵다.
프로젝트를 한다는 것은 힘든 일중의 하나다. 더욱이 문제 프로젝트를 수행한다는 것은 너무도 너무도 힘들다. 사람과 컴퓨터, 이 중간에 끼어서 개발을 해야 하는 정말 스트레스, 스트레스, 스트레스의 연속인 작업이다. 부디 이 글이 프로젝트를 수행하는 데 아주 조금이나마 보탬이 되었으면 좋겠다. Good Luck!!!
목차
4. 프로세스 M을 다시 한다면