시스템 - 과제, 무엇을 어떻게 관리해야 하는지

현장의 질문들 - 5

이 항목을 왜 채웁니까

연구원에게 물어보면 대체로 이렇게 답합니다.

"양식에 있으니까요."

관리 항목이 왜 있는지 설명할 수 있는 사람이 의외로 적습니다. 만든 사람은 이유가 있었을 텐데, 시간이 지나면서 그 이유는 사라지고 칸만 남습니다.

그리고 이유를 모르는 칸은 형식적으로 채워집니다. 형식적으로 채운 것은 아무도 안 보고, 아무도 안 보는 항목은 곧 비어 있게 됩니다.

지난 글에서 과제를 유형으로 나누는 이야기를 했습니다. 오늘은 그 다음입니다. 유형이 나뉘었으면, 유형별로 무엇을 관리할지는 어떻게 정하는가.

고르는 방식과 도출하는 방식

관리 항목을 정하는 방식에는 두 가지가 있습니다.

하나는 고르는 방식입니다. 기존 양식이나 다른 회사의 표준을 놓고, 우리에게 필요한 것을 남기고 필요 없는 것을 뺍니다.

다른 하나는 도출하는 방식입니다. 빈 종이에서 시작해서, 이 과제 유형에 무엇이 필요한지를 따져 하나씩 올립니다.

같은 결과를 얻으려는 것 같지만 방향이 반대이고, 결과도 다릅니다.

고르는 방식에서는 뺄 근거를 대야 합니다. 그런데 근거를 대기가 어렵습니다. 이걸 왜 빼느냐고 물으면 답이 궁하고, 뺐다가 문제가 생기면 책임이 돌아옵니다. 그래서 대부분 그냥 둡니다. 항목은 쌓이기만 합니다.

도출하는 방식에서는 넣을 근거를 대야 합니다. 근거가 없으면 안 들어옵니다. 그리고 들어간 항목은 왜 있는지 설명이 됩니다.

왜 고르는 방식이 굳어졌을까요

사람들이 편해서만은 아닙니다. 그동안 써온 방법론 자체가 그렇게 설계되어 있습니다.

기존 IT 구축 방법론은 대체로 이런 순서입니다. 요구사항을 수집하고, 표준 프로세스와 비교해 차이를 분석하고, 그 차이를 어떻게 처리할지 정합니다. 표준에 맞출 것인지, 고칠 것인지, 포기할 것인지.

이 방법론은 표준이 존재하는 영역을 전제로 만들어졌습니다. 거래(Transaction) 처리에는 표준이 있습니다. 회계 기준이 있고 세법이 있으니 "우리는 표준에서 무엇이 다른가"를 묻는 것이 옳고, 대체로 표준에 맞추는 것이 정답입니다.

그런데 프로젝트 관리에는 그 표준이 없습니다.

무엇을 개발할지, 어디까지 검토할지, 언제 접을지에 정해진 규칙이 없고 회사마다 다릅니다. 그런데도 같은 방법론을 씁니다.

그러면 무슨 일이 벌어집니까. 패키지가 들고 온 화면 목록이 사실상 표준 역할을 하게 됩니다. 표준이 아닌데 표준처럼 기능합니다. 그리고 논의는 자연스럽게 "이 화면에서 무엇을 빼고 무엇을 고칠까"로 흘러갑니다.

거래 처리가 아닌 영역에서는 당연히 업무에 시스템을 맞춰야 합니다. 그런데 방법론은 여전히 표준에 맞추는 쪽으로 설계되어 있습니다.

저희는 도출하는 방식을 권합니다. 그리고 그 출발점이 유형의 목적입니다.

그 유형은 무엇을 이루려는 것입니까

관리 항목을 정하기 전에 던져야 할 질문이 있습니다.

이 유형의 과제는 무엇을 이루려는 것인가.

당연해 보이는 질문인데, 막상 답을 적어보라고 하면 잘 안 나옵니다. "좋은 결과를 내는 것" 같은 답이 나오면 아직 안 된 것입니다.

예를 들어 이런 식으로 나와야 합니다.

위탁 과제 — 내부에 없는 역량을 정해진 기한 안에 확보한다.
Research형 과제 — 이 방향이 가능한지를 최소 비용으로 확인한다.
Development형 과제 — 정해진 규격을 정해진 일정과 원가 안에서 구현한다.
기술 도입 과제 — 필요한 권리를 감당 가능한 조건으로 확보한다.

목적이 이 정도로 적히면 다음 질문에 답할 수 있습니다.

그 목적은 어떤 성격을 갖습니까

목적이 정해지면 그 유형의 성격이 따라 나옵니다. 세 가지를 물으면 대체로 드러납니다.

무엇이 되면 성공입니까. 이게 명확한 유형과 그렇지 않은 유형이 있습니다. Development형은 규격 충족 여부로 판정됩니다. Research형은 "안 된다는 것을 확인한 것"도 성공일 수 있습니다.

무엇이 이 유형의 가장 큰 위험입니까. 위탁 과제는 상대 기관이 늦어지는 것입니다. Research형은 안 되는 방향에 오래 매달리는 것입니다. 기술 도입은 계약 조건을 잘못 보는 것입니다. 유형마다 다릅니다.

결정적인 순간이 언제입니까. 이 시점을 놓치면 되돌리기 어려워지는 지점입니다. 위탁은 계약 체결 시점, Research형은 계속할지 접을지 판단하는 시점, 기술 도입은 실사 단계입니다.

이 세 가지가 정리되면 필요한 항목이 저절로 나옵니다.

성격에서 항목이 나옵니다

앞의 예시를 이어서 보겠습니다.

위탁 과제의 성격은 통제권이 밖에 있다는 것입니다. 그러면 이런 항목이 필요합니다.

상대 기관의 진행 상황을 무엇으로 확인하는가. 중간 산출물을 언제 어떤 형태로 받는가. 늦어질 때 우리가 쓸 수 있는 수단이 무엇인가. 계약에 그것이 들어 있는가.

여기서 내부 인력 참여율은 나오지 않습니다. 목록에 있었다면 고민했겠지만, 목적에서 도출하면 아예 후보에 오르지 않습니다.

Research형 과제의 성격은 방향이 바뀔 수 있다는 것입니다. 그러면 이런 항목이 나옵니다.

다음 판단이 언제 필요한가. 그때 무엇을 보고 정할 것인가. 이 계획이 무엇을 전제로 하고 있는가. 시도한 것 중 안 된 것은 무엇이고 왜 안 됐는가.

월 단위 세부 일정은 여기서 나오지 않습니다. 방향이 바뀌면 그 일정은 무의미해지니까요.

Development형 과제의 성격은 절차가 정해져 있다는 것입니다. 그러면 단계별 일정과 산출물, 계획 대비 실적, 비목별 원가가 의미를 갖습니다. 여기서는 간트 차트가 실제로 유용합니다.

이렇게 도출하면 항목마다 이유가 붙어 있습니다. 왜 채우는지 설명이 되고, 설명이 되면 채웁니다.

그 다음이 항목별 관리방법의 선정입니다

항목이 정해졌으면 각각을 어떤 방법으로 관리할지 정합니다. 여기서도 기준은 그 유형의 목적입니다. 어느 방법이 우수한가가 아니라, 이 목적에 무엇이 맞는가입니다.

주요한 것들을 보겠습니다.

일정 — 여러 방식을 섞고 계층으로 나눕니다

일정 관리 방식은 하나를 고르는 것이 아닙니다. 실제로는 여러 개를 섞어서 계층으로 배치합니다. 그리고 그 폭이 생각보다 넓습니다.

