Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Khách nói bên em muốn quản lý kho chặt hơn. Câu đó đi qua những bước nào để thành các dòng yêu cầu đo được, và ba kiểu câu dễ đánh lừa người ghi.
Buổi khảo sát phòng kho của một doanh nghiệp phân phối hàng tiêu dùng, bốn kho đặt ở ba tỉnh, và câu đầu tiên trưởng kho nói khi được hỏi anh mong muốn gì ở hệ thống mới là bên em muốn quản lý kho chặt hơn.
Ba tuần sau, lúc ngồi đối chiếu từng yêu cầu với hệ thống, bạn mở lại dòng đó ra và không làm được gì với nó: không đánh giá được hệ thống đáp ứng tới đâu, không ước tính được khối lượng, và không viết được kịch bản kiểm thử.
Vấn đề không nằm ở chỗ trưởng kho nói không rõ, bởi với anh ấy thì câu đó rõ tới mức không cần giải thích thêm. Giữa một câu nói trong phòng họp và một dòng yêu cầu nghiệm thu được có cả một quãng đường phải đi, và đi quãng đường đó là việc của bạn chứ không phải việc của khách.
Một dòng yêu cầu không tồn tại để bạn nhớ lại buổi họp, mà tồn tại để một người chưa từng dự buổi nào có thể đọc vào là biết phải làm gì và biết thế nào là làm xong.
Đem tiêu chí đó ra soi thì câu quản lý kho chặt hơn thiếu cả ba thứ:
Hệ quả là hai người đọc cùng một dòng sẽ hình dung ra hai hệ thống khác nhau.
Chuyện này còn nặng hơn ở dự án triển khai nền tảng có sẵn, bởi bạn phải đem từng yêu cầu đi thử trên hệ thống rồi mới kết luận được đáp ứng hay không, mà với một câu như vậy thì bạn không biết mở màn hình nào ra để thử.
Chữ gây rắc rối trong câu của trưởng kho là chữ chặt hơn, và mọi tính từ so sánh đều gây rắc rối như vậy: nhanh hơn, dễ hơn, chính xác hơn, minh bạch hơn.
Phản xạ sai là hỏi thẳng anh muốn chặt tới mức nào, bởi câu hỏi đó bắt người trả lời tự chuyển ý mình thành thang đo, mà đó là việc họ không quen làm.
Cách tôi vẫn dùng là bỏ qua tính từ và hỏi về sự kiện: lần gần nhất kho gặp chuyện vì quản lý chưa chặt là khi nào, hôm đó ai làm gì, phát hiện ra lúc nào và xử lý ra sao. Người ta kể chuyện dễ hơn nhiều so với việc tự định nghĩa một mức độ, mà câu chuyện thì luôn có nhân vật, thời điểm và hậu quả, chính là những thứ bạn cần.
Trong buổi khảo sát đó, một câu tính từ đẻ ra ba tình huống:
Ba tình huống này khác nhau về bản chất chứ không phải ba mức của cùng một chuyện, nên dừng lại ở tình huống đầu tiên là mất hai phần ba khối lượng.
Trong trường hợp khách không kể được tình huống nào, đó cũng là thông tin: mong muốn kia thường đến từ một buổi demo họ xem ở đâu đó, nên ghi nhận cho giai đoạn sau thay vì đưa vào phạm vi lần này.
Ba tình huống vừa lấy được không nằm cùng một tầng, và đây là chỗ người mới hay gộp tất cả thành một dòng vừa to vừa không ai duyệt được. Có tầng là mục tiêu của ban giám đốc, có tầng là quy tắc thuộc thẩm quyền một trưởng phòng, có tầng là việc hệ thống phải làm được, và có tầng chỉ tồn tại đúng một lần lúc chuyển đổi, bốn tầng này cùng tên gọi của chúng đã được nói kỹ ở bài về BRD, FRD và SRS.
Cái đáng nhớ hơn tên gọi là hệ quả thực tế: mỗi tầng có một người xác nhận khác nhau. Nếu bạn gộp cả bốn vào một dòng rồi mang đi xin chữ ký, bạn đang bắt một người ký cho những thứ nằm ngoài thẩm quyền của họ, và tới lúc có tranh cãi thì chữ ký đó không bảo vệ được ai.
Một yêu cầu coi như viết xong khi nó có đủ tác nhân, hành động và điều kiện đo được, đồng thời chỉ trả lời đúng một câu hỏi chứ không gói nhiều việc.
Tình huống thứ ba ở trên, sau khi viết lại, trở thành thế này:
Thủ kho không xác nhận được phiếu xuất kho cho khách hàng có công nợ quá hạn vượt ngưỡng do kế toán trưởng quy định, trừ khi có phê duyệt của giám đốc kinh doanh trên chính phiếu đó.
Tác nhân là thủ kho, hành động là xác nhận phiếu xuất, điều kiện là ngưỡng công nợ cùng một đường thoát có người chịu trách nhiệm, và một người chưa dự buổi khảo sát nào vẫn dựng được kịch bản kiểm thử từ dòng này.
Phép thử nhanh nhất cho mọi dòng bạn viết ra là hỏi làm sao biết là đã đạt. Không trả lời được bằng một thao tác kiểm tra cụ thể thì dòng đó chưa viết xong, và đừng tự an ủi rằng lúc làm sẽ rõ hơn, bởi lúc làm thì người đọc dòng đó không phải bạn.
Đặc biệt, có một câu phải hỏi ngay khi khách dùng chữ quản lý: khách muốn lưu lại để tra cứu, hay muốn hệ thống ràng buộc để không làm sai được, hai mức đó cách nhau rất xa về khối lượng, và bài về Fit-Gap đã nói kỹ vì sao phải hỏi trước khi viết giải pháp.
Lưu ý rằng, không phải yêu cầu nào cũng gắn được một con số, đặc biệt là các yêu cầu về tốc độ, về giao diện hay về mức độ dễ dùng. Với nhóm đó, cách thay thế là lấy một mốc so sánh với thứ đang có, chẳng hạn thao tác tạo phiếu xuất trên hệ thống mới không được nhiều bước hơn cách họ đang làm; mốc này không phải con số nhưng vẫn đối chiếu được.
Kiểu thứ nhất là mong muốn đội lốt giải pháp, dấu hiệu mà bài về câu hỏi tại sao đã nêu rất rõ; ở đây chỉ cần một ví dụ để thấy nó trông thế nào trong lúc ghi nhận. Khách nói cho em thêm một ô ghi chú ở phiếu xuất kho để tụi em ghi biển số xe tải, nghe rất cụ thể, nhưng hỏi thêm một câu về việc ghi xong rồi dùng làm gì thì hóa ra họ cần đối chiếu với nhà xe cuối tháng xem chuyến nào đã chở những đơn nào. Đó là bài toán theo dõi chuyến giao hàng chứ không phải một ô ghi chú, và làm đúng được yêu cầu thì cuối tháng họ vẫn phải gõ lại từ đầu vào Excel.
Kiểu thứ hai là phàn nàn đội lốt yêu cầu. Câu kho lúc nào cũng thiếu người nên làm gì cũng chậm là một lời than có thật, nhưng nó không phải yêu cầu, và đưa nó vào danh sách thì tới buổi nghiệm thu sẽ không có cách nào kết luận là đã đáp ứng hay chưa. Cách xử lý là giữ nó ở phần hiện trạng, rồi đi tìm xem trong cái chậm đó có bao nhiêu phần đến từ những thao tác mà hệ thống gánh được. Nếu câu trả lời là gần như không có phần nào, hãy nói thẳng điều đó ngay ở giai đoạn khảo sát, thay vì để khách chờ tới lúc go-live mới thấy.
Kiểu thứ ba là thói quen đội lốt quy định, và đây là kiểu tốn tiền nhất. Khách nói hàng nhập kho phải có chữ ký của ba người, bạn ghi lại rồi thiết kế một luồng duyệt ba bước, tới lúc chạy thật mới phát hiện không có văn bản nào của doanh nghiệp quy định như vậy, mà đó là cách một người tự đặt ra từ mấy năm trước để tự bảo vệ mình sau một lần bị quy trách nhiệm. Ở những doanh nghiệp chưa từng có hệ thống quản lý thì chuyện mỗi người một biểu mẫu, mỗi người một quy tắc là rất phổ biến. Do đó với mọi câu bắt đầu bằng chữ phải, việc tiếp theo của bạn là hỏi quy định đó nằm ở văn bản nào và ai có thẩm quyền xác nhận nó.
Viết lại xong thì phải mang biên bản đó quay về chỗ người đã nói câu ban đầu, và cách mang về quyết định bạn nhận được xác nhận thật hay xác nhận cho xong.
Đừng đọc cho họ nghe dòng yêu cầu theo đúng cấu trúc bạn vừa viết. Người vận hành không phản ứng với câu chữ trong tài liệu, họ phản ứng với tình huống. Cách hiệu quả hơn hẳn là dựng lại một buổi sáng bình thường của họ: giả sử sáng mai xe hàng về mà thiếu hai thùng so với phiếu, thì theo cái em vừa ghi nhận, anh sẽ làm gì trước và hệ thống sẽ chặn ở chỗ nào. Nghe tới đó thì họ sẽ tự sửa lại cho bạn, và những chỗ họ sửa chính là những chỗ bạn hiểu sai.
Cuối cùng là chuyện thẩm quyền, bởi người kể tình huống cho bạn và người có quyền xác nhận quy tắc thường không phải một người, và một yêu cầu chỉ được coi là đã chốt khi người có thẩm quyền gật đầu. Trong trường hợp hai người đó nói khác nhau, đừng tự chọn một bên, hãy ghi lại cả hai phiên bản rồi chuyển cho người phụ trách dự án phía khách để họ chốt nội bộ, bởi bạn không có quyền quyết định quy tắc vận hành của doanh nghiệp họ.
Bảy việc này mất vài phút cho mỗi dòng khi bạn đã quen, và là phần rẻ nhất trong cả chuỗi, bởi mọi thứ đứng sau nó đều xây trên đúng những dòng này.
Khi đã có trong tay một tập những dòng như vậy, câu hỏi tiếp theo không còn là khách muốn gì nữa, mà là mỗi dòng sẽ nằm ở tài liệu nào và được viết chi tiết tới mức nào.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận