NBT가 일하는 방식

오늘은 현재(2016년 4월 26일)의 칸반 보드 구성을 기준으로 NBT에서 제품을 만들어내는 과정을 정말~ 간단하게 소개하 드리려고 한다.

(1) – 프로젝트 진행을 위한 메인 공간

(2) – 제품 개발 프로세스의 각 단계에 대한 정책 및 완료 기준을 명시화

(3) – 프로젝트 생산성 정량 지표

(4) – 앱 릴리스 정보

(5) – 프로젝트 출시 이후 성과 분석

(6) – 제품 전략

(7) – 수시로 발생하는 각종 운영성 업무 지표 수집

NBT의 제품 개발 프로세스는 매우 단순하다. (1) 부분을 보면 알 수 있는 것처럼 옵션, 분석진행중, 구현대기중, 구현진행중, 배포진행중, 출시완료의 다섯 단계로 이루어져 있다.

옵션

옵션 단계에 대해 설명하기 전에, 우선 “옵션”이라는 용어에 대한 추가 설명이 필요하다. 다른 회사의 제품 개발 프로세스를 살펴보면 대개 이 위치에 “요구사항”, “할 일”, “아이디어”, “백로그” 등과 같은 이름들을 사용한다. 모두 그 역할은 동일하다. 아직 진행하지 않은 프로젝트를 모아 놓는 곳이다. 그런데, 우리가 여기에 옵션이라는 다소 생소한 이름을 사용하는 데에는 이유가 있다. 요구 사항이라는 용어는 암묵적으로 작업자를 수동적 위치에 놓이도록 만든다. 내가 예민한건지 모르겠지만, 요구 사항이라는 단어를 들을 때마다 요구를 전달하는 외부의 누군가와 그 요청을 처리하는 내가 (또는 우리가) 분리된 별개의 존재가 되어버린다는 느낌을 받는다. 나는 다른 사람의 요구를 수동적으로 처리하는 존재가 되고 싶지 않다. 내가 주체적으로 판단하고 실행하는 존재가 되고 싶다. 그래서 선택한 단어가 옵션이다. 함께 캐시슬라이드를 개발하는 사람들이 제품 백로그를 보면서 해치워야 할 일감으로 받아들이는 것이 아니라, 제품을 어떤 방향으로 진화시켜나갈지 주체적으로 판단할 수 있는 여러 선택지로 받아들이기를 바라는 마음에 옵션이라는 단어를 사용하고 있다.

옵션 단계에서 가장 중요한 활동은 매주 금요일에 있는 리프레시 회의다. (옵션을 새로고침한다는 의미다.) 리프레시 회의에 대해서는 나중에 상세히 다룰 예정이기 때문에, 간략하게만 언급하자면 옵션에 등록되어 있는 프로젝트 중에서 현재 시점에 가장 중요한 상위 몇 가지를 선택하는 자리다. NBT의 거의 모든 부서가 모여 백로그를 살펴보면서 제일 먼저 개발에 착수해야 할 항목을 선정한다. 여기에서는 (6)에 있는 제품 전략을 가장 중요한 판단 기준으로 삼는다.

분석

분석 단계의 최종 산출물은 “분석 리포트”이며 NBT 구성원이라면 누구나 위키를 통해 모두 접근해서 볼 수 있다. 분석 보고서에서 다루는 주요 어젠다는 네 가지다.

해결해야 할 문제는 무엇인가?
문제를 해결하기 위한 최적의 솔루션 후보에는 어떤 것들이 있는가?
예상하는 프로젝트 완료 기준은 무엇인가?
어떤 성과를 기대하는가?

대개는 이매지니어가 분석 단계를 담당하지만, 항상 그런 것은 아니다. 프로젝트 성격에 따라 개발자가 분석을 진행하는 경우도 있다. 상세한 분석 리포트가 필요하지는 않기 때문에 A4 한 장 이내의 분량으로 5일 이내에 완료하기를 권장한다. 분석 단계에서 가장 중요한 것은 옵션의 불분명한 부분을 분명하게 만드는 일인데, 그렇게 하려면 해당 프로젝트를 요청한 사람, 제품 전략을 담당하는 PD, 실제로 개발을 진행하게 될 개발자 등 모든 이해 관계자들과 직접 만나 긴밀하게 소통할 필요가 있다. 그 과정에서 취소하는 방향으로 결론이 내려지는 프로젝트도 많다.

분석과 기획은 다르다. 흔히들 말하는 기획서를 작성하는 일은 구현 단계에서 이루어진다.

구현

기획, 개발, 디자인, 테스트 등 실제로 프로젝트를 진행하는 데 필요한 모든 주요 활동은 구현 단계에서 이루어진다.

구현 단계에서는 제일 먼저 프로젝트에 참여하는 모든 사람들이 모여 “프로젝트 차터”를 만든다.프로젝트에 참여하는 구성원들이 분석 리포트를 기반으로 프로젝트 차터를 작성하면서, 목표를 명확한 형태로 확정짓고, 프로젝트 완료 기준을 세우고, 대략적인 설계를 진행하면서 세부 업무를 분할하여 프로젝트를 곧바로 시작할 수 있는 상태로 만든다. 프로젝트 차터 작성이 끝나면, 그때부터 프로젝트가 본격적으로 진행된다.

개인적으로 구현 단계에서 가장 중요하게 생각하는 것은, 모든 참여자가 프로젝트를 함께 시작해서 함께 끝내는 것이다. 기획자의 최종 목표는 파워포인트로 기획서를 만들어 개발자에게 넘기는 것이 아니고, 디자이너의 최종 목표 역시 이미지 파일과 디자인 가이드를 개발자에게 넘기는 것이 아니다. 소프트웨어 엔지니어도 정해진 기능을 코드로 구현하는 것이 최종 목표가 되어서는 안된다. 팀에서 스스로 결정한 프로젝트 목표를 협업을 통해 달성해서 고객에게 가치를 전달하는 것이 모두의 최종 목표가 되어야 한다. 직군 사이의 갈등이 생기는 근본적 이유는 서로 달성하고자 하는 목표가 다르기 때문이라고 생각한다.

물론 역할에 따라 팀원 각자의 작업량과 업무 주기가 달라서, 모두가 프로젝트를 함께 시작해서 함께 끝내려면 불가피하게 남는 시간들이 생긴다. 아무래도 이매지니어는 프로젝트 초기에, 소프트웨어 엔지니어는 프로젝트 후기에 업무량이 집중되기 때문이다. 모든 작업자가 항상 100%의 효율을 발휘하도록 만드는 것이 당연하다고 생각하는 관리자는 이런 선택을 하기 어렵다. 불안감을 이겨내기 어려워서다. 다행스럽게도 나는 이 문제를 크게 고민하지 않고 살고있다. NBT 제품 길드의 구성원들은 (스스로 개선 프로젝트를 진행하거나, 주변 동료에게 도움을 주거나, 새로운 기술에 대한 학습 등을 통해) 이렇게 남는 시간을 생산적으로 사용할 수 있다는 믿음이 있기 때문이다.

성과 분석

위 사진의 (5) 부분은 성과 분석을 위한 곳이다. 이 공간을 마련하기 전까지는, 프로젝트를 완료해도 그 성과가 좋았는지, 더 개선할 부분은 없는지, 궁극적으로는 우리가 올바른 방향으로 가고 있는지 알기 어려웠다. 출시 이후 성과 분석이 필요한 프로젝트가 있다면, 이매지니어는 출시 완료 단계에 붙어있던 티켓을 성과 분석 부분으로 옮긴 다음, 적절한 시일이 지난 후 분석 리포트에서 미리 정해두었던 성과 지표의 결과를 간단하게 정리해서 모두와 함께 공유한다.

이 성과 분석의 결과가 새로운 옵션으로 이어지기도 한다.

향후 계획

여기까지 오는 데에도 오랜 시간이 걸렸지만, 지금도 고민하고 있고 여전히 해결하지 못한 숙제들도 많다. 대표적인 것들은 아래와 같다.

옵션에 등록되는 항목들의 품질을 더 높이려면 어떻게 해야 할까?
리프레시 회의가 아닌 어둠의 루트를 통해 들어오는 긴급 업무 요청에는 어떻게 대응하는 것이 좋을까?
아직 제품 길드 내부에서 함께 협업하지 않고 있는 UI/UX 기능과 원활하게 협업하려면 장/단기적으로 어떤 방법이 좋을까?
갈수록 레거시와 복잡도가 늘어나고 있는 제품의 품질을 개선하거나 유지하려면 또 무엇이 필요할까?
파티 사이의 협업과 합의가 필요한 프로젝트 진행이나 정책 결정은 어떻게 하는 것이 최선일까?

이전에도 여러 차례 반복해서 강조했지만, 지금까지 했던 이야기는 전부 현재의 스냅샷에 불과하다. NBT 제품 길드는 지속적이고 점진적으로 더 좋은 방법을 찾아 개선하는 문화를 추구하고 있기 때문에, 제품 개발 프로세스는 지금까지도 계속 진화해왔고 앞으로도 그럴 것이다.