프로젝트를 실패하는 방법

User Story Applied

프로젝트가 성공하기 위해서는 다양한 정보가 필요하다. 일부는 고객, 사용자, 때로는 분석가, 해당 분야 전문가, 소프트웨어를 사업적, 조직적 시각에서 바라보는 사람들이며, 그 반대편은 기술팀이다.

만일 어느 한쪽이 의사소통에서 우위를 차지한다면 프로젝트는 실패하게 된다. 

비즈니스 쪽 사람들이 우위를 차지하게 되면, 그들은 기능과 마감시한을 동시에 요구할 것이다. 개발자들이 이 두 가지 목표를 달성할 수 있는지, 요구사항을 정확히 이해했는지 등에 대해서는 별로 고려하지 않을 것이다.

 

반면 개발자들이 의사소통에서 우위를 차지하게 되면, 비즈니스 언어 대신 기술적인 용어들이 난무하게 될 것이고 개발자들은 정작 필요한 것이 무엇인지 알 수 없게 될 것이다.

우리에게 필요한 것은 함께 일하는 방법이다. 그리하여 어느 한쪽이 우위를 점하지 않으며, 감정적으로 흐르거나 혹은 정치적일 수 있는 자원 할당 문제를 공동의 문제로 공유하는 것이다. 자원 할당 문제를 어느 한쪽에만 떠맡기는 프로젝트는 실패한다. 

개발자에게 짐을 씌운다면(이는 주로 "어떻게 하는지는 모르고, 6월까지 모든 기능을 완성하시오."와 같은 말로 표현된다), 그들은 추가 기능을 구현하기 위해 품질은 뒤로 미룰지도 모른다. 혹은 기능을 일부만 구현한다거나, 고객과 사용자들이 꼭 참여해서 함께 결정해야 할 사항을 독단적으로 처리하는 경우가 발생할지도 모른다.

반대로 고객과 사용자에게 자원 할당 문제의 짐이 맡겨진다면,  프로젝트의 초기에 지루한 논의만 계속하다가 기능들을 점차 제거하게 될 것이다. 그리고 결국 완성된 소프트웨어는 이렇게 줄어든 기능 목록보다도 훨씬 적은 기능만 구현되어 있을 것이다.

우리는 지금까지의 경험으로 소프트웨어 개발 프로젝트가 어떻게 진행될지 완벽하게 예측하는 것이 불가능한 일임을 잘 안다. 사용자들은 소프트웨어의 초기 버전을 보고 나면 새로운 아이디어를 가져오고, 처음과 생각도 달라진다.

소프트웨어의 무형성 때문에 개발자들은 프로젝트가 얼마나 걸릴지 추정하는 데 많은 어려움을 겪는다. 이런 저런 요인들 때문에 프로젝트에서 수행할 모든 작업을 보여주는 완벽한 퍼트 차트를 펼쳐 놓는 것은 불가능하다.