Làm thế nào để thuyết phục một khách hàng phi kỹ thuật rằng thông số ứng dụng của họ cần được đơn giản hóa?

Thường thì tôi phải đối mặt với tình huống một khách hàng mới đến với tôi với một ứng dụng có đúng 100 tính năng không cần thiết và rõ ràng là mọi thứ cần được đơn giản hóa mạnh mẽ để dự án có bất kỳ cơ hội thành công nào. Làm thế nào để bạn thuyết phục khách hàng thực hiện một cách tiếp cận Sản phẩm khả thi tối thiểu (MVP) hơn và đơn giản hóa?

biên tập:

Vì vậy, câu trả lời hàng đầu hiện nay là cung cấp cho khách hàng ước tính thời gian / chi phí cho ứng dụng khổng lồ. Tôi không quá thích câu trả lời này vì nó không giải quyết được vấn đề thực sự với tình huống này. Và đó là - đó là một thực tế tồi để chỉ ra một ứng dụng lớn và sau đó thử và xây dựng nó ngay từ đầu. Tôi cảm thấy thoải mái hơn nhiều khi ban đầu xây dựng một nền tảng MVP nhỏ, đơn giản. Và sau đó thêm từng tính năng nhỏ vào nền tảng đó từng cái một. Vậy làm thế nào để tôi thuyết phục khách hàng tiếp cận phần mềm xây dựng theo cách này?

Bằng cách ước tính sẽ tốn bao nhiêu tiền / thời gian để thực hiện hàng trăm tính năng đó với chất lượng cao. Rất, rất ít khách hàng sẽ đặt tiền của họ ở nơi miệng của họ.

Hai từ: Câu chuyện của người dùng.

Tôi đã học được rằng cách nhanh nhất để giúp khách hàng Nhận A Clue® là yêu cầu họ nói chuyện với tôi thông qua câu chuyện người dùng cho từng tính năng hoặc trang họ muốn. Một số điều xảy ra, bao gồm:

1. Họ phải suy nghĩ về những gì trang / tính năng thực sự phải làm.
2. Khi bạn hỏi để biết thêm chi tiết ("và sau đó? ... và sau đó? ..."), họ bắt đầu hiểu rằng toàn bộ sự việc sẽ không xảy ra bằng cách có Magic Space Monkeys ™ bay vào và làm cuối tuần qua
3. Họ trở thành đối tác thực sự trong quá trình sáng tạo. Điều đó có nghĩa là họ sẽ hiểu tại sao việc thay đổi suy nghĩ về điều gì đó đã hoàn thành 80% sẽ gây ra a) trì hoãn lịch trình và b) tăng chi phí.

Nghiêm túc. Câu chuyện người dùng của chủ sở hữu là một trong những công cụ tốt nhất mà tôi biết để mang lại ít nhất sự tỉnh táo cho quy trình.

Trong khi thảo luận về khía cạnh chi phí và thời gian sản xuất, hãy yêu cầu xếp hạng các yêu cầu ("phải có", "nên có" và "tốt đẹp phải có") để bộ tính năng sản phẩm khả thi tối thiểu cần thiết là "Phải có" trong phiên bản 1, sau đó đặt phần còn lại của các yêu cầu vào các bộ tồn đọng có thể được thực hiện dưới dạng chạy nước rút sau phiên bản đầu tiên. Hy vọng rằng những sản phẩm "không cần thiết" không cần thiết sẽ xuất hiện ở mặt sau của gói và đến khi bạn đạt được những lần chạy nước rút mới, những thứ thiết yếu hơn (từ trải nghiệm thực tế với sản phẩm) sẽ nổi lên hàng đầu.

Khách hàng nên đánh giá cao rằng bạn đang xem xét chi phí kinh doanh của họ và tầm quan trọng của việc nhanh chóng nhận được sản phẩm và bạn không trực tiếp loại bỏ "điều tốt đẹp cần có" của họ bằng cách đưa họ vào tồn đọng.

