Cách ra quyết định và ghi lại quyết định

Vì sao phải ghi quyết định

Sáu tháng sau, một người mới nhìn vào code và hỏi "sao lại làm thế này, làm cách kia gọn hơn mà". Nếu không có gì ghi lại, chỉ còn hai khả năng: người cũ nhớ mang máng và giải thích lệch, hoặc không ai nhớ và đội quyết định lại từ đầu — có khi quyết ngược lại, rồi vấp đúng cái hố cũ.

Ghi quyết định tốn 20 phút. Tranh luận lại tốn vài buổi họp và một lần làm sai.

Quyết định nào phải ghi

Ghi khi thoả một trong các điều sau:

Khó đảo ngược: đổi lại sẽ tốn hơn một tuần công.
Ảnh hưởng nhiều hơn một module.
Chọn giữa các phương án mà phương án bị loại cũng hợp lý.
Đi ngược một quy ước đã có trong sổ tay này.
Có hệ quả về tiền, bảo mật hoặc dữ liệu người dùng.

Không ghi khi: đặt tên biến, chọn thư viện tiện ích nhỏ, cách chia hàm trong một tệp. Đừng biến việc ghi quyết định thành thủ tục hành chính, nó sẽ chết vì bị ghét.

Mẫu ghi quyết định

Mỗi quyết định là một tệp trong kho mã, đặt ở thư mục tài liệu, tên dạng YYYYMMDD-tieu-de-ngan.md:

# Chọn cách đồng bộ tin nhắn khi mất mạng

Ngày: 2026-09-12
Trạng thái: đã chốt
Người quyết: chủ kỹ thuật
Người góp ý: chủ module Chat, chủ module Task

## Bối cảnh
Chat phải dùng được khi mạng chập chờn. Tin nhắn gửi lúc mất mạng phải tới nơi
khi có mạng lại, và không được sai thứ tự.

## Phương án đã cân nhắc
1. Hàng đợi cục bộ trên máy, gửi lại khi có mạng.
2. Chặn gửi khi mất mạng, báo người dùng thử lại.
3. Dùng thư viện đồng bộ có sẵn của nhà cung cấp hạ tầng.

## Quyết định
Chọn phương án 1.

## Vì sao
Phương án 2 làm hỏng trải nghiệm ở đúng tình huống người dùng cần nhất.
Phương án 3 khoá ta vào một nhà cung cấp và ta không kiểm soát được thứ tự tin nhắn.

## Hệ quả chấp nhận
- Phải tự xử lý trùng lặp khi gửi lại.
- Phải có mã định danh do client sinh cho mỗi tin nhắn.
- Tăng độ phức tạp ở tầng lưu trữ cục bộ.

## Khi nào xem lại
Khi số lượng tin nhắn tồn trong hàng đợi vượt mức gây chậm client,
hoặc khi đổi hạ tầng thời gian thực.

Phần Hệ quả chấp nhận là phần hay bị bỏ nhất, và cũng là phần giá trị nhất. Nó cho người sau biết cái giá đã được cân nhắc chứ không phải bị bỏ sót.

Ai quyết khi không thống nhất

Tranh luận kỹ thuật là tốt, nhưng phải có điểm dừng:

Tranh luận tối đa hai buổi. Sau đó không được kéo dài thêm.
Nếu vẫn lệch, người có quyền quyết theo bảng vai trò sẽ chốt.
Người không đồng ý vẫn phải làm theo, nhưng ý kiến phản đối được ghi vào quyết định. Nếu sau này vấp đúng chỗ đã cảnh báo, đội nhìn lại và học, không đổ lỗi.

Nguyên tắc: bất đồng thì nói thẳng, chốt rồi thì làm cùng nhau. Im lặng trong buổi họp rồi làm khác ở ngoài là hành vi phá đội, nghiêm trọng hơn nhiều so với cãi to trong buổi họp.

Quyết định thử nghiệm

Khi chưa đủ dữ liệu để quyết chắc chắn, được phép ghi quyết định dạng thử:

Trạng thái: đang thử
Kèm một mốc thời gian rõ và một điều kiện đánh giá.
Tới mốc, bắt buộc quay lại chốt hoặc đổi, không được để trạng thái "đang thử" mãi.

Quyết định thử không có hạn đánh giá thì thực chất là quyết định chính thức, chỉ khác là không ai chịu trách nhiệm. Đừng làm vậy.

Khi cần đảo một quyết định cũ

Không sửa đè lên tệp cũ. Tạo quyết định mới, ghi rõ nó thay thế quyết định nào, và giải thích điều gì đã thay đổi so với lúc quyết lần đầu — dữ liệu mới, bối cảnh mới, hay ràng buộc mới. Đánh dấu quyết định cũ là "đã thay thế" và trỏ sang cái mới.

Lịch sử quyết định là tài sản của dự án. Xoá nó đi là xoá luôn lý do.