성탄전 연휴 사이에 읽은 "초난감 기업의 조건"이란 책에서 소개한 많은  IT 기업의 실패한 여러 사례를 들을 보면서 , 소프트웨어 라는 분야의 사업에 대해 다시 한번 많은 생각을 하게 되었습니다. 소프트웨어 개발사가 망하는 주요한 원인 제공처가 크게는 소프트웨어 기술을 이해못하는  난감한 CEO , 아둔한 개발진 , 띨방한 마케팅 부서 등을 볼 수 있는 것 같습니다.  최소한 난감한  CEO와 띨빵한 마케팅 부서를 제외하고 개발과 관련된 사안들에 대해 다음과 같은 실수는 피해야 하지 않을까 싶습니다.

- 제품을 처음부터 다시 개발해야 한다는 개발팀의 의견은?
심정은 이해하지만 절대 다시 개발해서는 안됩니다. 이미 경쟁자는 신규 개발 기간의 몇배는 빨리 시장에서 자리를 잡게 됩니다. 또한 안정화되기까지 엄청 많은 시간을 요하게 됩니다. 개인적으로도 유사한 상황에 빠진 경험이 몇 번 있었는데 구조적으로 문제가 있고 , 처음 시도하고 적용한 기술 등을 인해 많은 문제가 있어 다시 처음부터 시작해야 하는 상황이라면 어쩔수가 없습니다. 그러나  이미 시장에 출시되어 경쟁이 되는 제품이라면 현재의 상황을 점진적으로 개선해 나가는 것이 당연히 유리합니다. 유명한 사례지만 넷스케이프사가 전제 제품을 다시 개발하는 데 4년이 걸렸고 그 사이는 빌게이츠는 익스플로러로 인터넷 분야의 판세를 뒤집었죠.

- 개발 목표가 모듈화 라는 개발팀의 의견은?
모듈화의 필요성과 기존 모듈의 문제점, 투입 비용 및 기간 등 여러 요소를 비교하여 그 활용성을 세밀하게 살퍄보고 결정해야 합니다.

- 개발 환경을 변경하겠다는 개발팀의 의견은?
런타임 업그레이드 등을 통해 개발 환경이 손쉽게 변경된다면 큰 문제가 없지만 개발 언어를 다른 언어로 바꾼다거나 개발 환경을 바꾸면서 대대적인 변경이 생긴다면 투입 비용 대 효과에 대해 신중하게 판단하여 결정해야 합니다. 큰 효과가 없다면 변경하지 않는 게 유리합니다.

- 제품을 개발 일정이 부정확한 경우는?
일정 관리는 개발에 있어 가장 중요합니다. 주간 단위의 일정이 지켜지지 않으면 일단위, 일단위가 지켜지지 않으면 시간단위로 라도  일정을 수립하고 이를 지켜내는 프로세스가 있어야만 성공합니다.

- 의도적으로 개발을 거부하거나 태업을 하는 우수한 개발자는?
가슴 아프지만 집으로 돌려보내야 합니다. 결코 소프트웨어는 혼자 개발하는 것이 아닙니다.  여러가지 이유로 자신의 입장만을 고려하는 개발자는 반드시 전체 개발 조직에게 유익하게 작용하지 않습니다.

- 제품 관리(기획)팀의 80:20 법칙을 주장할 때는?
경력이 많은 기획자가 이렇게 말하면 내공을 의심하고 , 신입 기획자가 말하면 팔레토 법칙에 따라 80% 사용자가 20% 기능만을 사용한다고 생각하고 개발을 하면 반드시 망한다는 이야기를 해줘야 합니다.

마지막으로 제 경험상 우수한 QA 팀이 반드시 갖춰져야 고품질의 제품을 안정적으로 출시할 수 있습니다.  실제 위와 같이 하다보면 개발자가 오해를 할 수 있습니다. 그러나 결코, 그렇치 않습니다. 함께 개발로서의 제품이 아니라 , 비지니스로서의 제품으로 이해하는 과정을 통해 모두 이러한 현실을 이해하게 만드는 것이 반드시 병행돼야 합니다.