시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 17편이자, 4막의 시작입니다. 3편부터 16편까지 14개 도구를 해부하고 두 진영을 비교했습니다. 이제 그 모든 길이 모이는 한 점에 도착합니다. 왜 그렇게 좋다는 도구를, 정작 팀원들은 끝내 쓰지 않는가? 0편에서 던진 질문에, 이제 답합니다.
들어가며
긴 여정이었다. Jira의 강력함, Trello의 단순함, Linear의 아름다움, Redmine의 통제권 — 14개 도구는 저마다의 미덕이 있었다. 그런데 우리는 매번 같은 자리에서 멈췄다. 도구가 아무리 좋아도, 팀의 절반은 그것을 열지 않았다.
이건 우연이 아니다. 14번 반복된 건 패턴이고, 패턴은 원인이 있다. 이 글은 그 원인을 끝까지 추적한다. 결론을 미리 말하면 이렇다 — 문제는 도구가 아니라, 도구가 설계되는 방식이다.
1. 게으름이 아니다
가장 먼저 치워야 할 오해. “팀원이 도구를 안 쓰는 건 게을러서다.” 틀렸다.
같은 팀원이 메신저는 하루 종일 쓴다. 슬랙·카톡·이메일에는 즉각 반응한다. 그들은 도구를 쓰기 싫은 게 아니다. 특정 도구를 쓰기 싫은 것이다. 그렇다면 질문은 “왜 게으른가”가 아니라 “이 도구는 왜 외면받는가”여야 한다. 사람을 탓하는 진단은 늘 틀린 처방으로 이어진다.
2. 세 가지 공통 실패
14개 도구를 관통한 실패는 셋으로 모인다.
실패 하나 — 입력이 곧 보고였다. 2편에서 짚었듯, 소프트웨어의 진행은 누군가 입력해야만 보인다. 그런데 그 입력은 일이 아니라 ‘일에 대한 보고’다. 팀원은 코드를 짜고, 디자인을 하고, 문서를 쓴다 — 그게 그의 일이다. 그런데 도구는 거기 더해 “그 일을 했다고 도구에 또 적어라”라고 요구한다. 16편 채점표에서 봤듯, 14개 도구 중 단 하나도 이 이중 노동을 없애지 못했다. 한 번 일하면 한 번 더 보고해야 했다.
실패 둘 — 도구는 관리자를 위해 설계됐다. 화면의 주인공은 늘 대시보드, 진행률, 포트폴리오, 간트였다. 이것들은 누구를 위한 것인가? PM과 경영진이다. 팀원에게 필요한 건 “오늘 내가 할 일 세 개”인데, 도구는 그 위에 관리용 레이어를 잔뜩 얹었다. 그래서 팀원에게 도구는 ‘내 일을 돕는 곳’이 아니라 ‘윗선이 나를 보는 곳’이 됐다. 감시받는 느낌이 드는 도구를 누가 자발적으로 열겠는가.
실패 셋 — 강력함과 단순함이 양립하지 못했다. Jira는 강력했지만 복잡했고, Trello는 단순했지만 얕았다. 도구들은 시소 위에 있었다. 기능을 더하면 팀원이 떠나고, 덜어내면 관리가 부실해졌다. 누구도 “팀원에겐 단순하고, 관리자에겐 충분한” 두 얼굴을 동시에 갖지 못했다.
3. 세 실패는 하나의 뿌리에서 나온다
이 셋은 따로가 아니다. 한 뿌리에서 자란 가지다. 그 뿌리는 이것이다.
기존 도구는 “관리자가 보기 위한 그릇”으로 설계됐고, 그 그릇을 채우는 노동은 팀원에게 맡겼다.
도구의 출발점이 ‘가시성’이었기 때문에, 화면은 관리자를 향하고(실패 둘), 그 가시성을 위해 팀원의 입력이 필요하며(실패 하나), 더 많이 보이려 할수록 도구는 복잡해진다(실패 셋). 세 실패가 모두 이 한 줄에서 흘러나온다. 도구를 바꿔도 이 출발점이 같으면, 결과도 같다. 그래서 14번 반복됐다.
4. 그렇다면 질문을 뒤집어야 한다
문제의 뿌리가 ‘출발점’이라면, 해법도 출발점을 바꾸는 데 있다. 지금까지의 도구는 이렇게 물었다.
“관리자가 현황을 잘 보게 하려면, 팀원이 무엇을 입력하게 할까?”
이 질문이 모든 실패의 씨앗이었다. 질문을 뒤집어야 한다.
“팀원이 자기 일을 하는 것이, 그 자체로 관리자의 현황이 되게 하려면 어떤 구조여야 할까?”
이 질문에서는 입력과 보고가 분리되지 않는다. 팀원은 자기 일만 하면 되고, 관리자의 가시성은 그 부산물로 저절로 생긴다. 화면은 팀원을 향하되, 그 데이터가 위로 자동으로 흐른다. 감시가 아니라 협업이 된다.
이것이 가능한가? 14개 도구는 못 했다. 출발점이 반대였기 때문이다. 하지만 출발점을 바꾸면 — 가능할지 모른다.
짚고 가기: 14개 도구의 실패는 무능이 아니라 방향의 문제였다. 모두 “관리자가 보기 위한 도구”라는 같은 방향에서 출발했다. 그래서 더 좋은 도구를 만들수록, 더 정교하게 같은 실패를 반복했다. 답은 더 나은 도구가 아니라, 출발점이 반대인 도구다 — 팀원에서 시작해 관리자로 흐르는 구조.
다음 편 예고
이제 시리즈가 처음부터 향해온 곳에 도착했다. 다음 편(18부)에서는, 방금 뒤집은 그 질문에서 출발한 새로운 모델을 소개한다. PSTA — Project·Service·Team·Action. 이름이 곧 구조이고, 그 구조가 “팀원에서 시작하는” 발상을 어떻게 담아냈는지 본격적으로 풀어낸다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 16. 상용 vs 오픈소스 — 무엇을 언제 선택해야 하는가
다음 글: IT 프로젝트 관리 도구 완전 해부 – 18. PSTA의 발상 — Project·Service·Team·Action이라는 구조
