Mười bốn lần đổi yêu cầu. Không lần nào có ai đổi ý.

Đến cuối tháng Chín, phân hệ đồng bộ dữ liệu có mười bốn phiếu yêu cầu thay đổi.

Con số đó tự nó đã đủ để mọi cuộc họp đi theo một hướng. Trong biên bản giao ban có câu “đề nghị đơn vị thống nhất yêu cầu trước khi chuyển sang phát triển”. Bên mình thì bắt đầu nói với nhau rằng đơn vị không biết mình muốn gì.

Nhưng nếu ngồi đọc lần lượt mười bốn cái phiếu ấy, sẽ thấy một chuyện lạ: không phiếu nào là do ai đổi ý cả.

Cái làm mình nhớ ca này là vì Thảo đã làm mọi thứ đúng.

Đầu dự án, trước khi mở file, nó đã hỏi ngược lên. Bốn dòng trên đầu tài liệu, đủ cả bốn: người quyết là giám đốc trung tâm; quyết chuyện đồng bộ dữ liệu hộ tịch từ hệ thống của đơn vị A về kho dùng chung; trước cuộc họp Hội đồng tháng Tư; và ô cuối, ô khó nhất, nó cũng lấy được - đồng bộ mỗi ngày một lần là đủ, vì bên A cập nhật theo tuần.

Câu cuối ấy không phải Thảo tự nghĩ. Nó ngồi với anh phụ trách công nghệ thông tin bên A, hỏi đúng câu phải hỏi, và anh trả lời đúng như vậy. Có ghi vào biên bản. Anh đọc lại, ký.

Không có gì bị nén ở đây. Không có chữ nào hai nghĩa. Không có quy trình trên giấy nào khác quy trình đang chạy. Không có con số nào mất cách đo. Cái tiền đề - bên A cập nhật theo tuần - được viết ra đầy đủ, đúng người nói, đúng lúc, có chữ ký.

Tháng Bảy, đơn vị A đưa vào vận hành một cổng tiếp nhận mới. Từ đó dữ liệu bên họ cập nhật liên tục trong ngày.

Không ai báo cho dự án bên mình. Mà cũng không có lý do gì để báo: từ phía A, đó là một cải tiến trong nội bộ họ, chẳng liên quan gì tới một phân hệ đồng bộ của một đơn vị khác. Anh phụ trách công nghệ thông tin bên A, người đã ký vào cái biên bản kia, hôm ấy đang bận chuyện của mình.

Câu “đồng bộ mỗi ngày một lần là đủ” không sai đi. Nó hết hạn. Và không có một khoảnh khắc nào để chỉ vào mà nói rằng đó là lúc nó hết hạn.

Năm bài đầu tập này đều nói về thông tin rụng trên đường đi từ chỗ này sang chỗ kia: đi xuống thì rụng quyết định, đi ngang thì rụng hệ quy chiếu, từ văn bản sang thực tế thì rụng lớp bù đắp, từ nhu cầu sang giải pháp thì rụng bài toán, từ con số sang tài liệu thì rụng cách đo. Bài thứ sáu thì nói về một thứ chưa bao giờ có mặt để mà rụng: cái ngưỡng không ai đặt ra.

Lần này không có gì rụng cả. Câu trả lời còn nguyên, tiền đề của nó cũng còn nguyên, và cả hai đều nằm đúng chỗ trong biên bản. Thứ đổi là cái thế giới mà câu trả lời ấy từng đúng ở trong đó.

Một câu trả lời đúng thì đúng đối với một trạng thái nào đó của thế giới. Thảo đã ghi được cả trạng thái ấy - đó là chỗ nó làm tốt hơn hầu hết tài liệu mình từng đọc. Nhưng ngay cả khi bạn ghi được tiền đề, tài liệu vẫn không biết lúc nào tiền đề ấy thôi đúng. Trang giấy không có cách nào tự phát hiện rằng một mệnh đề trên nó vừa chết.

Đây là chỗ mình phải nói thẳng một chuyện, vì nếu không thì bài này sẽ dạy sai. Cái phản xạ mà sáu bài trước xây lên đã chạy đúng ở ca này. Và nó không cứu được gì cả.

