"Hệ thống phải nhanh" - câu đó không nói gì, và không ai phát hiện ra suốt tám tháng
Một tính từ trong bản cam kết không mô tả mức chất lượng. Nó hoãn việc xác định mức ấy lại, và việc bị hoãn thì chờ tới bàn nghiệm thu.
Bàn nghiệm thu, hai câu nói cách nhau chưa tới một phút.
Phía đơn vị: “Hệ thống chậm quá, cán bộ không dùng được, chúng tôi chưa ký được.”
Phía nhà thầu: “Hệ thống đáp ứng đúng yêu cầu đã ký, chúng tôi có biên bản kiểm thử.”
Cả hai đều đang chỉ vào cùng một dòng, trang mười bảy của bản đặc tả, mục yêu cầu phi chức năng:
Hệ thống phải có tốc độ đáp ứng nhanh, đảm bảo trải nghiệm người dùng.
Câu đó đã đi qua ba vòng rà soát. Đơn vị đọc, gật. Đơn vị thẩm định đọc, gật. Hai bên ký. Trong tám tháng làm dự án, không một ai hỏi lại nó một câu nào.
Và nó không hề trông có vấn đề. Nó có chủ ngữ, có động từ tình thái, có một thuộc tính chất lượng, có cả mệnh đề mục đích. Nó đọc giống hệt hai mươi câu yêu cầu nằm quanh nó - những câu hoàn toàn kiểm được. Nó có đúng hình dạng của một yêu cầu.
Bài trước nói về một con số mà không ai còn truy được cách đo. Bài này thì ngược lại: chẳng có con số nào cả, và điều đó cũng đi qua mọi vòng ký duyệt hệt như vậy.
Cái câu ấy không thất bại trong việc mô tả chất lượng. Nó làm một việc khác, âm thầm hơn: nó hoãn một quyết định lại. Quyết định “thế nào là đủ nhanh” không biến mất - nó chỉ được đẩy sang một thời điểm khác, là bàn nghiệm thu. Mà ở bàn nghiệm thu thì nó không còn được quyết bằng phân tích nữa. Nó được quyết bằng việc ai đang cần chữ ký của ai hơn.
Ở dự án ấy, bên yếu thế là nhà thầu, vì tiền chưa về. Bọn mình đã làm lại tầng truy vấn trong sáu tuần, không tính thêm một đồng. Mình cũng từng gặp chiều ngược lại: hợp đồng đã thanh toán theo tiến độ, đơn vị không có căn cứ nào để bắt bẻ, và cái “chậm” ấy ở lại với họ suốt vòng đời hệ thống. Một câu không có ngưỡng thì không trung lập. Nó đẩy việc quyết sang một thời điểm mà kết quả dễ bị chi phối bởi tương quan hai bên và bởi điều khoản hợp đồng hơn nhiều so với lúc còn đang cùng ngồi thiết kế yêu cầu.
Nên câu hỏi đúng không phải “yêu cầu này viết đã rõ chưa”. Là: nếu bây giờ có tranh chấp, câu này phân xử được không.
Đến đây thì cách sửa hiện ra rất rõ, và nó là cách gần như ai cũng nghĩ tới: gắn một con số vào.
Dự án sau, Thảo làm đúng vậy. Đặc tả viết: thời gian phản hồi trung bình dưới 2 giây.
Đến bàn nghiệm thu, vẫn cãi nhau. Chỉ khác là lần này cãi nhau tinh vi hơn.
Đo ở đâu - trên máy chủ hay trên máy cán bộ ngồi ở phường? Đo trên mạng nào? Trung bình của cái gì, của tất cả các màn hình hay của màn hình tra cứu mà người ta dùng cả ngày? Trung bình trong khoảng thời gian nào - cả ngày, hay đúng chín giờ sáng lúc bốn mươi người cùng đăng nhập? Và trung bình có che mất chuyện cứ hai mươi lần lại có một lần mất tám giây không?
Mỗi lựa chọn ấy đều cho ra một kết quả đo hợp lệ. Chúng chỉ không đo cùng một thứ.
Con số không đủ để thành một ngưỡng, vì bản thân con số cũng cần một cách đo - đúng cái chuyện của bài trước. Muốn “2 giây” phân xử được thì phải kèm: đo cái gì, đo bằng cách nào, ở đâu, lúc nào, và ngưỡng đặt ở đâu trên cái thang đó.
Chuyện này có người nói trước mình từ lâu và nói kỹ hơn nhiều. Tom Gilb, người viết về lượng hoá các thuộc tính chất lượng từ rất sớm, xây một ngôn ngữ đặc tả gọi là Planguage với đúng một nước đi trung tâm: mọi yêu cầu chất lượng phải mang theo hai thứ mà thực tế chúng hiếm khi mang - một thang đo và một cách đo. Thang đo không phải cái đơn vị suông: nó là một định nghĩa vận hành, nói rõ đang đo cái gì đã, rồi mới tới đơn vị. Cách đo là thủ tục thật để biết mình đang ở đâu trên thang ấy, và một thang có thể có nhiều cách đo. Rồi mới đặt các mốc lên: hiện ở đâu, dưới mức nào thì coi là hỏng, đang nhắm tới đâu. Bản đầy đủ nằm trong Competitive Engineering (2005).
Thảo bổ sung đủ cả thang đo và cách đo cho dự án tiếp theo. Đo trên máy trạm tại ba phường mẫu, giờ cao điểm, màn hình tra cứu, phân vị 95 dưới 3 giây, đo bằng bộ kịch bản đã thống nhất trước.
Nghiệm thu qua. Ký. Thanh toán.
Sáu tháng sau mình xuống một phường. Cán bộ tiếp dân nói: “Máy vẫn chậm.”
Mình mở đồng hồ ra đo. Hai giây tám. Đạt.
Xin phép ngồi nhìn thêm nửa buổi thì hiểu. Chị ấy tiếp dân, người dân đứng trước mặt, chị hỏi một câu rồi bấm tra cứu. Trong hai giây tám ấy, giữa hai người có một khoảng im lặng. Ngày làm chín mươi lượt là chín mươi khoảng im lặng, mỗi khoảng chị phải lấp bằng một câu xã giao. Cái mệt không nằm ở hai giây tám. Nằm ở chỗ chị không thể vừa chờ vừa nói chuyện tiếp được.
Con số 3 giây kia, Thảo lấy từ một bài viết về trải nghiệm người dùng. Con số ấy có thang đo, có cách đo, kiểm được, và không ai ở phường từng nhìn thấy nó trước khi nó thành điều khoản nghiệm thu.
Đây là chỗ cần đóng đinh. Một ngưỡng phân xử được cần ba phần, không phải hai:
Một con số. Một cách đo mà cả hai bên chịu. Và một căn cứ cho biết vì sao chính con số ấy là đủ tốt đối với công việc thật - căn cứ đó phải đi qua người sẽ chịu hậu quả nếu không đạt.
Để ý là mình không nói người chịu hậu quả phải là người chốt con số. Chị cán bộ ở phường không ký nghiệm thu, và cũng không nên phải cân đối giữa tốc độ với chi phí hạ tầng - đó là việc của người khác. Chuyện chị biết thì người khác cũng có thể biết - một anh tổ trưởng lâu năm, một đồng nghiệp ngồi cùng quầy, hoặc chính bạn nếu chịu ngồi nhìn một buổi. Cái làm chị khác không phải độc quyền thông tin. Là chị đang trực tiếp sống với hậu quả, nên cái chị mang vào cuộc quyết định là một ranh giới thực tế: đến mức nào thì công việc bắt đầu hỏng. Người có thẩm quyền cầm ranh giới đó, đặt cạnh chi phí và những ràng buộc mà chị không nhìn thấy, rồi mới chốt.
Người biết công việc hỏng ở đâu và người có quyền quyết mức chấp nhận thường không phải một người. Gộp hai vai ấy làm một là hỏng theo hai kiểu ngược nhau: hoặc bạn để một người không nắm ràng buộc tự đặt ngưỡng, hoặc bạn để một người không sống với hệ thống tự đặt ngưỡng. Ở bài đầu tiên của loạt này, bốn ô đã tách sẵn “ai quyết” và “biết gì thì dám chốt” thành hai ô riêng. Đây chính là chỗ việc tách ấy được trả tiền.
Còn câu hỏi để đi lấy nó thì không phải “anh chị muốn nhanh cỡ nào” - hỏi vậy thì rất dễ nhận lại “càng nhanh càng tốt”, và câu đó cũng vô dụng y như “phải nhanh”. Câu chạy được là: “Chậm tới mức nào thì công việc của chị bắt đầu hỏng?”
Chị cán bộ ấy trả lời ngay, không cần nghĩ: “Quá một giây là em phải nói chuyện đỡ với người ta, mà nói mãi cũng hết chuyện.”
Một giây. Không phải ba. Và con số ấy không tra được từ bài viết nào, vì nó không nói về hệ thống - nó nói về cái khoảng im lặng giữa hai người đang ngồi đối diện nhau.
Nhưng một giây cũng chưa phải yêu cầu của cả hệ thống, và mình sẽ không cho nó thành điều khoản nghiệm thu ngay sáng hôm sau. Đó là một chỗ, một loại việc, một người. Cái vừa có không phải một ngưỡng, mà là lần đầu tiên bọn mình cầm trong tay một con số sinh ra từ hậu quả thật thay vì từ một bài viết. Từ đó mới đủ cơ sở để đi hỏi thêm vài phường nữa, đặt cạnh chi phí, rồi mang tới người có thẩm quyền chốt.
Nói thật với bạn một chuyện, để bạn đừng tưởng lúc nào cũng lấy được: có những ngưỡng mà người chịu hậu quả cũng không biết, vì họ chưa từng sống qua tình huống đó. Hỏi một đơn vị chưa từng có hệ thống rằng bao nhiêu người dùng đồng thời thì chấp nhận được, bạn sẽ nhận một con số họ vừa nghĩ ra trong ba giây. Những ca ấy thì tốt nhất là nói thẳng ra rằng con số này là phỏng đoán, ghi vào biên bản như một phỏng đoán, và hẹn đo lại sau ba tháng chạy thật - chứ đừng để nó thành điều khoản nghiệm thu với vẻ mặt của một sự thật.
Mà đừng làm chuyện này với mọi yêu cầu. Nếu đặc tả của bạn có bốn mươi thuộc tính chất lượng và bạn đòi đủ ba phần cho từng cái, thì chính khâu đặc tả trở thành chỗ tắc - và những con số bạn nặn ra cho ba mươi cái không ai quan tâm sẽ là những con số bịa, chỉ khác là giờ chúng nằm trong hợp đồng.
Thang đo vẫn là thang cũ. Một tính từ trong tài liệu nội bộ, sai thì sửa: cứ để nguyên tính từ. Một tính từ sắp thành điều khoản nghiệm thu, thành căn cứ thanh toán, thành cái mà tám tháng nữa hai bên sẽ chỉ tay vào: phải có đủ ba phần trước khi ký. Câu để tự hỏi rất gọn - tám tháng nữa, hai bên cầm câu này ra thì phân xử được không?
Và cái nguyên lý đằng sau chẳng dính gì tới tốc độ phần mềm. Một tính từ trong một bản cam kết không mô tả một mức chất lượng. Nó hoãn việc xác định mức ấy lại, và việc bị hoãn thì không tự tiêu đi - nó chờ tới lúc buộc phải quyết, mà lúc đó thì cái quyết định ấy chịu ảnh hưởng của thế và của hợp đồng nhiều hơn hẳn so với lúc hai bên còn đang cùng thiết kế. Câu đó không phát tín hiệu gì, vì nó có đủ hình dạng của một cam kết. Thứ nó thiếu không nhìn thấy được bằng cách đọc nó.
Một việc bạn thử được trong hai mươi phút. Mở đặc tả đang làm, tìm mục yêu cầu phi chức năng, lấy một dòng bất kỳ. Trả lời ba câu: bao nhiêu thì gọi là đạt, đo bằng cách nào, và vì sao chính con số đó là đủ tốt cho công việc thật.
Điền không đủ ba ô thì điều đó chưa chứng minh dự án của bạn sắp có tranh chấp. Rất nhiều dòng như vậy chẳng bao giờ bị ai mang ra cãi - vì hệ thống chạy đủ tốt, vì hai bên tin nhau, vì không ai để ý. Nó cũng chưa chứng minh yêu cầu đó viết kém: có những thuộc tính mà cả ngành vẫn đang chật vật tìm cách đo cho thực tế. Cái duy nhất bạn vừa biết là dòng ấy hiện chưa phân xử được gì. Còn chuyện đó có quan trọng hay không thì phụ thuộc vào việc nó sắp được dùng để làm gì.
Thảo, sau buổi ở phường về, nhắn cho mình:
Tài nguyên bài 6
Cheat-sheet bài 6 Toàn bộ cơ chế trên một trang - in ra hoặc lưu về máy được.Vị trí trong Bản Nén Vô Hình
Bài này trả lời
- Nghiệm thu bế tắc vì một dòng yêu cầu mà hai bên đọc ra hai kết luận trái nhau
- Đo lại thì đạt đúng ngưỡng đã cam kết, người dùng vẫn nói máy chậm