비 기술적 인 고객에게 응용 프로그램 사양을 단순화해야한다고 설득하는 방법은 무엇입니까?

종종 새로운 클라이언트가 말 그대로 100 개의 불필요한 기능을 가진 응용 프로그램을 사용하는 상황에 직면하고 있으며 프로젝트가 성공할 수 있도록 상황을 크게 단순화해야한다는 것이 분명합니다. 고객이 더 MVP (Minimum Viable Product) 접근 방식을 취하고 단순화하도록 어떻게 확신하십니까?

편집하다:

따라서 현재 최고 답변은 고객에게 거대한 응용 프로그램에 대한 시간 / 비용 견적을 제공하는 것입니다. 이 상황에서 실제 문제를 다루지 않기 때문에이 대답을 좋아하지 않습니다. 그리고 그것은-거대한 응용 프로그램을 지정하고 시작부터 그것을 시도하고 구축하는 것은 나쁜 습관입니다. 처음에는 작고 단순한 MVP 기반을 구축하는 것이 훨씬 더 편안하다고 생각합니다. 그런 다음 그 기초에 작은 기능을 하나씩 추가합니다. 어떻게 클라이언트가 이런 식으로 소프트웨어를 구축하도록 설득해야합니까?

수백 개의 기능을 고품질로 수행하는 데 소요되는 비용 / 시간을 추정합니다. 매우 적은 수의 고객이 입가에 돈을 넣을 것입니다.

두 단어 : 사용자 사례.

나는 고객이 Get A Clue®를 도울 수있는 가장 빠른 방법은 그들이 원하는 모든 기능이나 페이지에 대한 사용자 스토리를 통해 나 에게 이야기하게 하는 것임을 배웠습니다 . 다음과 같은 몇 가지 일이 발생합니다.

1. 그들은 페이지 / 피처가 실제로 무엇을해야하는지 생각 해야합니다.
2. 점점 더 자세한 내용을 요청하면 ( "그리고 그때? ... 그리고 ?? ...") Magic Space Monkeys ™가 날아가서 모든 것이 존재하지 않을 것이라는 것을 이해하기 시작합니다. 주말에
3. 그들은 창조 과정에서 진정한 파트너가됩니다. 이는 이미 80 % 완료된 것에 대해 마음이 바뀌면 a) 일정이 지연되고 b) 비용이 증가 하는 이유 를 이해한다는 의미입니다 .

진심으로. 소유자의 사용자 스토리 는 프로세스에 최소한의 정신을 가져다주는 데 가장 적합한 도구 중 하나입니다.

비용 및 생산 시간 측면을 논의하는 동안 필수 기능의 최소 기능 세트가 필수가되도록 요구 사항의 순위 ( "필수 사항", "해야 함"및 "좋은 항목")를 요청하십시오. 버전 1에서 "필수 사항"을 유지 한 후 나머지 요구 사항을 첫 번째 버전 이후의 스프린트로 달성 할 수있는 백 로그 세트에 넣습니다. 비 필수적인 "좋아하기"가 좋은 제품은 팩 뒷면으로 이동하고 스프린트에 도달 할 때까지 (제품에 대한 실제 경험을 통해) 더 중요한 새로운 제품이 맨 위에 떠오를 것입니다.

고객은 비즈니스 비용과 제품을 신속하게 얻는 것의 중요성을 고려하고 있으며 백 로그에 넣음으로써 "가지고있는 것"을 직접 무시하지 않는다는 점을 이해해야합니다.

OP 편집에 응답하도록 편집 : 고객에게 최소 실행 가능한 제품을 조기에 출시하는 것이 좋은 이유를 설득하려면 실제 사용자가 제품을 사용할 때까지 (특히 사용성 측면에서) 제품의 성공 여부를 알기가 어렵다고 설명하십시오. 고객이 초기 제품을 전체 사용자 기반에 배치하는 것을 주저하는 경우, 대상 고객 중 일부에게만 제공되는 "제한적 베타"를 수행하는 것이 좋습니다. 이 접근 방식의 단점은 제품을 사용할 수 없다는 늦은 결정과 함께 길고 비용이 많이 드는 개발주기라는 것을 알려주십시오. 37 Signals는 이것에 관해 몇 가지 좋은 참고 자료를 만들었습니다 : 실제 와 재 작업하기 . Getting Real은 웹에서 무료로 제공됩니다.

상황에 대한 불만의 주요 원인은 고객이 사용하는 인식 및 오해의 소지가 있거나 잘못된 용어 일 수 있습니다. 고객은 보통의 목록을 당신에게 오지 않는 요구 하지만, 그 생각할 수있는 모든 단일 가지의 소원 목록은 수도 그들에게 유용합니다. 고객이 각 기능이 실제로 필요한지 여부를 실제로 생각하기 위해 아직 시간을 소비하지 않았기 때문에 이러한 요구 사항 이 모두 필요한 것은 아닙니다 .

항상 문제가되는 것은 아닙니다

고객이 모든 기능에 대한 돈을 가지고 있고 그 기능에 기꺼이 참여 하고 고객이 실제로 가지고있는 실제 문제를 해결하는 데 신경 쓰지 않는다면 매우 수익성이 높은 프로젝트가 될 수 있습니다. 매우 드물게 발생하며 대부분의 개발자에게는 프로젝트가 결국 고객에게는 성공하지 못할 것이라고 미리 느낄 수 있기 때문에 영혼을 죽이는 작업입니다 (개발자로서 재정적으로 성공하더라도). 또한 불확실성이 많은 고정 비용 프로젝트로 끝날 가능성이 높기 때문에 위험이 높으며, 대규모 프로젝트에서 위험을 잘못 판단하는 것은 실제로 문제가됩니다.

그것이 문제라면?

당신이 그 드문 상황에 있지 않다고 가정 해 봅시다. 이 경우 위시리스트의 두 가지 주요 단점을 다음과 같이 해결하려고합니다.

1. 고객이 이러한 많은 요구 사항을 개발하는 데 드는 비용에 대한 올바른 아이디어를 가지고 있지 않을 가능성이 높으므로 실제로 필요한 금액에 대한 계약을 체결 할 가능성이 없습니다.
2. 이 희망 목록이 고객이 가지고 있고 해결하고자하는 실제 문제를 정확하고 간결하게 설명하는 것은 아닙니다.

내 경험상 1을 해결하려면 2를 해결해야합니다. 실제 문제 로 드릴 다운 하면 개발자는 이제 고객 스스로도 생각조차하지 못한 방식으로 문제를 해결하는 데 창의력을 발휘하는 데 필요한 정보를 얻을 수 있습니다. 이러한 솔루션은 전체 위시리스트를 구현하는 것보다 훨씬 저렴하고 빠릅니다.

어떻게 고치나요?
Matthew Flynn이 그의 답변에서 밝힌 것처럼 고객이 요구 사항의 우선 순위를 정하도록 시작하십시오. 항상 쉬운 것은 아니지만 강제로 수행하도록하십시오. 필요한 경우 "누군가 머리에 총을 든 경우 어떤 단일 요구 사항을 유지 하시겠습니까?"라는 문구를 사용하십시오. 이 과정에서 고객이 실제로 개별 요구 사항의 의미에 대한 명확한 아이디어가 없다는 것을 알게 될 것입니다. 이 경우 Peter Rowell이 제안한 내용을 수행하고 고객이 User Stories를 통해 작업하도록하십시오. 고객과 고객은 문제와 요구 사항을 훨씬 더 잘 이해하기 시작하여 우선 순위로 돌아갈 수 있습니다. 고객의 문제를 해결할만큼 충분히 알기 쉬울 때까지 필요한만큼이 단계를 반복하십시오 .

이것이 솔루션 개발 문제에 어떻게 대답합니까? 우선 순위가 지정된 요구 사항 목록이 있으면 고객에게 증분 개발 프로세스를 제안해야하는 입력 사항이 있습니다. 이를 애자일이라고 할 필요는 없지만 계약을 각 요구 사항 (또는 불가분의 요구 사항)에 대해 더 작은 조각으로 나누고 고객의 검증을 통해 하나씩 제공하도록 제안 할 수 있습니다. 또는 온라인 및 오프라인에서 사용할 수있는 많은 리소스를 모두 사용하여 애자일 개발 스타일 중 하나에 협력하는 것이 고객에게 최선의 이익임을 확신시킬 수 있습니다. 어쨌든 이러한 요구 사항의 빌딩 블록을 우선 순위에 따라 명확하게 제안하는 양식으로 계약 / 프로젝트 제안을 제공 할 수 있습니다. 고객 앞에서 그 당근을 잡고

먼저 요구 사항이 현실적이지 않다는 것을 설명하고 설명하고 일련의 카운터 요구 사항을 제시합니다. 이렇게하면 문제를보다 간단하고 신속하게 해결할 수 있으므로 비용과 위험이 줄어 듭니다. 이것을 기술적 토론으로 만들려고하지 마십시오. 고객은 그것에 대해 신경 쓰지 않습니다. 고객은 좋은 제품을 제 시간에 확보하고 비즈니스 사례를 해결하는 것에 관심을 갖습니다. 고객이 돈을 버지 않으면 계약을 수락하고 작업을 수행하거나 고객에게이 양식으로 프로젝트에 대한 책임을 질 수없는 이유를 거부하고 설명하십시오.

다른 사람들이 제안한 것과 비슷하지만 약간 다릅니다. 고객이 모든 것을 유효하게 할 수 있지만 우선 순위를 정해야한다고 제안합니다. 먼저 수행해야 할 항목 두 번째로 수행해야 할 항목 가장 중요한 것은 시간이 부족한 경우 어떤 항목이 가장 아프지 않을 것입니다. 각 항목의 우선 순위를 1에서 732까지 (또는 무엇이든) 순서대로 완료하십시오.

과도한 요구 사항으로 인해 예산이 초과되고 일정이 뒤처진 애플리케이션의 역사적 예는 FBI의 가상 사례 파일입니다. 수십 개의 기존 애플리케이션을 대체하기위한 것이 었으며 모두 전환시 한 번에 완전히 작동해야했습니다. 프로젝트는 결국 취소되었습니다. 성공적인 것은 프레임 워크를 설계하고 개별 응용 프로그램을 새로운 시스템으로 점진적으로 대체하는 것이 었습니다. 대신, 정치와 투쟁으로 인해 모든 애플리케이션 이해 관계자는 자신의 앱이 가장 중요한 앱이라고 주장하며 모든 사람들이 기존 앱에 추가하려는 모든 기능에서 "필수 사항"으로 사양을 금메달했습니다. 결국 매일 작성된 변경 요청의 양이 실제로 매일 작성된 코드의 양을 초과했습니다.

나는 "모든 것을 가져야한다"는 2 가지 경우에서 일하는 것을 보았다. 하나의 대규모 금융 고객 (모든 것을 포함한 폭포)은 40 개의 서로 다른 시스템 (우리 회사가 40 개 중 하나를 만들었습니다)을 교체하고 한 번에 실패하게 운영했습니다. 통합 테스트 및 커뮤니케이션은 큰 문제였습니다. 내 추정치는 전화 회의에서 하루에 약 $ 10 만 불에 전화 한 것으로 추정됩니다 (통화에 대한 모든 사람의 청구 비율을 세는 경우). 두 경우 모두, 강력한 협상가가 전달 될 내용의 목록을 망치고 모든 사람의 발을 땅에 박았습니다. 골 포스트의 이동, 재협상은 없었습니다. 두 작업 모두 정시에 완료되었습니다. 하나는 예산을 넘어 섰고, 다른 하나는 예산에있었습니다. 이를 위해서는 팀이 무엇을 제공 할 수 있는지 잘 아는 매우 훌륭한 프로젝트 관리자가 필요합니다 (Q가 3이라는 기능을 말할 수있는 사람).

훌륭한 PM, 협상가 및 측정 항목이 없기 때문에 고객에게 점진적인 배송을 유도하는 것이 좋습니다. 그래도 한 번에 전체 금 벽돌을 원한다면 다른 상담을 찾도록 도와 더 나은 서비스를 제공 할 수 있습니다. 때로는 가장 좋은 대답은 "우리는 당신을 도울 수 없습니다"입니다.

짧은 답변: 고객의 의견을 경청하고 그들과 함께 중도적인 접근 방식을 찾을 것입니다.

고객의 의견을 듣고 예산과시기에 따라 프로젝트를 단계 (릴리스, 릴리스 2 등)로 분할하는 것이 좋습니다.

그런 다음 애플리케이션이 제공해야하는 필수 기능의 제공, 예산 및 우선 순위의 각 단계를 계속 추정 할 수 있습니다.

따라서 작업 범위와 결과물을 정의하는 것이 좋습니다. :)

다른 답변에서 알 수 있듯이 우선 순위는 매우 중요합니다. 이를 수행하는 편리한 방법은 MoSCoW- 방법을 사용하는 것 입니다. 그러나 전체 목록을 나누는 것으로 시작할 수도 있습니다. 그렇지 않으면 기능 목록 자체가 당신 (또는 고객)에게 이해력을 줄 것입니다 :)

이 옆에는 문제를 전체적으로 보는 문제가 있습니다. 고객과 함께 앉아 다음 단계를 수행하여이 문제를 해결할 수 있습니다.

• 기능을 통해 전 세계로 이동하여 범주를 추출하십시오.
• 범주를 우선 순위 화 (MoSCoW 사용)하고 계층 구조 (기본 기능이있는 하나의 기본 범주, 주요 주제의 범주, 주요 주제의 특정 변형에 대한 범주)를 정의 할 수 있습니다. 이전 단계에서 정의한 카테고리가 변경 될 수 있습니다 (새로운 통찰력 덕분에).
• 각 기능을 하나씩 살펴보고 카테고리에 할당
• 상위 x 카테고리의 항목을 우선 순위 화 (MoSCoW 사용)합니다.

이렇게하면 요청 된 피처를 멋지게 요약 한 하향식보기가 제공되며,베이스로 시작하고 다른 피처로 확장하기 위해 다른 반복을 정의 할 수있는 핸들 바가 제공됩니다.