Bạn có nên hứa sẽ cung cấp một tính năng mà bạn không chắc chắn nếu nó có thể thực hiện được không?

Trong một bài viết từ HN , tôi đã xem qua lời khuyên sau:

Luôn luôn nói với khách hàng / người dùng của bạn "có", ngay cả khi bạn không chắc chắn. 90% thời gian, bạn sẽ tìm ra cách để làm điều đó. 10% thời gian, bạn sẽ quay lại và xin lỗi. Giá nhỏ để trả cho sự tăng trưởng cá nhân lớn

Nhưng tôi đã luôn nghĩ rằng một người nên thực hiện một phân tích khả thi trước khi đưa ra bất kỳ loại lời hứa nào với khách hàng / người dùng, để họ không bị nhầm lẫn tại bất kỳ thời điểm nào. Trong trường hợp nào, sau đó, nên áp dụng lời khuyên trên?

Đây là câu hỏi thứ hai liên tiếp được kích hoạt bởi bài báo đó.

• Lập trình viên giỏi: Tôi tối ưu hóa mã. Lập trình viên tốt hơn: Tôi cấu trúc dữ liệu. Lập trình viên tốt nhất: sự khác biệt là gì?
  Có một tên khác cho điều này: tối ưu hóa sớm.

• Không bao giờ sử dụng lối thoát sớm.
  Đó là quy tắc "một điểm nhập cảnh / một điểm thoát duy nhất". Đó là một bản vá cho vấn đề thực sự, đó là việc thoát ra sớm có thể để lại một mớ hỗn độn. Quy tắc đúng là "dọn dẹp mớ hỗn độn của bạn". Một quy tắc thậm chí tốt hơn là sử dụng các cấu trúc dữ liệu tự dọn dẹp để lập trình viên không phải lo lắng về việc dọn dẹp mớ hỗn độn của họ.

• Và bây giờ, Luôn luôn nói với khách hàng / người dùng của bạn "có", ngay cả khi bạn không chắc chắn. 90% thời gian, bạn sẽ tìm ra cách để làm điều đó.
  Đây cũng là lời khuyên vô cùng tồi tệ.

Đôi khi khách hàng của bạn cần được nói không, hoặc "bạn muốn điều này trong thiên niên kỷ nào?" Đừng hứa điều gì đó sẽ phá hủy kiến ​​trúc của bạn, điều đó sẽ tốn kém hơn nhiều so với chi phí mà khách hàng sẵn sàng chi tiêu hoặc bạn không có manh mối về cách đạt được nó. Bạn biết công nghệ chứ không phải khách hàng. Nếu bạn không biết cách làm, đừng nói bạn có thể làm được. Nếu bạn không chắc chắn, hãy nói rằng bạn cần thời gian để nghiên cứu xem liệu điều đó có thể không. Thành thật mà nói, nó sẽ giúp bạn thoát khỏi rắc rối.

Khách hàng nhanh chóng trở thành khách hàng cũ nếu bạn không thể thực hiện lời hứa của mình. Tỷ lệ thất bại 10% nghe có vẻ nhỏ, nhưng đó là 10% khách hàng của bạn sẽ tập trung vào. Đôi khi họ kiện khi bạn không thực hiện được những gì bạn đã hứa. Bạn thực sự không muốn điều đó. Những lần khác, đảm bảo bạn thực hiện tốt lời hứa có thể khiến bạn phá sản, phát điên hoặc mất người phối ngẫu vì bạn đang làm việc 18 giờ. Bạn cũng không muốn điều đó.

Hãy nghĩ về nó theo cách này: Bạn nghĩ điều gì sẽ xảy ra với ngành hàng không nếu 90% tất cả các chuyến bay hạ cánh thành công? Bạn có nghĩ rằng quay lại và xin lỗi vì 10% bị rơi sẽ khắc phục điều gì không?

Sẽ là tốt hơn để nói "Tôi nghĩ rằng có thể được thực hiện". hoặc "Tôi sẽ kiểm tra và lấy lại cho bạn". Tôi đã có những lúc tôi nói không hoặc phản đối đề xuất một cái gì đó. Nếu khách hàng muốn "một ứng dụng dựa trên trình duyệt hoạt động mà không bao giờ được kết nối với internet và sử dụng phản hồi xúc giác", có lẽ điều đó là có thể. Nhưng nó rất tốn kém và sẽ hữu ích hơn khi thảo luận về nhu cầu thực tế là gì.

Khách hàng sẽ tôn trọng bạn nếu bạn trung thực. Trong lời khuyên trong câu hỏi, người đó sai 10% thời gian. Nếu tôi làm việc với một người thường xuyên sai một lần trong mười lần, tôi sẽ không tin tưởng anh ấy / cô ấy chút nào. Đó là một hồ sơ theo dõi khủng khiếp.

