Làm việc với những khách hàng không biết họ muốn gì

Gần đây tôi đã bắt đầu một công việc mà tôi đang làm việc trên một hệ thống hiện có. Nó đòi hỏi các chỉnh sửa và cập nhật cũng như mã mới. Bây giờ tôi đã thực hiện một số dự án bảo trì / bổ sung tính năng và một vài trong số chúng cuối cùng đã khác biệt đáng kể so với những gì thực sự được yêu cầu. Vì vậy, tôi đã phải lập trình vật phẩm nhiều lần để đưa nó đến nơi mà người yêu cầu muốn.

Bây giờ, tôi không ngại lập trình lại tính năng nếu đó là những gì cần phải làm. Tuy nhiên, tôi muốn giảm thời gian quay vòng cho các dự án của mình. Nút thắt dường như nằm trong nhận thức của người yêu cầu về những gì cần phải làm. Bạn có ý tưởng nào về những gì tôi có thể làm để tìm ra những gì người yêu cầu cần nhanh hơn không?

Một vài lời khuyên:

• Lắng nghe vấn đề, Không phải Giải pháp . Rất nhiều khách hàng muốn cho bạn biết làm thế nào để giải quyết vấn đề của họ. Đừng nghe họ nói. Bạn là lập trình viên và công việc của bạn là tìm giải pháp cho các vấn đề. Thay vào đó hãy lắng nghe những vấn đề mà khách hàng đang gặp phải và tìm ra cách tốt nhất để giải quyết nó. như những người khác đã nói, khách hàng không thực sự biết họ muốn gì, đôi khi bạn phải cho họ xem trước.

• Đặt câu hỏi . Khi bạn đặt câu hỏi xong, hãy hỏi thêm. Khách hàng hiếm khi đến với các chi tiết, vì họ không thực sự nghĩ về nó. Cách duy nhất bạn sẽ có được thông tin bạn cần là loại bỏ chúng ra khỏi chúng.

• Nhận mọi thứ bằng văn bản Tùy thuộc vào tình huống với khách hàng, điều này có thể thực sự quan trọng sau này khi họ bắt đầu phàn nàn về cách bạn gửi "không phải là những gì họ yêu cầu". và nếu không có gì khác, viết ra các thông số kỹ thuật chi tiết có thể giúp bạn đảm bảo rằng bạn có tất cả thông tin bạn cần và giúp xóa tan sự mơ hồ giữa bạn và khách hàng.

• Truyền thông là chìa khóa . không chỉ nói chuyện với khách hàng, nhận thông tin, loại bỏ một số mã và không nói chuyện với họ cho đến khi hoàn thành. Luôn giữ liên lạc với khách hàng. Đặt câu hỏi trong suốt quá trình. cho họ thấy tiến trình bạn đã thực hiện và nhận phản hồi. Nó sẽ làm cho cuộc sống của mọi người dễ dàng hơn trong thời gian dài.

Hầu như bất kỳ cuốn sách tự giúp đỡ nào bạn chọn trong giao tiếp sẽ cung cấp cho bạn một số biến thể của điều này:

• Tìm kiếm trước để hiểu, sau đó được hiểu

Điều đó xuất phát từ cuốn sách 7 thói quen, nhưng tất cả chúng đều là một số biến thể của phương pháp " lắng nghe tích cực ". Mục tiêu không chỉ là để hiểu, mà là để liên lạc lại với họ mà bạn đã hiểu.

Khi tôi nghĩ rằng tôi có một ý tưởng tốt về những gì họ cần (tránh xa những gì họ muốn đặc biệt nếu họ bắt đầu mô tả chi tiết thực hiện - đó là công việc của bạn không phải của họ), tôi đưa cho họ ví dụ về những câu chuyện của nhiều người sử dụng hệ thống, và xem liệu mà sống với họ.

Sau đó, tôi thực hiện điều đó, hoàn toàn mong đợi rằng một khi họ thấy tính năng này, họ sẽ thực sự nhận ra đó không phải là chính xác những gì họ muốn. Giữ mọi thứ linh hoạt. Chỉ có sự trung thành là thay đổi. Tôi thường nhận được hầu hết các cạnh thô đã được xử lý sau lần cập nhật nhanh thứ hai sau lần cập nhật ban đầu, nhưng tôi luôn thấy tôi đang tiếp cận một cách bất thường một số lý tưởng mà tôi không bao giờ có thể đạt được. Cuối cùng, bạn cần phải để những thứ không quan trọng đi và chuyển sang các mục tiêu có giá trị cao hơn.

Tôi cảm nhận được nỗi đau của bạn....

Tin xấu là: tùy thuộc vào chính xác loại khách hàng bạn giao dịch, đây có thể là công việc như bình thường.

Một vấn đề chung chung về cơ bản là khách hàng không biết họ muốn gì . Họ thường biết những gì họ muốn đạt được, về mặt mục tiêu kinh doanh, nhưng họ thường không biết nó nên trông như thế nào về giải pháp phần mềm. Vì vậy, trong nhiều trường hợp, bạn sẽ thấy mình trong chu trình lặp này, nơi một dự án bị trả lại gấp năm lần so với ước tính ban đầu, bởi vì khách hàng tiếp tục thay đổi ý định và muốn giải pháp được điều chỉnh và điều chỉnh lại. Và đúng vậy, không có gì bất thường khi kết quả cuối cùng được biến thành một thứ hoàn toàn khác với mục tiêu ban đầu trông như thế nào.