Thảo giải nén đúng một tầng. Nó lấy được một tiền đề rất dễ bị bỏ qua. Nếu nó không hỏi câu ấy, dự án đã hỏng theo một kiểu tệ hơn nhiều - sẽ không ai biết vì sao chọn một ngày một lần, và tới lúc vỡ thì cũng chẳng có gì để lần ngược. Việc nó làm đúng đã biến một thất bại mù thành một thất bại truy được.

Nhưng nó không ngăn được thất bại. Bốn ô cho bạn một quyết định tốt. Chúng không cho bạn một quyết định giữ được độ tốt qua thời gian. Đó là hai bài toán khác nhau, và bài toán thứ hai không giải được bằng một câu hỏi sắc hơn ở thời điểm bắt đầu.

Giờ đến cách sửa mà mình đoán bạn đang nghĩ tới, vì đó cũng là cách bên mình đã đề xuất trong biên bản: siết quy trình duyệt thay đổi. Có mốc gốc, có phiếu, có ai đó ký vào mỗi lần đổi.

Nó không chạm được vào ca này.

Quy trình duyệt thay đổi bắt được những thay đổi có người đề nghị. Nó là một cái cổng, và cổng thì chỉ chặn được thứ đi qua cổng. Còn chuyện vừa xảy ra không sinh ra đề nghị nào hết. Tiền đề chết ở đơn vị A, trong một cuộc họp mà bên mình không có mặt, và ở đó nó không mang hình dạng của một thay đổi - nó mang hình dạng của một cải tiến nội bộ. Cái phiếu yêu cầu thay đổi chỉ xuất hiện sáu tuần sau, khi có người phát hiện số liệu trên kho dùng chung lệch với số liệu bên A. Đến lúc ấy nó đã đội lốt một đề nghị của phía đơn vị, và bị đếm vào con số mười bốn.

Ở đây mình phải nói rõ một chuyện, kẻo bài này tự mâu thuẫn với chính nó.

Cách sửa mà ai cũng nghĩ tới tiếp theo là ghi tiền đề cạnh quyết định, kèm tên người và ngày. Không phải “đồng bộ ngày một lần”, mà: “đồng bộ ngày một lần - vì bên A cập nhật theo tuần (anh B, CNTT đơn vị A, 12/3).”

Nhưng Thảo đã làm gần đúng như vậy rồi. Tiền đề có, người nói có, ngày có, chữ ký có. Nếu cách sửa là ghi tiền đề thì bài này chẳng dạy được gì - nó chỉ khuyên bạn làm lại đúng cái vừa thất bại.

Chỗ ghi tiền đề làm được, và nó không nhỏ, là biến việc hết hạn thành thứ kiểm được. Có một mệnh đề cụ thể gắn với một người cụ thể, thì bạn đi hỏi lại được trong ba phút. Chỉ có một con số một-ngày-một-lần trơ trọi thì chẳng có câu hỏi nào để mà hỏi.

Nhưng kiểm được và đã kiểm là hai chuyện khác nhau, và khoảng cách giữa chúng chính là chỗ dự án hỏng. Ghi tiền đề trả lời câu “kiểm lại thế nào”. Nó không trả lời câu “làm sao biết đã tới lúc phải kiểm lại”. Câu thứ hai mới là câu ca này hỏi, và nó không cần một câu hỏi thông minh hơn để trả lời. Nó cần một nhịp quay lại.

Chuyện này không phải mình tự nghĩ ra. Trong khảo sát quốc tế về các vấn đề khâu làm yêu cầu - dữ liệu 2014–2015, 228 tổ chức, mười quốc gia - mục “mục tiêu trôi” đứng thứ ba về tần suất, một phần ba số tổ chức nêu. Nhưng trong năm vấn đề bị nêu nhiều nhất, nó là cái dẫn tới thất bại dự án nhiều nhất: trong số các tổ chức nêu nó, hơn một nửa nói nó đã khiến dự án của họ hỏng. Không phải vấn đề phổ biến nhất, nhưng trong nhóm đầu bảng thì là cái đắt nhất.

