Một lập trình viên có thể nghĩ ra ý tưởng cho khách hàng?

Tôi đã đi đến điểm mà tôi ghét thu thập yêu cầu. Khách hàng quá mơ hồ vì lợi ích của chính họ. Trong một môi trường nhanh, nơi chúng tôi có thể hiển thị cho khách hàng một phần công việc cần hoàn thành, nó không quá tệ vì chúng tôi có thể thực hiện các chỉnh sửa / cập nhật thường xuyên nhỏ cho chức năng.

Trong một loại "thác nước" trong môi trường (yêu cầu đầu tiên, sản phẩm gần như hoàn thành tiếp theo), mọi thứ có thể trở nên xấu xí. Loại môi trường này đã khiến tôi liên tục đặt câu hỏi. Khách hàng EG muốn "tự động chuyển đổi đầu vào thành số 1" (tham khảo số lượng theo thứ tự). Nhưng điều họ không nghĩ tới là "đầu vào" có thể là một kiểu đơn giản. Một "x" trong hộp văn bản có thể là "woops" chứ không phải tôi muốn 1 trong những sản phẩm "kem đánh răng" đó. Nhưng, có quá nhiều thứ trong không khí với những yêu cầu mà tôi có thể đứng và sửa chữa hàng giờ liền để phá vỡ những gì họ muốn. Điều này không tốt cho sức khỏe.

Làm việc cho một tập đoàn, tôi có thể cố gắng điều chỉnh văn hóa để phù hợp với mô hình nhanh nhẹn sẽ giúp chúng tôi (công việc không nhỏ, trên mức lương của tôi). Hoặc, quét các chi tiết xấu xí dưới tấm thảm và hy vọng điều tốt nhất. Có lẽ khách hàng của tôi đang cố gắng để đến quá gần với mã?

Làm thế nào để một người xử lý vấn đề "suy nghĩ cho khách hàng" mà không khiến họ bực mình với quá nhiều câu hỏi?

Trong hầu hết các trường hợp, khách hàng không nhận thức được những gì khác có thể được thực hiện. Họ chưa bao giờ phải mô tả những gì họ cần theo cách khiến nó không rõ ràng đối với chúng tôi. Trong tâm trí của họ, nó là rõ ràng. Ngay cả việc họ đang nghĩ về việc chuyển đổi đầu vào của người dùng thành số 1 thực sự vượt xa cách họ quen nghĩ.

Đó thực sự là như nó phải vậy. Nếu họ thực sự mới làm thế nào để mô tả chính xác những gì họ muốn, họ sẽ không cần chúng tôi viết nó cho họ. Do đó, trách nhiệm của chúng tôi là giúp họ trong suốt quá trình. Quá trình này đòi hỏi phải đưa ra quyết định, vì vậy họ cũng cần các khuyến nghị của chúng tôi để làm cho quá trình ra quyết định dễ dàng hơn.

Vì vậy, hãy để khách hàng mơ hồ và nói chuyện ở mức cao. Họ biết doanh nghiệp của họ và đó là những gì họ giỏi (hy vọng, hoặc họ sẽ không thể thanh toán hóa đơn của bạn ...). Lấy những gì họ nói và suy nghĩ về nó một lúc. Cuối cùng, bạn nhận được một số ý tưởng tuyệt vời để có được những gì họ muốn và cần, trong khi đảm bảo rằng những gì bạn cần là có thể kiểm chứng và nhất quán.

Tôi rất khuyên bạn nên làm việc trong chunk. Khi bạn gặp khách hàng có một tập hợp các yêu cầu có liên quan với nhau, và sau đó giải thích cách bạn dự định làm những gì họ muốn. Cũng giải thích lý do tại sao bạn thực hiện các lựa chọn bạn đã làm. Sau đó, khách hàng có thể nhìn vào những gì bạn cung cấp và tinh chỉnh nó. Nếu bạn nhận được câu trả lời như "Tôi chưa bao giờ nghĩ về điều đó, nhưng điều đó thực sự có ích" bạn biết rằng bạn đã có một nhịp đập về cách khách hàng nghĩ. LƯU Ý: rằng đây không phải là bệnh viêm gan, nó chọn các tính năng phù hợp để phù hợp nhất với vấn đề kinh doanh mà khách hàng gặp phải.

Nếu bạn có bất cứ điều gì trông giống như nó có thể mâu thuẫn với những gì khách hàng nói rõ ràng với bạn, thì đã đến lúc giải thích lý do. Bạn sẽ cần đưa ra một số vấn đề mà khách hàng không bao giờ nghĩ tới, và cách thay thế của bạn vẫn cung cấp cho họ những gì họ muốn / cần nhưng cũng tránh được những vấn đề tiềm ẩn đó. Bạn có thể nhận được một chút phản hồi, nhưng nó cũng tạo dựng niềm tin của khách hàng khi họ nhận ra bạn đang cố gắng cung cấp cho họ một sản phẩm mà họ thực sự có thể sử dụng. Nếu họ đưa ra một số phản hồi, nó buộc họ phải giải thích lý do tại sao họ muốn một cái gì đó theo một cách nhất định. Điều đó giúp bạn hiểu khách hàng của mình hơn và điều chỉnh các yêu cầu khi cần thiết.

Cách nhanh nhất để làm hao mòn khách hàng của bạn là hỏi hết những câu hỏi nhỏ này đến câu hỏi khác. Bạn muốn lập kế hoạch và lên lịch một loạt các cuộc họp để xem xét phương pháp của bạn. Miễn là bạn sở hữu các yêu cầu kỹ thuật (nhóm của bạn sử dụng để xây dựng sản phẩm) và khách hàng của bạn sở hữu các yêu cầu kinh doanh và bạn có thể liên kết chúng với nhau, bạn có cách để thu hẹp khoảng cách.

Nếu bạn đang 'chọc giận họ' từ quá nhiều câu hỏi, hãy kiếm một khách hàng tốt hơn.

Khách hàng không biết họ muốn gì. Họ sẽ không nhất thiết nhận ra giải pháp của họ khi họ nhìn thấy nó. Đó là một vấn đề, và đó là công việc bạn đang giải quyết: dịch các yêu cầu của họ thành thứ gì đó có thể được phân phối dưới dạng gói phần mềm.

Để làm điều đó bạn phải tìm hiểu về những gì bạn đang làm. Bạn không nên hỏi "điều gì sẽ xảy ra khi họ đặt một số vào hộp văn bản", bạn nên hỏi "tại sao số này lại quan trọng? Nó dùng để làm gì?" Có họ dạy bạn cách họ làm công việc của họ. Và đừng nghe những gì họ nói, vì họ không biết họ muốn gì, nhưng hãy xem những gì họ làm và đôi mắt của họ đi đâu .

Đọc phần này để biết thêm: http://www.joelonsoftware.com/articles/fog0000000356.html

Giả sử bạn là nhân viên tại một công ty nào đó, có vẻ như bạn đang cần một nhà phân tích kinh doanh giỏi để giúp hòa giải những chi tiết đó giữa khách hàng và chính bạn. Tôi đoán bạn không có đủ ảnh hưởng để biến điều đó thành hiện thực, vì vậy lời khuyên tốt nhất tiếp theo của tôi là tìm hiểu thêm về tên miền mà khách hàng của bạn đang làm việc. Bằng cách hiểu về doanh nghiệp và quy trình họ làm việc cùng, bạn ' sẽ có một ý tưởng tốt hơn về những gì họ thực sự muốn thực hiện, mặc dù cách lỏng lẻo và có thể sai mà họ đang mô tả nó. Điều đó cho phép bạn phân tích những gì họ đã yêu cầu và bạn có thể quay lại sau trong một cuộc họp riêng với giải thích về những gì họ muốn và một đề xuất có thể cho họ những gì họ thực sự muốn. Nếu bạn luôn làm việc với cùng một khách hàng, bạn '

Nếu điều đó có vẻ rất khó khăn, đau đớn, cực kỳ khó chịu hoặc không thực tế, lời khuyên cuối cùng của tôi là hãy bắt đầu tìm kiếm một công việc mới ở đâu đó mà họ có các nhà phân tích kinh doanh, bởi vì nó sẽ không dễ dàng hơn cho bạn nếu không nỗ lực.

Nếu bạn đang yêu cầu thu thập thì công việc của bạn là hỏi những câu hỏi này.

Vâng, khách hàng có thể cảm thấy khó chịu, nhưng trong trường hợp đó bạn cần giải thích lý do tại sao bạn hỏi "tất cả những câu hỏi này". Bạn cần hiểu doanh nghiệp của họ trước khi bạn có thể viết mã sẽ tự động hóa doanh nghiệp đó. Điều chắc chắn là nếu bạn không, họ sẽ chi rất nhiều tiền để phát triển một hệ thống không thực sự làm những gì họ muốn.

Tác dụng phụ của việc này là cuối cùng bạn sẽ giúp khách hàng tinh chỉnh các yêu cầu của họ.

Điều này áp dụng cho dù bạn đang thực hiện Big Design Up Front hay Agile.

Đáng buồn thay, công việc của bạn là nghĩ cho khách hàng nếu anh ta không thể hoặc sẽ không tự làm điều đó.

Tôi đã có cả hai kết quả có thể:

• khách hàng rất vui khi bạn thực sự nghĩ về những gì anh ta nói với bạn, anh ta cảm thấy rằng mình đang ở trong tay phải, hoặc

• khách hàng khó chịu vì bạn buộc anh ta phải suy nghĩ lại về yêu cầu của mình. Nhưng sau đó, loại khách hàng này sẽ khó chịu với bạn dù thế nào, sớm hay muộn. Anh ấy chắc chắn sẽ rất khó chịu nếu anh ấy phát hiện quá muộn mà bạn không nghĩ cho anh ấy lúc đầu. Tôi muốn nói: tránh loại khách hàng này nếu có thể :-)

Một Rapid Application Development (RAD) đề cập đến vấn đề này nữa.

Bắt đầu "suy nghĩ cho khách hàng" bằng cách tạo một giao diện người dùng phi chức năng rất thô sơ cho chương trình dựa trên dự đoán tốt nhất của bạn về những gì họ cần. Sau đó cho họ xem và làm việc lặp đi lặp lại cho đến khi bạn đáp ứng nhu cầu thực tế của họ.

Không phải là họ không biết họ muốn gì. Đó là họ không biết những gì họ muốn cho đến khi họ nhìn thấy nó, và đôi khi bạn có thể xác định những gì họ muốn bằng cách loại trừ. Đó là, cho họ thấy một cái gì đó họ KHÔNG muốn và chú ý đến cách họ chỉ trích nó.

Vấn đề chính với BFUD (thiết kế Big Up Front) là nó bảo vệ nhà phát triển khỏi sự đổ lỗi bằng cách buộc khách hàng ký hợp đồng mô tả rõ ràng những gì họ sẽ nhận được. Và thật không may, điều này được thực hiện vào thời điểm mà không ai trong dự án có ý tưởng tốt về những gì thực sự cần thiết. Cuối cùng, điều này chỉ khiến khách hàng chấp nhận những gì bạn xây dựng vì họ đã ký tắt, nhưng miễn cưỡng.

Nếu khách hàng không hài lòng với việc giao hàng thì đó chỉ là một chiến thắng của Pyrros.

Công việc của khách hàng là chuyển tiếp cho bạn những gì họ cần. Công việc của bạn là hiểu những gì họ cần đủ tốt để có thể lập trình những gì họ cần. Một câu hỏi rõ ràng cho vấn đề thay đổi tất cả đầu vào thành một câu sẽ là "Tại sao bạn muốn nó thay đổi tất cả đầu vào thành 1?" Sau đó, khách hàng có thể giải thích lý do đằng sau nó để bạn sẽ hiểu nhu cầu và sau đó có thể cung cấp không nhất thiết những gì họ yêu cầu mà là những gì họ cần. Nếu bạn tự tin bạn biết họ cần gì thì tôi không nghĩ bạn nhất thiết phải "sửa" dòng suy nghĩ của họ. Họ sẽ sử dụng sản phẩm và điều "Ồ! Thật hoàn hảo". Nhưng trừ khi bạn tự tin, bạn biết họ cần gì, sau đó bạn sẽ giải thích những gì bạn đang nghĩ và giải quyết nó với khách hàng. Thật không may Không có cách nào để thực hiện phần này của quá trình với nhiều giao tiếp liên quan đến việc lắng nghe thực sự trên cả hai phần. Hãy cẩn thận để bị làm phiền với tình huống và nói những điều bạn có thể hoặc không thực sự muốn nói.

Thành thật: Trừ khi đó là 'chức năng lớn' thì người có kiến ​​thức tên miền nhất sẽ đưa ra dự đoán tốt nhất về những gì sẽ xảy ra và thực hiện điều đó. Nó sẽ được bổ sung trong thử nghiệm chấp nhận - đó là những gì dành cho.