"필요성은 발명의 어머니입니다." 이 말은 인간의 정신과 발명에 대한 우리의 자연스러운 드라이브의 지울 수없는 캡처합니다. 옥스포드 영어 사전에 설명 된 바와 같이, "뭔가에 대한 필요성이 필수적이 될 때, 당신은 그것을 얻거나 달성 할 수있는 방법을 찾아야합니다." 발명에 대한 이러한 보편적 진리를 부인하는 사람은 거의 없습니다. 그러나 디지털 경제의 혁신 문서에서 설명하듯이 클라우드 혁신에는 발명과 채택 간의 균형이 필요합니다.
우리가 비유를 계속한다면, 혁신은 더 확장 된 가족에서 온다. 고객 공감은 혁신의 자랑스러운 부모입니다. 혁신을 이끄는 고객 공감 솔루션을 만들려면 중요한 문제를 해결하기 위해 다시 돌아오도록 하는 합법적인 고객의 요구가 필요합니다. 이러한 솔루션은 고객이 원하거나 변덕하기보다는 필요한 것을 기반으로 합니다. 고객의 진정한 요구를 찾으려면 공감과 고객 경험에 대한 깊은 이해로 시작합니다. 공감은 많은 엔지니어, 제품 관리자, 심지어 비즈니스 리더에게 저개발 기술입니다. 다행히 클라우드 설계자 역할의 다양한 상호 작용과 빠른 속도는 이 기술을 촉진합니다.
어떻게 공감을 형성하고 고객 공감이 왜 그렇게 중요한가? 고객 공감은 고객의 경험을 이해하고 공유하는 데 도움이 됩니다. MVP(최소 실행 가능한 제품)의 첫 번째 릴리스부터 시장 등급 솔루션의 일반 공급에 이르기까지 고객 공감은 더 나은 솔루션을 구축하는 데 도움이 됩니다. 더 중요한 것은 공감은 팀이 채택을 장려하는 솔루션을 발명할 수 있는 위치를 더 잘 지정한다는 것입니다. 디지털 경제에서 고객의 요구에 가장 쉽게 공감할 수 있는 제품 팀은 시장을 재정의하고 이끄는 더 나은 도구로 더 밝은 미래를 구축할 수 있습니다.
고객 공감으로 빌드할 가정 정의
가정을 정의하는 것은 계획의 기본 부분입니다. 더 많은 계획을 세울수록 가정이 훌륭한 아이디어의 기초로 들어오는 것을 더 명확하게 볼 수 있습니다. 가정은 일반적으로 자기 공감의 산물입니다. 즉, 내가 이 위치에 있다면 무엇을 원할까요? 빌드 단계로 시작하면 가정이 솔루션을 침해할 수 있는 기간을 최소화합니다. 또한 이 접근 방식은 실제 고객과의 피드백 루프를 가속화하여 더 일찍 배우고 공감할 수 있는 기회를 촉진합니다.
주의
빌드할 내용을 올바르게 정의하는 것은 까다로울 수 있으며 몇 가지 연습이 필요합니다. 너무 빨리 빌드하는 경우 고객의 요구 사항이 반영되지 않을 수 있습니다. 초기 고객의 요구 사항과 솔루션 요구 사항을 이해하는 데 너무 많은 시간을 할애하는 경우, 시장은 모든 것을 구축할 기회를 갖기 전에 이를 충족할 수 있습니다. 두 시나리오 모두 학습 기회가 크게 지연되거나 감소될 수 있습니다. 경우에 따라 데이터가 손상될 수도 있습니다.
역사상 가장 혁신적인 솔루션은 직관적인 믿음으로 시작되었습니다. 그 직감은 기존의 전문 지식과 직접 관찰 모두에서 온다. 직관의 빠른 테스트를 허용하기 때문에 빌드 단계로 시작합니다. 거기에서, 당신은 깊은 이해와 공감의 명확한 정도를 육성 할 수 있습니다. 솔루션의 모든 반복 또는 릴리스에서 균형은 고객 공감을 보여주는 MVP 빌드에서 비롯됩니다.
이 분산 작업을 안정하기 위해 다음 두 섹션에서는 공감으로 빌드하고 MVP를 정의하는 방법에 대한 개념을 설명합니다.
고객 중심 가설 정의
공감으로 빌드할 때 특정 고객의 필요를 보여 주는 정의된 가설을 기반으로 솔루션을 만드는 것을 의미합니다. 다음 단계에서는 공감으로 빌드를 장려하는 가설을 작성합니다.
- 공감으로 빌드할 때 고객은 항상 중점을 집니다. 이 의도는 여러 도형을 사용할 수 있습니다. 해결하려는 문제 중에 고객 아키타입, 특정 가상 사용자 또는 고객의 사진을 참조할 수 있습니다. 또한 고객은 내부(직원 또는 파트너) 또는 외부(소비자 또는 비즈니스 고객)일 수 있습니다. 이 정의는 테스트할 첫 번째 가설입니다. 이 특정 고객을 도울 수 있나요?
- 고객 환경을 이해합니다. 공감을 통해 구축한다는 것은 고객의 경험과 관련이 있고 고객의 과제를 이해할 수 있는 것을 의미합니다. 이 사고방식은 테스트할 다음 가설을 나타냅니다. 이 특정 고객에게 이 관리 가능한 과제를 도와줄 수 있나요?
- 단일 챌린지에 대한 명확한 솔루션을 정의합니다. 사람, 프로세스 및 실무 전문가의 전문 지식에 의존하는 경우 잠재적인 솔루션으로 이어질 수 있습니다. 테스트할 전체 가설은 다음과 같습니다. 제안된 솔루션을 통해 이 특정 고객이 관리하기 쉬운 과제에 도움을 줄 수 있나요?
- 값 문에 도착합니다. 이러한 고객에게 어떤 장기적인 가치를 제공하시겠습니까? 이 질문에 대한 답변은 전체 가설을 만듭니다. 제안된 솔루션을 사용하여 관리 가능한 이 문제를 해결함으로써 이러한 고객의 삶을 어떻게 개선할 수 있을까요?
이 마지막 단계는 고객 공감 중심 가설의 절정입니다. 대상 그룹, 문제, 솔루션 및 개선이 이루어지는 메트릭을 정의하며, 모두 고객을 중심으로 합니다. 측정 및 학습 단계 중에 각 가설을 테스트해야 합니다. 팀이 주소 지정 가능한 고객 기반에 대해 더 큰 공감을 개발할 때 고객, 문제 설명 또는 솔루션의 변화를 예상합니다.
주의
목표는 고객의 공감으로 구축하는 것이지 계획 하지 않는 것입니다. 완벽한 고객 공감 성명서에 부딪히기 위해 계획과 조정의 끝없는 주기에 갇히는 것은 너무 쉽습니다. 이러한 문을 개발하기 전에 MVP 정의 및 빌드에 대한 다음 섹션을 검토합니다.
핵심 가정을 증명한 후 나중에 반복은 공감 테스트 외에도 성장 테스트에 초점을 맞춥니다. 공감을 구축하고 테스트하고 유효성을 검사한 후에는 주소 지정 가능한 시장을 대규모로 이해하기 시작합니다. 앞에서 설명한 표준 가설 수식을 확장하여 주소 지정 가능한 시장을 더 깊이 이해할 수 있습니다. 그런 다음 사용 가능한 데이터에 따라 총 시장 크기(잠재 고객 수)를 예측합니다.
여기에서 비슷한 문제가 발생하므로 솔루션에 관심이 있을 수 있는 총 시장의 비율을 예측합니다. 그런 다음 주소 지정 가능한 시장이 있습니다. 테스트할 다음 가설은 다음과 같습니다. 제안된 솔루션을 사용하여 이 관리 가능한 문제를 해결함으로써 고객의 삶의 x% 어떻게 개선할 수 있을까요? 고객의 작은 샘플링은 참여 고객의 풀에 백분율 효과를 제안 선행 지표를 보여줍니다.
가설을 테스트하는 솔루션 정의
빌드-측정-학습 피드백 루프를 반복할 때마다 공감으로 빌드하려는 시도가 MVP에 의해 정의됩니다.
MVP는 고객과 함께 학습할 수 있는 충분한 솔루션을 만드는 데 필요한 가장 작은 노력 단위(발명, 엔지니어링, 애플리케이션 개발 또는 데이터 아키텍처)입니다. 모든 MVP의 목표는 이전 가설의 일부 또는 전부를 테스트하고 고객으로부터 직접 피드백을 받는 것입니다. 출력은 업계를 변경하는 데 필요한 모든 기능을 갖춘 아름다운 애플리케이션이 아닙니다. 각 반복의 원하는 출력은 학습 기회이며 가설을 더 깊이 테스트할 수 있는 기회입니다.
Timeboxing 은 제품이 마른 상태를 유지하도록 하는 표준 방법입니다. 예를 들어 개발 팀에서 빠른 테스트를 위해 솔루션을 단일 반복으로 만들 수 있다고 생각하는지 확인합니다. 속도, 반복 및 릴리스를 사용하여 최소한의 의미를 정의하는 방법을 더 잘 이해하려면 계획 속도, 반복, 릴리스 및 반복 경로를 참조하세요.
복잡성 감소 및 기술 급증 지연
혁신 방법론에 설명된 발명 분야는 성숙한 혁신 또는 규모가 준비된 MVP 솔루션을 제공하는 데 필요한 기능을 살펴봅니다. 이러한 분야를 기능 포함에 대한 장기 가이드로 사용합니다. 마찬가지로, 솔루션에서 고객 가치와 공감을 조기에 테스트하는 동안 경고 가이드로 사용합니다.
기능 폭과 발명의 다양한 분야는 모두 단일 반복으로 만들 수 없습니다. 여러 분야의 복잡성을 포함하려면 MVP 솔루션에 대한 몇 가지 릴리스가 걸릴 수 있습니다. 개발에 대한 투자에 따라 여러 분야 내에서 여러 병렬 팀이 작업하여 여러 가설을 테스트할 수 있습니다. 이러한 팀 간의 아키텍처 맞춤을 유지하는 것은 현명하지만 값 가설의 유효성을 검사할 수 있기 전까지는 복잡하고 통합된 솔루션을 빌드하는 것은 현명하지 않습니다.
기술적 급증 빈도 또는 볼륨에서 복잡성을 가장 잘 감지합니다. 기술 급증은 고객과 쉽게 테스트할 수 없는 기술 솔루션을 만들기 위한 노력입니다. 고객 가치와 고객 공감이 테스트되지 않은 경우 기술 급증은 혁신에 대한 위험을 나타내며 최소화해야 합니다. 마이그레이션 노력에서 찾은 완성도 높은 테스트된 솔루션의 유형에 대해 채택 전반에 걸쳐 기술 급증이 일반적일 수 있습니다. 그러나 혁신 노력의 가설 테스트를 지연시키고 가능하면 언제든지 연기해야 합니다.
끊임없는 단순화 접근 방식은 MVP 정의에 도움이 됩니다. 이 방법은 가설의 유효성을 검사하는 데 도움이 되지 않는 모든 항목을 제거한다는 것을 의미합니다. 복잡성을 최소화하려면 가설을 테스트하는 데 필요하지 않은 통합 및 기능 수를 줄입니다.
MVP 만들기
각 반복에서 MVP 솔루션은 다양한 모양을 사용할 수 있습니다. 일반적인 요구 사항은 출력에서 가설을 측정하고 테스트할 수 있다는 것입니다. 이 간단한 요구 사항은 과학적 프로세스에 착수하며 팀이 공감으로 구축할 수 있도록 합니다. 이 고객 우선 포커스를 제공하기 위해 초기 MVP는 발명 분야 중 하나에만 의존할 수 있습니다.
경우에 따라 가장 빠른 혁신 경로는 클라우드 채택 팀이 가설의 유효성을 정확하게 검사할 때까지 이러한 분야를 일시적으로 완전히 피하는 것을 의미합니다. Microsoft와 같은 기술 회사에서 이 지침은 직관적이지 않을 수 있습니다. 그러나 특정 기술 결정이 아닌 고객의 요구가 MVP 솔루션에서 가장 높은 우선 순위임을 강조합니다.
일반적으로 MVP 솔루션은 최소한의 기능과 제한된 광택을 가진 애플리케이션 또는 데이터 솔루션으로 구성됩니다. 전문 개발 전문 지식이 있는 조직의 경우 이 경로는 학습 및 반복에 가장 빠른 경로인 경우가 많습니다. 다음 목록에는 팀이 MVP를 빌드하는 데 사용할 수 있는 몇 가지 다른 방법이 포함되어 있습니다.
- 시간의 99%가 잘못되었지만 원하는 특정 결과를 보여 주는 예측 알고리즘입니다.
- 프로덕션 규모에서 안전하게 통신하지 않지만 프로세스 내에서 거의 실시간 데이터의 가치를 보여 주는 IoT 디바이스입니다.
- 가설을 테스트하거나 더 작은 규모의 요구를 충족하기 위해 시민 개발자가 빌드한 애플리케이션입니다.
- 따라야 할 애플리케이션의 이점을 다시 만드는 수동 프로세스입니다.
- 고객이 상호 작용할 수 있을 만큼 자세히 설명된 와이어프레임 또는 비디오입니다.
MVP를 개발해도 엄청난 양의 개발 투자가 필요하지 않습니다. 한 번에 테스트되는 가설의 수를 최소화하기 위해 가능한 한 투자를 제한하는 것이 좋습니다. 각 반복과 각 릴리스에서 여러 분야의 발명을 대표하는 확장 가능한 솔루션을 향해 의도적으로 솔루션을 개선합니다.
MVP 개발 가속화
출시 시간은 혁신의 성공에 매우 중요합니다. 릴리스 속도가 빨라질수록 학습 속도가 빨라집니다. 더 빠른 학습은 더 빠르게 확장할 수 있는 제품으로 이어집니다. 때로는 기존의 애플리케이션 개발 주기로 인해 이 프로세스가 느려질 수 있습니다. 더 자주, 혁신은 사용 가능한 전문 지식에 대한 제한에 의해 제한됩니다. 예산, 인원수 및 직원 가용성은 팀이 처리할 수 있는 새로운 혁신 수에 대한 제한을 만들 수 있습니다.
인력 제약 조건과 공감으로 구축하려는 욕구는 시민 개발자를 향한 급속한 성장 추세를 낳았습니다. 이러한 개발자는 위험을 줄이고 조직의 전문 개발 커뮤니티 내에서 규모를 제공합니다. 시민 개발자는 고객 경험에서 실무 전문가이지만 엔지니어로 교육을 받지는 않습니다. 이러한 개인은 프로토타이핑 도구 또는 전문 개발자가 눈살을 찌푸리게 할 수 있는 가벼운 개발 도구를 사용합니다. 이러한 비즈니스 정렬 개발자는 MVP 솔루션을 만들고 이론을 테스트합니다. 잘 정렬되면 이 프로세스는 값을 제공하지만 충분히 효과적인 규모 가설을 통과하지 못하는 프로덕션 솔루션을 만듭니다. 또한 Teams는 스케일링 작업이 시작되기 전에 솔루션을 사용하여 프로토타입의 유효성을 검사할 수 있습니다.
혁신 계획 내에서 클라우드 채택 팀은 시민 개발자 노력을 포함하도록 포트폴리오를 다양화해야 합니다. 개발 노력을 확장하여 투자 감소 시 더 많은 가설을 형성하고 테스트할 수 있습니다. 가설의 유효성을 검사하고 주소 지정 가능한 시장을 식별하는 경우 전문 개발자는 최신 개발 도구를 사용하여 솔루션을 강화하고 확장할 수 있습니다.
최종 빌드 게이트: 고객의 고통
고객 공감이 강할 때는 기존 문제를 쉽게 식별할 수 있어야 합니다. 고객의 고통은 분명해야 합니다. 빌드하는 동안 클라우드 채택 팀은 고객의 고민점을 기반으로 가설을 테스트하는 솔루션을 개발합니다. 가설이 잘 정의되어 있지만 고통점이 아닌 경우 솔루션은 고객의 공감을 기반으로 하는 것이 아닙니다. 이 시나리오에서는 빌드가 올바른 시작점이 아닙니다. 대신, 공감을 구축하고 실제 고객의 학습에 먼저 투자하십시오. 공감을 구축하고 고통을 검증하는 가장 좋은 방법은 간단합니다. 고객의 의견을 경청하세요. 자주 발생하는 고통을 식별할 수 있게 될 때까지 모임을 하고 관찰하는 데 시간을 투자합니다. 고객의 고통 지점을 잘 이해한 후에는 이러한 고통을 해결하기 위한 가설 솔루션을 테스트할 준비가 된 것입니다.
이 방법을 적용하지 않을 경우
대체 접근 방식을 필요로 할 수 있는 많은 법률, 규정 준수 및 업계 요구 사항이 있습니다. 개발 솔루션의 공개 릴리스인 경우 이 방법이 적합하지 않을 수 있습니다.
- 특허 타이밍, 지적 재산권 보호 또는 고객 데이터 유출에 대한 위험 만들기
- 설정된 규정 준수 요구 사항 위반
이러한 위험이 감지되면 릴리스 관리에 대한 안내된 접근 방식을 채택하기 전에 법률 고문에게 문의하세요.
참고문헌
이 문서의 개념 중 일부는 Eric Ries가 The Lean Startup 설명한 아이디어를 기반으로 합니다.
다음 단계
MVP 솔루션을 빌드한 후에는 공감 값과 배율 값을 측정할 수 있습니다. 고객에게 미치는 영향을 측정하는 방법을 알아봅니다.