9장. 애자일의 미래#4
#9-4 SW의 소멸사이클
#9-4 SW의 소멸 사이클
'14년 어느날, 한 장의 그림이 트위터에 걸려 IT업계를 뜨겁게 달궜다. 데이비드 블랜드라는 린 프로세스 컨설턴트가 위와 같은 다이어그램을 그려 트위터에 올렸다.
내용 자체는 아주 단순함에도 불구하고 2천 회 이상 리트윗이 되었고, 이에 대한 기사 및 블로그, 토론방이 활발하게 열렸다. 많은 사람들이 이 다이어그램에 관심이 있었던 이유는 이 소프트웨어가 죽는 사이클은 정말 많은 회사들에서 관찰할 수 있는 패턴이기 때문이다.
[SW의 소멸 사이클]아무도 제품을 쓰지 않는다 → 고객에게 부족한 기능이 무엇인지 묻는다 → 부족한 기능을 만든다 → 다시 아무도 제품을 쓰지 않는다.
혹시 여러분의 회사에서 위와 비슷한 패턴으로 제품을 만들고 있는 곳이 있는가? 혹시나 이 내용이 잘 이해되지 않으면 다음의 실사례를 보면 된다.
--------------------------
* A 제품의 개발사례
- 우리는 3개월간 소프트웨어를 만들기 위해 시장 조사했다. 필드 리서치와 사용자들을 만나고, 경쟁사 제품을 분석했다. 그 내용을 기반으로 기능 목록을 만들었다.
1) 가장 우선순위가 높은 기능부터 구현하기로 했다. 하지만, 경쟁사와의 차별점을 만들기가 어려웠다. 때문에 3개월의 개발 기간 동안 최대한 많은 기능을 만들기로 했다.
2) 3개월간 빡빡한 일정 동안 기능을 만들어 힘들게 론칭했다.
3) 사용자가 예상보다 늘지 않았다. 여러 가지 프로모션을 했지만, 사용자는 기대 수준 이하에 머물고 있었다. 사용자들은 경쟁사보다, 기능이 부족하다고 말했다.
4) 팀 내에서 사용자가 사용하지 않는 이유에 대해 토론했다. 결국 경쟁사 수준보다 기능 수가 적어 사용자가 찾지 않는다고 결론 내렸다.
5) 부족한 기능중에 다시한번 우선순위를 잡아 작업했다. 3개월간 더 개발하여 경쟁사 수준의 기능을 어느 정도 만들었다.
6) 여전히 사용자가 늘지 않았다. 그 이유를 내부적으로 확인했는데, 우리가 경쟁사 수준으로 제품의 기능을 채워나가는 동안 경쟁사는 새로운 기능을 론칭했기 때문이라고 결론지었다.
7) 팀은 또 다른 3개월을 투자하여 경쟁사의 새로운 기능을 만들 수 있는지에 대해 고민하기 시작했다.
8) 이 일은 계속해서 반복되었다. 하지만 여전히 사용자는 늘지 않았다.
--------------------------
제품을 론칭한 시점부터 사용자가 외면하는 경우는 위의 사례처럼 SW의 소멸 사이클에 들어갈 가능성이 더 높아진다. 원하는 수의 사용자를 확보하지 못하니, 유효한 사용자 반응을 얻기 어렵고, 이를 보완하기 위해 일반적으로 경쟁사 제품에 부족한 기능이 있어 사용자들이 사용하지 않는다고 판단하는 경우이다. 이럴 경우 부족한 기능을 경쟁사 제품에 맞춰 보완하는 형태로 기능 개선을 하게 된다.
하지만 일반적으로 경쟁사보다 상대적으로 짧은 시간 안에 비슷한 기능을 구현해야 하기에 오랜 시간 축적된 노하우로 만든 경쟁사의 기능보다 더 나은 기능적 성숙도를 갖기 어렵다. 또한 이미 시장에서 많은 사용자를 확보하고 있는 경쟁사의 경우 출시한 제품을 실제 사용하고 이에 대한 피드백을 받을 수 있게 된다.
이 때문에, 다시 한번 사용자의 싸늘한 반응을 얻게 되고 위의 사이클이 계속해서 반복되는 패턴이 나타난다. 이 악순환의 고리에서 나오려면, 일하는 방법의 마인드셋에 커다란 변화가 필요하다. 먼저, 증명되지 않은 많은 기능을 처음부터 만들지 않는 것이다. 많은 기능에 대해 약속하고 프로젝트를 하는 경우, 방향을 바꾸는 것은 매우 어렵다.
최근 시장에서는 시장에 증명되지 않은 기능들의 묶음이라는 의미로 “기능 부풀림(Feature Bloat)”이라는 용어를 탄생시켰을 만큼 최초 많은 기능에 투자하는 것을 위와 같은 이유로 지양하고 있다.
[기능 부풀림이 추가된 SW의 소멸사이클]이 SW 소멸 사이클을 피하려면 어떻게 하면 될까?
확실한 시나리오 한 개를 잡아 사용자에게 먼저, 검증하면 된다. 철저하게 시장의 사용자들에게 기능의 유효성을 검증하는 형태로 작게 작게 디자인 및 개발을 수행해야 한다. 이를 풀어서 설명하면 다음과 같다.
--------------------------
1) 프로젝트가 시작되자마자, 가장 중요한 이해관계자에게 찾아가 그들의 힘든 점과 그들에게 가장 중요한 사용자가 누구인지 묻는다
2) 그 사용자를 식별하자마자 직접 사용자들을 만나 그들의 워크플로에 대해 질문하고, 그들이 일할 때 가장 중요하다고 생각하는 워크플로를 듣고 이를 분석하여 해당 시나리오에 대한 것만 아주 간단하게 디자인을 한다.
3) 가장 짧은 시간 내에 디자인된 내용을 들고 그를 다시 찾아가 사용해보라고 주면서 피드백을 듣는다. 이때 적어도 4~5명의 사용자에게 검증을 받는 것이 중요하다.
4) 이 피드백을 통해 디자인을 몇 차례 업데이트한다.
5) 어느 정도 사용성이 보장되었다는 생각이 들면 개발자에게 부탁하여 가장 빠른 시간 안에 개발하게 하고, 이것이 해당 시나리오만 돌리는데 결함 없이 사용할 만큼이 되는 순간 다시 한번 사용자에게 준 뒤 사용하게 하고 피드백을 받는다.
--------------------------
최근 린 스타트업 + 애자일 + 디자인 싱킹을 함께 쓴다는 회사들은 위와 같은 형태로 일한다. 이를 그림으로 표현하면 다음과 같다.
[린스타트업 + 애자일 + 디자인 싱킹의 개발 방식]최근 애자일은 다양한 프로세스가 조합되고 불필요한부분은 빠지면서, 더 나은 제품을 개발하는 방식으로 진화하고 있다. SW소멸 사이클을 피하고 제품 가치를 높일 수 있는 방법을 찾기 위해 '지속적인 개선'이 필요하다.