Hứa hẹn mặt trăng và giao đá là một cách tiếp cận nhân viên bán hàng không nên dung thứ. Nếu bạn không biết nếu có thể, hãy nghiên cứu nó. Hoặc, cung cấp cho họ báo giá về thời gian bạn sẽ phải mất để xem xét nó. Bằng cách này, bạn không hứa hẹn bất cứ điều gì bạn không thể cung cấp, nhưng bạn đang được trả tiền cho thời gian bạn phải xem xét nó.

Câu hỏi này đã được nghiên cứu chính thức và được giải quyết bởi Bộ luật đạo đức của Hiệp hội máy tính / ACM được sản xuất chung .

2,01. Cung cấp dịch vụ trong các lĩnh vực năng lực của họ, trung thực và thẳng thắn về bất kỳ hạn chế nào về kinh nghiệm và giáo dục của họ.

3.04. Đảm bảo rằng họ đủ điều kiện cho bất kỳ dự án nào mà họ làm việc hoặc đề xuất làm việc bằng sự kết hợp thích hợp giữa giáo dục và đào tạo và kinh nghiệm.

3.09. Đảm bảo ước tính định lượng thực tế về chi phí, lập kế hoạch, nhân sự, chất lượng và kết quả cho bất kỳ dự án nào mà họ làm việc hoặc đề xuất để làm việc và đưa ra đánh giá không chắc chắn về các ước tính này.

5.05. Đảm bảo ước tính định lượng thực tế về chi phí, lập kế hoạch, nhân sự, chất lượng và kết quả cho bất kỳ dự án nào mà họ làm việc hoặc đề xuất để làm việc, và đưa ra đánh giá không chắc chắn về các ước tính này.

Chắc chắn có ý nghĩa kinh doanh và pháp lý về việc hứa hẹn một cái gì đó mà bạn không thể cung cấp. Thông thường những điều này đến từ khách hàng đi nơi khác, từ chối trả tiền, hoặc kiện công ty của bạn. Nếu bạn hợp tác với người khác, họ có thể kiện đòi bồi thường thiệt hại nếu phần của bạn không được giao. Các vụ kiện thậm chí có thể đến từ các đối thủ cạnh tranh.

Có một câu chuyện từ những ngày đầu của siêu máy tính, nơi Seymour Cray và một nhóm tại Control Data Corporation đã gần ra mắt một sản phẩm, và một công ty máy tính rất lớn khác nói với khách hàng của mình rằng nó cũng sắp ra mắt. Lời nói dối đã khiến CDC tốn rất nhiều kinh doanh và biến thành một vụ kiện mà công ty lớn không thể đưa ra bất kỳ bằng chứng xác thực nào cho tuyên bố của họ. Kết quả là những gì tại thời điểm một khoản thanh toán lớn trị giá 80 triệu đô la năm 1970 (khoảng $ 223 triệu vào năm 2012, được điều chỉnh theo lạm phát). Bạn có thể đọc nó ở đây:

http://en.wikipedia.org/wiki/Control_Data_Corpination#CDC_6600:_defining_supercomputing

Cho đủ thời gian, nguồn lực và sự linh hoạt xung quanh định nghĩa thành công bất cứ điều gì đều có thể. Ví dụ về khối lượng x trắng rất dễ dàng nếu bạn chỉ muốn độ chính xác cao hơn 50% và bạn có vị trí địa lý của người dùng và một ít dữ liệu thống kê.

Câu hỏi thực sự đầu tiên trong hầu hết các dự án không phải là nếu điều gì đó có thể xảy ra, mà là nếu nó hợp lý với một tình huống nhất định.

Liệu tính năng này có thêm giá trị đủ để đảm bảo chi phí cho nỗ lực này không?

Ngay cả khi ý tưởng sẽ khá tuyệt vời, nếu nó đòi hỏi một thời gian phát triển dài hoặc mua lại một số phần cứng kỳ lạ hơn, thì tốt hơn là khách hàng nên biết rằng trước mắt và sau đó điều khiển cuộc trò chuyện trở lại mục tiêu hợp lý hơn trong hầu hết các trường hợp.

Nếu ai đó đủ điên rồ để đưa cho bạn một tấm séc trắng và không có thời hạn thì bằng mọi cách hãy nói với họ mọi thứ đều có thể, chỉ cần cho họ biết bạn phải phát minh và phân phối một số công nghệ liên quan để đạt được mục tiêu trên đường đi.

Mặt khác, khi giao dịch với khách hàng hợp lý với tài nguyên hợp lý, đôi khi không có gì tệ hơn là nói với khách hàng một số tính năng phải được cắt sau khi bạn đã đồng ý vì họ có thể đã hết và dành thời gian / tiền / tài nguyên để quảng cáo hoặc ghi lại nó và 10% có thể là điều khiến dự án được bật đèn xanh ngay từ đầu. Rơi vào những tình huống đó và bạn vừa mất một khách hàng, và nhiều khả năng có được một tài liệu tham khảo rất tệ trong toàn bộ thị trường.

Chơi người ủng hộ của quỷ

Là người có tư duy phân tích, những người kỹ thuật có thể có xu hướng cho rằng hiệu suất của họ chủ yếu sẽ được đánh giá dựa trên bảng điểm hoàn thành so với yêu cầu đã cam kết, nhưng trên thực tế, nó không bị cắt và làm khô.

Trước khi bắt đầu phát triển, khách hàng bắt đầu hình thành ý kiến ​​về hiệu suất của nhóm dựa trên mức độ tự tin và sẵn sàng cam kết của họ.

Một phần lý do cho điều này là khách hàng có thể gặp khó khăn trong việc đánh giá xem sự do dự của nhà thầu có phải là do khó khăn trong yêu cầu hoặc thiếu khả năng của nhà thầu.

Vì không có tiêu chí tuyệt đối để đo lường độ khó của yêu cầu, nên điều quan trọng hơn đối với khách hàng là tin tưởng rằng nhà thầu đang nỗ lực 100%, thay vì liệu 90% hay 100% yêu cầu được đáp ứng.

Giả sử khách hàng phải lựa chọn giữa hai kịch bản:

Nhà thầu A :

• Tự tin họ có thể cung cấp trên tất cả các yêu cầu
• Kết quả: 90% yêu cầu được gửi
• Khách hàng hài lòng rằng nhà thầu đã nỗ lực 100%
• Khách hàng nhận thấy rằng các yêu cầu chưa hoàn thành là do các vấn đề không lường trước được, có thể nằm ngoài sự kiểm soát của các nhà thầu

Nhà thầu B :

• Cam kết cung cấp trên 90% các yêu cầu. Không tự tin họ có thể giao hàng trên 10% còn lại
• Kết quả: 90% yêu cầu được gửi
• Khách hàng thất vọng vì nhà thầu đã không cố gắng hoàn thành 10% yêu cầu khác của mình
• Khách hàng cho rằng 10% yêu cầu chưa hoàn thành là do thiếu nỗ lực hoặc khả năng của nhà thầu

Trong cả hai kịch bản, cùng một số lượng yêu cầu đã được gửi; tuy nhiên, khách hàng cảm thấy rằng Nhà thầu A "quá cố" đã nỗ lực 100% và sử dụng điều này để xác thực rằng các yêu cầu còn lại thực sự khó khăn, đối với tín dụng của Nhà thầu A.

Mặt khác, khách hàng cảm thấy như Nhà thầu B đã không nỗ lực 100% và việc không thể hoàn thành tất cả các yêu cầu là do Nhà thầu B thiếu nỗ lực hoặc khả năng.

Tuyên bố miễn trừ trách nhiệm: Tôi không ủng hộ việc áp dụng quá mức như một chiến lược; đây chỉ là một quan sát về một tình huống thực tế có thể xảy ra trong đó tình trạng thừa có thể có kết quả tích cực.

Bạn nên bảo họ cho bạn thời gian để tạo ra một "giải pháp tăng đột biến" .

Một giải pháp tăng đột biến là một chương trình nhỏ, trong việc mã hóa nó, cho phép bạn tìm ra cách thực hiện, hoặc thậm chí liệu có thể, một thứ gì đó đang tạo ra sự không chắc chắn trong một dự án.

Ví dụ: giả sử bạn chưa bao giờ gửi SMS theo chương trình, nhưng bằng cách nào đó bạn biết điều đó là có thể. Một giải pháp tăng đột biến sẽ là tạo một chương trình nhỏ gửi SMS. Bằng cách đó, nó không còn là một điều không chắc chắn và bạn có thể ước tính thêm về tính khả thi.

Đây là những gì tài liệu lập trình eXtreme nói về nó:

Tạo các giải pháp tăng đột biến để tìm ra câu trả lời cho các vấn đề kỹ thuật hoặc thiết kế khó khăn. Một giải pháp tăng đột biến là một chương trình rất đơn giản để khám phá các giải pháp tiềm năng. Xây dựng đột biến để chỉ giải quyết vấn đề đang được kiểm tra và bỏ qua tất cả các mối quan tâm khác. Hầu hết các gai không đủ tốt để giữ, vì vậy mong đợi để ném nó đi. Mục tiêu là giảm rủi ro của sự cố kỹ thuật hoặc tăng độ tin cậy của ước tính câu chuyện của người dùng. Khi một khó khăn kỹ thuật đe dọa kìm hãm sự phát triển của hệ thống, đặt một cặp nhà phát triển vào vấn đề trong một hoặc hai tuần và giảm rủi ro tiềm ẩn.

Theo kinh nghiệm của tôi, khi người dùng yêu cầu một cái gì đó, bạn nên yêu cầu họ cung cấp thông số kỹ thuật chi tiết về những gì người dùng thực sự muốn hoặc cần. Thường xuyên hơn không, bạn sẽ không bao giờ nghe về yêu cầu nữa.