Nguyen Le PhongNguyen Le Phong

Biến công việc mơ hồ thành shared notes

Một ghi chú thực tế về cách dùng shared notes để biến request mơ hồ thành context, decision, example và next step có thể nhìn thấy.

Request đến bằng một tin nhắn ngắn nhìn từ xa có vẻ đơn giản. Nó hỏi một cải tiến nhỏ, một điều chỉnh nhanh, thứ team có lẽ nhét được giữa hai task lớn. Nhưng sau mười phút bàn, request đơn giản đó mọc thêm nhiều góc cạnh. Có exception, user chưa rõ, dependency ẩn, và một quyết định cũ không ai nhớ trọn vẹn.

Một product team bình tĩnh sắp xếp sticky notes và diagram trừu tượng thành một brief rõ hơn quanh bàn làm việc.
Shared notes giúp công việc mơ hồ trở nên có thể inspect trước khi nó trở nên đắt đỏ.

Đây là lúc một shared note có thể làm được nhiều hơn một cuộc họp dài. Note không cần đẹp. Nó cần giữ công việc đứng yên đủ lâu để mọi người nhìn cùng một thứ. Ta đang muốn đổi gì? Ai bị ảnh hưởng? Example nào chứng minh behavior hiện tại? Decision nào đã được đưa ra? Điều gì còn open? Vài section đơn giản có thể biến sương mù thành vật liệu.

Giá trị không nằm ở documentation vì documentation. Giá trị nằm ở shared attention. Khi request chỉ sống trong chat, mỗi người mang một phiên bản hơi khác trong đầu. Product owner nhớ pressure từ customer. Engineer nhớ edge case. Designer nhớ màn hình awkward. QA nhớ scenario từng fail. Một note cho các mảnh đó cùng ngồi trên một cái bàn.

Shared notes tốt cũng giảm áp lực phải chắc chắn quá sớm. Thay vì ép ra plan cuối cùng, note có thể gọi tên uncertainty trực tiếp. Payment state chưa rõ. Cần legal wording. Check migration size. Confirm mobile behavior. Khi uncertainty visible, nó trở thành thứ có thể assign. Một người có thể own nó, trả lời nó, hoặc quyết định nó nằm ngoài current scope.

Example đặc biệt mạnh. Requirement mơ hồ rõ hơn khi team viết một input thật và output mong đợi. UI concern rõ hơn khi note có trạng thái screen trước và sau. Policy question rõ hơn khi nó liệt kê hai user nên nhận kết quả khác nhau. Example kéo conversation ra khỏi opinion và đưa về behavior.

Note cũng nên ghi decision khi decision còn ấm. Không phải decision nào cũng cần design document nặng. Nhiều team chỉ cần một trace nhỏ: mình chọn option B vì option A làm chậm release và option C tạo support risk. Teammate tương lai không cần replay cả cuộc họp. Họ cần đủ context để hiểu vì sao path này hợp lý.

Rủi ro là để note trở thành ceremony mới. Nếu task nhỏ nào cũng cần document polished, team sẽ né viết. Giữ shape nhẹ. Bắt đầu bằng bullet thô nếu cần, rồi chỉ clean phần quan trọng cho execution. Một shared note thành công khi nó giúp công việc đi tiếp với ít bất ngờ hơn, không phải khi nó trông impressive.

Công việc mơ hồ không rõ lên vì một người nghĩ chăm hơn trong im lặng. Nó rõ lên khi team có thể nhìn cùng context và chỉnh nó cùng nhau. Nếu một shared note nhỏ từng cứu team bạn khỏi build sai thứ cần build, mình muốn nghe section nào đã tạo khác biệt.

Bạn thấy bài viết thế nào?