Chỉnh sửa để đáp ứng với chỉnh sửa OP: Để thuyết phục khách hàng lý do tại sao nên sớm phát hành một sản phẩm khả thi tối thiểu giải thích rằng cho đến khi sản phẩm được sử dụng bởi người dùng thực, thật khó để biết liệu nó có thành công hay không (đặc biệt là về khả năng sử dụng). Nếu khách hàng ngần ngại đưa ra một sản phẩm sớm cho toàn bộ cơ sở người dùng của họ, hãy khuyên bạn thực hiện "beta giới hạn" trong đó nó chỉ dành cho một tập hợp con khách hàng mục tiêu của họ. Nói với họ mặt trái của phương pháp này là một chu kỳ phát triển dài, tốn kém với một quyết định muộn rằng sản phẩm không thể sử dụng được. 37 Tín hiệu đã tạo ra một vài tài liệu tham khảo tốt về điều này: Bắt Real và Rework . Bắt Real có sẵn trên web miễn phí.

Nguyên nhân cốt lõi của sự thất vọng của bạn với tình huống có lẽ là một trong những nhận thức và các thuật ngữ sai / sai được sử dụng bởi khách hàng. Khách hàng thường không đến với bạn với một danh sách các yêu cầu , nhưng một danh sách mong muốn về mọi điều họ có thể nghĩ về điều đó có thể hữu ích cho họ. Đó không phải là tất cả các yêu cầu bởi vì khách hàng chưa dành thời gian để thực sự suy nghĩ nếu mỗi tính năng thực sự được yêu cầu .

Điều này không nhất thiết luôn luôn là một vấn đề

Nếu khách hàng của bạn có tiền cho tất cả các tính năng đó và sẵn sàng tham gia với nó, và bạn không thực sự quan tâm đến việc giải quyết các vấn đề thực tế, thực sự mà khách hàng có, thì đây có thể là một dự án rất sinh lợi. Điều đó xảy ra, rất, rất hiếm khi, và đối với hầu hết các nhà phát triển, đó là công việc giết chết tâm hồn bởi vì bạn có thể cảm thấy trước rằng dự án sẽ không thành công cho khách hàng (ngay cả khi nó thành công về mặt tài chính cho bạn với tư cách là nhà phát triển). Nó cũng có rủi ro cao vì bạn có khả năng kết thúc với một dự án có chi phí cố định với nhiều sự không chắc chắn và thực sự có vấn đề để đánh giá sai rủi ro đối với các dự án lớn.

Nếu đó là một vấn đề thì sao?

Hãy cho rằng bạn không ở trong tình huống hiếm hoi đó. Trong trường hợp này, bạn sẽ muốn giải quyết hai thiếu sót chính của danh sách mong muốn như được đưa ra:

1. Không có khả năng khách hàng có ý tưởng chính xác về chi phí phát triển một danh sách các yêu cầu lớn như vậy, vì vậy bạn không có khả năng nhận được hợp đồng về số tiền bạn thực sự cần để thực hiện.
2. Không chắc rằng danh sách mong muốn này mô tả chính xác và ngắn gọn về vấn đề thực sự mà khách hàng gặp phải và muốn giải quyết.

Theo kinh nghiệm của tôi, bạn cần giải quyết 2 để khắc phục 1. Đi sâu vào vấn đề thực tế có nghĩa là bạn, nhà phát triển, hiện có đầu vào cần thiết để thực hiện bước nhảy vọt sáng tạo trong việc giải quyết vấn đề theo cách mà chính khách hàng chưa từng nghĩ tới. Những giải pháp này có thể sẽ rẻ hơn và nhanh hơn nhiều so với việc thực hiện danh sách mong muốn đầy đủ.

Làm thế nào để bạn khắc phục điều đó?
Giống như Matthew Flynn nói trong câu trả lời của mình - bắt đầu bằng cách khiến khách hàng ưu tiên các yêu cầu. Điều này không phải lúc nào cũng dễ dàng, nhưng buộc họ phải làm điều đó. Nếu cần thiết hãy sử dụng cụm từ "Nếu ai đó giữ một khẩu súng vào đầu bạn, bạn sẽ giữ yêu cầu nào?". Bạn sẽ thường thấy trong quá trình này, khách hàng thực sự không có ý tưởng rất rõ ràng về các yêu cầu riêng lẻ có ý nghĩa gì. Trong trường hợp đó, hãy làm những gì Peter Rowell gợi ý và khiến khách hàng làm việc thông qua Câu chuyện của người dùng. Bạn và khách hàng sẽ bắt đầu hiểu vấn đề và yêu cầu tốt hơn nhiều, và sau đó bạn có thể quay lại mức độ ưu tiên. Lặp lại các bước đó thường xuyên như bạn cần cho đến khi bạn cảm thấy thoải mái rằng bạn biết đủ để giải quyết vấn đề của khách hàng .

Làm thế nào mà trả lời câu hỏi phát triển một giải pháp? Khi bạn có một danh sách các yêu cầu ưu tiên, bạn có đầu vào bạn cần để đề xuất quy trình phát triển gia tăng cho khách hàng của bạn. Bạn không cần phải gọi nó là Agile, nhưng bạn có thể đề nghị chia nhỏ hợp đồng thành từng phần nhỏ hơn cho từng yêu cầu (hoặc bộ yêu cầu không thể chia tách) và cung cấp từng cái một với xác nhận của khách hàng. Hoặc bạn có thể sử dụng toàn bộ và sử dụng nhiều tài nguyên có sẵn trực tuyến và ngoại tuyến để thuyết phục khách hàng rằng họ hợp tác theo một trong những phong cách phát triển Agile. Trong mọi trường hợp, bạn có thể cung cấp đề xuất hợp đồng / dự án của mình dưới dạng gợi ý rõ ràng các khối yêu cầu xây dựng này theo thứ tự ưu tiên, mỗi khối có chi phí và kết luận riêng. Giữ củ cà rốt đó trước mặt khách hàng,

Trước tiên tôi muốn thử và giải thích rằng các yêu cầu của họ là không thực tế và trình bày chúng với một loạt các yêu cầu truy cập. Giải thích rằng điều này sẽ giải quyết vấn đề của họ đơn giản hơn và nhanh hơn, do đó với ít chi phí và rủi ro hơn. Đừng thử và biến điều này thành một cuộc thảo luận kỹ thuật, khách hàng không quan tâm đến điều đó. Khách hàng quan tâm đến việc có được một sản phẩm tốt trong thời gian, giải quyết trường hợp kinh doanh của họ. Nếu khách hàng không nhúc nhích, chấp nhận hợp đồng và thực hiện công việc, hoặc từ chối và giải thích cho khách hàng tại sao bạn không thể chịu trách nhiệm cho dự án theo hình thức này.

Tương tự như những gì những người khác đã đề xuất, nhưng hơi khác một chút, tôi đề nghị rằng mọi thứ khách hàng có thể hợp lệ, nhưng họ phải ƯU TIÊN. Những mục cần phải được thực hiện đầu tiên. Những mục cần phải được thực hiện thứ hai. Quan trọng nhất, nếu bạn hết thời gian, món đồ nào sẽ làm tổn thương ít nhất là không có. Ưu tiên mỗi mục từ 1 đến 732 (hoặc bất cứ điều gì) và hoàn thành chúng theo thứ tự đó.

Một ví dụ lịch sử về một ứng dụng đã kết thúc vượt quá ngân sách và chậm tiến độ do yêu cầu quá cao là Hồ sơ vụ án ảo của FBI. Nó được dự định để thay thế vài chục ứng dụng hiện có và tất cả chúng đều phải hoạt động hoàn toàn, cùng một lúc, khi chuyển đổi. Dự án cuối cùng đã bị hủy bỏ. Những gì sẽ thành công là kiến ​​trúc sư một khung và thay thế dần các ứng dụng riêng lẻ vào hệ thống mới. Thay vào đó, chính trị và đấu đá sâu sắc dẫn đến mọi bên liên quan đến ứng dụng tuyên bố rằng ứng dụng của họ là ứng dụng quan trọng nhất và mọi người đều mạ vàng thông số kỹ thuật của họ bằng "phải có" từ tất cả các tính năng mà họ muốn thêm vào ứng dụng hiện có. Cuối cùng, khối lượng yêu cầu thay đổi được viết mỗi ngày vượt quá số lượng mã thực sự được viết mỗi ngày.

Tôi đã thấy công việc "Tôi phải có tất cả" trong 2 trường hợp. Trong một, khách hàng tài chính lớn (sử dụng thác nước của tất cả mọi thứ), có 40 hệ thống khác nhau (công ty chúng tôi đã tạo ra một trong số 40) được thay thế và hoạt động trong một cú trượt ngã. Kiểm tra tích hợp và truyền thông là những vấn đề lớn. Ước tính của tôi là họ đã đốt khoảng 100 nghìn đô la / ngày trong các cuộc gọi hội nghị (khi bạn đếm tỷ lệ thanh toán của mọi người trong các cuộc gọi). Trong cả hai trường hợp, các nhà đàm phán mạnh mẽ đã đưa ra một danh sách những gì sẽ được chuyển giao và sau đó đóng đinh chân của mọi người xuống đất. Không có sự di chuyển của các cột gôn, không có sự đàm phán lại. Cả hai công việc đều kết thúc đúng giờ và đúng giờ. Một là vượt ngân sách, hai là ngân sách. Đối với điều này, bạn cần những người quản lý dự án rất giỏi, những người biết nhóm của họ có thể cung cấp những gì (loại người có thể nói rằng tính năng Q mất 3.

Thiếu các Thủ tướng, nhà đàm phán và số liệu xuất sắc, tôi khuyên bạn nên thúc đẩy khách hàng hướng tới việc giao hàng gia tăng. Nếu họ vẫn muốn toàn bộ gạch vàng cùng một lúc, họ có thể được phục vụ tốt hơn bằng cách giúp họ tìm một số tư vấn khác. Đôi khi câu trả lời tốt nhất là "chúng tôi không thể giúp bạn."

Trả lời ngắn gọn: Tôi sẽ lắng nghe khách hàng của mình và tìm cách tiếp cận giữa chừng với họ.

Tôi sẽ đề nghị lắng nghe khách hàng và tùy thuộc vào ngân sách và thời gian của họ, chia dự án thành các giai đoạn (phát hành, phát hành2, v.v.).

Sau đó, bạn có thể tiếp tục ước tính từng giai đoạn có thể phân phối, ngân sách và ưu tiên các tính năng cần thiết mà ứng dụng sẽ cung cấp.

Vì vậy, xác định phạm vi công việc và phân phối là cách để đi :)

Như các câu trả lời khác nêu, ưu tiên là rất quan trọng. Một cách thuận tiện để làm điều này là thông qua phương pháp MoSCoW . Nhưng bạn có thể muốn bắt đầu với việc chia toàn bộ danh sách, nếu không, chính danh sách tính năng sẽ cung cấp cho bạn (hoặc khách hàng của bạn) các vấn đề về hiểu biết :)

Bên cạnh này, bạn có vấn đề nhìn tổng thể vấn đề. Bạn có thể giải quyết vấn đề này bằng cách ngồi với khách hàng của mình và thực hiện các bước sau:

• Đi toàn cầu thông qua các tính năng và danh mục chưng cất từ ​​chúng
• Ưu tiên (sử dụng MoSCoW) các danh mục và có thể xác định cấu trúc phân cấp (một danh mục cơ bản với các tính năng mặc định, danh mục cho các chủ đề chính, các danh mục cho các biến thể cụ thể của các chủ đề chính). Điều này có thể thay đổi các danh mục bạn đã xác định trong bước trước (nhờ những hiểu biết mới).
• Đi qua từng tính năng từng cái một và gán chúng cho một danh mục
• Ưu tiên (sử dụng MoSCoW) các mục trong danh mục top-x.

Điều này sẽ cung cấp một cái nhìn đẹp mắt và cô đọng từ trên xuống về các tính năng được yêu cầu của bạn và sẽ cung cấp cho bạn các tay lái để xác định các lần lặp khác nhau để bắt đầu với một cơ sở và mở rộng nó với các tính năng khác.