Định nghĩa hoàn thành (Definition of Done): Cách tôi chữa trị căn bệnh "xong 90%"

Một nhiệm vụ "xong 90%" có thể tồn tại lâu hơn cả một chậu cây cảnh trong nhà. Tuần này nó ở trạng thái "gần xong", tuần sau lại là "chỉ chờ duyệt", và đến tuần thứ ba thì mọi người đối xử với nó như một cư dân lâu năm của dự án. Tôi chia sẻ điều này vì bản thân tôi đã từng sống trong đó, chứ không phải vì tôi đã giải quyết nó một cách hoàn hảo.

Tôi từng chứng kiến một nhiệm vụ dashboard đơn giản nằm ở mức 90% suốt ba tuần liền. Bản thiết kế đã hoàn thành, giao diện frontend "về cơ bản là xong", API cần "một tinh chỉnh nhỏ", và bộ phận QA thì "chưa kiểm tra đầy đủ." Trong cuộc họp rà soát, chúng tôi đã dành tới 25 phút chỉ để tranh luận về một câu hỏi duy nhất: nhiệm vụ này đã xong hay chưa? Cuộc tranh luận vô bổ đó chính xác là thứ mà một Định nghĩa hoàn thành (Definition of Done - DoD) chung sẽ ngăn chặn.

Bài viết này không phải là lời giới thiệu cơ bản về quản lý dự án — bạn đã biết nhiệm vụ, sprint, rà soát và phát hành là gì. Các tài liệu quản lý dự án uy tín đều mô tả việc kết thúc công việc và xác nhận chất lượng là một giai đoạn thực tế, chứ không phải một ý nghĩ xuất hiện sau cùng, và góc nhìn đó là điều cuối cùng đã cứu lấy tôi. Vì vậy, chúng ta sẽ đi thẳng vào căn bệnh: công việc trông có vẻ đã xong, nghe có vẻ đã xong, nhưng vẫn liên tục tạo ra lỗi, yêu cầu làm lại và gây ra drama trong các buổi rà soát. Bạn sẽ nhận được các checklist sẵn sàng sử dụng ở ba cấp độ — nhiệm vụ, tính năng và bản phát hành — để đưa vào mẫu dự án Notion của bạn ngay hôm nay.

Ý nghĩa thực sự của Định nghĩa hoàn thành

Một Định nghĩa hoàn thành là một checklist chung cho biết cho cả đội biết khi nào công việc thực sự hoàn thành — không phải hoàn thành kiểu "tôi đã làm xong phần của mình", không phải hoàn thành kiểu "xin đừng hỏi tôi nữa", mà là hoàn thành một cách thực sự. Nó xác định mức chất lượng tối thiểu trước khi một nhiệm vụ, tính năng hoặc bản phát hành có thể chuyển sang trạng thái Hoàn thành (Done).

Điều nó thực sự loại bỏ là sự diễn giải cá nhân. Cuộc hội thoại chuyển từ "tôi nghĩ nó đã xong" sang "nó đáp ứng các tiêu chí, vì vậy nó đã xong." Sự khác biệt đó giúp tôi tiết kiệm được các cuộc họp, và quan trọng hơn, nó cứu vãn lòng tin của cả đội.

Tại sao tình trạng "xong 90%" lại xảy ra

Theo kinh nghiệm của tôi, tình trạng "xong 90%" hiếm khi do lười biếng. Đó là do sự mơ hồ. Cả nhóm chưa bao giờ thống nhất xem thế nào là hoàn thành, vì vậy mỗi người âm thầm sử dụng một định nghĩa riêng của họ. Đối với lập trình viên, xong có thể nghĩa là "code chạy được trên máy cục bộ." Đối với designer, "màn hình cuối cùng đã được duyệt." Đối với QA, "nó đã vượt qua các kịch bản kiểm thử." Đối với PM, "khách hàng có thể sử dụng mà không cần hướng dẫn trực tiếp."

Mỗi định nghĩa đều hợp lý. Nhưng gộp lại chúng tạo ra sự hỗn loạn. Công việc vẫn tiến về phía trước, nhưng các cổng chất lượng thì vô hình — và 10% còn thiếu xuất hiện vào thời điểm tồi tệ nhất: buổi demo cho khách hàng, ngày ra mắt, hoặc lúc 11:47 đêm khi có ai đó hỏi, "chờ đã, chúng ta đã test trên điện thoại chưa?"

3 cấp độ của Định nghĩa hoàn thành

Một checklist duy nhất không thể phù hợp với mọi lớp công việc. Một nhiệm vụ nhỏ không cần các tiêu chí phức tạp như một bản phát hành lớn, vì vậy tôi sử dụng ba cấp độ, mỗi cấp độ bảo vệ một loại rủi ro khác nhau.

Tôi nghĩ về nó giống như an ninh sân bay. DoD nhiệm vụ là kiểm tra căn cước của bạn, DoD tính năng là quét hành lý, còn DoD phát hành là đảm bảo máy bay đã được nạp đủ nhiên liệu. Bỏ qua một bước, và mọi người sẽ bắt đầu lo lắng.

Checklist Định nghĩa hoàn thành cho các nhiệm vụ thông thường

Sử dụng checklist này cho công việc hằng ngày. Một nhiệm vụ thông thường được coi là xong khi:

• Kết quả đầu ra được yêu cầu đã hoàn thành.
• Nó khớp với bản mô tả hoặc tiêu chí chấp nhận.
• Người thực hiện đã tự kiểm tra công việc của mình trước khi yêu cầu duyệt.
• Các tệp tin, liên kết hoặc ghi chú liên quan đã được đính kèm.
• Mọi sự phụ thuộc hoặc rào cản đã được giải quyết hoặc ghi nhận rõ ràng.
• Người tiếp theo có thể tiếp quản công việc mà không cần hỏi thêm ngữ cảnh bị thiếu.
• Trạng thái nhiệm vụ được cập nhật trong hệ thống quản lý dự án.
• Nếu cần duyệt, người duyệt đã được tag kèm theo một yêu cầu cụ thể.
• Nếu không cần duyệt, nhiệm vụ được chuyển sang trạng thái Hoàn thành.

Checklist này cố tình được thiết kế rất nhàm chán — đó chính là điểm mấu chốt. DoD cấp độ nhiệm vụ nên ngăn chặn những rò rỉ nhỏ: thiếu liên kết, bàn giao thiếu thông tin, ghi chú viết dở và lỗi "tôi làm xong rồi nhưng quên cập nhật bảng công việc."

Checklist Định nghĩa hoàn thành cho các tính năng

Một tính năng lớn hơn một nhiệm vụ vì người dùng sẽ tương tác với nó, do đó DoD phải bao gồm sự sẵn sàng của sản phẩm, thiết kế, kỹ thuật, QA và hỗ trợ. Một tính năng được coi là xong khi:

• Nó giải quyết được vấn đề của người dùng được mô tả trong bản mô tả tính năng.
• Các tiêu chí chấp nhận được đáp ứng.
• UX và UI khớp với thiết kế đã được duyệt hoặc các thay đổi đã ghi nhận.
• Các luồng trải nghiệm cốt lõi của người dùng đã được kiểm thử.
• Các trường hợp đặc biệt (edge cases) được xử lý hoặc được chấp nhận rõ ràng như một giới hạn.
• Các trạng thái lỗi, trạng thái trống và trạng thái tải (loading) được kiểm tra kỹ.
• Việc đo lường hoặc theo dõi số liệu (analytics) được triển khai nếu cần.
• Nội dung chữ (copy) và các từ ngữ giao diện (microcopy) đã được duyệt cuối cùng.
• QA đã kiểm tra tính năng trên các thiết bị hoặc môi trường được yêu cầu.
• Các lỗi đã biết được sửa, hoãn lại hoặc được ghi tài liệu rõ ràng.
• Ghi chú nội bộ giải thích rõ cách hoạt động của tính năng.
• Tài liệu hướng dẫn khách hàng hoặc ghi chú phát hành đã sẵn sàng nếu cần.
• Nó được liên kết với yêu cầu gốc, phản hồi hoặc mục lộ trình ban đầu.
• PM hoặc người sở hữu sản phẩm đã nghiệm thu.

Hãy chú ý cụm từ "nếu cần." Một checklist tốt bảo vệ chất lượng mà không biến công việc thành một thủ tục hành chính. Không phải tính năng nào cũng cần tài liệu đầy đủ hay đo lường số liệu — nhưng cả nhóm nên đưa ra quyết định đó một cách có chủ đích, chứ không phải âm thầm quên đi.

Checklist Định nghĩa hoàn thành cho các bản phát hành

DoD cấp độ phát hành chính là nơi tôi nhận được nhiều bài học nhớ đời nhất. Một bản phát hành chưa thực sự xong khi code được merge; nó chỉ xong khi bạn có thể phát hành mà không cần phải chắp tay cầu nguyện. Một bản phát hành được coi là xong khi:

• Tất cả các tính năng hoặc nhiệm vụ đi kèm đều đáp ứng DoD của riêng chúng.
• Các lỗi nghiêm trọng đã được giải quyết.
• Các vấn đề đã biết nhưng không nghiêm trọng được ghi lại rõ ràng kèm theo người chịu trách nhiệm.
• Kiểm thử hồi quy (regression testing) đã hoàn thành cho các khu vực bị ảnh hưởng.
• Việc kiểm tra hiệu suất hoặc bảo mật đã được thực hiện khi cần thiết.
• Các bước di chuyển dữ liệu, thiết lập hoặc triển khai hệ thống đã được ghi tài liệu.
• Kế hoạch khôi phục phiên bản cũ (rollback plan) đã sẵn sàng và rõ ràng.
• Ghi chú phát hành (release notes) đã được viết xong.
• Đội ngũ hỗ trợ, bán hàng hoặc nội bộ đã nắm được những gì thay đổi.
• Các bên liên quan đã phê duyệt bản phát hành nếu việc này là bắt buộc.
• Ngày ra mắt và người phụ trách chính đã được xác nhận.
• Việc theo dõi sau phát hành đã được phân công rõ ràng.
• Các nhiệm vụ theo sát đã được tạo cho bất kỳ phần việc nào cố tình hoãn lại.

