Câu hỏi TẠI SAO và cái giá của việc không hỏi nó

Câu hỏi là anh cần báo cáo này để làm gì.

Câu trả lời hóa ra không phải để gửi cho khách hàng như anh nói lúc đầu, mà là để gửi cho sếp của chính anh xem, bởi sếp muốn nắm tình hình nên anh phải ngồi xuất báo cáo rồi gửi lên.

Vấn đề là con số sếp cần thì Odoo đã có sẵn: các phân hệ chính đều có khung báo cáo cho phép nhóm dữ liệu theo nhân viên, theo khách hàng hay theo sản phẩm, xem ở dạng bảng chéo hoặc biểu đồ, rồi lưu lại thành một dạng xem riêng để mở lại bất cứ lúc nào. Chỉ có điều sếp chưa bao giờ đăng nhập vào xem, và cũng chưa ai chỉ cho ông chỗ đó. Do đó cách xử lý cuối cùng chỉ là cho sếp truy cập hệ thống rồi hướng dẫn một lần; kết quả là người phụ trách đỡ phải ngồi làm báo cáo, sếp chủ động xem lúc nào cũng được, và không ai phải viết một dòng code nào.

Độ lệch giữa "gửi cho khách hàng" và "gửi cho sếp của tôi" chính là chỗ đáng chú ý nhất ở đây. Không ai nói dối cả, người phụ trách chỉ mô tả yêu cầu bằng cách gần nhất với công việc hằng ngày của anh, và cái nhãn anh gán cho nó lại không trùng với mục đích thật.

Điều đáng nói ở câu chuyện này không phải là ai đó đã cứu được một khoản tiền, mà là không có ai làm sai ở bất kỳ bước nào: khách mô tả yêu cầu rất rõ ràng, thư ký ghi lại chính xác, Dev estimate đúng khối lượng của thứ được mô tả, và quy trình chạy đúng từ đầu tới cuối, vậy mà kết quả vẫn là một khoản chi phí không phục vụ mục đích nào.

Đó chính là lý do chuyện này lặp lại được ở mọi dự án, kể cả những dự án có quy trình phân tích chặt chẽ.

Vì sao người dùng không nói ra mục đích

Không phải họ giấu. Là vì với họ, mục đích là chuyện hiển nhiên tới mức không đáng nói.

Người làm một công việc hằng ngày trong nhiều năm sẽ mô tả công việc đó bằng thao tác, bởi thao tác là thứ họ nhìn thấy và nhớ được. Mục đích thì nằm ở tầng dưới, đã trở thành phản xạ, và họ chỉ diễn đạt được nó khi có người hỏi thẳng.

Thêm một lớp nữa: user bị bias bởi phần mềm cũ. Họ đã quen làm theo cách mà công cụ hiện tại cho phép, nên khi được hỏi họ cần gì, cái bật ra trong đầu là tính năng của công cụ đó chứ không phải vấn đề gốc. Trong trường hợp báo cáo ở trên, "xuất báo cáo rồi gửi email" chính là cách duy nhất hệ thống cũ cho phép, và sau vài năm thì nó không còn được nhìn như một cách làm nữa, nó trở thành chính công việc.

Cần lưu ý rằng chuyện này không chỉ xảy ra với người dùng cuối. Nó xảy ra với cả trưởng phòng và giám đốc, thậm chí còn rõ hơn, vì họ càng lâu năm thì phản xạ càng sâu.

Bốn dấu hiệu phải dừng lại

Vấn đề thực tế không phải là biết hỏi tại sao. Vấn đề là nhận ra mình đang đứng trước một yêu cầu cần đào sâu, giữa một buổi khảo sát có hàng chục yêu cầu khác.

Đầu tiên là khi user mô tả giải pháp thay vì mô tả vấn đề. Câu "tôi cần một nút bấm ở màn hình này" là mô tả giải pháp, còn câu "tôi cần biết đơn nào sắp trễ hạn giao" mới là mô tả vấn đề; và khi nghe dạng câu thứ nhất thì việc của bạn là đi ngược lên tìm cho ra dạng câu thứ hai, bởi chỉ dạng thứ hai mới đối chiếu được với hệ thống.

Tiếp theo là khi yêu cầu bắt đầu bằng tên một chức năng của phần mềm cũ. Nghe khách nói bên em cần cái màn hình giống như phần mềm cũ đang có, đó là dấu hiệu rõ nhất của bias, và rất thường xuyên thì hệ thống mới đã có sẵn một cách làm khác đạt được cùng kết quả mà không cần dựng lại màn hình nào.

Ví dụ hay gặp nằm ở phân hệ kho. Khách yêu cầu dựng lại đúng màn hình nhập kho của phần mềm cũ, nơi thủ kho gõ tay số lượng thực nhận vào cùng một dòng với số lượng đã đặt; hỏi thêm một câu thì hóa ra thứ họ cần là biết chênh lệch giữa số đặt và số nhận để làm việc lại với nhà cung cấp, mà chuyện đó thì phiếu nhập kho của Odoo đã tách sẵn thành hai cột riêng, chỉ là nó nằm ở một màn hình khác với chỗ họ quen nhìn. Kết quả là không dựng lại màn hình nào, chỉ mất một buổi hướng dẫn.

