우리가 만든 진단을 우리 팀 차터로 옮긴 둘째 주

세 사람의 강점 진단 결과를 한 장에 펼쳐놓고 처음 든 생각은 솔직히 적지 않은 우려였습니다. 8개 강점 영역 가운데 '추진(Propel)'이 0명, '완성(Complete)'이 1명. 결정된 것을 끝까지 밀어붙이는 사람도, 마무리를 책임지는 사람도 사실상 없는 셈이었습니다. 우리가 만든 진단이 우리 자신을 향했을 때 가장 먼저 보여준 것은 빈 칸 두 개였습니다.

그날 팀원들에게 제가 한 말은 어쩌면 당연한 것이었습니다.

"우리가 만드는 것을 우리가 쓰지 않으면 의미가 없지 않을까요?"

태니지먼트는 사람의 강점과 약점을 진단하고 해석하는 회사이고, 저는 그 팀의 PL입니다. 강점은 더 잘 쓰이도록 설계되어야 하고, 약점은 문제가 되기 전에 보완되어야 한다고 우리는 고객에게 말해 왔습니다. 그런데 정작 제가 운영하는 스프린트는 이 언어로 설계되어 있지 않았습니다. 비즈니스 케이스에는 과제의 필요성이, 프로젝트 차터에는 목표와 일정이 적혔지만, 그 일을 수행하는 사람의 강점과 공백은 차터의 어느 칸에도 들어와 있지 않았습니다.

이 글은 PL의 자리에서 그 빈 칸을 차터로 옮긴 둘째 주의 기록입니다.

도그푸딩이라는 거울

제품을 만드는 팀에는 오래된 표현이 있습니다. "Eat your own dog food." 자기 회사의 개 사료를 먹어보라는 거친 말이지만, 의미는 분명합니다. 사용자에게 권하는 가치를 우리도 실제로 믿고 있는지 확인하는 가장 빠른 방법이라는 뜻입니다.

PL의 자리에서 도그푸딩을 다시 정의하면, 그것은 제품의 기능이 아니라 제품의 세계관을 검증하는 일입니다. 우리가 만든 언어가 현장에서 작동하는가. 우리가 설계한 경험이 실제 행동을 바꾸는가. 우리가 약속하는 가치를 우리가 먼저 살고 있는가. 우리 팀 진단을 처음 마주했을 때 가장 마음에 걸린 지점은, 제품을 설명하는 자리에서는 강점 기반 협업을 말하면서 정작 제가 쓰는 차터에는 그 언어가 없다는 사실이었습니다.

이번 스프린트가 우리 팀에 그 언어를 처음 들이는 시도입니다. 그래서 저에게 도그푸딩은 우리 제품에 로그인해서 기능을 눌러보는 일이 아니라, 우리가 만든 진단 언어를 제가 짜는 차터 안에 처음 들이는 일이었습니다.

---

강점은 살리고, 공백은 제도로 메운다

원칙은 한 줄로 정리됩니다.

강점은 살리고, 공백은 제도로 메운다.

비즈니스 케이스가 "왜 지금 이 일을 해야 하는가"에 답한다면, 프로젝트 차터는 "어떻게 성공시킬 것인가"에 답하는 문서입니다. 그동안 제가 쓰던 차터는 과제 중심이었습니다. 무엇을, 언제까지, 누가, 어떤 기준으로 만들 것인가. 저는 여기에 한 줄을 더하기로 했습니다. 이 일을 수행하는 사람은 어떤 강점과 공백을 가지고 있고, 그 조건이 어떤 운영 장치로 차터에 박혀야 하는가.

PL로서 가장 조심한 부분은 이것이 사람을 평가하는 기록이 되지 않게 하는 것이었습니다. 약점을 적는 칸은 사람을 탓하는 자리가 아니라, 약점이 터질 수밖에 없는 자리를 시스템이 메우게 하기 위한 설계여야 했습니다. 추진의 공백이 있다면 결정 이행을 외부 역할이 점검하게 만들고, 완성이 한 사람에게 쏠려 있다면 마무리 책임을 셋이 나눠 갖게 하는 식입니다. 약점은 비난의 근거가 아니라 보완책을 설계하기 위한 힌트라는 메시지를, 차터의 형식이 먼저 증명해야 한다고 봤습니다.

