Decision Making 방식에 따른 Waterfall, Agile 적용 전략
프로젝트 수행/ 관리방법을 선택할 때는 우리가 Business 결과를 예측할 수 있는 정도에 따라 Waterfall, Agile 방법론 선택의 전략이 필요합니다.
- Watefall 효과적
- 표준화가 중요하여 변경이 적으며, 이미 유사한 개발 경험이 있음
- 담당자(현업, PO)가 요구사항을 명확히 내고, 설계서에 따라 개발이 가능
- 지속적 개선 보다는 최종 납기일에 맞춘 품질 수준의 개발이 중요
- 시스템이 오픈되면 (개선작업은 최소화하며) 통상의 유지보수 진행
- 사전 계획된 요구사항/업무범위(계약)대로 개발이 중요
(상황에 따른 의사결정이 여의치 않은 비Self organization) - Agile 효과적
- 신규 Idea를 빠르게 개발하고, 시장의 반응에 따라 사업의 지속 여부 결정
- Web/Mobility, B2C 사업 등 고객의 반응에 따라 지속적 개선이 필요
- 시스템이 오픈되면 본격적인 개선 작업이 지속적 진행
(1차 오픈된 시스템은 MVP 수준)
- 기능을 개선할지, 다음 신규 기능을 개발하는게 더 Biz에 효과적일지 의사결정이 자유로운 조직(Self-organization)
최근에 Agile 방식이 각광을 받는 이유는 현업의 요구사항 대로 개발 보다는 시장 요구에 빠르게 대응이 biz를 성공하는 시대가 되었습니다. 또한, 수많은 스타트업과 핀테크 업체들이 전통적인 관리중심의 거대 회사 보다 고객 중심의 Agility로 빠르게 경쟁 우위에서 서비스 개발에 성공하고 있습니다.
1. 개인종목 vs. 계주종목 vs. 단체종목
개인종목은 상대적으로 결과 예측하기가 수월하지만, 단체종목으로 갈 수록 사람과 사람간의 관계와 경쟁자와의 관계가 있어서 결과 예측이 어렵습니다. 우리 프로젝트의 상황은 개인종목 보다는 정교한 협업과 상황에 따라 전략을 수시로 수정하며 대응해야하는 단체 종목에 가깝습니다. 따라서 프로젝트와 같은 단체종목의 경우에는 Agility 있게 상황에 따른 의사결정과 실행이 중요합니다.
- 개인 종목 : 개인의 이전 기록에 따라 승부 결과를 예측하기 쉽다.
- 계주 종목 : Hand-off가 있기 때문에 개인과 개인간의 연계 실수가 발생 될 수 있으므로 개인의 기록만 가지고 승부 결과를 예측하기는 어렵다.
- 단체 종목 : 개인과 개인간의 연계가 수시로 일어나며, 특히 경쟁자의 전략과 반응에 대응해야 하므로 승부 결과를 예측하기 최고로 어렵다.
2. Simple vs. Complicated vs. Complex vs. Chaos
이번에는 Decision making에 사용되는 Stacey Complexity Matrix와 Cynefin Framework에 대해서 소개합니다. Simple vs. Complicated vs. Complex vs. Chaos 차이에 따른 적절한 Decision Making방식을 선택해야 합니다.
- Simple
- 요구사항과 기술을 잘 알아서 쉽게 예측/대응이 가능
- Best Practice 활용 가능한 도메인 - Complicated
- 단순하지는 않지만 전문가의 분석을 통해 예측/대응 가능
- 전문가 활용 가능한 도메인 - Complex
- 완전히 알 수는 없지만 합리적인 탐색으로 예측/대응 가능
- 새로 출현한 도메인 - Chaos
- 미리 알거나 예측 할 수 없어 상황에 따라 예측/대응 필요
- 신속한 대응이 필요한 도메인
개발 경험이 있고 도메인이나 기술이 익숙하다면 Waterfall도 좋은 선택입니다. 하지만 최근의 Digital Biz. 프로젝트들은 고객의 요구사항에 따라 1차 개발하고 오픈 후 현장의 상황과 실사용자의 Needs에 따라 계속 AI/ML/Big data 등을 튜닝하고 대응하며 고도화해야 하는 시스템/솔루션이 점차 늘고 있습니다.
지구 옆을 지나간 혜성이 몇년만에 지구에 다시 올지는 전문가의 계산을 통해 정확하게 예측 가능합니다. 하지만, 프로젝트는 시장과 고객의 반응으로 어떻게 될지는 상대적으로 프로젝트 중에 사전 예측하기가 힘듭니다.
3. Common Ideas vs. New Ideas
현업이나 도메인 전문가의 오랜 경험, 표준화로 예측 가능한 System of Record 영역도 있지만, 경쟁사 대비 더 좋고 새로운 Idea를 지속적으로 개선하는 System of Innovation 영역도 있습니다.
아래 그림의 Mode1은 전통적인 Waterfall 개발 방식이 효과적이며, Mode2는 가설을 수립하고 검증하며 개선하는 Agile 개발방식이 효과적입니다. 따라서 System of Innovation 업무 개발을 위해 점차 Agile, DevOps 문화로 변해가고 있습니다. 최근에는 전통적인 System of Record 영역의 비즈니스도 System of Innovation으로 생각하며 비즈니스를 성공시키는 스타트업, 핀테크 기업들이 생기고 있습니다.
여러분들이 개발하려는 시스템이 표준 프로세스/데이터 반영 등 사전 예측이 가능한 System of Record 영역이면 Requirement를 명확히 하고 설계Spec대로 개발했는지 확인하는 Waterfall 모델이 효과적 일 수 있지만, 변화하는 시대의 흐름과 고객에 따라 빠르게 대응하며 지속적으로 개선 Release 해야 하는 System of Innovation은 Agile 모델이 효과적입니다.
체계적인 요구사항 분석과 설계를 통한 신뢰성 높은 시스템 개발은 Mode1에 적합하고, 고객/시장의 반응이 중시되며 지속적으로 실험과 개선을 반복하는 시스템은 Mode2로 정의 할 수 있습니다. Gatner에서는 Mode1과 Mode2를 다음과 같이 정리하였습니다.
결론
Waterfall, Agile 방법론은 상황에 따라서 선택이 필요합니다. 이미 유사한 업무를 개발해보았고, 담당자(현업, Product Owner)가 요구사항을 명확히 낼수 있다면 Waterfall이 더 효과적일 수도 있습니다. 하지만 Web/ Mobility 시대 흐름, B2C 사업, 경쟁사 대비 발빠르게 대응해야 하며 New Idea의 적용은 Agile이 좀 더 효과적입니다. 즉, 현업(전문가)의 요구사항대로 개발 보다는 시장의 요구에 빠르게 대응하는 시대가 되었습니다.
방법론 선정 방법은, System of Record 같이 미리 예측 가능하며 시스템 오픈 후 변경사항이 별로 없는 프로젝트는 Waterfall이 더 효율적 일 수 있고, System of Innovation 영역처럼 시스템 오픈 후 시장 대응(본격적인 시스템 개선 작업)을 해야하는 Business는 Agile을 넘어 지속적 개선/배포를 위한 DevOps로 기업문화를 바꾸고 있습니다. 또한 수많은 스타트업과 핀테크 업체들은 기존의 System of Record도 System of Innovation처럼 생각하며 경쟁 우위에서 개발하며 성공을 하고 있습니다.
Reference
- https://hbr.org/2007/11/a-leaders-framework-for-decision-making
- http://noop.nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html
- http://technologysalon.org/developing-an-organizational-ict4d-strategy/
- https://www.gartner.com/document/3414217?ref=TypeAheadSearch&qid=1e7280c7280a2c28fac90
- https://www.gartner.com/document/3414217?ref=TypeAheadSearch&qid=d4ffccae9719fff9c000
