brunch

You can make anything
by writing

C.S.Lewis

by 변재명 Dec 24. 2019

워터폴•그로스해킹•애자일 업무 프로세스에 대해

조직문화의 변화와 혁신, 리더의 강한 의지가 꼭 필요한 협업 프로세스

여러분 회사는 IT 협업 프로세스를 어떤 방식으로 진행하시나요? 제목에 있는 세 가지 중 하나이거나, 복합적으로 업무를 진행하시겠지요? 그렇지만, 대부분은 워터폴 방식으로 하고 있을 겁니다.


대표적인 구조도는 아래와 같습니다.

워터폴(Waterfall) 협업 방식은 직전 단계의 업무가 종료되어야 다음 단계로 진행되는 프로세스라고 보시면 됩니다. 워터폴을 통해 각 단계 전반의 통제력이 높아지지만 프로젝트 진행 중 범위가 변경되면, (예를 들어 요청이 변경되거나, 기획서 버전이 1.0으로 확정되지 않고, 계속 버전업이 된다면) WBS가 계속 변경되면서 관리가 어려울 수 있습니다.

위와 같이 WBS로 정교하게 짠 일정들이 범위가 조정되면 다 틀어지기 때문에 혼란을 초래할 수 있겠죠?

그래서 워터폴 방식은

범위의 확정, 기획서 v1.0

이 매우 중요합니다. 그것만 확정되면 모든 프로젝트 요건을 초기에 파악할 수 있도록 돕는 정보를 제공함으로써 초기 단계의 핵심 정보 및 요건 손실을 줄여줄 수 있습니다.

기획자들이 가장 듣기 힘든 얘기가 "기획서가 확정이 안돼서, 개발이 안돼요~" 같이 초기 요구사항 분석 및 스토리보드 공유과정에서 계속 바뀌는 범위인 거죠.

v1.0 이 선언된 기획서로 WBS(Work-Breakdown Structure)와 타임라인(Timeline)을 확정하고, 이후 요구사항은 v2.0으로 다시 정의하는 것이 중요합니다.


제가 전사 오리엔테이션 시에 IT부서가 아닌 분들께 설명드리는 협업 프로세스 문서입니다. 일반적인 IT 업무 요청 프로세스인 워터폴 방식에 대해 상세히 소개해 놓은 자료라 여러분들께서도 활용하시라고 공유드립니다.


VUCA (뷰카) 즉, 변덕스럽고(Volatility), 불확실하고(Uncertainty), 복잡하고(Complex), 모호한 (Ambiguity) 면이 많은 최근의 개발환경에서 유연함과 속도를 통해 성과를 창출해 내는 것이 종합적인 계획 하에서 움직이는 것보다는 매우 중요해졌습니다.

전체를 정리해서 일정을 잡는 게 아니라 기능 단위로 쪼개서 빨리 실행할 수 있도록 하는 것이 중요합니다.

그래서 마케팅에서는 그로스 해킹(Growth Hacking), 개발 수행에서는 애자일(Agile) 얘기가 나오는 겁니다.

급격한 시장 변화에 비즈니스 모델 변화의 필요성을 느낀 기업들은 애자일 문화로 전환하며, 성공 기업의 모델이나 실천법을 도입하는데요. 그게 쉽지는 않습니다.


애자일 도입 실패 요인 (4번 항목이 가장 많습니다.) (출처 : 휴넷 CEO)

일단 애자일한 조직을 구성해서 프로젝트를 수행할 때는 목표, 운영기간, 운영방법, 조직 구성 등에 대해 모두가 공감하면서 각 구성원들이 One of them의 업무가 아닌 All of them의 역할 배분을 통해 집중해서 업무를 수행할 수 있도록 해야 합니다.

Agile 소프트웨어 개발 선언문 (Manifesto for Agile Software Development, 2001)을 보면 더 명확해집니다.


절차와 도구보다는 개인의 상호작용

포괄적인 문서보다는 작동하는 소프트웨어

계약 협상보다는 고객과의 협력

계획을 따르기보다는 변화에 대응하기를 가치 있게 여긴다


협력과 피드백을 통해 조직원들이 기민하게 대처할 수 있도록 하고 (이를 위해서 애플처럼 해적 깃발을 꽂고 프로젝트 룸에 모두 모여서 업무 할 수 있도록 하는 것도 중요하지요), 리더는 세부적인 의사결정이 아닌 목표의 설정, 평가, 조정, 전파와 업무 우선순위를 결정해주는 역할에 집중하면 됩니다.

아래와 같은 기준으로 애자일 조직을 구성하면 일단 시작은 가능합니다.

애자일 조직 구성의 시기와 방법 (출처 : 휴넷 CEO)


유사한 개념으로 DevOps (개발+운영)가 있습니다. 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상하는 문화 철학, 방식 및 도구의 조합을 얘기하는 것이죠.

애자일이든 그로스해킹이든 DevOps 든 모두 가장 중요하게 보는 부분이 사람이고, 빨리 실패하고 (Fast Fail) 빨리 성과를 내는 것을 자연스럽게 받아들일 수 있어야 합니다.


저희 회사에서 그로스해킹 프로젝트를 진행했던 사례들을 보시면 좀 더 이해가 잘 되실 것 같습니다.

그로스해킹 프로젝트를 위한 애자일 조직 구성

그다음 업무 프로세스에 대한 정의, 그리고 핵심 요소를 정리합니다. 실제 이런저런 방법을 써보다가, 가장 최적의 프로세스를 찾은 거라고 봐야 합니다.

그로스해킹 업무 프로세스 정립 및 핵심 요소 도출

중요한 것은 결과를 추적하고 다시 새로운 시도를 해보는 것이겠지요. one of them으로 다른 업무들과 같이 진행했다면 거의 1년 가까이 걸릴 업무가 3개월에 228개의 기능 개선이 진행되었습니다.

그로스해킹 업무과제 선정 방법 중 AARRR 적용
그로스해킹 업무과제 선정 방법 중 고객경험지도 내 만족도 측정 적용
그로스해킹 프로젝트 업무 성과 종합

참고로 성과 측정에 사용한 Tool은


- GA(Google Analytics) : Web, 앱 의  방문, 액션, 사용자 흐름, 광고 트래킹 할 수 있는 보편적인 tool

- 로그매틱 (logmatic) : 앱  로그 수집  tool, 앱 사용자 분석을 위해 지표로 활용될 data의 raw를 수집

- 패브릭 (fabric) : 앱 retention 지표 확인 솔루션, DAU(일 활성화 유저), MAU(월 활성화 유저), 오류 보고


을 통해서 진행하면서 기능 론칭 시마다 AS-IA, TO-BE를 확인했었습니다.


본 프로젝트를 수행하면서 가장 좋았던 점이라면


- 개발자 투입, 기획-구현 gap 최소

  아이디어 확장, 기획 다각화로 브레인스토밍 시너지 발생

  기획과 개발자가 같은 공강에서 협업함으로 인해 기능 관련 빠른 의사결정이 가능하고 기능 구현의 장애요소 확인, 대안 수립도 유연하게 대응

- 프로토타입 통한 기획 정교화

   앱 개발자, 디자이너가 스케치, 제플린과 프로토파이를 활용하여 프로토타입으로 서비스를 미리 만들어보고

   UX 검증을 통한 기획  수정/보완이 가능했음.


회고 진행 시 아쉬웠던 점으로 나온 부분은


- 일부 업무만 전담자가 배치되어, 작업자 간 속도 불균형 이슈

→ 차후, “작업 프리패스”권으로 속도 균형 개선하였으나 근본 해결 필요.

- 작업 중 파생/추가 업무 발생 多 기존 업무 지연

기존 데이터가 없거나, 추가로 구축해야 하는 파생 업무 발생

→ 필수 여부, 빠른 우선순위 설정으로 지연 완화

- 단계별 업무 균형 수행에 있어 한계 존재

기반 작업이 미비한 상태로 3개월이라는 기간 내에 기반 작업부터 매출 견인까지 모든 효과를 끌어올리기에는 한계 존재(기반 작업 비중 높음)
각 프로세스별 장/단기 관점을 나누어 접근 필요


결국 기획&웹개발자만으로 구성된 불완전 조직이 아닌 기획, 웹개발, 앱개발, DBA, 디자인, 퍼블리셔까지 완벽한 완전체 조직으로 구성하는 것이 중요하다고 결론 짓고, 현재 몇 개의 프로젝트들을 이러한 방식으로 수행하고 있습니다.


결국은 회사의 의지(진짜는 대표이사의 의지), 프로젝트 참여자의 공감대가 확실해야 가능했고, 처음에는 다른 회사들의 사례를 따라 해보기도 했지만, 자사의 환경과 업무프로세스에 맞는 방법을 찾아야 한다는 점도 부가적으로 나온 얘기였지요.

아래 얘기가 딱 와 닿더라고요.

도요타 방식으로 성공한 기업은 도요타뿐이다 (출처 : 휴넷CEO)


이전 09화 이런 업무까지 기획팀에서 해야 하나요? (R&R이야기)
brunch book
$magazine.title

현재 글은 이 브런치북에
소속되어 있습니다.

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari