Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi đến Bài 49 của khóa PSPO III, bạn không còn là người mới với Scrum. Bạn đã biết Sprint, Product Backlog, Definition of Done. Nhưng PSPO III không kiểm tra xem bạn có thuộc Scrum Guide hay không — nó kiểm tra xem bạn có hiểu được nền tảng triết học đằng sau Scrum hay không. Và nền tảng đó có một cái tên: Empirical Management — Quản trị dựa trên thực nghiệm.
Đây chính là bài viết mà Ken Schwaber (đồng sáng lập Scrum, người sáng lập Scrum.org) trình bày trong cuốn whitepaper "Unmanned Management" và sau này được mở rộng trong tài liệu "Empirical Management Explored". Nếu bạn đọc kỹ các đề thi PSPO III, bạn sẽ thấy phần lớn câu hỏi essay đều ngầm đòi hỏi bạn lập luận theo tư duy thực nghiệm — chứ không phải tư duy lập kế hoạch chi tiết kiểu truyền thống.
Vì sao bài này quan trọng với một Senior Product Owner? Bởi vì khi bạn lên đến tầm Head of Product hoặc lãnh đạo một product organization, bạn sẽ liên tục bị kéo về hai phía: một bên là ban lãnh đạo muốn dự báo chắc chắn, lộ trình cố định, cam kết ngày tháng; một bên là thực tế thị trường phức tạp, khách hàng thay đổi, công nghệ biến động. Empirical Management chính là khung tư duy giúp bạn giải thích cho CEO vì sao "cam kết 18 tháng trước" lại là một lời nói dối tử tế, và làm thế nào để quản trị một tổ chức sản phẩm trong môi trường mà bạn không thể biết trước.
Khái niệm cốt lõi
Luận điểm trung tâm của Schwaber
Luận điểm gốc rất sắc bén: Quản trị mệnh lệnh — kiểm soát (command-and-control) thất bại trong các lĩnh vực phức tạp. Quản trị thực nghiệm (dựa trên dữ liệu thật và thử nghiệm liên tục) mới là cách phù hợp.
Schwaber phân biệt hai loại quy trình:
- Quy trình định nghĩa được (defined process): Đầu vào giống nhau luôn cho ra đầu ra giống nhau. Bạn lập kế hoạch một lần, thực thi đúng kế hoạch, kết quả như dự đoán. Ví dụ: dây chuyền lắp ráp ô tô, đổ bê tông móng nhà.
- Quy trình thực nghiệm (empirical process): Quá nhiều biến số, đầu ra không thể dự đoán chính xác. Bạn buộc phải làm từng bước nhỏ, quan sát kết quả thật, rồi điều chỉnh. Ví dụ: phát triển một sản phẩm phần mềm mới cho một thị trường chưa ai phục vụ.
Ba trụ cột của thực nghiệm
Mọi kiểm soát thực nghiệm đứng trên ba trụ cột mà bạn cần thuộc nằm lòng:
- Transparency (Minh bạch): Mọi người liên quan phải nhìn thấy sự thật theo cùng một định nghĩa. Một "feature đã xong" phải có nghĩa giống nhau với dev, với PO, với khách hàng. Nếu minh bạch giả tạo (báo cáo màu xanh trong khi dự án đang cháy), hai trụ cột còn lại sụp đổ.
- Inspection (Kiểm tra): Thường xuyên xem xét sản phẩm thật và tiến độ thật để phát hiện sai lệch. Quan trọng: kiểm tra phải đủ thường xuyên nhưng không cản trở công việc.
- Adaptation (Thích nghi): Khi kiểm tra cho thấy sai lệch, phải điều chỉnh càng sớm càng tốt. Inspection mà không Adaptation thì vô nghĩa.
Schwaber nói gì về "management" cũ
Điểm độc đáo trong "Empirical Management Explored" là Schwaber không chỉ trích lập trình viên hay quy trình — ông chỉ trích vai trò của nhà quản lý. Trong mô hình cũ, manager là người: lập kế hoạch, phân công, kiểm soát, và chịu trách nhiệm dự báo. Schwaber lập luận rằng trong lĩnh vực phức tạp, công việc của manager phải chuyển từ "điều khiển con người" sang "tạo ra môi trường để đội tự tổ chức tạo giá trị".
Nhà quản lý thực nghiệm không hỏi "tại sao chưa xong đúng hạn?" mà hỏi "chúng ta học được gì từ Sprint vừa rồi và nên điều chỉnh gì?". Đây là sự dịch chuyển từ kiểm soát đầu ra (output control) sang quản trị kết quả và sự học (outcome and learning).
Value, không phải Velocity
Một ý cốt lõi khác: thực nghiệm phải đo bằng giá trị thực giao cho khách hàng, không phải bằng số story point hay số tính năng. Nếu đội của bạn tăng velocity 30% nhưng doanh thu, mức độ giữ chân khách hàng, sự hài lòng không nhúc nhích — thì bạn đang "bận rộn một cách hiệu quả mà vô giá trị". Chính ý này là cầu nối sang Evidence-Based Management (EBM) — nhưng EBM là chủ đề riêng của Bài 50, ở đây ta chỉ nhấn mạnh nguyên tắc nền: thực nghiệm là thử nghiệm để tìm giá trị, không phải để sản xuất nhanh hơn.
Tình huống thực tế
Ví dụ 1 — Một ngân hàng số tại Việt Nam và "kế hoạch 18 tháng"
Một ngân hàng tầm trung tại TP.HCM (gọi là Ngân hàng V) quyết định xây ứng dụng ngân hàng số mới để cạnh tranh với các fintech. Ban lãnh đạo yêu cầu một roadmap 18 tháng với 140 tính năng được liệt kê chi tiết, ngân sách cố định 60 tỷ đồng, và cam kết go-live đúng quý IV.
Sau 9 tháng, dự án đã chi hết 38 tỷ nhưng chưa có gì đến tay người dùng thật — vì đội phải xây "đủ 140 tính năng" trước khi ra mắt. Khi cuối cùng bản beta được mở cho 2.000 khách hàng, dữ liệu thực tế gây sốc: 70% lượt sử dụng tập trung vào đúng 6 chức năng (chuyển tiền, xem số dư, thanh toán hóa đơn, QR, lịch sử giao dịch, khóa thẻ). Hơn 90 tính năng còn lại gần như không ai chạm tới.
Diễn giải: Đây là thất bại kinh điển của tư duy "defined process" áp lên bài toán "empirical". Họ giả định biết trước khách hàng cần gì (140 tính năng) và lập kế hoạch như đổ bê tông. Nếu áp dụng thực nghiệm, họ đã ra mắt 6 tính năng cốt lõi sau 3 tháng, quan sát hành vi thật, rồi mới quyết định xây tiếp cái gì.
Bài học: Trong môi trường phức tạp, giá trị của việc ra mắt sớm không nằm ở tính năng — mà nằm ở dữ liệu thật bạn thu được để điều chỉnh. 35 tỷ đồng chênh lệch chính là cái giá của việc không kiểm tra (Inspection) và không thích nghi (Adaptation) đủ sớm.
Ví dụ 2 — Một startup logistics Đông Nam Á và sự minh bạch giả tạo
Một startup giao vận tại khu vực Đông Nam Á (gọi là LogX) có văn hóa báo cáo "mọi thứ đều ổn". Mỗi tuần, các Product Owner trình bày dashboard xanh lè cho founder. Velocity tăng đều, sprint nào cũng "hoàn thành 95% cam kết".
Nhưng có một vấn đề: "Done" ở LogX nghĩa là "code đã merge", không phải "đã chạy trên production và tài xế dùng được". Khi tính năng tối ưu tuyến đường được "hoàn thành" suốt 4 sprint liên tiếp, thực tế nó chưa từng hoạt động ổn định ngoài thực địa. Đến khi founder tự đi theo một tài xế ở Cần Thơ và chứng kiến app gợi ý tuyến đường vòng thêm 12km, sự thật mới vỡ ra.
Diễn giải: LogX có đủ cuộc họp Inspection (sprint review hằng tuần) nhưng thiếu Transparency thật. Khi định nghĩa "Done" mơ hồ và báo cáo được tô màu, mọi cuộc kiểm tra đều dựa trên dữ liệu sai. Ba trụ cột sụp đổ ngay từ trụ đầu tiên.
Bài học: Là Senior PO, công việc khó nhất của bạn không phải tạo ra cuộc họp Inspection, mà là tạo ra văn hóa nơi sự thật khó nghe được nói ra mà không bị trừng phạt. Một Definition of Done chặt chẽ và một môi trường an toàn tâm lý chính là điều kiện tiên quyết của thực nghiệm.
Ví dụ 3 — Spotify và "bet" thực nghiệm có kỷ luật
Lấy một ví dụ quốc tế quen thuộc: Spotify nổi tiếng với cách tổ chức "company bets" — các đặt cược chiến lược được phát biểu dưới dạng giả thuyết cần kiểm chứng, không phải kế hoạch cần thực thi. Mỗi bet đi kèm Data, Insights, Beliefs, Bet (khung DIBB). Họ không cam kết "chúng tôi sẽ xây tính năng X", mà cam kết "chúng tôi tin rằng nếu làm X thì sẽ đạt kết quả Y, và đây là cách chúng tôi sẽ đo để biết mình đúng hay sai".
Diễn giải: Đây là thực nghiệm ở cấp tổ chức. Thay vì một roadmap cố định, họ có một danh mục giả thuyết được sắp xếp ưu tiên, mỗi cái đều có cơ chế kiểm tra và thoát (kill) rõ ràng. Quản trị ở đây là quản trị học tập, không phải quản trị tuân thủ kế hoạch.
Bài học: Empirical Management có thể mở rộng lên cấp portfolio. Khi bạn phát biểu chiến lược dưới dạng giả thuyết có thể kiểm chứng, bạn vừa minh bạch với ban lãnh đạo về độ bất định, vừa tạo cơ chế để dừng đúng lúc khi giả thuyết sai.
Hướng dẫn từng bước
Đây là cách bạn áp dụng tư duy Empirical Management vào công việc của một Senior PO, và cũng là cách bạn nên lập luận trong essay PSPO III:
- Phân loại bài toán trước khi chọn cách quản trị. Hỏi: lĩnh vực này là defined hay empirical? Nếu đầu ra có thể dự đoán chắc chắn từ đầu vào (ví dụ: di chuyển data center), dùng kế hoạch chi tiết. Nếu có nhiều biến số chưa biết (ví dụ: sản phẩm mới, thị trường mới), dùng thực nghiệm. Sai ở bước này thì mọi thứ sau đều sai.
- Thiết lập Transparency trước. Định nghĩa rõ "Done" nghĩa là gì, "giá trị" được đo bằng chỉ số nào, và đảm bảo mọi bên liên quan đọc cùng một bảng dữ liệu. Không có minh bạch, đừng nói đến kiểm tra.
- Rút ngắn vòng lặp kiểm tra. Thay vì kiểm tra mỗi quý, kiểm tra mỗi Sprint, hoặc với dữ liệu sản phẩm thì theo dõi gần như thời gian thực. Mục tiêu: phát hiện sai lệch khi nó còn rẻ để sửa.
- Phát biểu công việc dưới dạng giả thuyết. Thay vì "xây tính năng A", viết "chúng tôi tin A sẽ tăng retention từ 40% lên 50%; chúng tôi sẽ biết sau 2 Sprint qua chỉ số X". Điều này biến mỗi hạng mục thành một thí nghiệm có thể đúng hoặc sai.
- Thích nghi dựa trên bằng chứng, không dựa trên ý kiến to nhất. Khi dữ liệu cho thấy giả thuyết sai, điều chỉnh Product Backlog ngay — kể cả khi điều đó nghĩa là bỏ thứ bạn đã đầu tư công sức (tránh bẫy chi phí chìm).
- Tái khung báo cáo cho lãnh đạo. Thay vì báo cáo "% hoàn thành kế hoạch", báo cáo "giá trị đã giao + những gì chúng ta đã học + giả thuyết tiếp theo". Đây là kỹ năng chính trị quan trọng nhất của Empirical Management ở cấp cao.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm "Agile" với "không có kế hoạch". Thực nghiệm không phải là tùy hứng. Nó là kế hoạch ngắn hạn cực kỳ kỷ luật cộng với cơ chế điều chỉnh. Bạn vẫn có hướng đi (Product Goal), chỉ là không khóa cứng con đường.
Lỗi 2 — Inspection mà không Adaptation. Rất nhiều tổ chức họp Sprint Review đều đặn nhưng không bao giờ thay đổi Backlog dựa trên kết quả. Đó là "kịch hát thực nghiệm" — diễn cho có. Mẹo: kết thúc mỗi cuộc kiểm tra phải có ít nhất một quyết định thay đổi cụ thể, hoặc một quyết định "có ý thức không thay đổi".
Lỗi 3 — Transparency giả tạo. Báo cáo xanh để giữ thể diện chính là kẻ thù số một. Mẹo: tách bạch "đo lường để học" khỏi "đo lường để đánh giá con người". Khi nhân viên sợ bị phạt vì số liệu xấu, họ sẽ làm đẹp số liệu, và bạn mất luôn dữ liệu thật.
Lỗi 4 — Đo velocity thay vì value. Velocity là chỉ số nội bộ, không phải thành công. Mẹo: với mỗi sáng kiến, luôn buộc một chỉ số kết quả (outcome) hướng khách hàng hoặc kinh doanh đi kèm.
Mẹo cho phòng thi PSPO III: Khi gặp câu essay kiểu "CEO yêu cầu cam kết ngày ra mắt cố định cho 12 tháng tới", đừng trả lời "không thể". Hãy lập luận theo thực nghiệm: giải thích đây là lĩnh vực empirical, đề xuất cam kết về Product Goal và nhịp giao giá trị thay vì danh sách tính năng cố định, và mô tả cách bạn sẽ minh bạch về độ bất định bằng dữ liệu thật qua từng Sprint.
Bài tập thực hành
- Phân loại lĩnh vực: Liệt kê 5 sáng kiến gần đây nhất bạn (hoặc tổ chức bạn) đang làm. Đánh dấu từng cái là "defined" hay "empirical". Với những cái empirical mà đang bị quản trị bằng kế hoạch cứng, viết một câu mô tả rủi ro lớn nhất.
- Soi định nghĩa "Done": Viết ra định nghĩa "hoàn thành" hiện tại trong đội bạn. Nó có nghĩa giống nhau với dev, PO, và khách hàng không? Nếu không, viết lại một phiên bản tạo Transparency thật.
- Viết lại một hạng mục Backlog thành giả thuyết: Chọn một tính năng sắp tới. Viết lại theo mẫu: "Chúng tôi tin [hành động] sẽ dẫn đến [kết quả đo được] cho [đối tượng]; chúng tôi sẽ biết mình đúng/sai bằng [chỉ số] sau [khoảng thời gian]."
- Tái khung một báo cáo: Lấy một báo cáo tiến độ bạn từng gửi lãnh đạo. Viết lại nó từ "% hoàn thành kế hoạch" sang "giá trị đã giao + điều đã học + giả thuyết tiếp theo". So sánh cảm giác hai bản.
- Essay mini (250–350 từ): Trả lời câu hỏi: "Vì sao quản trị mệnh lệnh-kiểm soát thất bại trong phát triển sản phẩm phần mềm, và Empirical Management giải quyết điều đó như thế nào?" Dùng đúng ba trụ cột Transparency, Inspection, Adaptation làm xương sống.
Tóm tắt
Empirical Management của Ken Schwaber không phải một kỹ thuật — nó là một thế giới quan. Cốt lõi: trong các lĩnh vực phức tạp, bạn không thể biết trước, nên quản trị bằng cách lập kế hoạch chi tiết một lần và ép tuân thủ sẽ thất bại. Thay vào đó, bạn quản trị bằng thực nghiệm: làm từng bước nhỏ, minh bạch về sự thật, kiểm tra thường xuyên, và thích nghi dựa trên bằng chứng.
Ba trụ cột cần khắc cốt: Transparency (sự thật chung), Inspection (kiểm tra thật và thường xuyên), Adaptation (điều chỉnh kịp thời). Thiếu một, hệ thống sụp.
Với một Senior Product Owner hay Head of Product, giá trị lớn nhất của bài này là khả năng tái khung cuộc đối thoại với lãnh đạo: từ "có đúng kế hoạch không" sang "có tạo ra giá trị không và ta đã học được gì". Đó cũng chính là tư duy mà mọi câu hỏi essay của PSPO III ngầm đòi hỏi ở bạn. Ở bài tiếp theo, ta sẽ đi sâu vào các bộ tài liệu của Scrum.org — EBM, Nexus, Kanban — chính là nơi tư duy thực nghiệm này được cụ thể hóa thành công cụ đo lường và mở rộng quy mô.