"Em muốn có nút export" - và bài toán biến mất ngay trong câu đó

Buổi grooming, phút thứ mười.

Yêu cầu từ đơn vị: thêm nút xuất toàn bộ danh sách hồ sơ ra Excel, đủ bốn mươi trường.

Bạn dev nói luôn: bảng hiện hơn hai triệu bản ghi, xuất đủ trường thì timeout, phải làm hàng đợi và gửi file qua email, mà bốn mươi trường thì có cả thông tin cá nhân nên còn phải xét quyền. “Không khả thi trong sprint này.”

Không ai cãi. Vì bạn ấy nói đúng.

Thư ký ghi vào biên bản: đề nghị chưa khả thi, chuyển khảo sát bổ sung. Phòng họp sang mục tiếp theo. Cả buổi mất bốn phút cho việc đó.

Ba tháng sau, mình ngồi với chị Nhung - người đã đề nghị cái nút ấy. Không phải để bàn về nút export. Chỉ là hỏi cuối tháng chị làm những gì.

Chị kể: cuối tháng phải rà xem hồ sơ nào đã quá hạn mà chưa có kết quả, để còn nhắc các bộ phận. Trên phần mềm không lọc được cái đó. Nên chị xuất danh sách ra Excel, mở lên, lọc hai cột - ngày tiếp nhận và trạng thái - rồi đếm.

Hai cột. Chị xin bốn mươi trường để dùng hai cột.

Và cái việc chị cần - lọc ra những hồ sơ quá hạn chưa có kết quả, đếm, xuất ra một danh sách ngắn - bên mình làm trong nửa ngày. Không hàng đợi, không email, không đụng tới thông tin cá nhân nào ngoài mã hồ sơ và tên bộ phận.

Ba bài trước đều nói về việc thông tin rụng trên đường đi: rụng khi đi xuống, rụng khi đi ngang, rụng vì bản mô tả không phải bản đang chạy. Lần này thì rụng ở một chỗ mà bạn không canh được, vì nó xảy ra trước khi bạn nghe thấy câu nói.

Chị Nhung không hề nén một câu của ai. Chị nén bài toán của chính chị. Chị có một nhu cầu rất rõ - biết hồ sơ nào quá hạn - và cái đến tai bọn mình đã là một bản dịch của nhu cầu ấy sang thứ chị biết là làm được. Cái không đi cùng bản dịch là phần vì sao, và bọn mình chỉ moi được nó ra ba tháng sau, khi ngồi hỏi chị làm gì vào cuối tháng.

Và đây là chỗ cần đóng đinh. Nếu trong tay bạn chỉ có câu giải pháp, bạn đánh giá được nó có làm được hay không. Bạn chưa đánh giá được nó có đáng làm hay không. Buổi grooming hôm ấy đã trả lời rất tốt câu thứ nhất. Câu thứ hai thì không ai hỏi, vì muốn hỏi thì phải biết nó đang giải quyết chuyện gì - mà chuyện đó đã ở lại nhà rồi.

Ở bài đầu mình ví cái task như một tờ chỉ định xét nghiệm. Lần này thì bệnh nhân tự kê đơn mang tới. Và với một tờ đơn thuốc thì bạn chỉ có thể cấp hoặc từ chối cấp - muốn kê thuốc khác thì phải biết bệnh, mà bệnh thì tờ đơn không ghi.

Cái câu từ chối hôm ấy đúng về kỹ thuật, và nó đã chôn theo một bài toán mà chưa ai trong phòng từng nghe.

Giờ mình phải chặn trước một câu, vì mình đã nghe nó ở gần như mọi dự án: “Người dùng không biết mình muốn gì.”

Chị Nhung biết rất rõ chị muốn gì. Chị muốn biết hồ sơ nào quá hạn. Chị biết chuyện đó rõ hơn tất cả mọi người trong buổi grooming hôm ấy cộng lại.

Thứ chị không biết - và không có lý do gì để biết - là cái gì rẻ và cái gì đắt ở phía bên kia. Chị không biết một cái nút export bốn mươi trường thì tốn gì, cũng không biết một bộ lọc theo hạn thì tốn gì. Còn Excel thì chị đã dùng hai mươi năm.

Vì sao chị chọn nói ra thành cái nút export thì mình không biết, và hôm ấy bọn mình cũng chưa từng hỏi. Có một lý do rất hay gặp: người đưa yêu cầu cố dịch nhu cầu sang một thứ họ tin là hệ thống làm được, tức là đang cố xin một thứ khả thi. Nhưng cũng có thể chị đơn giản nghĩ không còn cách nào khác, hoặc từng thấy hệ thống nào đó có nút ấy, hoặc từng bị nhắc là phải xin cho cụ thể. Bốn khả năng, và bọn mình chưa loại được cái nào.