종료일만 — 언제까지 끝내는지 하나만 정합니다. 중간 일정은 관리하지 않습니다.
마일스톤 — 중간 시점 몇 개만 잡습니다. 언제까지 무엇이 나와야 하는지만 정합니다.
간트 차트(활동 단위) — 활동을 나열하고 시작과 끝을 그립니다. 선후 관계까지 표시할 수 있습니다.
작업 단위 완료 여부 — 일정 없이 했는지 안 했는지만 봅니다.
반복 횟수 관리 — 몇 번 시도했고 몇 번째에 어떤 결과가 나왔는지를 봅니다.
공정 분석(PERT/CPM) — 여러 경로 중 무엇이 전체 일정을 결정하는지 계산합니다.

맨 앞을 그냥 넘기지 마십시오. 종료일 하나만 관리하는 것도 정당한 선택입니다.

기간이 짧고 담당자가 한 사람이면 중간 일정을 관리해서 얻는 것이 거의 없습니다. 어차피 그 사람이 자기 일정을 압니다. 그런데 관리 체계를 만들다 보면 이런 과제에도 습관적으로 단계를 넣게 됩니다. 관리하지 않기로 정하는 것도 설계입니다.

계층으로 배치한다는 것도 중요합니다. 상위는 마일스톤으로 잡고, 그 아래 활동은 간트로 그리고, 말단은 완료 여부만 보는 식입니다. 전부 같은 정밀도로 관리하면 유지가 안 됩니다.

목적에 따라 조합이 달라집니다.

정해진 규격을 정해진 일정과 원가 안에서 구현하는 것이 목적이라면, 활동 단위 간트가 중심입니다. 지연이 즉시 보여야 하니까요. 공정이 복잡하게 얽혀 있으면 공정 분석까지 갑니다.

가능한지를 최소 비용으로 확인하는 것이 목적이라면 다릅니다. 세부 일정보다 반복 횟수와 판단 시점이 중요합니다. 이 조건으로 몇 번 시도했는가, 언제 방향을 바꿀 것인가. 월 단위 간트를 그리게 하면 지킬 생각 없는 계획이 나옵니다.

위탁이 목적이라면 내부 활동보다 상대 기관의 마일스톤과 중간 산출물 수령 시점이 일정 관리의 중심이 됩니다.

연구비 — 무엇을 어느 단위로 볼 것인가

먼저 정할 것이 있습니다. 계획과 실적을 모두 관리할 것인가, 실적만 관리할 것인가.

둘 다 관리하면 계획 대비 집행을 볼 수 있지만, 계획을 세우는 부담이 생깁니다. 실적만 관리하면 부담은 적은데 초과 여부를 미리 알 수 없습니다.

계획을 세운다면 어느 단위로 세울 것인가. 총액만 잡을지, 비목별로 나눌지, 비목별에 기간까지 더할지.

그리고 여기서 자주 놓치는 것이 있습니다. 모든 비목을 관리할 필요가 없습니다. 오히려 대부분은 관리하지 않는 쪽이 맞습니다.

연구비 비목을 펼쳐 보면 상당수가 오버헤드에 가깝습니다. 인건비는 참여 인력이 정해지면 거의 자동으로 따라오고, 간접비는 비율로 계산되며, 일반 관리비 항목들은 과제별로 판단할 여지가 별로 없습니다. 이런 비목을 계획 단계에서 나눠 잡게 하면, 채우는 시간은 드는데 그것을 보고 내리는 결정은 없습니다.

앞에서 말씀드린 기준이 여기서도 그대로입니다. 이 숫자로 무슨 판단을 합니까. 답이 안 나오면 관리 대상이 아닙니다.

실적은 회계 데이터에서 받아오는 것이 원칙입니다. 다만 회계 계정과 연구 비목이 일대일로 대응하지 않으니 매핑 규칙을 반드시 정해두어야 합니다. 이걸 안 정하고 연계하면 숫자가 안 맞고, 안 맞으면 아무도 그 숫자를 믿지 않습니다.

참여 연구원 — 어느 단계까지 볼 것인가

