회사에 다닐 때, 몇몇 프로젝트 관리 도구들 – Microsoft Project나 dotproject 같은 웹 기반 도구들을 사용해보았는데, 쓸데없이 너무 복잡하거나, 필수적인 기능이 빠져있는 경우가 많았을 뿐만 아니라, 사용하기가 너무 불편했다.
XP 방법론이나 TDD 같은 practice를 보면서, 그러한 방법론에 잘 들어맞는 툴이 없다는 것도 느낄 수 있었다.
예를 들어, XP 방법론에서는 User Story로부터 요구사항을 수집하고 구현해야할 기능들을 찾아낸다. 그리고 이러한 기능들 중, 특정 기간 내에 개발할 기능들을 골라낸다. 기능별로 여러 사람들에게 분배되고, 기능을 구현하면서 또는 사용자의 피드백을 통해 추가적으로 찾아낸 기능들은 다음번에 구현할 기능으로 넣어둔다. 이러한 프로세스를 따라가면서 기존의 프로젝트 관리 도구를 사용해보라. 페이지를 이리저리 왔다갔다 해야하고, 불필요한 수많은 정보들을 입력해야한다. 방법론이 강조하는 프로세스를 따라가면서, 프로젝트 관리자나 개발자가 프로세스 상에서 발생하는 정보를 자연스럽게 입력하고 조회하는 것은 매우 불편하다.
한마디로, 방법론 상의 프로세스와 프로젝트 관리 도구의 사용성은 잘 들어맞지 않는다. 하지만, 복잡한 프로젝트 관리 도구들을 사용하더라도 위의 프로세스에서 발생하는 정보들을 모두 표현할 수는 있다. 그렇다면 무엇이 문제인가?
그 이유는, 여러가지 방법론 사이의 중요한 차이점이 그것들이 가지고 있는 정보가 아니라, 정보가 전달되는 방법과 방향의 특성 – 프로세스에 있기 때문이다. 우리에게는 프로세스의 흐름을 잘 반영하는 도구를 찾아보기가 힘들다. 만약 이러한 요구를 잘 반영한 도구가 있다면, 요구의 반영은 잘 신경써서 만들어진(crafted) 사용자 인터페이스의 형태로 나타날 것이다. 이러한 점에서, 프로젝트 관리 도구의 불편함은, 도구의 기능적인 면과 도구가 다룰 정보에만 치중하고, 사용자 인터페이스 즉, 도구를 다루는 방법은 무시하는 프로그래머들의 일반적인 경향이 반영된 결과일런지도 모른다.
한편, 기존의 프로젝트 관리 도구들은 방법론의 특성을 제대로 반영하지 못할 뿐만 아니라, 그러한 방법론이 실무에 적용되면서 발생하는 변형들도 잘 반영하지 못한다.
프로세스 상의 약간의 변형이나, 필요한 정보 자체의 변형이 발생하는데, 대부분의 프로젝트 관리 도구는 이러한 변형을 잘 반영할만한 유연성을 갖추고 있지 못하다. 반대로, 특정 방법론(이른바 표준 방법론)에 잘 맞춰져있는 도구에 자신들의 방법론을 맞추는 것은 완전히 어불성설이다. (이는 많은 사람들이 저지르는 실수중의 하나이다.) 프로젝트의 환경에 따라 방법론은 적절하게 변형되기 마련이다.
nohmad 옹의 최근의 웹 어플리케이션에 관한 글에서 소개된 sproutliner는 작업 관리를 위한 도구다. sproutliner는 자기가 원하는 대로 작업 항목의 필드를 늘리거나 줄일 수 있는데, 위와 같은 프로젝트 관리 도구상의 필요를 반영하는 것이 아닐까. 물론 작업 관리라는 한정된 기능을 수행하고 있고, 정보의 변형에 있어서의 요구만을 반영하고 있어서, 아쉬운 점이 좀 남는다.
또, 어떻게 보면, 방법론에 무관하게 유연한 도구를 만들고 싶다는 목적을 달성하기 위해서는, 커다란 단일한(monolithic) 도구가 아니라, sproutliner처럼 서로 통신할 수 있고 조합할 수 있는 작은 단위의 도구들의 형태를 가져야할 지도 모른다.
기회가 된다면, 내 주변의 – 나 자신 또는 나를 포함한 팀의 – 방법론에 잘 들어맞는 프로젝트 관리 도구를 만들어보고 싶다.