현재 존재하지 않은 상품과 서비스를 개발하거나 경쟁사를 앞질러 시장을 공략하러 할 때 어자일(agile) 방법론이 최적으로 여겨진다.
어자일 방법론의 핵심은 신속하게 최소한의 기능을 구현한 프로토타입을 만들어 소비자들의 반응을 살피는 것이다. 대략 2주간 진행되는 스프린트(sprint) 워크샵을 통해 아이디어 도출에서 프로토타입 테스트까지 순식간에 진행한다.
그런데 어자일의 근본적 문제는 바로 그 속도에서 나올 수 있다. 개발자들은 불과 몇 주 만에 최소한의 기능을 구현한 프로토타입을 만들어야 한다. 제한된 시간에 빨리 시제품을 만들려다 보니 제품이 담아내야 하는 내용들을 모두 담지 못한다.
"속도(speed)가 전부는 아니다."
어자일 개발자들은 새로운 기능을 개발할 때 더 많은 시간을 투입하고 불확실성을 요리조리 깊이 있게 살펴보기 보다는, 현재 가지고 있는 스킬과 자원으로 신속하게 진행하려 한다. 현재 존재하는 제약 사항들을 그대로 수용하고 제품이 구현할 수 있는 잠재력을 제한해버린다. 프로토타입으로 구현해낼 수 있는 수준의 점진적인 개선으로 그치기 쉽다.
개발자가 생각하는 급진적인 아이디어들을 짧은 시간에 모두 담아내려 한다면, 최소 기능의 실행 가능한 제품(MVP: minimum viable product)이 그 짧은 시간만에 실행 가능하게 만들어질 수 없다. 자연히 고객들에게 현실감 있는 피드백도 받을 수 없다.
2주간의 스프린트 워크샵을 마친 뒤에, 개발팀은 다시 시간을 되돌려 기획에 추가로 공을 들이거나 진정 고객을 만족시키기에 필요한 기능들을 되 살펴보기 힘들다. 그들이 이미 확보한 프로토타입과 피드백을 기반으로 그만큼의 단편적인 기획적 사고를 가지고 개발을 진행한다. 어자일 방법론을 구사하면서 기획에 많은 시간적 여유를 가지는 게 쉽지 않다.
"Amazon의 느리게 걷기 방법론, Working backward"
Amazon의 거꾸로 일하는 방법은 그럴싸한 제품을 신속하게 만드는 게 아니라, 초기에 제품의 컨셉을 잡는 단계에서 훨씬 많은 시간을 할애한다.
Jeff Bezos는 자신을 Chief Slowdown Officer라고 부르곤 한다. 개발팀이 고객의 문제나 제품이 제공하는 솔루션을 명확하게 정의하지 않고 서둘러 코딩 작업을 진행하려 할 때, Bezos가 개입을 한다.
Amazon은 기획하는 제품이 구현할 최종 이미지를 제품 출시 시점의 언론 보도 형태로 서술한다. 개발팀은 몇 주 동안 끈질긴 논의를 통해 제품 개발에 앞서 가상의 언론 보도를 작성한다. 동료들과 고객, 그리고 경영층을 대상으로 얼마나 멋진 제품을 저렴하지만 회사가 수익을 창출할 수 있는 가격으로 제공할 수 있을지 자주 묻는 질문(FAQ)의 형태로 담아낸다.
경영층이 이 내용에 만족할 수 있어야 코딩을 시작하고 실제 제품을 개발할 수 있다. Kindle 이북, AWS 클라우드 서비스, 그리고 Alexa를 이용한 Echo 서비스 등이 이런 방식으로 탄생했다.
어자일 방법론 옹호자들은 Amazon의 거꾸로 일하는 방식이 개발팀의 권한과 신속함을 떨어뜨릴 것이라고 우려한다. 그러나 속도가 모든 것을 해결해주지 않는다. 특히나 전에 없던 새로운 돌파구를 기획할 때는 서두른다고 되지 않는다. 코딩 작업을 하는 것과 앞으로 나아가는 것을 헷갈려 해선 안된다. 오히려 거꾸로 일하는 방식을 통해 성공적인 제품을 더 빠르게 시장에 출시할 수도 있다.
Amazon은 아이디어 개발 단계에서는 거꾸로 일하는 방식을 활용하고, 제품을 개발하거나 런칭할 때는 어자일 방법론을 적용한다.
Source: Colin Bryar, Bill Carr (Apr 2021), "Have We Taken Agile Too Far?", HBR Blog
댓글 없음:
댓글 쓰기