Dấu hiệu thứ ba là yêu cầu đắt nhưng không ai giải thích được nó phục vụ quyết định gì. Mọi báo cáo tồn tại để một người ra một quyết định nào đó, cho nên nếu bạn không chỉ ra được quyết định đó là gì và ai là người ra nó, thì hoặc báo cáo này không cần thiết, hoặc bạn chưa hiểu đúng yêu cầu và cả hai khả năng đều buộc bạn phải hỏi thêm.

Cuối cùng là khi một yêu cầu chỉ có đúng một người cần. Điều này không có nghĩa yêu cầu đó sai, bởi nhiều khi người đó nhìn ra thứ mà cả phòng chưa nhận ra; tuy nhiên nó có nghĩa là bạn phải hiểu rất rõ bối cảnh và phải có người đủ thẩm quyền xác nhận trước khi đưa nó vào phạm vi dự án.

Hỏi thế nào để không bị coi là vặn vẹo

Đây là phần khó, vì hỏi tại sao ba lần liên tiếp thì nghe như đang chất vấn, và người bị hỏi sẽ phòng thủ.

Cách tôi vẫn dùng là không hỏi "tại sao", mà hỏi cái gì sẽ xảy ra sau đó.

Thay vì "tại sao anh cần báo cáo này", hỏi "báo cáo này ra rồi thì anh làm gì tiếp với nó".

Câu thứ hai không đặt người ta vào thế phải biện minh, mà mời họ kể tiếp câu chuyện, và câu chuyện đó chính là thứ bạn cần.

Một biến thể khác dùng được khi khách yêu cầu thứ gì đó mơ hồ, đó là hỏi ngược về tiêu chí. Có lần khách nói muốn hệ thống dự đoán ngày chốt của các cơ hội bán hàng, và họ dùng đúng chữ AI. Câu hỏi ngược là hiện tại bên anh đang dựa vào tiêu chí gì để đoán, và khách kể ra ngay một quy tắc rất cụ thể: cơ hội có doanh thu dự kiến dưới một ngưỡng nào đó thì thường chốt trong khoảng hai mươi ngày kể từ ngày phát sinh, còn trên ngưỡng đó thì lâu hơn.

Từ chỗ này thì yêu cầu đổi hình dạng hoàn toàn. Nó không còn là một hạng mục mơ hồ nữa mà trở thành một trường tính toán dựa trên ngày phát sinh và ngưỡng doanh thu, thứ làm được bằng Studio hoặc bằng custom tùy mức độ, và ước tính được. Việc tích hợp AI thật thì vẫn khả thi về mặt kỹ thuật nếu khách muốn đi tiếp, nhưng giờ họ đã có một tiêu chí đo được để đối chiếu xem AI có làm tốt hơn quy tắc của chính họ hay không.

Đồng thời, thứ tự đặt câu hỏi cũng quan trọng. Khung tôi được một quản lý dự án lâu năm chỉ lại và vẫn dùng tới giờ là:

1. người này là ai
2. vai trò gì
3. làm công việc đó ở đâu
4. khi nào
5. để giải quyết vấn đề gì
6. và cuối cùng mới là tại sao

Năm câu đầu là mô tả nên chúng làm người trả lời thoải mái; câu cuối mới là câu đào, và nó dễ được đón nhận hơn hẳn khi năm câu trước đã tạo đủ ngữ cảnh.

Cái giá của việc không hỏi

Trong case ở đầu bài, cái giá là năm mươi ngày công, và may là nó được phát hiện trước khi bắt đầu làm.

Trường hợp tệ hơn là phát hiện sau khi đã làm xong. Lúc đó bạn có một tính năng chạy đúng như đặc tả, đã được nghiệm thu, và không ai dùng. Không ai kêu ca, không ai báo lỗi, nó chỉ đơn giản là nằm đó, và đó là loại lãng phí khó nhìn thấy nhất trong một dự án, bởi mọi chỉ số đều xanh.

Chuyện này không chừa ai. Một quản lý dự án lâu năm mà tôi làm việc cùng từng nói rằng dự án đầu tiên của anh có vấn đề đúng ở chỗ này, là không hiểu rõ mục đích đằng sau những gì khách nói, tới lúc nhận ra thì đã đi quá xa để quay lại. Nghe một người đã làm hơn chục dự án nói vậy thì tôi hiểu rằng đây không phải kỹ năng học một lần là xong, mà là thứ phải nhắc lại với chính mình ở từng buổi khảo sát.

Việc tiếp theo, sau khi bạn đã hiểu đúng khách cần gì, là quyết định xem nên đáp ứng nó bằng cấu hình hay bằng cách custom.