Tôi đã có một ví dụ điển hình về điều này xảy ra vài năm trước - một dự án ban đầu mất 10 tuần để mã hóa thành một lần lặp lại 15 tháng. Trong trường hợp đó, chủ yếu là do các nhà quản lý và bộ phận khác nhau tại công ty khách hàng muốn những thứ khác nhau, vì vậy họ tiếp tục gửi công việc trở lại, để được điều chỉnh và điều chỉnh lại (phần mềm của chúng tôi dựa trên đăng ký và đây là một khách hàng lớn, vì vậy điều này không có da tài chính trên lưng của chúng tôi - thực sự là một phiền toái kỹ thuật lớn).

Vì vậy, về cơ bản lời khuyên của tôi là:

Nếu đây là cách ngành công nghiệp cụ thể của bạn và những khách hàng này (đó là một IF lớn), thì hãy làm quen với nó. Hãy nghĩ về nó như là một công việc Agile, định hướng bảo trì (đây là cách biểu diễn hiện tại của tôi, ít nhiều). :)

Nếu đây không phải là cách mọi thứ được thực hiện và bạn đang đổ lỗi cho những bước ngoặt dài, thì hãy nói với sếp của bạn. Giải thích cho họ rằng có các vấn đề giao tiếp và các thông số kỹ thuật đến với bạn từ khách hàng không đủ rõ ràng để bạn thực hiện giải pháp mong muốn. Bạn không muốn thấy mình trong tình huống bị bắt lỗi vì đã không cung cấp cho khách hàng những gì họ muốn, nếu bạn không nhận được tất cả thông tin cần thiết để cung cấp cho họ những gì họ muốn.

Trước hết, bạn nên chấp nhận thực tế rằng khách hàng không thực sự biết họ đang tìm kiếm gì cho đến khi họ nhìn thấy nó. Họ có thể nói với bạn ngay bây giờ rằng họ cần tính năng X. Hiển thị cho họ tính năng X sau đó họ sẽ nhận ra rằng thứ họ thực sự cần là tính năng Y hoặc một biến thể khác của tính năng X.

Một cách tốt để tìm ra những gì khách hàng thực sự muốn nhanh hơn là nắm lấy và tuân theo Tuyên ngôn Agile , tập trung vào giao tiếp và hợp tác với khách hàng. Chia chu trình phát triển thành các lần lặp và hiển thị cho khách hàng một nguyên mẫu của tính năng mỗi khi kết thúc lần lặp. Bằng cách đó, bạn sẽ nhận được phản hồi ngay lập tức và thay đổi nó, theo phản hồi từ khách hàng, mà không phải đầu tư quá nhiều tài nguyên vào tính năng. Bằng cách đó, cả bạn và khách hàng sẽ hài lòng với kết quả của sản phẩm.

Tôi khá chắc chắn rằng việc chuyển đổi sẽ khó khăn cho nhóm của bạn hoặc công ty của bạn nhưng đó là một trong những cách tốt nhất để đối phó với các yêu cầu thay đổi nhanh chóng.

Rất nhiều, và rất nhiều câu chuyện tương tự có thể được tìm thấy ở đây . Tôi chưa bao giờ, thậm chí làm việc như một nhà thầu phụ cho một công ty phát triển khác, đã tìm thấy một khách hàng biết chính xác những gì họ muốn.

Tôi đủ hạnh phúc để làm việc với một người có ý tưởng thực sự tốt về những gì họ KHÔNG muốn hoặc muốn tránh. Tôi thường có thể làm việc từ đó đến một cái gì đó mà họ hài lòng.

Kinh nghiệm của tôi chủ yếu là trong phát triển ứng dụng / nền tảng, mặc dù. Rất may, tôi hiếm khi phải đối phó với các vấn đề về thẩm mỹ như các nhà thiết kế web làm.

Sau nhiều lần viết lại gây phiền nhiễu, bây giờ tôi vận hành những gì tôi gọi là tiết lộ đầy đủ.

Vì vậy, sau khi thảo luận về các yêu cầu và mong muốn của khách hàng, tôi sẽ luôn viết ra những gì tôi cảm nhận được họ muốn và cách tôi sẽ tiến hành để thực hiện yêu cầu đó. Sau đó tôi sẽ gửi cho họ những gì tôi đã viết và đợi cho đến khi họ trả lời trong lời khẳng định trước khi bắt đầu công việc.

Nếu đó là một dự án lớn (hơn 5 ngày làm việc) tôi cũng sẽ làm nguyên mẫu. Điều này cho họ một cơ hội để thay đổi tâm trí của họ mà không cần thay đổi mã lớn vào cuối của tôi.

Nó không phải lúc nào cũng hoạt động, nhưng ít nhất tôi đang ở một vị trí mà khách hàng biết rằng họ đang thay đổi ý định và không phải tôi thực hiện không đúng.