Trello로 효율적으로 협업하기

원문 : http://www.uservoice.com/blog/founders/trello-google-docs-product-management/

Trello는 매우 개방적인 툴이다. Trello는 한가지 방법으로만 사용하도록 제한하지 않았기 때문에, Trello를 제대로 이용하려면 규칙을 잘 만들어야 한다.

다행히 몇번의 시행착오를 거친후 우리에게 맞는 방법을 발견했고, 그 과정에서 겪은 경험과 노하우를 공유하려고 한다.

우리가 만든 협업 프로세스

우리는 개발 프로세스를 6개의 Trello 보드로 구성했다. 이 보드들의 중심에는 Current Development 보드가 있다. 나머지 모든 보드의 목적은 Current Development 보드의 Next Up 리스트로 카드(기능 향상이나 버그 픽스에 관한)를 보내는데 있다. Next Up 리스트은 모든 엔지니어와 디자이너가 다음 할일을 찾기 위해 뒤져보는 가장 중요한 곳이다.

각 보드의 역할에 대해 깊이 들어가기 전에, 우리 개발 프로세스의 핵심인 Trello Cards 에 대해 살펴보자.

Cards

UserVoice Trello card

카드는 구현할 스토리를 나타낸다. 그것은 기능 향상, 코드 리팩토링, 버그 등이 될수 있다.

기능 향상 카드는 1~2 문장의 간단한 아이디어로 시작하지만, 그게 실제 개발로 이어지기 전에 Google Docs로 작성한 완전한 spec 문서 링크를 포함하고, wireframe 이나 mock up을 포함하게 된다. 여기서 spec 은 대학교 또는 IT 컨설팅 업체에서 사용하는 장황한 것을 말하는게 아니라, 대략적인 유저 스토리를 의미한다. 왜 이것이 비지니스 측면에서 필요한지, 목표가 무엇인지를 설명하고 구현 방법에 대한 제안도 포함할수 있다.