이 원칙이 들어오자 차터의 거의 모든 칸을 다시 보게 됐습니다.

내가 차터에 박은 다섯 개의 장치

처음에는 추상적인 일곱 개의 질문 리스트로 정리해 봤습니다. "참여자는 누구인가", "주요 강점은 무엇인가", "예상 약점은" 같은 질문들. 그러나 PL로서 차터를 굴려본 경험에 비추어 보면, 질문은 답을 강제하지 않는 한 결국 빈 칸으로 남기 쉽습니다. 그래서 질문 리스트를 버리고 운영 장치를 직접 박는 길을 택했습니다.

양면 합의 카드. 합의 시점마다 동의·반대·보류를 분리해 적되, 반대 칸을 비워둘 수 없게 만든 양식입니다. 저를 포함해 우리 팀 세 사람 모두 진단에서 갈등 표면화가 늦은 패턴을 공유한다는 결과가 나왔기 때문입니다. 표면 합의는 빠르지만 묻혀둔 이견이 후반에 한꺼번에 폭발하는 경험을 저도 여러 차례 했고, 그 패턴을 이 작은 의례로 차단하기로 했습니다.

공식 반대 라운드. 산출물이 잠기는 게이트마다 각자가 묻혀둔 우려 한 가지를 의무로 발화하게 하는 5분짜리 의례입니다. 합의 카드가 매 결정 단위에서 작동한다면, 반대 라운드는 잠금 직전 마지막 안전핀입니다. PL이 라운드를 진행할 때 가장 중요한 것은, "할 말 없다"는 답을 받지 않는 것이라고 저는 생각합니다.

단일 모드 룰. 한 시점에 한 사람의 주 작업이 항상 한 가지여야 한다는 룰입니다. 깊이 들어갈 때 강점이 가장 잘 발휘되는 사람의 진단 결과를 그대로 실행 환경으로 옮긴 것이고, 컨텍스트 스위칭 비용을 0으로 만듭니다. 이 룰을 박으면서 저는 PL로서 일정 압축 카드 한 장을 포기한 셈입니다. 대신 결과물의 일관성을 얻었습니다.

조건부 인력 재배치. 한 사람의 작업량 추산이 위험 수위에 들면 옆 사람이 같은 작업에 잠시 합류해 일정을 압축합니다. 같은 영역을 두 사람이 만지면 충돌이 생기므로, 책임 영역을 페이지·뷰·컴포넌트 단위로 미리 분리하는 룰을 함께 둡니다. PL인 제가 직접 코딩에 합류해야 하는 경우의 룰까지 차터에 사전 합의로 박아놨습니다. 완성의 쏠림을 사람의 인내가 아니라 구조로 분산하는 장치입니다.

회복 블록. 회의와 발표가 없는 90분짜리 시간을 주에 두 번 차터에 의무로 박았습니다. 진단 결과 우리 팀 전원이 외향성이 약한 패턴을 보였기 때문입니다. PL이 회의를 잡을 때 가장 자주 깨지는 시간이 바로 이 블록이고, 그래서 저는 제 자신이 이 블록을 가장 먼저 지켜야 한다고 봤습니다.

이 다섯 가지가 전부는 아닙니다. 1:1 의례, Evidence 로깅의 공동 책임, Done 체크리스트의 3중 분담까지 — 차터의 거의 모든 칸이 진단 결과의 특정 강점이나 공백, 패턴에 일대일로 대응합니다. PL로서 매핑 작업을 하면서 가장 중요하게 본 것은 룰의 개수가 아니라 매핑의 방향이었습니다. 진단의 모든 신호가 차터 안에 자리를 가져야 하고, 차터의 모든 룰은 어떤 진단 근거에서 나왔는지 제가 설명할 수 있어야 했습니다. 매핑이 끊어지는 순간, 차터는 다시 일반론으로 돌아갑니다.

신념을 시스템으로 만드는 마지막 한 단계

좋은 일이 좋은 일로만 머무르면 그것은 신념이 아니라 분위기입니다. PL로서 가장 경계한 지점이 바로 여기였습니다. 그래서 저는 차터의 운영 건강을 매주 측정하기로 했습니다.

양면 합의 카드의 반대 칸이 비어 있지 않은 비율, Daily 블로커 핀의 전원 응답률, 게이트의 정시 통과 여부, 반대 라운드의 의무 발화 인원수, 회복 블록에 회의가 잡힌 비율. 다섯 개의 지표가 매주 차터의 신념이 어떤 모양으로 작동하고 있는지를 보여줍니다. 이 다섯 줄은 PL로서 PO에게 보내는 주간 보고의 핵심이기도 합니다.

지표가 임계치 아래로 떨어지면 룰을 다시 검토합니다. 합의 카드의 반대 칸이 3주 연속 비어 있다면 그 양식 자체가 현장에서 무겁게 작동하고 있다는 뜻이고, 조건부 재배치가 분기 절반 이상 발동한다면 그것은 임시 장치가 아니라 인력 구조 자체의 신호일 수 있습니다. 후자는 PL의 운영 룰로 메울 수 있는 영역을 넘어선 신호이고, 그 시점에는 PO와 함께 인력 보강 논의로 들어갑니다.

지표가 룰을 만들고, 룰이 다시 지표로 측정되는 순환. 이것이 PL의 자리에서 차터를 글이 아니라 시스템으로 만드는 단계입니다.

내가 만든 것을 내가 쓴다는 것

이 방식을 도입한 이유는 차터를 더 잘 쓰기 위해서가 아니라, PL로서 우리가 고객에게 말하는 가치를 제가 먼저 증명해야 한다고 생각했기 때문입니다. 강점은 발견에서 끝나면 안 되고, 관계 시너지는 이해에서 끝나면 안 되며, 개인의 고유성은 리포트 안에 갇혀 있으면 안 된다고 우리는 말해 왔습니다. 그렇다면 제가 짜는 차터부터 그렇게 일하게 만들어야 한다고 봤습니다.

이번 첫 스프린트를 PL로서 운영해보며 새롭게 배우고 있는 것은, 제품과 운영이 서로를 학습하게 만든다는 점입니다. 차터에 진단을 담아보면, 어떤 표현은 너무 추상적이고 어떤 표현은 바로 행동으로 연결되는지가 보입니다. 어떤 리포트 문장은 공감은 되지만 실행 장치로 옮기기 어렵고, 어떤 문장은 역할 배치를 바꾸는 데 직접적인 힌트가 됩니다. 이 경험은 다시 제품팀의 의사결정으로 돌아옵니다. 리포트를 더 실행 가능한 언어로, 관계 시너지 해석을 더 현실적인 협업 장치로 바꾸자는 제안의 근거가 되는 셈입니다. 제가 우리 제품을 쓰는 이유는 그래서 신념의 문제만이 아니라, 더 좋은 제품을 만들기 위해 PL이 가장 먼저 빠질 수 있는 학습의 자리이기도 합니다.

PL로서 제가 다시 정리하면 이렇습니다. 강점은 리포트의 문장이 아니라 차터의 칸과 게이트의 잠금 조건 안에서 작동해야 합니다. 약점은 감춰야 할 결함이 아니라 미리 설계해야 할 리스크이고, 매주 측정되는 지표입니다. 관계 시너지는 좋은 팀워크라는 추상이 아니라, 역할과 리뷰와 의사결정 방식에 반영되어 매주 한 줄의 숫자로 잡히는 실행 변수입니다.

그래서 저는 비즈니스 케이스에서 프로젝트 차터로 넘어갈 때, 과제만 보지 않습니다. 그 일을 수행하는 사람도 함께 봅니다. 왜 해야 하는지에서 멈추지 않고, 누가 어떤 방식으로 해야 가장 잘될 수 있는지를 설계하고, 그 설계가 실제로 작동하고 있는지를 매주 한 줄의 숫자로 확인합니다.

이것이 PL의 자리에서 제가 우리 제품을 쓰는 방식이고, 다음 스프린트 회고에 다시 적히게 될 출발점입니다.