프로젝트 관리

<!> 미완성

Contents

이슈 관리 시스템과 wiki, 간트차트와 같은 툴을 이용해서 프로젝트를 관리하는 방법들에 대한 정보는 인터넷에서 쉽게 찾아볼 수 있다. 내가 정리하는 문서도 인터넷에서 찾아볼 수 있는 그것들과 큰 차이가 (아마도)없을 것이다. 굳이 시간을 들여서 정리하는 이유는 다음과 같다.

• 글로 남기지 않는 것은 내 지식이 아니라고 생각한다.
• 머리속에서 맴돌던 정보를 글로 정리하면서 새로운 아이디어를 얻을 수 있다.
• 다양한 성격의 프로젝트들이 있으며, 프로젝트 마다 서로 다른 관리 방법을 적용해야 한다. 글로 정리해 두면, 정리해둔 정보를 바탕으로 쉽게 응용할 수 있다.

이 문서는 프로젝트 관리 툴들에 대한 메뉴얼이 아니다. 툴들을 이용한 (나만의)프로젝트 관리 방법론을 정리하는게 목표다. 툴은 거들 뿐이다. 목적이 아니다.

1. 툴 들간에 큰 차이는 없다. jira, trac, bugzilla, redmind 별 차이 없다. 컨플루언스, miedia wiki, moniwiki 별 차이 없다. 때때로 jira + 컨플루언스 같은 경우 통합 환경을 제공하기 때문에 다른 툴들의 조합보다 강력하다고 하는데, 프로젝트에 큰 영향을 주는 정도는 아니다. 기타 일정관리 툴도 마찬가지. 큰 차이 없다
2. 프로젝트 관리에 대한 철학을 가진 사람은 어떤 툴을 사용해도 프로젝트 관리에 문제가 없다. 이것 저것 쓸만하다 싶은 툴들 끌어모아서 사용해도 프로젝트 잘 돌아간다.
3. 프로젝트 관리에 대한 철학이 없으면, 아무리 좋은 툴을 가져다 써도 도루묵이다. 그냥 사용하기 열라 복잡한 (그렇지만 멋진)장식품일 뿐이다.

이에 근거한 프로젝트 툴 선택에 대한 내 기준은

1. 어쨋든 툴은 사용해야 한다.
2. 사용하기로 했다면 최악만 아닌 것 선택하면 된다. 위에서 언급했듯이 별 차이 없다. 최선의 선택을 찾는거, 내가 봤을 땐 그냥 시간 날리는 거다. (각 툴들에 대한 정보를 수집하는게 목적이라면 나름의 의미는 있겠다.)
3. 접근성이 보장되야 한다. 언제, 어디서나 접근 할 수 있어야 한다. 예컨데 웹브라우저로 접근할 수 있어야 한다.

Ticket의 LifeCycle는 다음과 같다.

1. Open : 티켓이 만들어진다.
2. Assign : 티켓을 할당한다.
3. Progress : 티켓을 처리하는 과정이다. 필요에 따라 다른 사람에게 다시 Assign 되기도 한다.
4. Resolve : 티켓을 해결했다. 해결은 몇 가지 다른 상태가 있을 수 있다.
   • 해결 : 깔끔하게 해결했다.
   • 중복 : 같은 일을 하는 티켓이 있다.
   • 재현불가 : 문제를 재현할 수 없다.
   • 버그아님 : 버그로 보고를 했지만, 버그가 아닌 경우.
   • 잘 작동함 : 기능이 작동하지 않는다고 보고 했지만, 기능이 잘 작동할 경우가 있다. 보고자에게 기능이 작동하지 않았던 상황을 좀더 명확히 설명해달라고 요청할 수 있다.
   • 설명부족 : 설명이 부족해서 문제를 처리할 수 없다. 티켓 발행자와 담당자가 밀접하게 묶여있는 SI나 사내 프로젝트의 경우 "설명부족"이 있는 경우는 거의 없다. 오픈소스 프로젝트에서 주로 발생한다.
5. 티켓은 Close 하는 것으로 주기를 끝낸다.

Resolve와 Close는 권한을 가진 사람이 분리된다. Resolve는 티켓을 할당받은 사람(Assignee)이 일을 마쳤음을 알리기 위해서 사용한다. 하지만 아직 끝난 건 아니다. 티켓 발행자 혹은 프로젝트 메니저가 확인 하고 Close해야 비로서 일이 끝난다. 프로젝트 메니저가 Close 하기에 아직 부족하다고 생각하면, 이 티켓은 ReOpen 될 수 있다.

티켓이 여러 정보를 포함하면, 판단이 어려워진다. 티켓은 짧고 명료해야 하며, 하나의 정보만을 가지도록 구성해야 한다.

하나 이상의 밀접하게 연관된 JOB으로 구성된 티켓을 발행해야 하는 경우도 있을수 있다. JOB이 밀접하게 연관되어 있을 경우 이것들을 분리하면 오히려 작업내역을 판단을 어렵게 할 수도 있는데, 이런 JOB은 서브 티켓으로 구성한다.

Due Date를 짧게하려면 업무를 잘게 쪼갤 수 있어야한다. 그런데 업무를 쪼개는게 쉬운일이 아니다. 업무를 잘 이해하고 있어야지만 업무를 잘 쪼갤 수 있다. 예컨데 이 원칙을 지키려면 "맡은 업무를 먼저 잘 분석해야"한다.