참여 여부만 기록할지, 참여 기간까지 기록할지, 투입 시간까지 기록할지.

뒤로 갈수록 정보는 좋아지고 부담은 급격히 커집니다. 특히 투입 시간은 연구원이 주기적으로 자기 시간을 배분해 입력해야 하고, 대체로 정확하지 않습니다.

정산 요건이나 원가 계산이 목적에 걸려 있으면 정밀하게 가야 합니다. 그렇지 않다면 참여 기간까지로 충분한 경우가 많습니다. 계획에만 참여율을 잡고 실적은 안 받는 방식도 있습니다.

산출물 — 관리 단위마다 무엇이 나와야 하는가

이건 자주 빠지는 항목인데, 실무적으로 대단히 유용합니다.

각 관리 단위가 끝났을 때 반드시 나와야 하는 산출물이 정해져 있는가. 시험 결과 보고서인지, 검토 의견서인지, 계약서 사본인지.

정해져 있으면 두 가지가 생깁니다. 빠진 것이 보입니다. 그리고 나중에 찾을 것이 어디 있는지가 정해집니다.

특히 B2B 기업이나 인증 대응이 필요한 곳에서는 이게 결정적입니다. 고객사나 기관이 자료를 요청할 때 마감 직전에 찾아 헤매는 일이 사라집니다.

목적에 따라 필수와 선택이 갈립니다. 규제 대응이 목적에 걸려 있는 유형은 산출물이 필수이고, 탐색이 목적인 유형은 최소한으로 둡니다.

단계 이행 조건 — 다음으로 넘어가는 기준이 있는가

Gate라고 부르는 것입니다. 이 단계를 마쳤다고 자동으로 다음으로 가는 것이 아니라, 정해진 조건을 충족했는지 확인하고 넘어가는 지점입니다.

여기서 정할 것은 셋입니다. 어느 지점에 둘 것인가. 무엇을 기준으로 판정할 것인가. 누가 판정할 것인가.

Research형 과제에서는 이것이 일정 관리보다 중요합니다. 앞서 이야기한 판단 시점이 실제로는 이 형태로 구현됩니다. 계속할지 접을지를 정하는 자리이고, 그 판정 근거가 기록으로 남습니다.

Development형 과제에서는 품질 관문 역할을 합니다. 이 조건을 못 채우면 다음 단계로 못 갑니다.

그리고 이행 조건이 있으면 접는 것이 자연스러워집니다. 앞선 글에서 접어야 할 과제가 안 접힌다는 이야기를 했는데, 판정 지점이 정해져 있으면 누군가 먼저 접자고 말할 필요가 없습니다. 그 자리에서 조건을 못 채운 것이니까요.

어디까지 자세히 쓸 것인가

항목과 방법이 정해지면 마지막으로 상세 수준을 정합니다. 같은 항목이라도 두 줄로 쓸 수도 있고 한 장으로 쓸 수도 있습니다.

여기서도 순서가 중요합니다.

흔히 "이만큼 자세히 써주세요"부터 정합니다. 그러면 기준이 없어서 계속 늘어납니다.

순서를 뒤집어야 합니다. 경영진이 무엇을 알아야 하는지를 먼저 정하고, 그것을 알기 위한 최소 입력을 역산합니다.

그리고 경영진 쪽 질문은 의외로 짧습니다.

지금 하고 있는 것들이 여전히 할 만한 일인가. 어디가 막혀 있고 언제부터인가. 접어야 할 것이 붙들려 있지는 않은가. 자원이 어디에 몰려 있는가.

이 질문에 답하는 데 필요한 입력은 생각보다 적습니다. 시작할 때 왜 하는지와 무엇을 전제로 하는지, 접을 때 왜 접는지, 막혔을 때 무엇이 막혔는지. 각각 두세 줄입니다.

두 쪽을 함께 보아야 합니다

여기서 이 작업의 성격을 분명히 하겠습니다.

관리 수준을 정하는 일은 양쪽의 균형점을 찾는 일입니다.

경영진 쪽 — 무엇을 알아야 판단할 수 있는가.
현장 쪽 — 그것을 알려주려면 무엇을 얼마나 채워야 하는가.

한쪽만 보면 반드시 실패합니다.

경영진 쪽만 보면 항목이 계속 늘어납니다. 알면 좋은 것은 끝이 없으니까요. 그리고 현장은 형식적으로 채우기 시작합니다.

현장 쪽만 보면 아무것도 안 남습니다. 최소한으로 하자고 하면 결국 하던 대로 하게 됩니다.

그래서 이 작업은 양쪽이 함께 앉아서 해야 합니다. 관리하는 쪽이 혼자 설계하면 반드시 앞의 함정에 빠집니다.

정량은 대체로 계산으로 나옵니다

한 가지 짚고 갈 것이 있습니다. 항목을 도출하다 보면 상당수가 사람이 입력할 일이 아니라는 것을 알게 됩니다.

계획이 유형별 양식에서 나왔으면 비교할 기준이 이미 있습니다. 그러면 이런 것들은 계산됩니다.

이 단계가 계획보다 얼마나 지연됐는가. 예산이 얼마나 집행됐고 남은 기간 대비 적정한가. 이 확인 항목이 비어 있는데 다음으로 넘어갔는가. 회신 기한이 지난 요청이 있는가.

사람이 입력해야 하는 것은 실제로 일어난 일과, 그때 내린 판단뿐입니다. 나머지는 그것으로부터 나옵니다.

그래서 항목을 도출할 때 이 질문을 함께 던지시면 좋겠습니다. 이건 사람이 입력해야만 알 수 있는 것입니까, 계산으로 나오는 것입니까.

그래야 시스템이 삽니다

마지막으로 왜 이 순서를 지켜야 하는지 정리하겠습니다.

목록에서 고른 항목은 누구의 것도 아닙니다. 왜 이걸 채우는지 아무도 설명하지 못합니다. 그러면 형식적으로 채우고, 형식적으로 채운 데이터는 아무도 안 보고, 안 보면 곧 안 채워집니다.

앞선 글에서 다룬 정착 실패가 여기서도 그대로 반복됩니다.

목적에서 도출된 항목은 다릅니다. 이 유형의 과제에서 이게 왜 필요한지가 설명됩니다. 그리고 설명이 되면 사람들이 채웁니다. 독려할 필요가 없습니다.

그리고 이건 도입 시점만의 이야기가 아닙니다. 새 유형의 과제가 생기면 같은 순서로 하면 됩니다. 목적을 적고, 성격을 따지고, 항목을 도출하고, 방법과 상세 수준을 정합니다.

기존 양식을 복사해서 고치기 시작하면, 그 순간 다시 고르는 방식으로 돌아갑니다.

정한 것은 템플릿으로 고정합니다

마지막으로 한 가지를 짚겠습니다.

지금까지 이야기한 것 — 유형의 목적, 성격, 도출된 항목, 각 항목의 관리 방법, 상세 수준 — 을 정하고 나서 그때그때 적용하면 안 됩니다.

유형별 템플릿으로 고정되어야 합니다.

이유가 둘입니다.

유지가 됩니다. 사람이 기억으로 관리하면 담당자마다 달라집니다. 이번 과제는 이렇게 하고 다음 과제는 저렇게 하면, 유형을 나눈 의미가 없어집니다. 템플릿으로 있으면 누가 하든 같은 수준에서 시작합니다.

발전이 됩니다. 이게 더 중요합니다. 개선하려면 개선할 대상이 있어야 합니다. 문서로 고정되어 있어야 "이번에 이게 빠졌으니 추가하자"가 됩니다. 머릿속에 있으면 고칠 곳이 없습니다.

앞선 글에서 체크리스트가 갱신되면서 회사의 노하우가 된다는 이야기를 했습니다. 그 갱신의 대상이 바로 이 템플릿입니다.