Nhà phát triển phần mềm có trách nhiệm hiểu ý nghĩa của khách hàng với yêu cầu của mình không?

Loại câu hỏi có / không và tại sao?

Nhà phát triển phần mềm có trách nhiệm hiểu ý của khách hàng đối với yêu cầu của mình hay trách nhiệm của khách hàng là phải giải thích chính xác yêu cầu của mình cho nhà phát triển?

Tình huống tại nơi làm việc hiện tại là "khách hàng đã giải thích cho chúng tôi, anh ta muốn gì. Trách nhiệm của bạn là hiểu yêu cầu, không hỏi thêm câu hỏi nào".

Mặc dù tiếng Anh không phải là bộ phần mềm mạnh mẽ của tôi, nhưng tất cả các yêu cầu được viết bằng tiếng Anh tối nghĩa với các từ bị đặt sai và các câu khó hiểu, một số yêu cầu cho rằng sự hiểu biết trước đó về hệ thống của tôi.

Tôi là nhà phát triển thứ 3 hoặc thứ 4 của hệ thống (các nhà phát triển cuối cùng bỏ việc) và đó có thể là lý do khách hàng mong đợi một số hiểu biết về phía nhà phát triển.

Bản thân hệ thống này khá lộn xộn cả về giao diện người dùng và mã nguồn. Điều này trông giống như khỉ mã hóa với tôi - mã và hy vọng bạn nhận được yêu cầu đúng, trong khi không thực sự hiểu yêu cầu.

Tôi thực sự nghĩ về việc bỏ công việc, nhưng chưa, vì tôi không chắc ai đúng và ai sai.

Nếu đó là công việc của bạn để hiểu, thì công việc của bạn là đặt câu hỏi cho đến khi bạn làm

Người bạn hỏi có thể không phải là khách hàng (tôi thường nói chuyện với một người trung gian, người đã tiếp xúc với khách hàng), vì vậy những người cấm bạn nói chuyện với khách hàng nên tự trả lời các câu hỏi hoặc giới thiệu bạn với ai đó có thể.

Nhưng, cuối cùng phải có MỘT SỐ loại giao tiếp. Nếu họ từ chối nó (và cung cấp một số tài liệu mà bạn không hiểu là từ chối giao tiếp một cách hiệu quả), bạn nên làm như những người đi trước đã làm: chạy đi, nhanh chóng.

Khi khách hàng và cấp trên của bạn để lại cho bạn một vệt giấy lộn xộn, điều duy nhất bạn có thể làm là thu thập càng nhiều ý nghĩa càng tốt từ những gì bạn có và bắt đầu viết kịch bản bằng tiếng Anh để cố gắng cấu trúc kiến ​​thức về cách thức hệ thống được cho là hành xử.

Các kịch bản được đưa ra / Khi / Sau đó giúp bạn có thể biết chi tiết về những gì cần xảy ra và vì chúng được viết bằng tiếng Anh đơn giản và chúng có cấu trúc, bạn có thể sử dụng chúng để giao tiếp với cấp trên và khách hàng của mình: "Nghe, Tôi đã đi đến điểm này và tôi không biết hệ thống phải làm gì ở đây ".

Nếu bạn đơn giản xa lánh khi bạn yêu cầu làm rõ thêm, mặc dù bạn đã đầu tư công sức để ghi lại mọi thứ bạn làm và không hiểu, thì các nhà phát triển trước đó đã thất bại không phải vì họ không biết cách truyền đạt thông số kỹ thuật, mà bởi vì Không thể làm như vậy.

Theo tôi cả (khách hàng và nhà phát triển) phải có cùng sự hiểu biết về vấn đề và giải pháp của nó.

Nếu bạn không hiểu yêu cầu, bạn không thể tạo ra giải pháp.

Vì vậy, bạn phải đọc thông số kỹ thuật. Nếu thông số kỹ thuật không đủ rõ ràng (hoặc không có thông số kỹ thuật bằng văn bản) thì nên có người có thể đưa ra câu trả lời.

Tôi làm việc trong các nhóm có một người có thể trả lời các câu hỏi kinh doanh. Đây chủ doanh nghiệp hoặc là thành viên của sự phát triển-công ty tôi làm việc cho mà biết việc kinh doanh khách hàng hoặc một thành viên của nhóm khách hàng.

Dường như trong câu hỏi cụ thể của bạn, người quản lý dự án lo ngại rằng khách hàng sẽ khó chịu nếu họ hỏi những câu hỏi tương tự nhiều lần (cần thiết vì doanh thu của nhà phát triển) và điều này sẽ phản ánh kém về anh ta và công ty của anh ta.

Tất nhiên, nếu bạn không hỏi những câu hỏi đó, bạn sẽ mất nhiều thời gian hơn để hoàn thành / sửa đổi hệ thống và kết quả có thể không phải là điều khách hàng muốn, điều này sẽ gây ra nhiều sự chậm trễ và CSONG phản ánh kém về người quản lý dự án và người quản lý dự án công ty, ít nhất là trong mắt khách hàng.

Có một số lý do tại sao người quản lý dự án có thể chọn không cho phép bạn đặt câu hỏi:

1. Anh ta không thực sự hiểu những hậu quả tiêu cực hoặc phủ nhận về chúng.
2. Anh ta nhận thức được các lựa chọn thay thế nhưng biết khách hàng có nhiều khả năng chấp nhận sự chậm trễ và chất lượng kém hơn các câu hỏi gây phiền nhiễu.
3. Anh ấy chơi trò chơi chính trị: có thể anh ấy biết rằng anh ấy sẽ sớm rời khỏi dự án và muốn giấu kín vấn đề cho đến lúc đó, hoặc anh ấy định đổ lỗi cho bạn về những vấn đề gây ra bởi sự thiếu giao tiếp này.

IMO lý do 2 là không thể. Để loại bỏ lý do 1, hãy thử giải thích các lựa chọn thay thế cho anh ta và yêu cầu anh ta đưa ra lựa chọn rõ ràng giữa họ - đề nghị giải thích vấn đề cho khách hàng để giảm bớt sự khó chịu. Để loại bỏ lý do 3, hãy thực hiện điều này bằng văn bản để bạn có thể chứng minh rằng bạn đã sớm nhận ra những vấn đề tiềm ẩn và cố gắng khắc phục chúng. Nhưng thành thật mà nói, nếu bạn nghi ngờ điều này là cần thiết, có lẽ bạn nên ra khỏi đó càng nhanh càng tốt.

Tôi nghĩ rằng trách nhiệm của nhà cung cấp dịch vụ là luôn đảm bảo rằng họ đã hiểu được ý định của khách hàng.

Là chuyên gia trong lĩnh vực của chúng tôi, công việc của chúng tôi không chỉ là hoàn thành tóm tắt mà còn giúp hướng dẫn khách hàng của chúng tôi trong quá trình sử dụng dịch vụ của chúng tôi và điều này liên quan đến việc giáo dục họ về các khả năng chúng tôi cung cấp và những gì chúng tôi làm bây giờ.

Tôi tin rằng một cách tiếp cận tập trung vào khách hàng hoàn toàn là cách để làm mọi thứ, đó là một mô hình kinh doanh đã được thử nghiệm và thử nghiệm.

Khách hàng và nhà phát triển cần phải làm việc cùng nhau để tinh chỉnh hiểu biết của họ về hệ thống.

Công ty phần mềm cần phải đi đến thỏa thuận với khách hàng về những gì được yêu cầu của mỗi bên, đó là khía cạnh cơ bản của hợp đồng. Nếu không có "cuộc họp tâm trí" thì, theo một nghĩa rất thực, không có hợp đồng.

Giả sử rằng bạn là một lập trình viên có năng lực, nếu thông số kỹ thuật không rõ ràng thì chỉ cần nói "Đó là khả năng đáp ứng yêu cầu của bạn, không hỏi thêm câu hỏi" là khá ngớ ngẩn.

Điều này dựa trên một số thông tin mới trong các bình luận về câu hỏi ban đầu.

Tuyên bố rằng

khách hàng đã giải thích cho chúng tôi, những gì anh ấy muốn. Bạn có trách nhiệm hiểu yêu cầu, không đặt thêm câu hỏi

xuất phát từ người lãnh đạo dự án; lý do đã nêu là

rằng vì tôi không phải là nhà phát triển đầu tiên trên hệ thống, chúng tôi không nên làm phiền người đại diện của khách hàng với nhiều câu hỏi hơn, nhưng hãy cố gắng và nếu cần, hãy dành thêm thời gian để giải thích câu hỏi

Vì vậy, những gì bạn đặc biệt được nói để tránh là làm phiền khách hàng bằng các câu hỏi .

Yêu cầu bạn "dành thêm thời gian để giải thích câu hỏi" không nhất thiết là không hợp lý. Bạn nên thực hiện một nỗ lực hợp lý, hoặc thậm chí là một nỗ lực hơi vô lý, để tìm ra những yêu cầu dựa trên những gì khách hàng đã thực sự nói. Nếu không có gì khác, đó là một kỹ năng có giá trị.

Nếu điều đó không thành công (và có vẻ như nó đã có, vì nhiều lý do), sau đó yêu cầu người lãnh đạo dự án của bạn giúp đỡ. Cố gắng cụ thể nhất có thể trong các câu hỏi của bạn, cho thấy bạn đã hoàn thành bài tập về nhà. Ví dụ, thay vì

Những người này muốn gì ??? "

hỏi vài thứ như

Trong đoạn 17 của tài liệu yêu cầu, nó nói rằng foobar phải làm xáo trộn phần bị đóng băng; cái nào trong ba cái vòi này đề cập đến? "

Hoặc, nếu các yêu cầu thực sự được viết quá tệ đến mức bạn không thể giải mã chúng, hãy nói với anh ấy điều đó.

Tôi muốn nói rằng cuối cùng, trách nhiệm của người dẫn đầu dự án là đảm bảo rằng các yêu cầu được hiểu chính xác (chắc chắn là vì lợi ích tốt nhất của anh ta để dự án thành công). Nhưng là một thành viên của nhóm, bạn chia sẻ một số trách nhiệm đó. Nếu bạn cho thấy rằng bạn đã tự mình nỗ lực và người lãnh đạo dự án từ chối giúp đỡ bạn, thì anh ta hoàn toàn chịu trách nhiệm. Nếu nó đạt đến điểm đó, hãy chắc chắn rằng anh ấy biết điều đó.

Trong một thế giới hoàn hảo, cần có một danh sách các tính năng và thông số kỹ thuật ở đâu đó, một cái gì đó được viết trên một hợp đồng ràng buộc công ty và khách hàng của bạn.

Để trả lời câu hỏi của bạn, nhà phát triển nên thực sự hiểu khách hàng muốn gì và có một tài liệu bằng văn bản để cả hai bên đồng ý với cùng một tầm nhìn.

Tất nhiên, đây không phải là một thế giới hoàn hảo và thường không có thông số kỹ thuật, và nếu bạn không có bất kỳ đặc điểm kỹ thuật bằng văn bản nào, thì điều này sẽ khó khăn. Có ai còn lại trong công ty của bạn làm việc với tư cách là đại biểu mối quan hệ với khách hàng, ai có thể giúp bạn hiểu khách hàng muốn gì không?

Nếu không, ở vị trí của bạn, tôi sẽ thử và lấy thông tin từ các nhà phát triển trước đó, giả sử họ hiểu nhiệm vụ tất nhiên.

Tôi nghĩ rằng vai trò thực tế chỉ định người chăm sóc các yêu cầu hiểu biết khác nhau tùy thuộc vào một số biến này

• Kích thước nhóm
• Tiêu chuẩn công ty
• Cách ông chủ được sử dụng để làm việc
• Chuyên môn khác nhau giữa các thành viên trong nhóm

Vì vậy, nếu bạn chỉ là một nhóm một người, bạn nên cố gắng hết sức để đi đến tận cùng của các yêu cầu. nếu bạn là người mới trong một dự án đang diễn ra, bạn nên nỗ lực để vượt qua các yêu cầu một lần nữa với khách hàng.

EDIT: Quan trọng nhất, khách hàng có thể không biết anh ta đưa ra những yêu cầu kém như vậy và quá trình thu thập các yêu cầu thường kéo dài và tẻ nhạt, nhưng đó là một quá trình quan trọng, và nếu nó rơi vào bạn bởi vì không ai khác làm điều đó, thì bạn nên làm điều đó với họ