드리밍 인 코드
국내도서>컴퓨터/인터넷
저자 : 스콧 로젠버그 / 황대산역
출판 : 에이콘출판사 2009.01.02
상세보기


   일반적인 소프트웨어 프로젝트 실패의 이유  
 

  보통, 소프트웨어 프로젝트가 어려움에 빠지는 것은 개발자들이 충분한 개발시간을 확보하지 못하는데 있다. 이런 사태는 일반적으로 개발에 대하여 가장 모르는 사람 - 사장님, 영업 책임자, 마켓팅 담당자 등 - 이 프로젝트의 일정을 좌지우지 하기 때문이다. 프로젝트와 기술에 대하여 가장 많은 정보를 가지고 있는 사람은 말단 개발자인데, 이 프로젝트 완료까지 얼마나 걸릴지는 가장 적은 정보를 가진 사람들이 결정을 하는 것이 일반적인 문화이다. 이로 인하여 프로젝트는 별 성과를 내지 못하거나, 엉망진창으로 흐르거나, 하청업체와 개발자들을 착취하는 방향으로 흘러가게 된다. 근로기준법 같은 것은 염두에 두지 않는다. 각자 자기 입장에 맞춰 꿈속에서 본 날짜를 데드라인 (Dead line) 이라고 적어내면 그건 정말로 개발자를 죽이는 날짜가 된다. 그래서 이 땅에는 제대로된 개발자일수록 일찍 일을 접는다. 진짜 똑똑한 사람은 기술고시나 의학대학원으로 가버리고 별로 똑똑하지 못해서 다른데 갈 수가 없는 사람들만 남는, 약자생존(弱者生存)의 생태계가 만들어진다. 


   여기, 또 하나의 끔찍한 실패담이 있다   

  그런데, 이 책에서 예로 든 "챈들러" 프로젝트는 정반대의 경우이다. 충분히 경험많고 실력인 개발자들이 있어고, 그들을 전폭적으로 지지해주는 CEO가 충분한 자본과 시간을 투자했다. 개발자간에는 소통이 너무 많아서 문제가 되었고, 일정이 쫒기기 보다는 일정을 다그치는 사람이 없어서 프로젝트가 지지부진했다. 우리가 늘 꿈꿔오던 개발환경이 갖춰진 셈인데, 이것이 독이되어 프로젝트는 처참한 실패의 결과로 남게 되었다. 

  가장 큰 문제는 기획의 부재였다. 무엇이든 다 되는 PIM (Personal Information Management system) 을 기획했지만, 실제로는 무엇을 하고 싶은지 명확히 알지 못했다. 창업자의 머릿속에만 있는 신기루 프로그램 (Vapor-ware)를 만들다가 시간도, 비용도, 인재도, 모멘텀도 모두 잃어버리고 말았다. 

   그럼 우리가 옳은건가?   
 

  확실히, 책으로 묶어 낼 만큼 신기한 실패사례이기는 하다. 우리가 상상해오던, 그런 재미있는 개발자의 놀이터 같은 회사였는데, 개발자들이 도전해볼만한 과제였고, 모든 의사결정과정이 개발자들간의 민주적인 토론에 의해서 진행되었는데, 프로젝트는 처참하게 실패했다. 그렇다고 우리가 옳은 것은 분명 아닐텐데 말이다. 소프트웨어는 어렵다 - Software is hard - 는 명언이 새삼 확인되는 순간이다. 이순간에도 죽을만큼 힘들게 일하고 있는 개발자들에게, 꿈속도 결코 꿈같이 행복하지는 않다고 말하고 싶었던 것일까. 


Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  아키텍트( Architect). 소프트웨어 프로젝트를 진행할 때 가장 먼저 요구사항을 분석하고 전체 구조를 잡는 사람을 뜻한다. 프로젝트 매니져 (Project Manager)와 비슷한 의미로 쓰기도 하는 것 같다만, 하는 역할만 놓고 본다면 아키텍트(건축가)가 더 맞는 것 같다.

  우리 프로젝트를 진행하는 데도 아키텍트가 꼭 필요한데, 문제는 아무도 이 역할을 맡으려 하지 않는 다는 것이다. 애초에 아키텍트가 있어 본적이 없는 것도 문제지만, 정말 임원과 부장님들이 아키텍트의 필요성을 인지하지 못하고 있는 것인지도 의문이다.

  사업자 요구사항은 단순한 UI설계도로 넘어왔다. 그에 대한 분석을 UX팀이 대응을 했다. 개발팀에서도 참여한 사람들이 있었는지 모르겠지만, 없었던 것 같다. 이건 정말 쉽지 않은 일인데, 그저 피상적이고 최소한의 UI문서만 가지고 작업이 진행되었고, 드디어 가장 어려운 문제들이 터져 나오는 중이다. 90%의 버그는 이미 처리가 되었지만, 숨어있어 악질 문제들이 발견되고 있다. 더 심각한 것은 검증팀이 전혀 발견하지 못했고, 컨셉에는 아얘 나와있지도 않다.

  아키텍트가 있었다면 어땠을까? 프로젝트 킥 오프 단계에서 요구사항에 대한 좀 더 세세한 분석과 사업자측 요구사항 중 미진한 부분에 대한 문서화 요청이 있었을 것이다. 또한 연관 기능들에 대하여 관련 개발자들간의 미팅이 있었을 것이고, 서로 연동되는 부분들에 대한 인터페이스 설계와 타이밍에 대한 규정이 있었을 것이다. UX팀은 폰 기능을 불행하게도 정말 잘 모른다. 특히나 기능과 기능이 충돌하면서 발생될 수 있는 여러가지 상황들에 대한 이해가 절대적으로 부족하다. 결국 아키텍트 외에는 각 기능들 간의 조율을 담당할 사람이 없다. 문제는 아키텍트가 없다.

  과연... 이 프로젝트는 어떻게 진행이 될 것인가. 또, 아키텍트 없이 우리팀은 계속 프로젝트를 꾸려갈 수 있을 것인가. 지금까지 꾸려진게 용할 정도지만...
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2020/02   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
Total : 316,427
Today : 10 Yesterday : 13