Làm việc trong một tổ chức lớn, thường thì các thành viên của nhóm phát triển không thể truy cập trực tiếp vào máy khách để thu thập các yêu cầu. Có thể / khuyên bạn nên đưa ra một danh sách các câu hỏi cho người quản lý tài khoản để họ có thể thu thập các yêu cầu thay cho bạn không?
Câu trả lời:
Có thể: có :-)
Khuyến khích: chỉ khi thực sự không có cách nào khác. Điều này sẽ dễ dàng dẫn đến các yêu cầu rất dễ vỡ, hiểu kém. Và các vấn đề chỉ có thể xuất hiện ở giai đoạn sau, trong quá trình thực hiện hoặc thử nghiệm chấp nhận.
Yêu cầu thu thập lý tưởng nên là một loạt các cuộc thảo luận chi tiết giữa khách hàng và nhà phát triển.Khách hàng thường có những ý tưởng rất mờ nhạt về những gì họ thực sự muốn, do đó thực hiện phân tách mơ hồ đầu tiên của họ gần như chắc chắn sẽ dẫn đến các vấn đề. Vì vậy, các nhà phát triển sẽ có thể nói giá của từng ý tưởng / câu chuyện / yêu cầu, giúp khách hàng ưu tiên nhu cầu của họ và đưa ra phản hồi kỹ thuật về những gì có thể và khả thi. Ngoài ra, họ nên hiểu miền vấn đề sâu đến mức cần thiết, để cung cấp giải pháp kỹ thuật tốt nhất cho vấn đề của khách hàng. Và trên đường đi, họ phải đảm bảo rằng họ hiểu khách hàng đúng cách, điều đó có nghĩa là thường xuyên hỏi lại để làm rõ và lặp lại những gì họ hiểu bằng lời nói của họ trong các phiên giao tiếp (và thường xuyên cung cấp các nguyên mẫu / mô phỏng UI về ý tưởng của khách hàng).Phương tiện tốt nhất cho việc này là giao tiếp bằng miệng - nếu không thể đối mặt trực tiếp, một cuộc hội thảo qua video hoặc điện thoại là lựa chọn tốt nhất tiếp theo.
Có một người phi kỹ thuật như một kênh giao tiếp giữa khách hàng và nhà phát triển hạn chế nghiêm trọng hiệu quả của truyền thông. Ngay cả việc gửi tài liệu qua lại bằng e-mail sẽ tốt hơn, nơi ít nhất không có trung gian, do đó, có một khả năng ít xảy ra cho sự hiểu lầm.
Mặc dù tôi đồng ý với Péter Török rằng việc đi giữa có thể hạn chế hiệu quả, nhưng việc nói chuyện không phải với nhà phát triển với người dùng cuối cũng có thể làm tăng hiệu quả của giao tiếp.
Tôi đã phát hiện ra rằng các nhà phát triển và người dùng cuối thường có thể nói chuyện với nhau nhưng vẫn hiểu sai về nhau vì họ đến từ "những thế giới khác nhau". Trong khi nói những từ giống nhau, họ có thể hiểu chúng có nghĩa là những điều hoàn toàn khác nhau ... Một người đi giữa hiểu cả tư duy / ngôn ngữ của người dùng cuối và nhà phát triển, có thể có giá trị trong việc cải thiện sự hiểu biết lẫn nhau về những gì cần thiết / những gì sẽ được phát triển.
Điều đó đang được nói, hỏi người quản lý, có thể là người quản lý tài khoản hoặc bất kỳ loại người quản lý nào khác, không phải là cách để đi. Thu hẹp khoảng cách giữa thế giới của nhà phát triển và người dùng cuối là một kỹ năng và không phải là thứ bạn làm "như một bên".
Nói tóm lại, cách làm việc này đầy nguy hiểm và là một trong những lý do khiến Tuyên ngôn Agile ra đời.
{nỗ lực xấu về sự hài hước} Bắt đầu, mượn, chiến đấu, lừa gạt, ăn cắp, quyến rũ, đến quán rượu, làm những gì bạn có thể thực sự tham gia với người dùng cuối {/ cố gắng xấu về sự hài hước}
Nhưng nghiêm túc, nếu bạn không thể có quyền truy cập thì ít nhất hãy đảm bảo có chu kỳ phản hồi nhanh. Vì vậy, có, bạn có thể đặt câu hỏi thông qua người quản lý tài khoản (nếu bạn có thể truy cập trực tiếp vào máy khách, ngay cả khi từ xa qua email vẫn tốt hơn), nhưng hãy hỏi họ mỗi ngày và cung cấp nguyên mẫu thường xuyên nhất để khách hàng dùng thử.
Nếu không, bạn có một rủi ro lớn trong việc cung cấp một cái gì đó mà khách hàng cuối cùng không thực sự muốn.
Tôi làm việc trong một tổ chức quy mô vừa và chúng tôi có một nhóm giải pháp kinh doanh có nhiều nhà phân tích kinh doanh. Họ làm một công việc quan trọng vì họ hiểu rất rõ quy trình kinh doanh và dịch những gì doanh nghiệp muốn thành những gì nhà phát triển hiểu. Nó hoạt động theo cách khác là tốt. Nếu tôi phát hiện ra một số vấn đề về thiết kế và / hoặc kiến trúc hoặc đề xuất một cách khác để giải quyết vấn đề, tôi sẽ nói chuyện với họ và họ lần lượt kinh doanh.
Trong một doanh nghiệp lớn có nhiều điều cần xem xét ngoài những điều kỹ thuật khi thực hiện một yêu cầu. Giống như các vấn đề đào tạo nhân viên, như không tác động đến khách hàng bằng thay đổi, như quy trình bù trừ tồn tại để làm cho câu hỏi của bạn không thành vấn đề, hoặc "John" là tiếp thị sử dụng chức năng này và bạn không thể thay đổi điều này, v.v.
Để trả lời câu hỏi của bạn nếu bạn có một cấu trúc tại chỗ thì hãy sử dụng nó. Cung cấp cho họ danh sách các câu hỏi để theo dõi với các nhà quản lý tài khoản doanh nghiệp.
Bạn đang chơi phiên bản thu thập yêu cầu của trò chơi điện thoại. Tốt nhất, điều này sẽ gây ra nhiều giao tiếp không hiệu quả. Tồi tệ nhất, nó sẽ gây ra các yêu cầu thu thập không chính xác. Tầm quan trọng của vòng phản hồi này và hiệu quả của nó là một trong những lý do chính khiến Đại diện khách hàng là một trong những vai trò có giá trị nhất (và khó quy mô nhất) trong nhóm Agile.
Theo câu hỏi của bạn theo nghĩa đen, câu trả lời không thể là gì khác hơn là một câu "KHÔNG! KHÔNG! MỘT THỨ VÀ HAI LẦN THỨ HAI!" trừ khi "Trình quản lý tài khoản" cũng là một nhà tư vấn, nhà phân tích và nhà phát triển được đào tạo
Nếu phải có một người trung gian chưa được đào tạo trong quy trình, bạn nên gửi bản khảo sát người dùng qua email và chỉ cần CC quản lý tài khoản. Anh ấy / cô ấy không thể có thể thêm giá trị cho quá trình, nhưng chắc chắn có thể cắt xén thông tin liên lạc.
Vai trò thích hợp của Trình quản lý tài khoản trong quy trình này là tham gia vào cuộc trò chuyện với tư cách là một bên liên quan , không chơi phần mềm trung gian hoặc nhà phân tích nghiệp dư.