버그에 대한 카드라면 버그를 어떻게 재현할수 있는지(가능하다면 스크린샷을 포함)를 포함한다. (spec 문서의 예 : https://docs.google.com/a/uservoice.com/document/d/1lojmnN9fZiGUt4eC5rOQqFEV86C33QqAiE3haIeuKH4/edit)

프로젝트가 진행되는 과정

UserVoice current development Trello board

“Current Development” 보드는 전체에서 핵심이 되는 곳으로, 아래와 같은 리스트로 구성된다.

Next Up

    • 당장 처리해야할 카드 리스트로, 디자인하고 개발해야 할 것들이다.
    • 이 리스트내에서의 순서는 의미가 없으므로, 디자이너와 엔지니어들은 현재 실행하기 가장 적합한 카드 순으로 처리하면 된다.

In Progress

  • 현재 디자인/개발 중인 카드들이다.
  • 디자이너/엔지니어는 카드를 이쪽으로 옮길 때, 자신의 얼굴을 카드에 붙인다. (자신에게 배정한다는 말이다.) 효율적으로 일하기 위해, 엔지니어는 자신을 동시에 최대 2개까지의 카드에만 배정한다.  : 1개의 큰 일거리와, 1개의 작은 일거리.

QA

  • 엔지니어가 카드에 적힌 스토리를 구현했다고 판단하면 staging (또는 production 이지만 feature flag로 막혀있을 수 있음)에 적용한 후, 카드를 QA 로 옮긴다. 이 시점에 QA 담당자와 UX 헤드가 살펴보고 확인 후 production 에 적용할지 결정한다.
  • 카드가 대규모 기능 향상 프로젝트일 경우에는 이것만을 위해 따로 분리된 보드를 만들고 그 안에서 QA 과정을 거친다. 분리된 보드내에서 QA 과정이 끝날때까지 원래의 카드는 QA 리스트에 머무르게 된다.

Launch Pad

  • 여기까지 온 카드는 QA를 거쳐서 production에 릴리즈해도 된다는 확인을 받은 것이다. (제대로 된 버전 관리를 하고 있다면, GitHub Pull Request 링크 같은 것을 포함하고 있을 것이고, 이것만 클릭하면 production 에 적용되어야 한다. 이 클릭을 엔지니어만 해야 하는 것은 아니다.)
  • 카드가 버그나 코드 리팩토링에 관한 것일 경우, 즉각 production 에 릴리즈한다.
  • 그게 아니라 카드가 기능 향상에 관한 것일 경우에는 production 에 릴리즈하되, feature flag로 실 적용은 막아둔다. Feature flag 는 계정별로 feature를 활성화 시킬수 있도록 하는 flag인데, 기능을 활성화 해서 production 에서도 문제가 없는지 확인하고, feature opt-in 을 한 유저들의 피드백을 듣고 난 후, 문제가 없을 경우 feature flag를 없애고 모든 유저들에게 적용한다.

Live (Week #)

  • 이 카드들은 LaunchPad를 거쳐 production에 feature flag 없이 모든 유저들에게 적용된 것들이다.
  • 기능 향상 카드는 PM 이 릴리즈해서 Live로 옮기고, 버그 픽스 카드는 버그 리포터가 릴리즈 하고 Live로 옮긴다. 이렇게 해야 처음 카드를 만든 사람이 카드가 처리되어 완료되는 것을 확인할 수 있기 때문이다.
  • 각 주마다 각각의 Live 리스트가 있어서, 언제 어떤 기능을 런치했는지 확인할수 있다.

위 리스트들에 추가적으로 아래 3개의 label 을 카드에 태깅한다.

  • Bug
  • Staging : Staging 에 배포 됨.
  • Production : Production 에 배포 됨.

쉽지 않은가? 도요타 자동차 생산공장에서 시작된 Kanban 시스템을 개발 과정에 적용한 것이다. 이제 카드들이 처음에 어떻게 생성되는지를 설명하겠다.

카드는 어디로부터 오나요?

카드는 4개의 보드로부터 온다.

Product Roadmap

  • 매 쿼터마다 해야할 주요 프로젝트를 나열 한 것으로, 3쿼터 정도를 미리 계획한다. 매 쿼터가 시작될때마다 이 덩치큰 카드들을 Planning 보드로 옮긴다.

Inbox

  • 여기에는 2개의 리스트가 있다. 하나는 회사내 구성원으로부터 시작된 아이디어이고, 다른 하나는 고객들로 부터 들어오는 아이디어이다. (이 회사에는 UserVoice Helpdesk 포럼이 있어서 고객들로부터 아이디어를 받기도 한다)
  • 이 보드의 아이디어는 한주에 한번 Inbox review meeting에서 검토한다. (잠시후 다시 설명)

Bugs

여기에는 세개의 리스트가 있다.

  • Inbox : “카더라” 정도의 진단되지 않은 버그.
  • Needs input : 버그를 재현하지 못했기 때문에, bug reporter로부터 좀 더 정보를 제공받아야 하는 버그.
  • Accepted : 재현 가능한 것을 확인해서, 확실히 버그로 인정되는 버그.

만약 버그가 Accepted 로 옮겨지고 QA가 critical 버그라고 생각할 경우에는 즉각 Current Development 보드 Next Up 리스트로 옮긴다.

반대로 Accepted 로 옮겨지더라도 critical 버그가 아닌 경우에는 QA가 Next Week 리스트로 옮긴다. Next Week 리스트는 다음 주에 수정할 버그를 말한다. 주의 할 것은, QA는 한 주에 최대 7개 버그만 Next Week 리스트로 옮겨야 한다는 것이다. 버그는 언제나 존재하고 QA는 모든 버그를 수정하고 싶어하지만, 우리의 경험에 의하면 non-critical 버그 픽스에 투자하는 엔지니어링 리소스를 적당히 제한해야 한다는 것이다. (이 회사는 엔지니어가 많기 때문에 7개이지, pooq 의 경우라면 3개도 벅참)

Engineering

  • 우리는 refactoring 해야할 영역들을 리스트로 관리한다. 리스트는 엔지니어링 영역(eg. Backend, Frontend, Tests, Infrastructure)를 나타내고, 리스트 내의 카드는 refactoring 할것이나, 유저와 직접 맞닿지 않는 엔지니어링 태스크들로 이뤄진다.
  • 작은 일거리의 경우 엔지니어가 아무때나 하고 싶은 마음이 들때 자신을 배정하고 일을 시작하면서 카드를 Current Development 내 In Progress로 옮긴다. 큰 일거리의 경우에는 해야할 시점이 되었을 때 Current Development 내 Next Up 리스트로 옮긴다.

누가 계획 개발이 불가능하다고 했는가? (Planning 보드)

UserVoice planning Trello board

Planning 보드는 Lead Engineer, PM, head of UX 가 대부분의 시간을 보내는 장소이다. 아래 리스트들이 있다.

Next Up

  • 개발을 위한 spec 작성이 필요한 대략적으로 우선순위가 매겨진 프로젝트 리스트.

Spec

  • 이 리스트에 있다는 것은 “누가 spec 좀 써줘요” 를 의미한다. 이 단계의 카드는 대략적인 아이디어 단계인 경우가 많다.
  • 우리는 Google Docs 로 spec을 작성하는데, 문서에 메모하는 기능을 활용하여 시공간에 구애받지 않고 논의를 한다. 복잡한 아이디어는 즉흥 design 미팅으로 이어지기도 한다.

Design

  • “누가 디자인 좀 해줘요” 단계에 있다는 것을 의미한다. 이것이 wireframe이나 mock up을 의미하는 것은 아니다. 이 단계에서는 spec의 요구사항을 이해해서, design concept, usability, workflow 등을 정리하고, 기존 기능들에 미치는 영향들을 찾아내는 것이다. 개발 사이클로 넘어가기 전에 전체 틀안에서 발생할수 있는 문제를 조기 발견하는 것이라고 할수 있다. 만약 문제가 발견되면, 다시 Spec 리스트로 돌려보낸다.

Ready

  • 이 단계에 왔다면, spec 이 아이디어 제안자와 디자인 팀에서 검토한 결과 문제가 없다는 것이다. 필요하다면 wireframe이나 다른 것들을 추가할수도 있다. 아무튼 이 단계의 카드는 Current Development의 Next Up 리스트로 옮겨질 준비가 된 것이고, 옮길지의 여부는 Product Planning 미팅에서 결정한다.

다른 보드들에서는 카드는 거의 왼쪽에서 오른쪽으로만 옮겨지지만, Planning 보드에서는 예외다. 카드가 Ready 단계로 가기 전에 Spec 과 Design 단계를 한두번 이상 오가는건 흔한 일이다.

협업을 위한 회의들 (카드 이동에 관한)

우리는 한 주에 몇개의 회의밖에 하지 않는다.

월요일 오전 – Product Meeting (30분)

  • 참석자 : 모든 직원
  • 이 시간은 모든 직원들이 어떤 일이 굴러가고 있는지 알게 하고, 지난 주에 production launch 한 팀멤버들을 축하하기 위한 회의이다. Product manager 가 회의를 진행하는데, 회의를 위해 프리젠테이션을 준비하는 유일한 회의이다.
  • 프리젠테이션 한 슬라이드에서는 지난 주에 픽스된 모든 버그들을 버그 수정자의 아바타 사진과 함께 리스트하고 리뷰한다. 이것은 버그 픽스라는 재미없고 고된 과정을 한데 대한 자부심을 부여하는데 목적이 있다.
  • 지난 주에 완료된 기능 향상 프로젝트에 대해서는 각 프로젝트마다 (모든 관련자들의 아바타 사진을 포함한) 하나의 슬라이드를 할당해서, 이것이 얼마나 서비스에 긍정적 변화를 줬는지 플러스 포인트로 표현하고, 변화된 부분을 스크린샷이나 스크린캐스트로 보여준다. 프로젝트 관련자 아무나 한명이 20-30 초간 어떤 것을 만든 것인지 설명하기도 한다.
  • Product manager나 CEO는 Current Development – Next Up에 등록된 새로운 프로젝트들에 대해 왜 이것이 중요한지 설명한다. (비지니스와 연관된 프로젝트의 경우만)

금요일 오전 – Inbox Review Meeting (30분)

  • 참석자 : Product manager, Head of UX는 의무, 나머지 사람은 옵션.
  • 이번 주에 카드를 Inbox에 추가한 경우(Customer 리스트든, Internal 리스트든) 이 미팅에 참석해서, 그 카드에 대해 설명하는 것이 좋다. 설명의 목적은 나머지 팀원들이 use case를 이해하고, 현재 어떤 부분이 pain point 인지 알게 하는 것이다.
  • 미팅이 산만해지지 않도록 하기 위해, 이 미팅에서는 해결책은 논의하지 않는다. 오직 급한 문제점이 무엇인지만 선별한다.

금요일 오후 – Product Planning Meeting (1시간)

  • 참석자 – CEO, PM, Head o UX, Lead Engineer
  • 회의 목적 : Planning 보드와 Engineering 보드의 카드들을 모두 리뷰해서 Current Development 보드의 Next Up 으로 옮길 것을 정한다. 카드를 옮길 때는 그 카드에 관련된 모든 사항이 명확해야 한다. (ex. 정책이 아직 픽스되기 전인데, 개발 카드를 옮겨서는 안된다.)
  • 카드들을 Next Up 으로 옮긴 후에는 지난 주에 완료되지 않은 카드를 포함하여 전체 Next Up 리스트를 다시 우선순위대로 정렬한다. (지난 주에 top priority였던 카드라 해도 이번주에 급한일들이 많으면 가장 바닥으로 내려갈수도 있다.
  • 마지막으로 급한 버그로 선정된 Bugs 보드내의 Next Week 카드들을 리뷰한다. Next Week 에 있다고 무조건 Current Development의 Next Up으로 승격시키는 것은 아니고, 버그에 대한 충분한 정보가 없거나, 하루 이상 걸리는 버그일 경우에는 Next Up으로 옮기지 않는다. 대신, 승격시키는 버그들에 대해서는 앞서 Planning과 Engineering에서 승격된 카드들보다 상단에 놓는다. 다른 무엇보다 현재 고장난 부분부터 고치는게 최우선이기 때문이다.

매일 아침 – Standup Meeting (10분)

  • 참석자 – 모든 product 팀 멤버 (디자이너, 엔지니어, QA)
  • 이 회의는 지루하게 “어제 뭘했고, 오늘 뭘 할꺼다” 를 나열하는게 아니라, 각자 맡은 일을 하기 위해 다른 팀원으로부터 필요한게 뭐가 있는지 체크하는 것이다. 짧게 10분 내로 한다.

이것이 Product team 의 공식적인 정기 미팅 전체이지만, Planning 보드내의 여러 카드에 걸친 in-depth design discussion을 위해 Head of UX, Product Manager, Lead Engineer 가 즉흥적으로 회의를 하기도 하는데, 이런 때에는 모호함을 걷어내고 공중부양중인 개념들을 지상으로 끌고 오기 위해 3시간 이상씩 진행되기도 한다.

이런 in-depth design discussion은 주로 목요일이나 금요일 쯤, 그 주에 진행중인 여러 카드에 걸쳐 서로 다른 방향의 움직임들이 보일 경우 진행한다. 이것은 회의 중 가장 생산적이고, 재밌는 회의다. 회의 끝무렵이 되면 여전히 미결정 상태의 수많은 design decision이 남아있고, 원래 시작했던 지점으로 다시 돌아온 것처럼 보일때가 많지만, 그것은 각 design decision 을 진행했을 때 발생하는 trade-offs를 제대로 파악해가고 있다는 긍정적인 신호이다. 주요한 결정을 내릴때는 “문제를 이해하지 못한채 무작정 아무 방향으로 가는것”보다 “문제를 이해하고 제대로 된 방향으로 가는 것”이 중요하기 때문이다.

경험으로부터 얻은 교훈

카드에 코멘트를 남길 때는 항상 명시적으로 대상자에게 @mention 하라.

코멘트를 남길때 대상자를 명시하지 않는 경우는, 나중에 자신이 참조할 용도로 데이터를 남기는 것이다. 정말 대상자의 답변이 필요하다면, 명시적으로 지칭하라.

최우선 순위 목록 하나만을 유지하라. (Current Development 의 Next Up 리스트)

처음에는 서비스의 각 영역(admin console, onboarding, widgets, iOS, end-user web portal, emails)별로 최우선 순위 리스트를 따로 만들었다. 만약 우리가 각 영역별로 개발팀을 가지고 있었다면 이 방법도 제대로 동작했겠지만, 개발팀의 구조는 서비스 영역의 구조와는 달랐고, 그 때문에 팀원들은 다음으로 무엇을 최우선으로 해야 하는지 헷갈려했다. 이 방법은 매우 불편한데다, 전체팀이 어디에 포커스를 두고 일하고 있는지 알기가 힘들었다. (팁: Trello를 쓰면서 수평 스크롤을 많이 사용하고 있다면, Trello를 잘못 사용하고 있다는 의미다.)

버그 관리를 위해 따로 시스템을 두지 마라.

처음엔 버그 트래커를 따로 쓰고 있었고, 새 프로젝트에 대해서만 Trello를 사용했다. 이것은 위에서 설명한 서비스 영역별로 리스트를 두는 것처럼 문제점이 많았다. 하나 이상의 리스트를 가지고 있을 때, 우선 순위 시스템은 제대로 동작하지 않았다.

버그 픽스에 쓰는 시간을 한정하라.

우리는 한주에 Next Up으로 승격시키는 버그의 수를 한정함으로써 대략적으로 위 원칙을 지키고 있다. 중요 버그만을 선별해서 엔지니어에게 전달하므로, QA와 엔지니어간에 버그의 중요성에 대해 논쟁하는 것을 막아준다. 시간이 지날수록 QA팀이 버그를 선별하는 능력도 높아져 팀 전체의 효율성도 높아진다.

Next Up 리스트에 카드를 추가하거나 우선순위를 재배정하는 것은 일주일에 한번만!

이 원칙은 Next Up 리스트가 계속해서 흘러내리는 모래 언덕처럼 변하는 것을 방지한다. 월요일 오전 회의에서 Next Up 내의 새 카드들이 소개되면, 팀원들은 그 주동안 무슨일을 해야 하는지 알게 된다. 팀원들은 우선순위 높은 일을 골라서 하는데, 자신이 하고 있는 일의 우선순위가 주중에 바닥으로 떨어질까 걱정하길 원하진 않을 것이다.

좋은 spec은 유저 스토리나 비지니스에 대한 설명이지, 구현 레시피가 아니다.

누구나 프로젝트에 최선을 다하기 전에, 자신이 왜 그 일을 하는지, 목표에 매료되어야 한다. 목표를 실행할 엔지니어가 customer pain point 나 business pain 이 무엇인지 알게 하라.

프로젝트 기간을 예측하려고 노력하지 마라.

예전에 기간을 예측하고 다음 프로젝트를 계획해서 일정표를 그리느라 많은 시간을 허비한 적이 있다. 많은 시간과 노력을 퍼부었지만, 예측은 항상 빗나갔다. 대신 그런 불확정성을 끌어안기로 했다.

Production에 올라가서 완료된 카드에 대해 관련자의 노고를 치하하는 자리를 만들어라.

구성원이 일거리가 끝없는 쳇바퀴에 갇힌 것처럼 느끼면, 급격한 생산성 저하가 일어난다. 우리는 Current Development 내에 Week 리스트를 매주 단위로  만들고 그 주에 production으로 배포된 카드들을 그 리스트로 옮긴다. 월요일 오전 Product Meeting에서 Week 리스트 내 완료된 카드들을 소개하고 새로운 스크린샷을 보여줄때, 이들의 노고를 치하할수 있을 것이다.

————————————————————————————————————————

여기까지 우리의 경험을 공유했는데, 많은 도움이 되길 바란다. 현재의 탄탄한 프로세스를 만드는데 기여한 Dejana Bajic (PM), Joshua Rudd (Head of UX), Jonathan Novak (Lead Engineer) 에게 감사의 뜻을 표한다.

About these ads

One thought on “Trello로 효율적으로 협업하기

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s