프로젝트, 관리하기 쉽지 않아요
안녕하세요! 파드에서는 숏커톤, 롱커톤을 앞두고 어느덧 파트별로의 연합 세미나가 코앞에 다가 왔어요. 그래서 지난 토요일에는 기획파트 마지막 세미나가 있었는데요. 오늘은 그 때 배운 내용에 대해 나눕니다.
프로젝트 매니징은 필연적으로 관리의 성격을 띄는 업이다. 무엇인가 관리해내려면, 일의 스코프와 스케쥴이 먼저 파악되어야 한다.
- 스코프는 업무 범위를 설정하고, 제품 개발을 위해 필요한 각각의 기능을 찢어내는 작업이다.
- 스케쥴은 투입 가능한 시간과 자원을 관리하는 것이다.
그런데 이때, 개발 범위가 유동적인가 비유동적인지? 내지는, 주어진 기간 내 변경될 가능성이 잦은지 적은지? 에 따라 워터폴 방식이 적합한 경우, 애자일 방식이 적합한 경우로 판별 가능하다.
IT 산업 분야에서 프로젝트를 관리하는 대표적인 방법 두 가지에 대해서 알아보자.
워터폴 방법
이 방법은 대기업에서 사용하기에 적합하다. WBS(work breakdown structure) 라 불리는 것이 워터폴 방법의 대표적인 사례다.
워터폴 방법을 사용해 제품을 개발하는 조직에 기획자로 일하고 있다면, 요구사항 정의하고, 그것을 문서화해 엔지니어들에게 넘기게 된다. 이때 염두할 것은, ‘워터폴 방식’ 이기 때문에 굉장히 디테일한 요구사항 정의서를 쓸 줄 알아야 하는 것이 기획자의 자질이자 책임이라 하겠다. 워터폴 방식을 사용할 때의 단점은, 개발 기간이 무한정 길어질 수 있다는 점이다.
NOTE:
admin 화면을 back office라고 한다
turn key로 맡긴다 = SI 업체에 외주를 맡길 때 처음부터 끝까지 맡긴다
애자일 방법론
스타트업에서 일하는 현직 근로자들에게 애자일이 뭔가요? 혹은 스크럼이 뭔가요? 라고 물으면 ‘밤 만이 새는 것’이라는 답변을 듣기 쉽다고 한다. 그러나 빨리빨리 끝내려고 하는 것, 혹은 밤 많이 새는 것이 애자일이 아니다..
애자일 방법의 핵심은 ‘니 일이 내 일이고, 내 일이 니 일이다’의 마인드가 갖추어져 있어야 스크럼이 가능하다는 것이다. (우습게도 그래서 야근이 많은 상황이 펼쳐진다.) IT 스타트업 조직에선 데일리 스크럼이라는 활동을 하는데 이것은 아침의 15분 동안, 서로가 하고 있는 일들을 확인하며 일의 싱크를 맞추는 활동이다. 이때 특징은 기획자가 주도하여 체크하는 것이 아니라 모두가 참여하여 진행상황을 공유하는 것, 30분을 넘기지 않는 것이다.
이는 비단 IT 개발 회사에만 국한된 내용이 아닐 것이다. 양자 컴퓨터를 개발하고 있는 회사라도, 혹은 정부 산하의 연구 조직이더라도 문화를 애자일하게 세팅하면 애자일 방법론이 가져다 줄 수 있는 효용들을 누릴 수 있을 것이다. 스크럼 매니저, 프로덕트 매니저라는 말도 있는데 IT 산업 뿐만 아니라 boring company, 뉴럴 링크, IBM 과 같은 조직의 JD 에도 심심찮게 구경할 수 있는 직무이다.
스크럼 외에도 몇 가지 알아두어야 할 용어들이 있는데 한번 정리해보자.
스프린트는 보통 2주로 설정되는 것이 일반적이다. 한 스프린트 안에는 2~3일 단위의 태스크들이 할당된다. jira를 사용해본 경험이 있는 사람이라면 공감이 빠를 것이다. 프로덕트 하나를 만들기 전까지 스프린트를 얼마나 생성하면 좋을지, 각 스프린트 하나하나를 어떻게 밀도있게 보내도록 할지 고민하는 것이 관리자로서 PM이 해야할 일이다.
개발 이후엔 스프린트 회고를 한다. 목표대로 개발이 되었는지 안 되었는지 확인하는 것이 첫번째 목적이고, 두번째 목적은 커뮤니케이션이 잘 되었는지, 갈등은 없었는지, 팀으로서 좋았던 점이나 미진했던 점이 무엇인지, 앞으로는 스프린트 시 밀도있게 협업해야 할지, 느슨하게 협업해야 할지 개선사항을 도출해내고자 알고자 함이다. 회고하는 방식으로는, kpt 방식이 잘 알려져 있다.
프로덕트 백로그는, 어떤 것들을 개발해야 하는지 생각한 뒤, 그 생각들을 기능단위로 내려서 기능들을 정의한 뒤 리스트화 하여 전달하는 것을 의미한다. 크게 세 가지 갈래로 done/ todo/ block 으로 나눌 수 있고, 한 일, 할 일, 문제점을 ‘매일’ 공유함으로써 애자일하게 일할 수 있게 된다. 형식적으로는, 주로 칸반 보드를 이용해 작업의 work pipeline을 찢는 방식을 사용한다.
프로젝트 관리자가 사용할 수 있는 좋은 도구들이 시중에 많이 나와 있다. 그런데 중요한 것은, 여러 툴 들을 사용해보았다는 사실이 아니고 비동기 커뮤니케이션을 어떻게 효과적으로 구현해냈는지가 담겨 있는지 아닌지의 여부이다. 동기 커뮤니케이션은 협업자들이 동시간, 동일한 장소에서 함께 일하는 것을 의미하고, 비동기 커뮤니케이션은 다른 시간, 다른 장소일에서 함께 일하는 것을 의미한다. 그렇기 때문에 비동기 커뮤니케이션은 더 어렵다. 하지만 covid 19의 유행을 필두로 비동기 커뮤니케이션을 유연하게 돕는 각종 철학을 담은 툴들이 쏟아져 나왔는데 그 중 하나가 슬랙이라 할 수 있겠다.
슬랙에서 댓글 말고도, 모래시계 이모티콘, 체크 이모티콘, 눈 이모티콘 등을 사용할 수 있는데 해당 글에 내가 어떤 리액션을 하고 있는지 상대가 파악하기 쉽도록 돕는 것이다. 이 외에도 깃헙에 나의 status를 알리는 데 사용할 수 있는 여러 이모지도, 비동기 커뮤니케이션을 수월하게 하고자 하는 목적을 담고 있다.
사소하되, 중요한 것을 놓치지 않도록 시각화 해내어 ‘인지’를 돕는 것이다.
앞서 살핀 프로덕트 백로그와 스프린트를 ‘나의 일’로 끌어들여와서 생각해보자. 내가 고려해야 할 일의 순서가 어떻게 되겠는가?
- 백로그 작성하기
- 필요할 일들의 총량을 파악하고 스프린트를 몇 개로 찢어낼지 정하기
- 서비스가 나오기까지 스프린트 하나 당 (이걸 Iteration 부르기도 한다더라) 어떻게 계획을 수립할지 고민하기
이렇게 크게 3가지 면면이 있을 텐데, 매니저 입장에서 이를 잘 기록해두고 추적하는 것은 아주 의미있는 일일 것이다. 알려져 있기로는 x축에 투입된 조직의 Input, y축에 resource를 놓고 추적하는 Plot이 있다.
스프린트 보드의 대략적인 구성은 아래와 같다.
- 작업 중
- 작업 완료(검수 요청)
- 검수 중
- 수정 요청
- 검수 완료
그렇지만 익숙하지 않은 프로젝트를 처음 맡게 된 PM 이라면, 스프린트를 작성할 때 막막할 수 있다. 데이터의 흐름이나 UX 에 대한 전반적인 지식이 없다면 더욱 그럴 수 있다. 그럼에도, 스프린트를 작성할 수는 있다. 스토리 - 에픽 - 태스크 의 흐름을 타고 만들면 된다.
기획자들이 서비스 기획 초기에 많이들 작성하는 “유저 저니 맵” 을 떠올려보자. 유저 저니 맵을 어떻게 만들었던가? 에 대한 고민이 여기 녹아 있다.
그럼 스토리 - 에픽 - 태스크 가 각각 무엇을 의미하는지 살펴보자.
스토리:
스토리는 스프린트 보드를 만들 때 고려할 최상위 토글에 해당하며, 유저의 이야기를 말한다. 스토리에 해당하는 내용은 ‘사용자는 _해야 한다’ 이다. 예를 들어 당근 마켓의 경우, ‘사용자는 이웃과 물건을 거래할 수 있어야 한다’ 가 그들이 목표한 스토리 중 하나가 될 것이다.
에픽:
에픽은 feature, 즉 기능을 의미하며, 일의 중간 토글에 해당한다. 스토리 하나를 구현하기 위해선 기능들 몇 가지의 조합이 필요할 것인데 그때의 기능들을 에픽에 적으면 된다.
태스크:
테스크는 업무로서, 일의 하단 토글을 차지하고 있다. 기능은 사람이 업무를 함으로써 구현되지 않는가? 기능을 구현하기 위해 해야할 업무들을 쪼개어 놓으면 그것이 태스크다. 이 때 일반적으로는 한 태스크 당 3일 분량의 일이 할당되는 것이 권장된다.
자. 이렇게 정리된 태스크들을 칸반보드에 잘 뿌려서 관리하면 된다. 그런데 여기서 실력 있는 PM과 없는 PM의 차이가 드러난다. 스프린트에 필요한 일들을 무작정 뿌리는 것이 아니라 업무가 유기적으로 흐르게끔 유도해낸다.
상황에 따라 스프린트 하나에 여러개의 스토리를 담아내기도 하고, 칸반 보드가 단순한 개인 투두리스트로만 사용되는 것을 방지하기 위해 개인 또는 팀 단위의 다양한 필터를 걸어두기도 한다.
그리고 마이크로 매니징이 필요한 시기에는 체크리스트를 일의 사이즈 센스에서 좀 더 촘촘하게 내려앉혀 각자가 각자의 일을 스프린트 보드에 적고, 그 일들이 이루어지게 하는데 개연성을 수시로 부여한다.
추가적으로 날짜도 중요한 요소 중 하나인데, 작업 시간과 마감 시간을 관리하는 것은 리소스 관리 면에서 수치적인 증거가 반영된 회고를 가능하게 하기 때문이다.
칸반 보드의 맨 앞에 전체 일정에 대해 깔아두어 작업 자들이 플랫폼들을 이리저리 옮겨다니지 않게 배려하는 것도 하나의 센스다.
마지막으로 몇 가지의 팁을 더 적어보자면, 아래와 같다.
- 툴이 뭔지는 정말이지 중요하지 않다
- 기능의 사이즈에 따라, 스프린트 보드의 위계는 2 depth 가 되도록 하는 게 적당하다.
- x축에 시간, y축에 해야 하는 작업(누적총량 100)으로 놓고 선 위에 있는 부분과 아래 있는 부분을 추적하면 잘한 일들과 잘못한 일들을 파악할 수 있고 ⇒ 일/기간/사람을 더 늘일지 말지 애기할 수 있게 된다
또한 프로덕트 선택 후 스토리보드를 작성해보았다. 디스크립션은 개발자와 디자이너의 입장👀에서 다시 물어보는 일이 없도록! 작성해야함을 깨달을 수 있었다. 
