4장. Lean UX 캔버스
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
가정은 새로운 요구 사항입니다
회사가 무엇을 만들고 있는지, 제품을 만드는 데 무엇이 필요한지, 제품이 완성되었을 때 어떤 모습인지, 고객이 제품을 가지고 무엇을 할 것인지에 대한 위험이 낮고 확실성이 높은( ) 비교적 예측 가능한 산업에서 일한다면 엄격하고 미리 정해진 일련의 요구 사항을 가지고 편안하게 작업할 수 있습니다. 이러한 제조업 시대의 사고방식에서는 미리 큰 틀에서 설계하는 것이 일반적이며, 제품 생산에 있어 가변성은 변화하는 시장에 대한 민첩한 대응이 아니라 오히려 계획에서 벗어나는 비용이 많이 드는 것으로 간주됩니다. 이러한 요구 사항에 대한 사고 방식은 소프트웨어 산업 초기에 채택되어 수십 년 동안 지배적인 모델로 자리 잡았으며 오늘날까지도 많은 팀의 업무 방식에 스며들어 있습니다.
요구사항은 우리가 무엇을 구축해야 하는지 정확히 알고 있다고 가정합니다. 이상적으로는 엔지니어링의 엄격함에서 비롯됩니다. 하지만 소프트웨어에서는 일반적으로 엄격함이 뒷받침되지 않습니다. 그럼에도 불구하고 작성자의 신뢰도나 조직 직책에 따라 액면 그대로 받아들여집니다. 많은 경우, 이러한 맹목적인 믿음은 "전에도 효과가 있었잖아"라는 문구를 통해 더욱 강화됩니다. 받은 요구사항의 절대성에 의문을 제기하는 개인이나 팀은 프로젝트가 기한을 놓치거나 범위를 초과하거나 둘 다에 해당할 때 문제아로 인식되어 희생양으로 취급됩니다. 여전히 팀에게 해야 할 일을 지시하는 방법으로 요구사항에 크게 의존하는 조직에서 요구사항은 제프 패튼이 즐겨 쓰는 말처럼 단순히 "닥쳐"라는 의미일 때가 많습니다.
그러나 오늘날의 소프트웨어 기반 비즈니스는 일관성, 예측 가능성, 안정성, 확실성이 없는 현실에서 운영되고 있습니다. 코드, 카피, 디자인의 특정 조합이 원하는 비즈니스 결과를 달성하고 명시된 기한까지 완벽하게 제공될 것이라고 권위를 가지고 말하는 것은 위험할 뿐만 아니라 대부분의 경우 거짓말입니다. 소프트웨어 개발은 복잡하고 예측하기 어렵습니다. 변화의 속도도 엄청나게 빠릅니다. 기업은 전례 없는 속도로 지속적으로 기능을 출시할 수 있을 뿐만 아니라 소비자 행동도 마찬가지로 빠르게 변화하고 있습니다. 기능 세트, 디자인 접근 방식 및 특정 사용자 경험을 결정하자마자 잠재 고객은 다른 온라인 서비스에 대한 경험을 바탕으로 새로운 사고 모델로 진화하기 시작합니다.
좋은 소식은 요구사항에 의존할 필요가 없다는 것입니다. 업계는 엄격한 요구 사항에서 벗어날 수 있는 새로운 작업 방식을 개발했습니다. 이 책의 초판을 썼을 때 아마존은 11.6초마다 코드를 프로덕션에 배송했습니다. 오늘날에는 출시 시간을 1초로 단축했습니다.1 즉, 매초마다 에코시스템 어딘가에서 아마존 고객이 제품 작동 방식의 변화를 경험하고 있습니다. 1분에 60번씩 아마존은 고객의 요구를 얼마나 잘 충족하고 있는지 파악할 수 있는 기회를 ...