프로젝트가 수렁에 빠지는 이유
분류없음 2006/08/20 19:26
(1)IT프로젝트는 눈에 보이지 않는다
흔히 IT프로젝트를 건축에 비유한다. 설계-시공(구현)이라는 과정이 닮아서 일게다. 하지만 IT프로젝트는 베타버전까지는 눈에 보이지 않는다는 특징이 더 있다. 건축은 토목공사를 시작하면서 첫삽을 뜨게 되는데, 이때부터 공사과정이 다 보인다. 하지만 IT는 아무리 열심히 코딩을 해대도 베타버전까지는 아무것도 진척이라고 보이는게 없다. IT프로젝트 팀장과 사장님들의 조급성은 여기에서 나온다
(2)컨베이어벨트가 없다
포드가 자동차산업에 컨베이어벨트시스템을 도입하면서 획기적으로 생산성을 높였다는것은 교과서에 실릴 정도로 유명하다. 그럼 그전에는 어땠는가? 장인이 수작업으로 몇개월에 걸쳐 자동차 하나를 만들었다. 아주 개성이 넘치고 사랑스러운 자동차가 많았을거다. 빛이 있으면 그림자도 있는법. 만들때마다 서로 다른 자동차를 만드는 그 장인은 자신의 자동차가 몇월 며칠에 정확히 출고될지 예측할 수 있었을까? IT프로젝트에서 프로젝트종료일이라는 것은 '그때까지 일을 다한다'가 아니라 '그때까지 가능한한 많이하기'이다. 왜 그럴까?
자동차산업에서의 컨베이어벨트처럼 보편적인 개발방법론이 확립되지 않았기 때문에 수작업과 같은 조악한 방법으로 작업을 하게되는데, 보편적인 개발방법론이 없기때문에 요구사항과 추가요구사항이 수시로 발생하기 때문이다.
(3)설계서는 없다. UI자체가 설계서다
건축과 IT가 유사하다고 말은 하지만 IT에서 설계서를 찾아보기 힘들다. 있긴하지만 보고용 설계서다. 그냥 종이뭉치일뿐이고 아까운 펄프만 낭비하는 죄악이다. 진짜설계는 머리속에 있기도 하고 개발자들이 담배피우면서 하는 얘기속에 있기도 하다. 더군다나 고객(사용자)들은 프로젝트에 의견을 잘내지 않는다. 그러다가 막상 베타버전이 나오면 UI를 캠버스삼아 이리저리 요구사항을 마구 쏟아낸다. 이때부터가 문제다. 개발자들은 베타버전은 프로젝트의 마무리를 의미하지만 고객(사용자)들은 이제 겨우 시작이라고 생각한다. 주먹구구로 설계하는 개발자와 막상 UI가 나와서야 의견을 쏟아내는 고객(사용자). 둘다 왜이리 한심한가?
아니다 그들은 모두 유능하다. 만약 프로젝트 초기에 개발자들에게 제대로된 설계를 주고 고객(사용자)들에게는 요구사항을 조사했다라면 상황은 어땠을까? 조금 나을것이다. 하지만 큰 변화는 없을것이다. 아무리 초기에 요구사항을 조사하고 설계를 잘한다 하더라도 그둘은 계속 바뀐다. 시간이 갈수록 개발자(설계자)도 고객(사용자)들도 프로젝트에 대해서 좀더, 또는 다시 알게되기 때문이다.
어째거나 IT프로젝트의 성공여부는 얼마나 빨리 변경된 요구사항(또는 상황변화)에 적응하는가 이다.
(4)전쟁의 안개
전쟁터라는 난리통에서 통신체계가 붕괴되면서 정확한 보고가 올라오지 않고 적들의 의도된 악성루머등으로 전투지휘자의 판단력을 흐리는 현상을 전쟁의 안개(fog of war)라고 한다. 이 전쟁의 안개는 IT프로젝트의 유지보수에도 그대로 나타난다. 설계서도 유지보수 가이드도 없고, 혹 있다하더라도 버전이 너무 낮아서 어떤 내용이 맞고 어떤 내용이 틀린지도 모르겠고, 소스는 여러사람의 손을 거쳐서 일관된 패턴도 없다.
실제 현장에서는 이럴때 아예 프로그램을 걷어내고 다시 만드는 방법이 더 비용이 적게 들때도 있다. 이글을 읽고 있는 IT종사자들은 자신이 만든 프로그램이 어느순간 지워져버리고 당신들이 고생한 의미도 같이 사라지게 되리라는 것을 알아야 한다.
이딴건 다안다. 그래서 어쩌라고?
라고 하는 말들이 들리는거 같다.
이글을 쓰는 이유는 travelogr.com의 제작과정은 기존 IT프로젝트의 수렁에 빠지는 일이 없도록 하기 위해서다. 당연히 대안에 대해서도 생각한다.
(1)짧은주기의 업데이트
IT프로젝트가 당장 눈에 보이지 않는다고 조급증을 가지지 말고 , 누가 쫓아와서 '당장 동작하는것을 보여봐'라고 말해도 꾸꿎이 설계를 한다. 게다가 설계가 얼마나 중요한지 오류를 구현과정에서 고치는것보다 설계과정에서 고치는 것이 얼마나 비용이 적게 먹히는지를 열심히 설득한다.
하지만 이런 대응은 우리자신도 자신이 없다. 설계를 아무리 잘해도 이후에 결국 다른 방향으로 수정될것이기 때문이다. 회사전략이 바뀔수도 있고 새로운 신기술을 도입할수도 있기 때문이다. 설계는 중요하다. 동시에 빠른 베타버전출시와 짧은주기의 업데이트가 더 중요하다. 결국 설계없이 코딩부터 하고 보자는 건가? 결국 다시 원점인가? 아니다 설계는 반드시 필요하다.
(2)최소한 아키텍처설계와 UI프로토타입은 반드시 만든다
이것만은 해야한다.
(3)워드프로세서로 문서를 만들지 마라. wiki를 써라
MS워드, 아래한글등으로 프로젝트문서를 만들지 마라.
버전관리가 안되고
여러명이 공동으로 작업할 수 없기 때문이다.
결정적으로 팀원들이 매일 수많은 프로젝트문서들을 열어보고 변경된 부분을 수정할것으로 기대할수 없기 때문이다.
이것에 대한 해결책으로 Wiki시스템을 적극추천한다. 물론 팀문화를 wiki의 생활화로 자연스럽게 유도해야 하는 전제조건이 있긴하지만 공동작업의 중요성에 대해서 인식하는 사람이면 무리없이 동의할것이라 본다. wiki에 요구사항, 설계, 아키텍쳐, 마케팅, 일정등등의 모든 내용에 대해서 기록하고 팀원들은 그것을 공유해야 한다. wiki는 팀워크다.
흔히 IT프로젝트를 건축에 비유한다. 설계-시공(구현)이라는 과정이 닮아서 일게다. 하지만 IT프로젝트는 베타버전까지는 눈에 보이지 않는다는 특징이 더 있다. 건축은 토목공사를 시작하면서 첫삽을 뜨게 되는데, 이때부터 공사과정이 다 보인다. 하지만 IT는 아무리 열심히 코딩을 해대도 베타버전까지는 아무것도 진척이라고 보이는게 없다. IT프로젝트 팀장과 사장님들의 조급성은 여기에서 나온다
(2)컨베이어벨트가 없다
포드가 자동차산업에 컨베이어벨트시스템을 도입하면서 획기적으로 생산성을 높였다는것은 교과서에 실릴 정도로 유명하다. 그럼 그전에는 어땠는가? 장인이 수작업으로 몇개월에 걸쳐 자동차 하나를 만들었다. 아주 개성이 넘치고 사랑스러운 자동차가 많았을거다. 빛이 있으면 그림자도 있는법. 만들때마다 서로 다른 자동차를 만드는 그 장인은 자신의 자동차가 몇월 며칠에 정확히 출고될지 예측할 수 있었을까? IT프로젝트에서 프로젝트종료일이라는 것은 '그때까지 일을 다한다'가 아니라 '그때까지 가능한한 많이하기'이다. 왜 그럴까?
자동차산업에서의 컨베이어벨트처럼 보편적인 개발방법론이 확립되지 않았기 때문에 수작업과 같은 조악한 방법으로 작업을 하게되는데, 보편적인 개발방법론이 없기때문에 요구사항과 추가요구사항이 수시로 발생하기 때문이다.
(3)설계서는 없다. UI자체가 설계서다
건축과 IT가 유사하다고 말은 하지만 IT에서 설계서를 찾아보기 힘들다. 있긴하지만 보고용 설계서다. 그냥 종이뭉치일뿐이고 아까운 펄프만 낭비하는 죄악이다. 진짜설계는 머리속에 있기도 하고 개발자들이 담배피우면서 하는 얘기속에 있기도 하다. 더군다나 고객(사용자)들은 프로젝트에 의견을 잘내지 않는다. 그러다가 막상 베타버전이 나오면 UI를 캠버스삼아 이리저리 요구사항을 마구 쏟아낸다. 이때부터가 문제다. 개발자들은 베타버전은 프로젝트의 마무리를 의미하지만 고객(사용자)들은 이제 겨우 시작이라고 생각한다. 주먹구구로 설계하는 개발자와 막상 UI가 나와서야 의견을 쏟아내는 고객(사용자). 둘다 왜이리 한심한가?
아니다 그들은 모두 유능하다. 만약 프로젝트 초기에 개발자들에게 제대로된 설계를 주고 고객(사용자)들에게는 요구사항을 조사했다라면 상황은 어땠을까? 조금 나을것이다. 하지만 큰 변화는 없을것이다. 아무리 초기에 요구사항을 조사하고 설계를 잘한다 하더라도 그둘은 계속 바뀐다. 시간이 갈수록 개발자(설계자)도 고객(사용자)들도 프로젝트에 대해서 좀더, 또는 다시 알게되기 때문이다.
어째거나 IT프로젝트의 성공여부는 얼마나 빨리 변경된 요구사항(또는 상황변화)에 적응하는가 이다.
(4)전쟁의 안개
전쟁터라는 난리통에서 통신체계가 붕괴되면서 정확한 보고가 올라오지 않고 적들의 의도된 악성루머등으로 전투지휘자의 판단력을 흐리는 현상을 전쟁의 안개(fog of war)라고 한다. 이 전쟁의 안개는 IT프로젝트의 유지보수에도 그대로 나타난다. 설계서도 유지보수 가이드도 없고, 혹 있다하더라도 버전이 너무 낮아서 어떤 내용이 맞고 어떤 내용이 틀린지도 모르겠고, 소스는 여러사람의 손을 거쳐서 일관된 패턴도 없다.
실제 현장에서는 이럴때 아예 프로그램을 걷어내고 다시 만드는 방법이 더 비용이 적게 들때도 있다. 이글을 읽고 있는 IT종사자들은 자신이 만든 프로그램이 어느순간 지워져버리고 당신들이 고생한 의미도 같이 사라지게 되리라는 것을 알아야 한다.
이딴건 다안다. 그래서 어쩌라고?
라고 하는 말들이 들리는거 같다.
이글을 쓰는 이유는 travelogr.com의 제작과정은 기존 IT프로젝트의 수렁에 빠지는 일이 없도록 하기 위해서다. 당연히 대안에 대해서도 생각한다.
(1)짧은주기의 업데이트
IT프로젝트가 당장 눈에 보이지 않는다고 조급증을 가지지 말고 , 누가 쫓아와서 '당장 동작하는것을 보여봐'라고 말해도 꾸꿎이 설계를 한다. 게다가 설계가 얼마나 중요한지 오류를 구현과정에서 고치는것보다 설계과정에서 고치는 것이 얼마나 비용이 적게 먹히는지를 열심히 설득한다.
하지만 이런 대응은 우리자신도 자신이 없다. 설계를 아무리 잘해도 이후에 결국 다른 방향으로 수정될것이기 때문이다. 회사전략이 바뀔수도 있고 새로운 신기술을 도입할수도 있기 때문이다. 설계는 중요하다. 동시에 빠른 베타버전출시와 짧은주기의 업데이트가 더 중요하다. 결국 설계없이 코딩부터 하고 보자는 건가? 결국 다시 원점인가? 아니다 설계는 반드시 필요하다.
(2)최소한 아키텍처설계와 UI프로토타입은 반드시 만든다
이것만은 해야한다.
(3)워드프로세서로 문서를 만들지 마라. wiki를 써라
MS워드, 아래한글등으로 프로젝트문서를 만들지 마라.
버전관리가 안되고
여러명이 공동으로 작업할 수 없기 때문이다.
결정적으로 팀원들이 매일 수많은 프로젝트문서들을 열어보고 변경된 부분을 수정할것으로 기대할수 없기 때문이다.
이것에 대한 해결책으로 Wiki시스템을 적극추천한다. 물론 팀문화를 wiki의 생활화로 자연스럽게 유도해야 하는 전제조건이 있긴하지만 공동작업의 중요성에 대해서 인식하는 사람이면 무리없이 동의할것이라 본다. wiki에 요구사항, 설계, 아키텍쳐, 마케팅, 일정등등의 모든 내용에 대해서 기록하고 팀원들은 그것을 공유해야 한다. wiki는 팀워크다.
이올린에 북마크하기