좋은 일정관리란 무엇일까?
제품을 제 시간에 출시하는 방법에 대하여
지금 이 순간에도 판교에서 일정으로 싸우는 조직이 1,000개도 넘을 겁니다.
사업팀은 새 제품을 빨리 런칭하고 싶은 반면, 개발팀은 기존 업무도 산더미처럼 쌓여있기 때문이죠. 비즈니스맨 입장에서는 빨리 돈을 벌어야 회사를 지탱하는데 개발팀이 게으르고 속 편한 소리만 한다 생각하고, 개발자들은 시스템도 모르는 인간들이 말을 계속 바꾸며 모순된 스펙을 강요한다고 느낍니다.
실제로 저도 6-7년 전쯤 팀장님들이 회의실에서 소리 지르는 게 일상이던 시절이 있었는데요. 정말 심할 때는 서로 얼굴도 안 본다고 하셔서 각 팀 막내끼리 옥상에 모여 슬럼가의 아이들처럼 푸념하곤 했었습니다. 그런데 IT개발이라는 게 정말 이렇게 얼굴 붉히고 싸우면서 해야 하는 일이었을까요?
이번 챕터에서는 단순히 워터폴, 애자일 같은 추상적인 개발 방법론에 대한 이야기가 아니라 1) 일정관리란 무엇인지에서 출발하여, 2) 왜 하는지, 3) 어떻게 하는지, 4) 실무에서 중요한 것은 무엇인지까지 생각해 보겠습니다.
1. 일정관리란?
일정관리란
1) 복수의 과제들 중 우선순위를 선정하여
2) 조직 자원을 효율적으로 투입하는 행위
입니다.
앞서 이야기했지만 개발팀은 동시에 여러 과제를 진행합니다. 심지어 PM이 과제가 없다고 생각하는 시점조차 1) 코드 리팩토링, 2) 인프라 대응, 3) 운영 대처까지 상시 업무를 처리하고 있습니다. 여기에 더해 사업 과제들이 와르르 쏟아지는데 일정관리를 잘해야 병목이 없습니다.
2. 일정관리는 왜 할까?
일정관리는 제한된 시간 안에 최대의 임팩트를 만들기 위해 합니다.
일정관리는 단순히 모든 과제를 빨리빨리한다는 뜻이 아닙니다. 과제 별로 들어가는 자원과 만들 수 있는 임팩트(ROI)를 고려하여 우선순위를 정하고 따르는 것이 핵심입니다. 출시 목표는 보통 시장 전문가인 사업기획자들이 PM과 함께 결정합니다. ASAP(빠르면 빠를수록 좋다)이 가장 많지만 연간 계획이나 피크 시즌, 경쟁 환경을 고려해 종료일을 찍기도 합니다.
예를 들어 배달의 민족 사례를 생각해 보면
1) 쿠팡이츠가 멤버십을 무기로 시장 침투를 확대하니 최대한 빨리 무료 배달을 만들자
2) 올림픽 시즌에 맞추어 오토바이 라이더를 확보할 신규 기능을 만들자
3) 소상공인 연합회의 고발에 대응하여 수수료 체계를 개편하자
처럼 심각한 요구사항이 동시다발적으로 들어올 수도 있습니다.
결국 타의건, 자의건 1개 플랫폼에 여러 프로젝트가 한 번에 발생하게 되고, 우선순위를 판단하여 자원을 효율적으로 투입해야 합니다.
3. 일정관리는 어떻게 할까?
일정 수준의 백로그(예비과제)가 쌓이면 PM은 과제 리스트 작성을 시작합니다. 짧으면 분기, 길면 반기 단위로 대청소하듯 작업하는 경우가 많습니다. 아래 5단계를 따라갑니다.
1. 과제 리스트 작성
생각나는 일을 전부 씁니다. 거창하게 작성할 필요가 없습니다. 엑셀, 노션, 지라, 위키, 피그마 중 가장 익숙한 화면을 켜두고 현재까지 파악한 해야 할 일을 떠오르는 대로 쓰면 끝입니다. 1) 과제명, 2) 플랫폼, 3) 니즈, 4) 개요, 5) 상세설명 정도면 충분합니다. (뒤에 계속 추가됩니다.)
2. 1차 우선순위 판단
다음으로 우선순위를 판단합니다. 우선순위 판단은 PM이 1차적으로 진행하며 확인은 유관 리더들을 전부 동석시킨 상태에서 진행합니다. 1) 얼마나 임팩트 있는 일인지, 2) 얼마나 쉬운 일인지, 3) 외부 압력은 없는지 다각도로 채점하여 순위를 매깁니다. 여기서 같은 순위는 존재할 수 없습니다.
3. 직군 별 검토 후 토론
우선순위 판단이 끝나면 여러 직군을 모아 과제 리스트를 설명하고 각자 흩어져서 투입 자원을 검토합니다. 기획팀, 디자인팀, 개발팀 별로 리더와 구성원이 머리를 맞대고 현재 예측 가능한 수준에서 자원 투입량을 따져봅니다. 여러 사람이 함께 의견을 내기 때문에 비교적 객관적인 일정이 나옵니다.
최초 작성이 끝나면 PM은 담당자들을 만나 왜 이 정도 자원이 필요하다고 생각하는지 이유를 듣습니다. 과제의 난이도에 따라 우선순위가 조정될 수 있습니다. 똑똑한 PM은 동료들이 방어적으로 변하지 않도록 최대한 솔직하게 대화할 수 있는 분위기를 조성합니다. 더 빨리 못하냐고 다그치는 것이 아니라 도와주려는 자세로 듣습니다.
4. 담당자 지정
투입 자원을 검토한 뒤, 담당자를 지정합니다. 조직이 20명 미만이라면 한 명씩 짧게 면담하여 원하는 일을 듣고 가능한 선에서 반영합니다. 유사한 과제가 있다면 동일한 담당자에게 지정하여 업무에 연속성이 생기도록 도와줍니다. 동료마다 개인 성향을 파악하여 직군 별로 모였을 때의 케미스트리를 고려합니다.
5. WBS 배치 후 토론
담당자 지정이 끝났다면 WBS(Work Breakdown Structure)를 작성합니다. 어떻게 만들어도 상관없습니다. 핵심은 모든 구성원이 읽기 쉽게 만들어야 한다는 것뿐입니다. 이 문서는 동료들이 자주 들여다 보고 토론 시 화면에 띄워놓을 때 가치가 생기는 문서입니다.
WBS 작성 시에는 프로젝트 별 1) 우선순위와 2) 필요한 일정, 3) 담당자 리소스를 고려하여 순서를 배치합니다. 최초 작성이 끝나면 모든 구성원이 한자리에 모여 짧게는 1분기, 길게는 1년 동안 진행할 과제들의 개략적인 일정표를 확인합니다. 마지막으로 프로젝트의 전후 순서를 변경할 수 있습니다.
4. 일정관리를 잘하려면?
일정관리는 단순히 WBS를 잘 그리는 문제가 아닙니다.
PM이 아래 4가지를 늘 신경 써야 WBS과정이 순조롭습니다.
1. 동료 파악
PM은 동료들을 잘 알아야 합니다. 단순히 몇 명이 있고, 그들이 어떤 직군이다의 수준이 아닙니다.
1) 무슨 일을 해왔고,
2) 현재 담당 과제는 무엇이며
3) 언제까지 현재 과제를 해야 하는지,
4) 다음에는 무슨 일을 하고 싶으며
5) 업무 성향은 어떠 한지 (좋고 싫은 것)
까지 세세하게 파악합니다.
동료에 대해 깊이 알면 프로젝트 별로 1) 적임자는 물론, 2) 업무그룹 결성 시 케미스트리까지 예상할 수 있습니다. 1) 기존 업무가 끝나지도 않았는데 새로운 과제를 들이붓거나, 2) 평상시 지겨워하는 업무만 맡기거나, 3) 서로 성향이 잘 맞지 않는 파트너끼리 연결할 때 일정 관리가 실패합니다.
2. 신뢰 조성
PM은 조직 내 신뢰를 조성해야 합니다. 스스로는 엄격하게, 동료에게는 관대한 것이 요지입니다. 예를 들어 PM이 일정을 약속했다면 최선을 다해 지켜야 합니다. 설령 피치 못한 변경이 생기더라도 마지막까지 방어하는 모습은 보여야 합니다. 특히 상위 리더가 시킨 일이라며 기존 결정을 손바닥 뒤집듯 하는 것은 평판을 무너뜨리는 일입니다.
반면 동료들에게는 관대해야 합니다. 특히 동료가 개선작업 도중 실수를 했다면 내 일처럼 나서서 수습해 주어야 합니다. 사람들은 실수를 하면 본인이 이미 그것을 압니다. 굳이 동료의 잘못을 책잡아 따지고 드는 것은 앞으로 다시는 이 사람과 일을 하지 않겠다는 선언과 같습니다. 문제를 일으킨 사람이 아니라 재발 방지에만 집중합니다.
한번 동료들과 신뢰관계에 금이 가면 일정관리에 ‘버퍼’라는 비효율 덩어리가 끼기 시작합니다. 프로젝트가 확정적이지 않은 상황(대부분 이렇습니다.)에 최대한 안전한 대답만 합니다. 이렇게 되면 아주 간단한 수정작업조차 3일 ~ 5일씩 걸린다는 응답이 나오기 시작합니다. 사업조직은 기분이 상하고 개발팀을 공격하며 악순환이 시작됩니다.
3. 목표 및 결과 공유
PM은 사업 목표를 끊임없이 공유해야 합니다. 재무적인 상황, 경쟁 환경 등을 개발팀에도 적극적으로 공유합니다. 쉽게 말해 사업팀이 왜 이렇게 조급할 수밖에 없는지 간접적으로 이해할 수 있게 돕는 겁니다. 이렇게 하면 굳이 데시벨을 높이지 않아도 바깥세상은 차갑고 혹독하며 우리 팀이 이 안에서는 똘똘 뭉쳐야 살아남는다는 걸 알릴 수 있습니다.
프로젝트가 끝날 때마다 목표를 달성했는지 회고하는 것도 중요합니다. 사업팀과 개발팀이 서로 협조하면 실제 이기는 경험(winning experience)을 만든다는 것을 보여주어야 합니다. 이렇게 한두 번 업무에 효능감이 전달되면 ‘우리 사업팀 요청은 반드시 도와줘야 하는 것’이라는 끈끈한 감정이 생기기 시작합니다.
4. 유연한 업무 방식
PM은 업무 방식을 유연하게 선택합니다. 과거 개발관리라고 하면 워터폴(Waterfall), 애자일(Agile)처럼 어떤 원칙 하나 세워 놓고 큰 고민 없이 따르는 게 일반이었는데요. 변화무쌍한 IT서비스업을 하다 보면 하나의 규칙만 지키는 것보다 융통성을 발휘할 때 훨씬 효율적입니다.
예를 들어 고객 멤버십처럼 BM(돈 버는 방식)을 바꾸는 큰 개편의 경우 필연적으로 워터폴이 될 수밖에 없습니다. 회사의 장기 방향성이 담긴 핵심 과제는 주 단위로 짧게 끊어가는 개발이 반복업무만 많아지기 때문입니다. 반면 상품 표시 방식처럼 다양한 테스트가 가능한 기능은 주 단위로 끊어가며 빠른 호흡으로 달릴 수 있습니다. PM이 적합한 방식을 채택합니다.
5. 정리하며
과거 IT역사가 짧아 외주가 당연하던 시절, PM은 소위 동료를 압박하는 사람이었습니다. 개발자들을 제한된 시간 안에 ‘갈아 넣어’ 어떻게든 움직이는 결과만 나오던 것이 무용담인 때도 있었습니다.
그러나 점차 훌륭한 IT제품은 유독한 환경에서 절대로 나올 수 없다는 경험이 퍼지면서 지속가능한 제품 개발 을 고민하기 시작합니다. 특히 대성공한 스타트업의 제품들이 런칭 자체보다는 런칭 후 운영단계까지 조직적인 대응을 통해 시장에 자리 잡는 것을 보면서 소모적인 일정관리가 후진적이라는 사실이 분명해졌습니다.
PM에게 일정관리란 건강한 업무문화를 만들고 지키는 일입니다. 일방적으로 날짜 하나를 찍고 이때까지 달리도록 들들 볶는 것이 아닙니다. 동료 모두 1) 안전한 환경에서 일한다는 편안함, 2) 내가 만드는 변화가 중요하다는 긴장감이 동시에 드는 상황을 조성합니다. 문화는 가만히 앉아있는다고 생기지 않습니다. PM이 쉬지 않고 노력해야 합니다.