분석을 통한 업무쪼개기는 전문화를 달성하기 위해서 사용하는 일반적인 방법이다. 전문화는 업무의 효율적인 처리를 가능하게 해주기도 하지만 자칫 업무처리자로 하여금 업무의 전체적인 흐름을 놓치게 만들 수도 있다. 따라서 해야 하는 전체 업무를 먼저 설명하고, 업무를 분석하고 티켓을 발행하는 과정을 업무처리자와 함께 진행하는게 좋다.

제대로된 답을 얻을려면 제대로된 질문이 필요하다. 티켓은 질문을 만드는 과정으로 제대로된 답을 얻을려면 제대로된 내용을 가진 티켓을 만들어야 한다. 티켓 그 자체로 "자기 완결성"을 가져야 한다. 다시 말해서 다른 것 볼필요 없이 티켓만으로 작업요청자가 무엇을 원하는지를 확인할 수 있어야 한다.

때때로 요청 내용을 대충 요약하고 "자세한 내용은 wiki 페이지"를 참고하세요 라고 하는 경우가 있는데, wiki페이지를 참고하지 않더라도 모든 내용을 이해할 수 있어야 한다.

좋은 티켓을 만드는 가장 확실한 방법은 "상대방의 입장에서" 생각하는 거다. 복잡하게 생각할 것도 없다. 육하원칙을 따르면 된다. 라고는 하지만 이게 말 처럼 쉬운게 아닌게 문제다. 커뮤니케이션이 제일 어렵다는 말이 괜히 나오는게 아니다. 꾸준히 노력하는 수 밖에 없다.

나는 가능하면 아래의 정보들을 포함하도록 티켓을 만든다.

1. 현재 상태 : 이 티켓과 관련해서 현재의 상태를 기술한다. 예컨데, "어느어느 조직과 요러한 논의를 했고 그래서 지금 기본뱡향은 이러하다."등의 내용을 포함한다.
2. 해결해야 하는 문제 : 현재 상태에서 업무를 진행하려고 하니, 이러한 문제가 있다. 혹은 이러한 기능을 개발해야 한다 등등. 문제를 제기한다.
3. 티켓이 반드시 포함해야할 내용을 구체적으로 명시한다. 예컨데 VPN 설정을 하려고 한다면 "1. OpenVPN을 이용한다. 2. A와 B를 Site-to-Site로 연결한다. 3. Subnet 정책을 포함해야 한다. 4. B는 A의 git, dbms, chef등에 접근할 수 있어야 한다. 5. A가 서버가 된다. 6. A와 B는 서로의 IP에 대해서만 접근을 허용해야 한다. 7. 관련내용은 wiki에 정리하고 링크를 알려줘야 한다"
4. 참고할 문서들은 링크를 걸어둔다.

관리하는 이슈의 종류에 따른 적당한 툴들이 있다. 예를 들어 Trello는 작업목록을 관리하기에는 좋지만 소프트웨어 이슈를 추적하기에는 좋은 편은 아니다. Jira는 소프트웨어 개발 이슈부터 영업이슈, 기획이슈, 작업목록 등 다양한 이슈를 통합해서 관리할 수 있지만 작업목록에 관해서라면 Trello에 미치지 못하고, 소프트웨어 이슈추적은 Bugzilla에 미치지 못한다.

• Jira : 요즘은 Jira를 이용해서 관리하고 있다. 강력하고 복잡하다. 상용 소프트웨어다.
• Bugzilla : 주로 소프트웨어 이슈를 관리하기 위한 목적으로 사용한다. 오랜 전통을 자랑한다.
• Trello : 작업관리에 최적화됐다. 애자일하게 일하는 조직이라면 유용하게 사용할 수 있을 거다.
• Trac : 소프트웨어 이슈관리를 위한 목적으로 사용한다. 형상관리 시스템과 위키까지 함께 제공하는 토탈 솔류션이다. Jira와 가깝다고 볼 수 있겠다.

내가 즐겨 사용하는 프로젝트 관리 툴이다.

이슈 추적 시스템은 전문화 시스템으로 프로젝트를 분석하고 원자화 해서 하나씩 해결해 나가는 것으로 전체 문제를 해결하려 한다. 이 방식은 전문화 시스템의 단점을 그대로 가지고 있다. 작은 문제들은 해결했는데, 프로젝트를 놓칠 수 있다. 전투에서는 승리했는데, 전쟁에서 지는 상황이 발생할 수 있다.

나는 이 문제를 마인드맵을 그리는 것으로 해결한다. 마인드맵을 그리면서 프로젝트 전체에 대한 이해도를 높이는 것으로 전문화 시스템의 단점을 보완할 수 있다. 마인드 맵 프로그램으로는 공개 소프트웨어인 mindmup을 사용하고 있다. Progress 플러그인을 설치하면, 그림처럼 각각의 노드에 진행상황을 표시할 수 있다.

https://lh5.googleusercontent.com/-Oqu9WjoiVx4/Up3s4hM5qjI/AAAAAAAADbw/DspIJGFnynA/s800/IOT.png