Checklist cuối cùng này có vẻ hơi nghiêm ngặt. Tốt thôi — các buổi ra mắt chính là nơi những công việc mơ hồ biến thành nỗi đau đớn công khai trước khách hàng.

Cách tôi áp dụng Định nghĩa hoàn thành trong Notion

Bạn không cần một thiết lập phức tạp. Bạn chỉ cần DoD hiển thị rõ ràng ngay tại thời điểm công việc chuẩn bị chuyển đổi trạng thái.

1. Thêm phần "Định nghĩa hoàn thành" vào mọi template nhiệm vụ

Thêm một khối checklist vào bên trong template nhiệm vụ. Sử dụng DoD nhiệm vụ cho các nhiệm vụ thông thường, và một checklist liên kết hoặc nút template cho DoD tính năng.

2. Thêm thuộc tính "Cấp độ DoD" (DoD Level)

Một thuộc tính dạng Lựa chọn (Select) với các giá trị Nhi vụ (Task), Tính năng (Feature), Phát hành (Release) giúp nhóm áp dụng đúng loại checklist mà không cần suy nghĩ nhiều.

3. Tạo chế độ xem rà soát "Sẵn sàng để Hoàn thành?"

Lọc các nhiệm vụ có Trạng thái = Đang duyệt và checklist chưa được hoàn thành 100%. Điều này giúp bạn có một nơi để kiểm tra những công việc "đã xong" nhưng thực chất vẫn chưa xong.

4. Đặt checklist ngay trước cột Hoàn thành

Đừng giấu DoD trong một trang wiki mà không ai mở ra đọc. Càng nằm gần thời điểm thay đổi trạng thái công việc, nhóm của bạn càng có nhiều khả năng sử dụng nó.

Một quy tắc vàng cứu lấy các buổi họp rà soát của tôi

Trước khi một nhiệm vụ chuyển sang trạng thái Đang duyệt, người thực hiện phải trả lời được câu hỏi này: "Bằng chứng nào cho thấy việc này đã xong?" Bằng chứng đó có thể là một liên kết dẫn đến tệp tin cuối cùng, một video quay màn hình chạy thử, kết quả test, một URL đã deploy, một ghi chú của QA hoặc một bản tóm tắt ngắn gọn những gì thay đổi. Nó làm cho buổi rà soát bớt tính cảm tính — thay vì tranh luận về nỗ lực bỏ ra, chúng tôi xem xét các bằng chứng rõ ràng. Sự thay đổi duy nhất đó đã biến buổi rà soát từ một phiên tòa đầy kịch tính thành một buổi kiểm soát chất lượng nhẹ nhàng.

Những sai lầm phổ biến tôi đã mắc phải với DoD

Làm cho checklist quá dài

Nếu DoD nhiệm vụ thông thường của bạn có tới 27 mục cần tích, không ai thèm sử dụng nó cả. Giữ cho DoD cấp độ nhiệm vụ thật nhẹ nhàng; hãy để dành các kiểm tra nặng đô cho tính năng và phát hành.

Sử dụng các từ ngữ mơ hồ

Tôi từng viết "trông ổn" hoặc "đã được test kỹ." Bây giờ tôi thay thế chúng bằng những bằng chứng rõ ràng — "luồng người dùng cốt lõi được test trên máy tính và điện thoại," "người duyệt được tag kèm yêu cầu cụ thể," "lỗi đã biết được ghi tài liệu kèm theo người xử lý."

Coi DoD là thủ tục giấy tờ của PM

DoD không phải là công cụ riêng tư của người quản lý; đó là một thỏa thuận chung của cả nhóm. Khi những người trực tiếp làm việc tham gia định hình nó, họ sẽ sử dụng nó để bảo vệ chất lượng thay vì đối phó với người quản lý.

Điểm cốt lõi

"Xong 90%" không phải là một trạng thái — đó là một nhãn cảnh báo. Những gì tôi liên tục tự nhắc nhở mình:

• Định nghĩa hoàn thành biến các giả định cá nhân thành tiêu chí chung của cả đội.
• Sử dụng các cấp độ khác nhau cho nhiệm vụ, tính năng và bản phát hành.
• Đặt checklist ngay bên trong quy trình làm việc, chứ không phải ở một trang wiki bị lãng quên.

Nếu bạn muốn quy trình làm việc này được tích hợp sẵn trong Notion, hãy khám phá Project Package - Smart.

Muốn đọc hướng dẫn quản lý dự án rộng hơn trước? Hãy đọc Quản lý dự án là gì? Hướng dẫn dễ hiểu cho đội ngũ nhỏ và nhà sáng lập.