Có một chi tiết nữa trong đúng bộ dữ liệu ấy đáng đọc kỹ. Khi được hỏi nguyên nhân, các tổ chức làm theo mô hình kế hoạch nêu ra, trong số những nguyên nhân hàng đầu, là thiếu quản lý thay đổi ở phía khách hàng. Tức là chính cái câu mà bên mình đã viết vào biên bản giao ban, và chính cái câu mà bài này đang tháo ra.

Giờ mình kể lại chuyện đó ở chỗ nó gây thiệt hại nhiều hơn cả phần kỹ thuật.

Mười bốn cái phiếu ấy, đọc riêng từng cái thì cái nào cũng hợp lý. Đọc gộp lại thành một con số thì nó kể một câu chuyện khác hẳn: phía đơn vị không dứt khoát. Và câu chuyện ấy đi vào biên bản, đi vào báo cáo tiến độ, đi vào cách hai bên nhìn nhau trong sáu tháng còn lại.

Không ai bịa. Mười bốn là mười bốn. Chỉ có điều một con số đếm số lần thay đổi thì không phân biệt được thay đổi vì có người đổi ý với thay đổi vì thế giới đã đổi. Nó gộp cả hai vào một ô, rồi cái ô ấy có tên là “khách hàng hay đổi yêu cầu”.

Hai triệu chứng. Một cái là phân hệ làm sai vì một tiền đề đã chết, một cái là quan hệ hai bên xấu đi vì một con số đếm. Nhưng cùng một chỗ hỏng: cả hai đều đến từ việc chúng ta ghi lại câu trả lời mà không ghi lại hạn dùng của nó - nên đến lúc câu trả lời hết hạn, không có chỗ nào để quy trách nhiệm ngoài con người.

Mà đừng đi rà lại mọi tiền đề mỗi tháng. Làm vậy thì bạn không còn thời gian làm gì khác, và phần lớn tiền đề sẽ vẫn nguyên như cũ.

Nhịp ấy áp cho tiền đề nào thì thang đo là tiền đề đó thuộc về ai. Những gì phụ thuộc vào chính đội bạn thì bạn sẽ nghe thấy khi nó đổi - bạn ngồi ngay đó. Những gì phụ thuộc vào một đơn vị khác, một nhà cung cấp khác, một quy định của cấp trên thì đổi trong im lặng, vì với họ chuyện đó chẳng liên quan gì tới bạn. Và một con số nữa đáng để ý: khoảng cách từ lúc chốt tới lúc chạy thật. Chốt tháng Ba, chạy tháng Mười một thì có tám tháng cho các tiền đề chết. Chốt xong chạy trong ba tuần thì gần như không cần lo.

Và cái nguyên lý đằng sau chẳng dính gì tới đồng bộ dữ liệu. Mọi câu trả lời đều đúng đối với một trạng thái nào đó của thế giới, nhưng khi được ghi ra thành chữ thì nó rụng mất phần “đối với trạng thái nào”. Tài liệu giữ được kết luận và không giữ được điều kiện. Và vì không có gì trong tài liệu ghi hạn dùng, nên lúc nó hết hạn cũng không có tín hiệu nào - chỉ có một loạt sự cố rời rạc, mỗi cái trông như một sai sót của ai đó.

Một việc bạn thử được trong mười lăm phút. Lấy một yêu cầu đã chốt trên hai tháng trước, loại có con số hoặc có lựa chọn giữa hai phương án. Tìm xem lý do khiến nó được chốt như vậy nằm ở đâu - trong biên bản, trong chat, hay chỉ trong trí nhớ ai đó. Rồi hỏi một câu: cái lý do ấy bây giờ còn đúng không.

Nếu không tìm ra lý do, điều đó chưa chứng minh yêu cầu ấy giờ đã sai. Rất có thể nó vẫn đúng, và phần lớn thời gian là vậy. Nó cũng chưa chứng minh hồ sơ của bạn làm ẩu - ghi lý do cạnh quyết định là chuyện gần như không ai làm. Cái duy nhất nó cho biết là: với yêu cầu đó, bạn hiện không có mệnh đề nào để đi hỏi lại - và không có mệnh đề thì cũng không có câu hỏi.

Thảo, sau khi đọc hết mười bốn cái phiếu, nhắn cho mình: