Về bản web

caltalys.dev

Tài liệu của mình đúng từng chữ. Và không ai dùng nó.

Một tài liệu đúng, đủ, nộp sớm nửa ngày - và không ai mở lại. Vì cái task bạn nhận là bản nén của một quyết định, và bản nén thì không báo lỗi.

Caltalys · 19/08/2026 · 14 phút đọc

Tuần trước Thảo nhắn cho mình lúc gần nửa đêm.

Thảo vừa nộp một tài liệu phân tích flow đăng ký tài khoản. Mười bốn bước. Ba luồng ngoại lệ. Sơ đồ vẽ sạch, đánh số, có bảng đối chiếu với màn hình hiện tại. Nộp sớm nửa ngày so với hạn.

PM đọc, thả tim, nhắn “ok em, cảm ơn”.

Rồi thôi.

Ba tuần sau, feature vẫn được build. Nhưng không ai mở lại cái tài liệu đó. Trong buổi grooming, PM tự mô tả flow bằng miệng, sai hai chỗ so với tài liệu, không ai đối chiếu. Thảo nhắn mình:

Thảo Anh ơi, em làm sai ở đâu vậy? Mà sao không ai nói gì hết?

Không ai nói gì, vì không có gì để nói. Không có comment. Không có request sửa. Không một dòng feedback tiêu cực nào.

Thảo không làm sai. Thảo làm đúng một đề bài đã hỏng từ trước khi tới tay nó. Và cái hỏng đó không phát ra tín hiệu lỗi.

Trước hết, thống nhất ba từ, vì ba từ này hay bị dùng lẫn nhau mà cả bài sẽ đứng trên chỗ chúng khác nhau.

Quyết định là thứ ai đó phải chọn, trước một thời điểm, và chịu hậu quả nếu chọn sai. “Có bỏ bước xác thực OTP ở màn 2 không” là một quyết định. Nó có chủ, có deadline, có cái giá.

Vùng mờ là cái chưa biết đang chặn quyết định đó. Không phải mọi cái chưa biết - chỉ cái mà nếu biết thì quyết được, không biết thì không quyết được. Phần còn lại là tò mò.

Task không phải quyết định, cũng không phải vùng mờ. Loại task bài này nói tới - task phân tích, thứ có output là một tài liệu, một báo cáo, một kết luận - là một chỉ định: một câu ngắn được viết ra để ai đó đi thu hẹp vùng mờ giúp người ra quyết định. Task kiểu “deploy bản 2.3” thì khác, nó không thu hẹp gì cả, và bài này không nói về loại đó.

Nói gọn: quyết định là ca mổ, vùng mờ là chỗ bác sĩ chưa nhìn thấy, task là tờ chỉ định xét nghiệm. Còn tài liệu bạn nộp là tấm phim chụp. Giữ lấy hình ảnh này, phần sau sống nhờ nó.

Bây giờ đi ngược lại, về trước cái lúc task tồn tại.

Nhịp một - có người phải quyết. Trước khi có task, thường có một người đang bị kẹt. PM phải chốt scope sprint. Sếp phải trả lời khách hàng thứ Sáu. Nhịp này gần như không bao giờ được nói ra thành lời với bạn.

Nhịp hai - quyết định vướng một vùng mờ. Người đó không quyết được vì thiếu một mảnh: không biết user rớt ở bước nào, không biết luật có bắt buộc không. Bác sĩ nghi tràn dịch màng phổi nhưng chưa nhìn thấy.

Nhịp ba - vùng mờ bị nén thành một câu. Đây là nhịp quan trọng nhất của cả bài, và là nhịp gần như không ai nhìn thấy lúc nó xảy ra.

Bản đầy đủ của cái đang chặn PM - nếu viết nó ra thành lời - đại loại thế này: “Thứ Sáu tao phải chốt có bỏ OTP không. Tao nghi user rớt chính ở màn đó nhưng không chắc. Bỏ mà sai thì fraud tăng, giữ thì conversion chết. Tao cần đủ bằng chứng để dám chốt.”

Cái được viết ra, sau khi nén, là thế này: “Em phân tích flow đăng ký giúp anh.”

Nhìn hai câu đó cạnh nhau mà xem. Giả thuyết rụng, deadline thật rụng, hậu quả rụng, và cái ngưỡng thế nào là đủ để dám chốt cũng rụng nốt.

Và đây là điểm cần đóng đinh: bản nén vẫn trông như một task hoàn chỉnh. Nó có động từ, có tân ngữ, có phạm vi. Nó không thiếu chữ nào. Không có gì trong câu đó báo cho bạn biết rằng bốn thông tin quyết định vừa rơi ra ngoài trên đường đi.

Nén không báo lỗi.

Nhớ kỹ bốn chữ đó.

Nhịp bốn - bạn làm đúng bản nén. Bạn vẽ mười bốn bước. Bạn đối chiếu với bản nén: không thiếu gì. Người giao đối chiếu với bản nén: cũng không thiếu gì, nên lời cảm ơn kia không mâu thuẫn với chỗ nào cả. Chỉ có điều bản nén không phải cái đang chặn ai cả.

Nói thật với bạn một chuyện, để bạn đừng tưởng bốn nhịp này gọn gàng như mình vừa kể: rất nhiều lần chính người giao việc cũng không nắm được nhịp một và nhịp hai. Họ cũng đang cầm một bản nén nhận từ tầng trên. Nén xảy ra nhiều tầng, mỗi tầng rụng thêm. Nghĩa là khi bạn hỏi ngược lên, có lúc bạn không lấy lại thông tin - bạn giúp người kia lần đầu nhìn thấy thứ họ đang thật sự cần.

Gói lại: quyết định → vùng mờ → nén thành task → bạn làm đúng bản nén. Bây giờ nhìn lại tấm phim của Thảo.

Nhưng khoan. Ở đây có một câu bạn sắp hỏi, và mình đoán bạn đang định hỏi: chẳng lẽ trước mọi task đều phải chạy đi hỏi “tại sao”? Làm vậy không phải là cãi sếp, là chậm việc, là làm quá lên à?

Đúng, nếu bạn hỏi “tại sao”. “Tại sao” là câu hỏi về động cơ, và người bị hỏi về động cơ thì phòng thủ. Cái cần lấy lại không phải động cơ. Là quyết định. Ba ô thôi: ai quyết, quyết cái gì, trước lúc nào.

Với ba ô đó, đề bài thật của Thảo hiện ra: PM, chốt bỏ hay giữ OTP màn 2, trước grooming thứ Sáu.

Và đây là chỗ hầu hết mọi người hiểu sai. Người ta nghĩ tài liệu bị bỏ vì làm chưa đủ sâu. Không phải. Vẽ hai mươi bước thay vì mười bốn cũng không cứu được gì, vì sâu hơn theo trục “mô tả hiện trạng” thì vẫn không có một con số nào nói user rớt ở đâu. Sai không nằm ở độ sâu. Nằm ở trục.

Không có ai lười ở đây cả. Không có ai làm ẩu. Chỉ là một người làm rất kỹ một tấm phim chụp đúng kỹ thuật, rõ nét, đúng hạn - chụp nhầm bộ phận.

Cái sửa nhỏ đến mức buồn cười: một câu hỏi, hai mươi giây, gõ ngay trong chat lúc nhận task. “Anh đang cần chốt gì từ cái này, và cần trước lúc nào ạ?”

Nhưng khoan đã. Tại sao chính câu đó chạy được, trong khi “anh giải thích rõ hơn yêu cầu giúp em” thì không?

Vì “giải thích rõ hơn yêu cầu” là xin thêm chi tiết bên trong bản nén - bạn vẫn ở nhịp bốn, chỉ là một bản nén dài hơn. Còn câu kia đi ngược lên đúng một tầng, về nhịp một và nhịp hai, chỗ thông tin đã rụng. Nó không xin thêm dữ liệu. Nó giải nén.

Và còn một câu nữa, gỡ nốt mảnh cuối cùng đã rụng ở nhịp ba: “Biết được gì thì anh dám chốt ạ?” Nghe na ná câu trên nhưng hỏi một thứ khác hẳn. Câu trên cho bạn đúng trục. Câu này cho bạn biết dừng ở đâu trên trục đó - vì biết mình đang tìm drop-off rồi thì vẫn có thể đào bảy chiều trong hai ngày, trong khi thứ PM cần chỉ là một con số đặt cạnh một ngưỡng. Đây cũng là câu duy nhất bạn không tự trả lời hộ được. Ngưỡng nằm trong đầu người sẽ chịu hậu quả.

Làm đúng một bản nén sai vẫn là làm sai. Và sẽ không ai báo cho bạn biết.

Giờ mình kể lại đúng câu chuyện đó, trên một tình huống mà bạn sẽ không nghĩ là cùng gốc.

Bạn chạy UAT xong, tìm được 5 issue. Viết cẩn thận: step to reproduce, screenshot, môi trường, mức độ. Gửi lên nhóm. Rồi nhận lại: “Vậy giờ em muốn anh làm gì?” Hoặc tệ hơn - im lặng ba ngày, tới sát giờ release mới có người hỏi lại.

Lần này có thể bạn chẳng thiếu dữ liệu nào. Bạn biết rõ deadline, biết rõ quyết định là “release thứ Năm hay hoãn”. Nhưng người nhận thì vẫn thiếu đúng thứ họ cần để quyết. Sao lại thế?

Vì lần này bạn là người nén. Bạn cầm trong tay một thứ đã đọc được và nén nó thành “5 issue” - đúng, đủ, và rụng mất phần đọc. Năm tấm phim rõ nét, chưa ai đọc. Người nhận vẫn phải tự làm lại toàn bộ đoạn suy nghĩ mà bạn vừa làm xong rồi vứt đi.

Bản giải nén nằm ở đây: “3 trong 5 issue cùng một nguyên nhân ở tầng validate, fix một chỗ là hết cả ba. 2 issue còn lại impact thấp, em đề xuất để phase sau. Theo em là release được.”

Cùng một dữ liệu. Khác nhau ở chỗ vùng mờ của người ra quyết định có bị thu hẹp hay không.

Hai triệu chứng. Một cái là tài liệu công phu không ai mở, một cái là báo cáo issue chuẩn chỉnh bị hỏi ngược. Trông chẳng liên quan gì tới nhau. Nhưng cùng một nguyên nhân, và nguyên nhân ấy nằm ở đúng cùng một chỗ - cái điểm nén giữa quyết định và task. Lần đầu bạn là nạn nhân của bản nén người khác đưa xuống. Lần sau bạn là tác giả của bản nén mình đẩy lên. Cùng một cơ chế, chạy theo hai chiều.

Đến đây mình phải nói rõ một chuyện, kẻo bạn tưởng đây là chuyện riêng của mình với Thảo. Có một khảo sát quốc tế về các vấn đề trong khâu làm yêu cầu, chạy lặp từ 2012; đợt được trích nhiều nhất thu dữ liệu 2014–2015, ở 228 tổ chức thuộc mười quốc gia. Hai thứ bị nêu nhiều nhất, trên tất cả những thứ khác: yêu cầu thiếu hoặc bị giấu, và đứt gãy giao tiếp giữa đội làm và khách hàng. Nhưng thứ đáng đọc không phải bảng xếp hạng. Là mấy dòng người tham gia tự gõ vào ô trả lời tự do. Một người ở công ty lớn viết rằng bộ phận kinh doanh và quản lý sản phẩm bên họ đóng vai người dùng cuối - đội làm việc với một bản đại diện, không với người thật.

Cái chỗ nén này, hoá ra có người ngồi ở một tổ chức khác, một nước khác, đã mô tả nó bằng đúng một câu.

Nhưng mình không định bán cho bạn một thói quen không mất gì.

Giải nén tốn thời gian, và tốn vốn xã hội. Có nơi hỏi ngược bị đọc là chống đối, nhất là khi câu hỏi của bạn phơi ra chuyện người giao cũng chưa nghĩ thông. Và có người giải nén quá tay, thành ra mỗi lần nhận việc là một lần chất vấn - thứ đó làm hỏng quan hệ nhanh hơn là làm hỏng tài liệu.

Chỗ này mình không có nghiên cứu nào để đưa cho bạn. Nó là thứ mình rút ra sau khi ngồi đếm lại những lần mình nộp một thứ đúng mà vô dụng - và bạn hoàn toàn có thể đếm lại trên chỗ làm của bạn để xem có ra cùng một kiểu không.

Nên liều lượng không tỉ lệ với độ khó của task, cũng không tỉ lệ với thời lượng của nó. Nó tỉ lệ với chi phí của việc làm sai hướng - hai thứ đó lệch nhau nhiều hơn bạn tưởng. Một script migration chạy hai tiếng, đi sai hướng thì gỡ mất hai ngày. Một tài liệu nội bộ làm hai tuần, sai thì viết lại, không ai chết. Câu đáng hỏi không phải “việc này lâu không”, mà “nếu sai hướng thì gỡ có dễ không”. Gỡ dễ thì cứ làm. Gỡ khó - output đi vào hợp đồng, vào báo cáo gửi khách, vào một quyết định không rút lại được - thì dừng lại hai mươi giây.

Và cái nguyên lý đằng sau chẳng dính gì tới nghề BA. Trong mọi tổ chức, việc được truyền đi bằng cách nén: bối cảnh → ý định → yêu cầu → task. Mỗi tầng nén làm rụng thông tin mà không phát tín hiệu lỗi, vì bản nén luôn trông như một đơn vị công việc hoàn chỉnh. Dev nhận ticket, designer nhận brief, sale nhận target. Người dần có ảnh hưởng là người quen giải nén ngược lên một tầng trước khi bắt tay làm. Và biết lúc nào thì không cần.

Đó cũng là lý do mình càng ngày càng không tin “senior là biết nhiều hơn”. Biết nhiều làm tấm phim nét hơn. Nó không chọn hộ bạn chụp bộ phận nào.

Lần tới, trước khi mở Figma, mở Word, mở Excel - gõ bốn dòng lên đầu file:

Ai quyết:
Quyết cái gì:
Trước lúc nào:
Biết gì thì dám chốt:

Mất chưa tới một phút. Điền được cả bốn thì xóa đi rồi làm, bạn đang ở đúng trục và biết chỗ dừng. Ô cuối là ô hay trống nhất, và cũng là ô đắt nhất.

Một ô trống không chứng minh việc này sắp hỏng. Có rất nhiều việc chạy tốt mà chẳng ai điền nổi ô nào, vì quyết định đã rõ với mọi người tới mức không cần nói ra. Cái ô trống chỉ cho bạn biết một chuyện: bạn không tự trả lời được. Còn có đáng đi hỏi hay không thì quay lại câu ở trên - nếu đi sai hướng thì gỡ có dễ không.

Thảo nghe xong, im một lúc rồi nhắn lại:

Thảo Vậy là em không cần biết nhiều hơn. Em cần biết cái tài liệu này đang giúp ai bớt phải đoán.

Ừ, đúng rồi đó.

https://caltalys.dev/tai-lieu-dung-tung-chu

Caltalys · 19/08/2026 · Phân tích nghiệp vụ · Yêu cầu · Giao việc