차세대 개발 프로젝트 실패 전조현상 26가지

차세대 개발 프로젝트 실패 전조현상 26가지

모든 소프트웨어 개발 프로젝트를 성공적으로 마치려는 수많은 노력에도 불구하고, 어떤 프로젝트는 굳이 끝까지 가보지 않고도 망했다는 것을 알 수 있다. 다음은 기업의 소프트웨어 개발 프로젝트가 실패의 길로 가고 있다는 것을 알려주는 26개 경고 신호들이다. 안타깝게도 이 모든 것은 모두 실제 경험을 바탕으로 한 것이다.

1. 몇 달 동안 프로젝트 이름이 세 번째 바뀌었다.

2. 개발 관리자가 전 세계적인 단일 버전을 만들기보다는 영국에 대해서는 완전히 다른 버전의 소프트웨어를 만드는 것이 낫겠다고 결정한다.

3. 개발이 시작된 지 네 달이 지나서 소프트웨어 권장 사양 정의를 시작한다.

4. 새롭게 고용된 R&D 책임자가 이사회에서 이 프로젝트는 일정 상 6개월만 지나면 99% 완성될 것이라고 소개하고, 이사회에서는 이 소프트웨어를 베타 테스트없이 고객들에게 바로 출시해도 되겠다고 결정한다.

5. 웹 개발자가 웹 애플리케이션으로 통합해야 하는, 고객이 만든 HTML 문서가 담긴 ZIP 파일을 열어본다. 그리고 고객의 HTML 문서가 모두 단지 HTML 형식으로 저장했을 뿐인 마이크로소프트 워드 파일이라는 것을 발견한다.

6. 컨설턴트를 고용한 이유가, 어떤 기술 플랫폼을 사용할지 경쟁하는 두 부서간의 싸움을 중재하기 위함이라는 것을 깨닫는다.

7. 16비트 플랫폼을 이용해 64비트 애플리케이션을 개발해야 된다는 쪽지를 받는다.

8. 개발자가 스펙이 적힌 문서를 이해하지 못하고 계속 개발을 한다. 그리고 QA팀은 어떻게 테스트를 해야 할지 모르지만 그냥 "테스트" 한다.

9. 프로젝트 예산을 확인해보니, 절반 이상이 웹 디자이너가 홈페이지의 포토샵 목업(mock-up)을 제작하기 위해 사용됐다는 것을 발견했다. 그 디자인이 실현 가능한지 고려하지 않은 채로, 또는 홈페이지에 들어간 수천 페이지의 콘텐츠를 전혀 고려하지 않은 채 말이다.

10. 사용자나 고객이 버그 수정이나 성능 향상에 관심을 가지기보다는 새로운 기능을 원한다.

11. 16가지 소프트웨어 개발 연습 방법이라는 리스트를 발견하고, 이 중에 단 한 가지도 지켜지지 않았다는 것을 깨닫는다.

12. 윈도우에서 MS 도스로 프로젝트를 전환하라는 요구를 받는다.

13. 기술 프로젝트 관리자가 실제로 가능성 있는 사용자들을 참고하지 않고서 사용자의 요구사항 목록을 작성하라고 시킨다.

14. 사람들이 서로에게 기록을 보내는 대신에 "파일"을 만든다. 여기에는 앞으로 닥칠 실패에 대해 왜 아무 일도 하지 않았는가 하는 알리바이가 담겨있다.

15. 현황 보고서가 작성하기가 쉽지 않다.

16. 새로운 CIO가 회사 정보를 잘 알고 있는 모든 사람들을 옛 회사의 문외한들로 교체한다.

17. 이 중요한 프로젝트는 아이스버그라고 불린다. 그러나 회사가 이 프로젝트를 해내기 위해 시도한 것이 벌써 세 번째이며, 이제 "불사조"라는 코드명으로 불린다. 어찌되었건 프로젝트가 잿더미 상태에서 다시 살아날 것으로 보이지는 않는다.

18. 무료 버전을 받았던 사용자들조차 화를 내고 있다.

19. 회사 수입의 80%를 쥐고 있는 매우 중대한 프로젝트의 관리자가 3개월간 기술을 선택하고, 4명의 새로운 개발자들을 한 번에 교육한다. 관리자에게 주어진 실제 프로젝트 수행기간은 3개월이다.

20. 초기 코드가 작동을 멈추고 나서야 경영진이 인터페이스 정의가 버전에 맞는지 점검해야 된다고 주장했어야 한다는 것을 깨닫는다.

21. 프로젝트 관리자가 교체되고 프로젝트 전체가 다른 도시로 재배정된다. (다만 새로 옮겨갈 도시가 적어도 같은 대륙 안에 있다는 사실에 감사할 따름이다)

22. QA팀이 이렇게 말한다. "우리는 테스트를 단지 3주 동안만 했어." 또는 "날짜가 정해져 있었어. 우리는 그 날에 맞춰 모든 기능을 점검해야만 했어."

23. 프로그램 관리자가 "시간을 아끼기 위해" 민첩한 방법론(Agile methodology)을 사용하기로 결정한다.

24. 휴대폰이 흔하지 않고 인터넷 접속이 쉽지 않았던 시대에 있던 일이다. 뉴욕에서 3일 전에 고용된 새 프로젝트 관리자가 소리를 마구 지르며 욕을 했다. 당사자는 프랑크푸르트에서 CIO와의 미팅으로 3일간 갇혀 있다가 막 돌아왔는데 말이다. 왜냐? 새로운 관리자가 보낸 이메일에 답장을 하지 않았고, 그 메일을 받지 못 했으니까 전혀 모를 수밖에 없는 "프로젝트 진행표"를 업데이트 하지 않았기 때문이다.

25. 경영진이 수십만 달러를 2만 달러짜리 프로젝트에 쓰기로 결심한다. 그러면 관리자들은 소프트웨어에 10만 달러, 하드웨어에 20만 달러가 필요하다는 컴퓨터 회사 판매원들에게 동의하기 시작한다. 게다가 비서들은 재고로 쌓인 PC와 새로운 오피스 자동화 패키지가 담긴 CD를 구입하고, 점심시간 동안에 프로젝트를 실시한다. (아마도 이것을 그나마 성공이라고 봐야 한다.)

26. 최고 개발자가 데이터베이스의 모든 업데이트 기록을 완전하게 유지해야 한다고 강조한다. 하지만 정작 본인은 아직 이를 위한 데이터 모델을 설계할 시간을 가지지 못했다. (아마도 하는 방법을 모른다) 결국 데이터 모델은 나중에 걱정하고, 웹의 프론트 엔드부터 작업하기로 결정한다. 이것이 바로 최고 개발자이다.

비즈니스 리더나 프로젝트 후원자가 "창의적으로 하라"라는 말은 한다. 이는 경영진이 프로젝트 인원을 20% 감원한 다음 벌어지는 일이다. 그리고는 IT 관리자가 재활용 하드웨어의 먼지를 털어 꺼내주면서 이것이 프로젝트를 위한 새로운 환경이라고 말한다.

이것은 수많은 소프트웨어 개발자와 IT 전문가들이 말한 것을 기초로 작성된 목록이다. 한 가지 더 안타까운 것은 이것이 전부가 아니라는 것이다.

출처 : http://www.itworld.co.kr/print/53471