Điều không phụ thuộc vào lý do là: dù vì lý do nào, cái đến tai bọn mình cũng đã là bản dịch.

Cho nên câu “người dùng không biết mình muốn gì” không chỉ sai. Nó còn là một bản nén nữa, lần này của phía làm phần mềm: nó gom một khoảng chênh lệch hiểu biết thành một câu kết, và câu kết thì làm cuộc suy nghĩ dừng lại.

Nói thật với bạn một chuyện, để bạn đừng tưởng chỗ này lúc nào cũng gỡ ra được: đôi khi bản gốc không còn tồn tại nữa. Có những yêu cầu đã đi qua bốn năm người, mỗi người dịch một lần theo cái họ biết, và đến lúc bạn hỏi thì người cuối cùng thật lòng tin rằng cái nút export chính là nhu cầu. Không ai nói dối, chỉ là bản dịch đã thay chỗ bản gốc trong trí nhớ của mọi người. Những ca đó thì có khi hỏi tiếp cũng không còn ai lấy lại được bản đầu.

Đến đây thì mình đoán bạn đang cau mày: chẳng lẽ mỗi lần ai xin gì cũng phải truy ngược lại? Nghe vừa mệt vừa phiền, mà người ta chỉ muốn có cái nút thôi.

Không cần truy ai cả. Dấu hiệu nằm ở hình dạng của câu, không nằm ở thái độ người nói.

Một yêu cầu có dạng danh từ của hệ thống - thêm nút, thêm cột, cho phép sửa, mở quyền - là một giải pháp đã được dịch xong. Một yêu cầu có dạng tình huống - cuối tháng em không biết hồ sơ nào quá hạn, mỗi lần khách gọi hỏi em phải mở ba màn hình - là một bài toán còn nguyên.

Bạn không cần tra vấn ai. Bạn chỉ cần để ý cái nào vừa đi vào phòng.

Nhưng hình dạng câu chỉ là dấu hiệu để hỏi tiếp, không phải bằng chứng rằng yêu cầu chưa được phân tích. “Thêm cột mã số thuế theo quy định mới” là câu dạng giải pháp, và rất có thể phần phân tích đã xong từ lâu ở chỗ khác. Ngược lại, “cuối tháng em không biết hồ sơ nào quá hạn” nghe như một bài toán nguyên vẹn, nhưng cũng có thể mới chỉ là triệu chứng của một chuyện khác nữa. Dấu hiệu cho bạn biết chỗ nào không tự đọc ra được, chứ không cho biết chỗ nào sai.

Và khi nó là loại thứ nhất, cái sửa cũng chỉ là một câu, hỏi ngay lúc đó: “Có cái nút đó rồi thì việc đầu tiên chị làm với nó là gì ạ?”

Câu này chạy được vì nó không bắt ai phải giải trình. Nó không hỏi “tại sao chị cần” - câu đó nghe như đang xét duyệt, và người bị xét duyệt thì sẽ đi bảo vệ cái nút thay vì kể về công việc. Câu kia thì chỉ mời người ta kể tiếp câu chuyện. Mà đoạn tiếp theo thường kéo bạn gần hơn về cái việc đang cần làm. Không phải lúc nào cũng tới nơi trong một bước - có khi câu trả lời là “chị gửi file đó cho anh A”, và bài toán thật đang nằm ở chỗ anh A.

Nếu chị Nhung được hỏi câu đó trong buổi grooming hôm ấy, chị đã trả lời: “Chị mở lên lọc hai cột xem cái nào quá hạn.” Bốn phút của buổi họp đó vẫn là bốn phút. Chỉ khác là bọn mình sẽ bước ra khỏi phòng với một bài toán nửa ngày, thay vì một dòng biên bản.

Giờ mình kể lại đúng chuyện đó, ở chiều ngược lại - và chiều này mới là chiều đắt hơn.

Một yêu cầu khác, cũng đơn vị đó: thêm một cột ghi chú vào màn hình danh sách. Lần này khả thi. Nửa ngày làm xong, UAT pass, nghiệm thu ký, có trong biên bản bàn giao.

Sáu tháng sau mình xem log: cột đó được dùng ba lần. Ba, không phải ba trăm.

