관리의 공학적 접근 - 템플릿, 표준코드, 그리고 체크리스트

실무이야기 - 4

관리를 잘한다는 것이 무엇입니까

연구는 공학으로 대접받습니다. 방법이 있고, 축적된 지식이 있고, 배워야 할 수 있다는 합의가 있습니다.

그런데 그 연구를 관리하는 일은 그렇게 취급되지 않습니다. 열심히 챙기면 되고, 꼼꼼하면 되고, 경험이 쌓이면 는다고 봅니다.

그래서 관리를 잘한다는 말이 대체로 사람에 대한 평가로 쓰입니다. "그분이 관리를 잘하셨죠."

그런데 그 사람이 나가면 그 관리 수준도 함께 나갑니다.

오늘은 그것을 조직에 남기는 방법에 대한 이야기입니다.

Manual로 관리한다는 것

공학은 같은 조건이면 같은 결과가 나오게 만드는 일입니다. 그러려면 조건을 표준으로 정의하고, 조건과 결과의 관계를 관찰하고, 관찰한 것을 다시 표준에 반영해야 합니다.

Manual 방식이 나쁘다는 뜻이 아닙니다. 숙련된 사람이 그때그때 판단해서 처리하는 방식은 빠르고 유연합니다. 다만 조직에 쌓이지 않습니다.

관리 방법이 표준으로 정의되어 있지 않으니 무엇을 어떻게 했는지가 기록되지 않습니다. 기록이 없으니 비교할 수 없고, 비교할 수 없으니 학습이 안 됩니다.

관리를 공학으로 다룬다는 것은 이 순환을 돌리겠다는 뜻입니다.

다섯 가지와 그 관계

먼저 용어를 정리하고 시작하겠습니다.

표준코드 — 회사 전체에 하나 있는 사전입니다. 관리 방법(일정을 어떻게 볼지, 비용을 어느 단위로 잡을지)과 활동(기관 선정, 시험 의뢰, 계약 검토)이 이름과 코드로 정의되어 있습니다.

프로젝트 유형 — 우리 회사가 반복 수행하는 과제의 종류입니다.

템플릿 — 유형별로 표준코드에서 골라 조합한 것입니다.

체크리스트 — 각 활동에서 무엇을 확인해야 하는지입니다.

산출물 — 활동을 수행하면서 남는 것입니다. 확인 결과, 그때의 판단, 그리고 견적서나 검토 의견서 같은 문서.

이렇게 이어집니다.

유형이 정해지면 템플릿이 따라옵니다. 새 과제를 등록할 때 담당자가 하는 일은 유형을 고르는 것뿐이고, 나머지는 딸려 옵니다.

활동마다 체크리스트가 붙습니다. 다만 활동 코드 하나에 체크리스트 하나가 아닙니다. 같은 "기관 선정"이라도 탐색형 과제에서 위탁 기관을 고를 때와 개발형 과제에서 시험 기관을 고를 때는 봐야 할 것이 다릅니다. 체크리스트를 특정하는 것은 유형과 활동 코드의 조합입니다.

활동을 수행하면 산출물이 남습니다. 활동 코드 단위로요.

골격과 내용물

표준코드는 골격이고, 체크리스트는 내용물입니다.

코드가 담는 것은 "어떤 방식으로 관리하는가"까지입니다. 그 활동을 실제로 할 때 무엇을 확인해야 하는지는 체크리스트에 있습니다.

그리고 움직이는 속도가 다릅니다.

관리 방식은 자주 바뀌지 않습니다. 일정을 마일스톤에서 활동 단위로 바꾸는 결정은 웬만해서는 일어나지 않고, 그게 정상입니다. 골격이 자주 바뀐다면 처음에 잘못 정한 것입니다.

체크리스트는 다릅니다. 과제를 할 때마다 새로 알게 되는 것이 생기고, 그것이 항목에 반영됩니다.

쌓아온 것이 아니라 지금의 최적입니다

여기서 이 체계가 무엇인지 분명히 하겠습니다.

템플릿과 체크리스트는 지금까지 쌓아온 것의 총합이 아닙니다. 현재 시점에서 우리가 아는 가장 나은 방식입니다.

이 구분이 중요합니다.

"쌓아온 것의 총합"으로 보면 좋은 템플릿은 항목이 많은 템플릿입니다.

"현재 시점의 최적"으로 보면 다릅니다. 좋은 템플릿은 지금 조건에서 봐야 할 것들이 정확히 들어 있는 템플릿입니다. 3년 전 규제 기준으로 확인하는 항목이 남아 있으면 그건 축적이 아니라 노후입니다.

그래서 갱신은 더하는 일이 아니라 맞추는 일입니다. 바뀐 것은 교체되고, 지금은 중요하지 않은 것은 빠지고, 새로 알게 된 것이 들어옵니다. 총량은 크게 늘지 않고, 최적 상태가 유지됩니다.

마스터 데이터로 관리합니다

표준코드와 템플릿과 체크리스트는 마스터 데이터입니다. 각 과제에서 담당자가 알아서 고치는 것이 아니라 권한을 가진 관리자가 관리합니다.

각자 고칠 수 있으면 같은 활동인데 과제마다 다른 코드로 기록됩니다. 그러면 "기관 선정"으로 조회해도 지난 과제들이 안 나옵니다. 코드가 같아야 그 활동을 예전에 어떻게 했는지 불러올 수 있습니다.

다만 엄격함의 정도는 층마다 달라야 합니다. 골격일수록 엄격하게, 내용물일수록 느슨하게. 체크리스트 항목 하나 고치는 데 결재를 받아야 한다면 아무도 안 올립니다.

그리고 현장에서 올라오는 길이 있어야 하고, 그것이 별도 업무가 아니어야 합니다. 과제를 끝내면서 "다음 사람이 알아야 할 것"을 적는 자리가 종료 처리 안에 있으면 됩니다.

쌓이는 것은 활동별 기록과 문서입니다

체크리스트는 갱신되고, 쌓이는 것은 따로 있습니다.

기관 선정이라는 활동을 할 때마다 무언가가 남습니다. 확인 결과, 그때 내린 판단, 그리고 받은 견적서와 검토 의견서와 계약서. 과제가 열 건 쌓이면 그 활동에 열 건의 기록이 붙어 있습니다.

그래서 새 과제를 시작할 때 지난 것들을 볼 수 있습니다.

위탁 기관을 선정한다고 해봅시다. 지난 과제들에서 어느 기관을 후보로 봤고, 무엇을 기준으로 골랐고, 계약에서 어떤 조건이 문제가 됐는지.

같은 유형의 과제들만 보는 것이 아닙니다. 유형이 달라도 활동 코드가 같으면 불러올 수 있습니다. 탐색형 과제에서 겪은 그 기관 이야기를 개발형 과제를 하면서도 참고할 수 있습니다.

이건 일정이나 예산 같은 숫자가 아닙니다. "이 유형은 평균 14개월 걸렸습니다"는 알아도 별 도움이 안 됩니다. 필요한 것은 그때 무엇을 봤고 어떻게 판단했는가이고, 그때의 문서까지 따라옵니다.

관리 방법 자체도 배웁니다

한 층 위의 이야기입니다.

코드로 기록되어 있으면 이런 질문에 답할 수 있습니다. 이 유형에서 판단 지점을 여러 개 둔 과제와 하나만 둔 과제 중 어느 쪽이 나았는가. 이 확인 항목이 실제로 문제를 걸러낸 적이 있는가.

개별 과제에 대한 학습이 아니라 관리 방법 자체에 대한 학습입니다. 그리고 이건 다른 회사에서 가져올 수 없습니다. 우리 과제를 우리 방식으로 관리해 본 결과에서만 나옵니다.

앞에서 이야기한 공학의 순환이 여기서 완성됩니다.

편차는 아래를 올려서 줄입니다

표준을 만들면 다들 그것만 하게 되는 것 아니냐는 걱정이 있습니다. 반대입니다.

템플릿은 상한이 아니라 하한입니다. 체크리스트가 있으면 누가 하더라도 그 수준까지는 나옵니다. 잘하는 사람은 여전히 그 위로 가서 거기 없는 것을 봅니다.

중요한 것은 편차를 줄이는 방향입니다. 잘하는 사람을 끌어내리는 것이 아니라 아래를 끌어올리는 것입니다.

그리고 그 하한선은 고정된 것이 아닙니다. 다만 올라간다는 것이 확인할 항목이 많아진다는 뜻은 아닙니다.

누군가 알아낸 것이 체크리스트에 반영되면 다음 사람은 지금 조건에 맞는 최신 상태에서 시작합니다. 여기에 활동별 기록이 더해집니다. 무엇을 봐야 하는지는 체크리스트로 알고, 지난번에 어땠는지는 기록으로 압니다.

정리하면 이렇습니다

공학은 표준으로 정의하고, 관찰하고, 다시 반영하는 순환입니다. 관리도 그렇게 다룰 수 있고, 그래야 사람이 아니라 조직에 쌓입니다.

구조는 이렇습니다. 표준코드에 관리 방법과 활동이 정의되고, 유형이 정해지면 템플릿이 따라오고, 체크리스트는 유형과 활동 코드의 조합마다 붙고, 수행하면 산출물이 남습니다.

골격은 거의 그대로, 내용물은 계속 갱신됩니다. 그리고 이것은 쌓아온 것의 총합이 아니라 현재 시점의 최적 상태입니다.

마스터 데이터로 관리하되, 골격은 엄격하게 내용물은 느슨하게 다룹니다.

쌓이는 것은 활동별 기록과 문서입니다. 늘어나는 것은 확인할 항목이 아니라 참조할 자료입니다.