1. 내 서비스 런칭, 왜 자꾸 미뤄지는가?
B: 이 데이터 고려가 안되어있는데요?
C: 진행하다 보니 구조적인 오류를 발견했어요.
A: …
이 많고 복잡한 문서들만 정리하는데 한 세월,
나름 모든 구조를 고려하고 많은 케이스를 생각했다고 했는데도 자꾸만 변수나 오류로 인해 화살이 두배가 되어 되돌아온다.
예상치 못한 변수로 여태 세워놓은 여러 정의들이 흔들거리면 눈앞이 캄캄해지고 어디서부터 어떻게 고쳐야하는지 일정은 또 얼마나 늘어날지..
2. 나의 프로젝트 진행 프로세스는 어떻게 진행되고 있을까?
서비스 개발 프로젝트엔 어떤 방법이 있는지 크게 방법론 2가지에 대해서 알아보자.
1) 폭포수 방법론
폭포수 방법론은 아직까지 많은 비중으로 사용하고 있는 서비스 개발 방법론이다.
특징으로는 기획자->디자이너->개발자->테스터->런칭(현업자) 이렇게 단계별로 진행을 하여
각 담당하고 있는 개발 단위에 책임을 지고 다음 단계로 토스하며 진행하는 방법이다.
장담전으로는,
장점
(1)단계가 명확히 구분되어 정확한 진척률 확인이 용이하다
(2)단계별로 책임 소재가 명확하다
(3)산출물 문서가 명확하여 관리에 용이하다
(4)외주 인력과 작업하기 용이하다
=> 즉, 이런 산출물 기준이 명확하고 책임소재가 명확하여 Push를 잘하는 조직일수록 오히려 오픈일정을 맞추기에 적합할 수 있는 방법이다.
단점
(1)앞의 단계에서의 잘못된 기획, 설계가 되면 되돌리는 것이 굉장히 오래 걸린다.
(2)앞단계 문서에서 명시되지 않은 부분에 대한 누락이 되기 쉽고 기획 변경 시 영향 범위가 넓다.
(3) 테스트기간 전까지 산출물의 형태를 미리 보거나 테스트하기 어렵다.
=> 앞 단계에서 완벽한 기획에 대한 부담이 더 크고 단계별로 진행되는 방법이다 보니 잘못된 방향도 다시 돌아가려면 거의 모든 단계에 영향을 주기 때문에 변수나 기획 오류에 대한 리스크가 굉장히 큰 편이다. 또한 각 단계별 완료시점이 명확하기 때문에 잘못 된 경우도 기간엄수를 위하여 그냥 넘어가는 경우들도 발생하여 문제도 늦게 발견될 확률이 높다.
2) 에자일 방법론
에자일 방법론은 빠르게 돌아가는 IT시장과 맞지 않는 폭포수 방법론처럼 느리고 높은 리스크같이 어려운 상황들을 대응하고자 생긴 방법론이다.
특징으로는 에자일은 4가지의 핵심사상을 통해 진심으로 이해해야 적용할 수 있는 방법이다.
(1) 절차와 도구를 넘어선 개성과 화합
– 고정적이고 한정된 기획을 오퍼레이터로써 수행하기보다 기획 목표와 러프한 형태만 공유하며 개발적인 여러 방법을 시도를 한다.
(2) 종합적인 문서화를 넘어선 동작하는 소프트웨어
– 불필요한 문서를 쓰기보다 개발을 한다.
(3) 계약과 협상을 넘어선 고객과의 협력
– 갑과 을 관계 보다 서로 대화하며 의견 화합을 이뤄 협력을 한다.
(4) 계획 준수를 넘어선 변화에 대응
– 중간에 변화가 찾아오면 다음 스프린트에 적용하여 변화에 빠르게 대응한다.
이렇게 에자일은 큰 프로젝트를 잘게 쪼개어 스프린트 단위로 2~3주 사이클로 빠르게 개발하고 검증하여 결과물을 발전시키며 변화에 유연성을 가진 특징을 가졌다.
장단점으로는,
장점
(1) 문서화를 단축하고 개발 산출물을 빠르게 볼 수 있다.
(2) 중간 단계에서 변화하는 기획을 수용하여 빠르게 변화할 수 있다.
(3) 개발자와 디자이너의 자유도가 높아 창의적인 결과를 가져올 수 있다.
(4) 과정 내내 팀원들과 많은 협의를 통해 최고의 산출물을 만들 수 있으며, 개발자와 디자이너와의 끈끈한 협업이 가능하다.
=> 형식 절차보다 빠른 개발 대응으로 눈으로 확인하기 좋으며, 단계적인 책임이 아닌 팀원 한명 한명의 직무 역량을 최상위로 끌어내야하는 부분들에 있어서 소규모의 인력일 경우에 적용하기 좋은 방법이다.
단점
(1) 복잡한 프로젝트에서 참여자의 수준이 제각각이면 전체적인 진척률과 수준 관리가 어렵다.
(2) 참여자들이 에자일 사상에 대한 공감이 없는 상태에서 출발하면 상호간 책임 문제로 번지기 쉽다.
(3) 팀과 밀접하게 움직여야 하기 때문에 에자일 전문가 역할이 필요하고 전체적인 사상과 팀웍 관리가 필요하다.
=> 결국 팀원들의 역량에 따라 진척이 좌우될 가능성이 높고, 사상에 대한 공감이 없는 팀일 경우 역할과 책임의 문제로 인한 프로젝트 전체 진행도가 영향을 받을 수 있다.
3. 그러면 내 프로젝트는 어떻게 준비를 했어야했는가?
일단 각 방법론에 필요한 문서에 대해서 봐보자.
1) 폭포수 방법론의 주요 산출물
(1) RFP : 외주사와 시스템 공급사 등 제안 업체들에게 제안 요청/발주를 하는 문서(기본적인 기획 요구)
(2) 정책서 : 서비스에서 필요한 약속, 정책에 대한 정의
(3) 요구사항정의서 : 서비스 전략에 필요한 기술적인 부분을 정리한 협업 요청서
(4) IA : 화면간의 상하관계를 마인드맵, 트리구조, 테스크 동선별 화면구조 등으로 정의하여 고객 동선을 관리하는 문서
(5) 스토리보드 : 기획에 대한 총체적인 내용과 화면에 대한 룰과 규칙, 케이스 등을 정리 한 문서
(6) 테스트케이스(T/C) : 기능만 테스트 하기 위한 단위 테스트, 서비스 전체의 흐름에 따라 시나리오 베이스의 통합 테스트 등의 테스트 항목, 시나리오들을 정리한 문서
(7) 운영가이드 : 서비스를 운영하는 현업자들에게 배포하기 위한 매뉴얼 문서
2) 에자일 방법론의 주요 산출물
(1) 유저스토리(Userstory) : 고객이 왜, 무엇을, 왜 하고싶은지 페르소나를 정하고 이용자 관점에서 기능정의를 간단하게 정리하는 것
+ 유저스토리는 간단하더라도 6가지 특성으로 작성한다
① 모든 유저스토리는 전부 독립적이어야 한다. (중복되어서는 안된다.)
② 협상이 가능해야 한다. (경중 판단이 가능해야 한다)
③ 사용자, 비즈니스의 가치가 모두 포함되어 있어야 한다.
④ 예측 가능해야 한다. (KPI나 결과를 측정할 수 있어야 한다.)
⑤ 사이즈가 작아야 한다. (2~3주 내 사이클로 가능한 범위만 작성해야 한다.)
⑥ 테스트가 가능해야 한다.
(2) 백로그(Backlog) : 기능 리스트들의 우선순위를 정하고, 기능적인 방향성을 간단하게 적는 것
(3) 기획 프로토타입 : 협업자에게 빠른 이해를 전달하기 위한 기획적인 페이퍼 목업 프로토타이핑
(4) 개발 프로토타입 : UI,인터랙션,기능이 적용 된 실제 결과물과 비슷한 프로토타이핑
(5) 운영가이드 : 서비스를 운영하는 현업자들에게 배포하기 위한 매뉴얼 문서
두 방법론의 가장 큰 차이는
폭포수에서 나오는 산출물들은 하나하나의 정의들을 계속 종합적으로 취합하며 큰 범위의 문서로 정리를 하는 편이고,
에자일 같은 경우는 대부분 직관적이고 최소한으로 간략하게만 적어내는 것이다.
프로젝트의 자원/인력, 규모를 고려하여 여러 사람을 거쳐야하는 프로젝트라면 문서적으로 명확히 명시되어 있는 방법을,
소규모로 내부에서 주로 진행하게 될 프로젝트라면 빠른 검증과 공통된 목표에 대한 협의와 합심을 중점적으로 하는 방법을 택해보면 좀 더 낫지 않을까 생각해본다
방법은 방법일 뿐 결국엔 본질적으로 기획이 탄탄해야 한다고 할 수도 있지만
프로세스를 제대로 이해하고 그에 맞는 준비를 해두면 더 내가 원하는 진행방향으로 이끌 수 있지 않을까? 🙂