Cái người ta cần không phải chỗ để ghi. Là chỗ để đánh dấu một hồ sơ cần quay lại xem hôm sau. Cột ghi chú cho họ chỗ ghi, nhưng hôm sau không có cách nào tìm lại những hồ sơ đã ghi - không lọc được, không sắp xếp được. Ghi xong thì mất hút. Nên sau ba lần, họ quay lại dùng giấy nhớ dán màn hình.

Hai triệu chứng. Một cái bị từ chối, một cái được chấp thuận. Trông như hai kết cục trái ngược hẳn nhau. Nhưng cùng một chỗ hỏng: bài toán chưa bao giờ bước vào phòng họp, nên cái được đem ra cân nhắc - dù để gật hay để lắc - chỉ là bản dịch.

Và cái được chấp thuận thì tệ hơn. Vì lần bị từ chối, ít nhất còn một dòng biên bản ghi lại rằng có ai đó đã hỏi. Còn lần được chấp thuận thì sinh ra một tờ nghiệm thu, một feature chạy được, một dòng trong báo cáo tiến độ. Nó tự chứng minh là thành công. Sáu tháng sau mới có người tình cờ mở log ra xem.

Chuyện này không phải mình tự nghĩ ra. Có một khảo sát quốc tế về các vấn đề trong khâu làm yêu cầu, dữ liệu đợt được trích nhiều nhất thu năm 2014–2015 ở 228 tổ chức thuộc mười quốc gia. Trong hai mươi mốt vấn đề được liệt kê, có một mục nói đúng chuyện này: người đưa yêu cầu gặp khó khăn trong việc tách nhu cầu khỏi giải pháp mà họ đã nghĩ sẵn. Khoảng một phần tư số tổ chức tham gia khảo sát kể tên nó trong nhóm vấn đề của mình.

Chỉ có điều để ý cách nó được đặt tên: vấn đề được gán cho phía người đưa yêu cầu. Mình thì không đọc như vậy. Một người mô tả nhu cầu bằng cái công cụ mà họ biết đang làm đúng thứ ai cũng làm - kể cả bạn, mỗi lần bạn nhắn cho bộ phận hạ tầng “cho em xin thêm RAM” thay vì “con service của em đang chết lúc cao điểm”.

Còn cái giá thì phải nói cho sòng phẳng. Hỏi thêm một câu trong buổi họp thì gần như không tốn gì. Nhưng làm gì đó với câu trả lời thì có tốn. Nó có nghĩa là mở lại một thứ vừa được chốt, đôi khi trước mặt đúng những người vừa gật. Và nếu bài toán thật hoá ra lớn hơn cái nút, bạn vừa biến một việc nửa ngày thành một cuộc thảo luận hai tuần.

Nên thang đo vẫn là thang cũ. Yêu cầu rẻ, làm nhanh, sai thì bỏ - cứ làm, đừng biến buổi họp thành buổi phân tích. Yêu cầu sắp bị từ chối, hoặc sắp ngốn vài tuần, hoặc sắp thành một điều khoản trong hợp đồng - hỏi câu đó trước khi gật hay lắc. Chỗ đắt nhất chính là ngay trước lúc ai đó nói “không khả thi”, vì sau câu ấy thì không còn ai quay lại nữa.

Và cái nguyên lý đằng sau chẳng dính gì tới nút với cột. Khi người ta phải xin một thứ từ một hệ thống, người ta xin bằng vốn từ của cái hệ thống mà họ đã biết. Việc dịch xảy ra trước khi bạn nghe thấy, nó xảy ra vì thiện chí, và bản gốc thì không đi cùng bản dịch. Chỗ này không có tín hiệu lỗi nào cả - vì một yêu cầu được nói dưới dạng giải pháp nghe rõ ràng hơn hẳn một yêu cầu nói dưới dạng tình huống. Nó nghe chuyên nghiệp hơn. Đó chính là lý do nó qua được mọi cửa.

Một việc bạn thử được trong mười lăm phút. Mở backlog, lấy mười mục gần nhất. Đếm xem bao nhiêu mục được viết dưới dạng một thứ hệ thống nên có, bao nhiêu mục được viết dưới dạng một tình huống ai đó đang gặp.

Con số đó không chứng minh gì về chất lượng backlog của bạn. Nhiều mục dạng giải pháp là hoàn toàn ổn - có team cố ý viết như vậy sau khi đã phân tích xong, và như thế là đúng quy ước của họ. Cái nó cho bạn biết chỉ là: với những mục đó, bạn không còn cách nào tự đọc ra bài toán nữa. Muốn biết thì phải đi hỏi. Còn có đáng hỏi hay không thì quay lại thang đo ở trên.

Thảo hôm ấy ngồi cùng mình với chị Nhung. Lúc đi ra nó bảo: