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