Bỏ qua

I've read through the full existing chapter carefully. It's already comprehensive and well-structured. Let me strengthen it while preserving all required layers, depth, and structure.

P5.3 — Shaping, appetite và delivery không biến thành feature factory

Module: P5 - Prioritization, Roadmap và Delivery Mục tiêu đọc: Hiểu cách chuyển từ vấn đề và kết quả mong muốn sang công việc đủ rõ để cam kết; đặt giới hạn đầu tư trước khi xây; giao quyền cắt phạm vi cho đội; thiết kế ranh giới đội và cơ chế quản trị để việc giao hàng không biến thành dây chuyền sản xuất tính năng. Nguồn tổng hợp: Shape Up — Ryan Singer; Team Topologies — Matthew Skelton, Manuel Pais; Inspired — Marty Cagan Giới hạn của chương: Đọc chương này không tương đương kinh nghiệm điều hành một betting table (diễn đàn chọn khoản đầu tư) thật hoặc tái cấu trúc một tổ chức đang chạy feature factory (tổ chức đo thành công bằng số tính năng đã giao). Các case trong chương là mô phỏng để minh họa cách áp dụng khái niệm, không phải số liệu hoặc kết quả đã được kiểm chứng độc lập.

Mental model — nhìn toàn cảnh trước khi đi vào chi tiết

Feature factory hình thành thế nào

Feature factory (tổ chức đo thành công bằng số tính năng đã giao) không bắt đầu từ đội kỹ thuật chậm. Nó thường bắt đầu từ governance (cơ chế phân quyền và kiểm soát) sai:

  1. Lãnh đạo hoặc stakeholder (bên liên quan có quyền hoặc lợi ích) đưa ý tưởng.
  2. Roadmap (lộ trình ưu tiên và cam kết) biến ý tưởng thành lời hứa.
  3. Product Manager (PM — người chịu trách nhiệm giá trị và kết quả sản phẩm) viết yêu cầu.
  4. Designer (người thiết kế trải nghiệm) làm giao diện.
  5. Engineer (kỹ sư xây và vận hành sản phẩm) nhận ticket.
  6. Thành công được tính bằng release (lần phát hành), không bằng outcome (thay đổi có giá trị sau phát hành).

Inspired gọi đây là operating model (mô hình vận hành) kiểu dự án: rủi ro được kiểm tra quá muộn, giải pháp bị khóa trước khi người có năng lực giải quyết tham gia, đội chịu trách nhiệm đầu ra nhưng không có quyền chọn cách đạt kết quả.

Shape Up xử lý một phần khác của cùng vấn đề: công việc được cam kết khi còn mơ hồ, sau đó scope (phạm vi cần làm) tăng dần và dự án kéo dài. Phương án: shaping (định hình công việc trước cam kết), appetite (ngân sách thời gian đáng đầu tư), bet (cược đầu tư có giới hạn) và quyền cắt scope (phạm vi cần làm) trong cycle (chu kỳ thực hiện cố định).

Team Topologies bổ sung điều kiện tổ chức. Một đội không thể tự chủ nếu phải chờ nhiều đội chức năng, mang quá nhiều cognitive load (tải nhận thức phải xử lý), hoặc không sở hữu luồng giá trị từ đầu đến cuối. Giao quyền trên giấy không sửa được kiến trúc và cấu trúc đội đang ép mọi thay đổi đi qua hand-off (bàn giao giữa nhóm).

Ba nguồn tạo một mental model (mô hình tư duy) chung:

  • Inspired: Chọn đúng vấn đề và giảm rủi ro giá trị trước khi cam kết.
  • Shape Up: Định hình giải pháp vừa đủ, giới hạn đầu tư và giữ scope (phạm vi cần làm) linh hoạt.
  • Team Topologies: Đặt công việc vào đội có quyền sở hữu, năng lực và ranh giới phù hợp.

P5.3 - Shaping, appetite và delivery không biến thành feature factory — diagram 1

Source mermaid — có thể chỉnh sửa 
flowchart TB
    A["Strategy và outcome: Chọn kết quả cần đổi."]
    B["Discovery: Giảm rủi ro giá trị, khả dụng, khả thi và kinh doanh."]
    C["Shaping: Đặt appetite, phác giải pháp, xử lý rabbit holes và no-gos."]
    T["Điều kiện đội: Sở hữu luồng giá trị, đủ năng lực, tải nhận thức phù hợp, ít phụ thuộc và bàn giao."]
    D["Betting: Chọn khoản đầu tư, đội sở hữu và cycle cố định."]
    E["Delivery: Đội tự khám phá task, xây lát cắt dọc và cắt scope trong cycle."]
    F["Deploy và đo outcome."]
    G{"Outcome có đổi không?"}
    H["Học và định hình lại."]
    X["Dừng."]
    I["Mở rộng, tối ưu hoặc chuyển sang cơ hội khác."]

    A --> B
    B <--> C
    C --> D
    T -. "điều kiện để cam kết và thực hiện" .-> D
    T -. "điều kiện để thực hiện" .-> E
    D --> E
    B <-->|"Discovery tiếp diễn song song"| E
    E -. "thực tế mới" .-> C
    E --> F
    F --> G
    G -- "Không; còn đáng học." --> H
    H --> B
    G -- "Không; không tiếp tục." --> X
    G -- "Có." --> I

Sơ đồ không phải pipeline (dây chuyền tuần tự) cứng. Discovery (khám phá để giảm rủi ro trước khi xây) và delivery (xây, kiểm thử, phát hành đạt chuẩn vận hành) có thể chạy song song. Shaping (định hình công việc trước cam kết) dùng learning (hiểu biết thu được từ bằng chứng) của Discovery (khám phá để giảm rủi ro trước khi xây), rồi tiếp tục được điều chỉnh khi đội xây phát hiện thực tế mới.

Đơn vị quản trị đúng: khoản đầu tư vào outcome, không phải danh sách feature

Ba câu hỏi tách hệ sản phẩm khỏi feature factory (tổ chức đo thành công bằng số tính năng đã giao):

  1. Tại sao đáng đầu tư? Outcome (thay đổi có giá trị sau phát hành) nào cần đạt, cho ai, baseline (mức hiện tại dùng để so sánh) là gì? — Inspired.
  2. Đáng đầu tư tối đa bao nhiêu? Appetite (ngân sách thời gian đáng đầu tư) nào phù hợp với giá trị và độ bất định? — Shape Up.
  3. Đội nào có thể sở hữu luồng này với ít hand-off nhất? Ranh giới nào giữ cognitive load (tải nhận thức phải xử lý) trong khả năng đội? — Team Topologies.

Thiếu câu một, đội giao đúng thứ nhưng không tạo giá trị. Thiếu câu hai, dự án có thể đúng hướng nhưng hút nguồn lực vô hạn. Thiếu câu ba, đội có ý định tốt nhưng không đủ quyền hoặc năng lực để giao.

Core — hiểu đúng nền tảng

1. Phân biệt outcome, appetite, estimate và commitment

Bốn khái niệm dễ bị trộn lẫn:

Khái niệm Câu hỏi trả lời Ai quyết định chính Không phải là
Outcome (thay đổi có giá trị sau phát hành) Điều gì phải thay đổi cho khách hàng hoặc doanh nghiệp? Product leadership (lãnh đạo sản phẩm) và business leadership (lãnh đạo kinh doanh), có đối thoại với đội Danh sách tính năng
Appetite (ngân sách thời gian đáng đầu tư) Cơ hội này đáng dùng tối đa bao nhiêu thời gian? Nhóm shaping (định hình công việc trước cam kết) và người phân bổ đầu tư Dự báo công việc chắc chắn mất bao lâu
Estimate (ước tính công sức hoặc thời gian) Với scope (phạm vi cần làm) giả định, công việc có thể mất bao lâu? Engineer (kỹ sư xây và vận hành sản phẩm) cùng người thực hiện Trần đầu tư
Commitment (cam kết có trách nhiệm) Sau khi giảm đủ rủi ro, ta hứa giao điều gì, khi nào? Lãnh đạo và đội cùng xác nhận; stakeholder (bên liên quan có quyền hoặc lợi ích) liên quan chấp thuận constraint (ràng buộc) Mong muốn áp xuống trước Discovery (khám phá để giảm rủi ro trước khi xây)

Shape Up đảo câu hỏi truyền thống. Thay vì hỏi "tính năng này mất bao lâu?", nhóm hỏi "vấn đề này đáng sáu tuần hay hai tuần?". Appetite (ngân sách thời gian đáng đầu tư) tạo constraint (ràng buộc) để buộc giải pháp nhỏ lại.

Inspired cảnh báo không được biến appetite (ngân sách thời gian đáng đầu tư) thành cam kết giả. Khi value risk (rủi ro khách hàng không muốn hoặc không dùng), usability risk (rủi ro người dùng không dùng được), feasibility risk (rủi ro không thể xây trong điều kiện hiện có) hoặc business viability risk (rủi ro giải pháp không phù hợp doanh nghiệp) còn lớn, nhóm cần Discovery (khám phá để giảm rủi ro trước khi xây), không cần ép ngày giao.

Decision rule (quy tắc quyết định):

  • Chưa biết giải pháp có đáng dùng: chạy Discovery (khám phá để giảm rủi ro trước khi xây) bằng prototype (mẫu thử để học), phỏng vấn, usability test (kiểm tra người dùng có dùng được) hoặc demand test (kiểm tra mức quan tâm ban đầu). Theo Inspired.
  • Biết vấn đề đáng giải nhưng giải pháp quá lớn: đặt appetite (ngân sách thời gian đáng đầu tư), thu hẹp use case (tình huống sử dụng) và shape (định hình) phương án nhỏ hơn. Theo Shape Up.
  • Giải pháp phụ thuộc nhiều đội: sửa ranh giới sở hữu hoặc nêu rõ interaction mode (chế độ tương tác giữa đội) trước khi cam kết. Theo Team Topologies.
  • Cần hứa ngày với thị trường hoặc đối tác: chỉ tạo high-integrity commitment (cam kết độ tin cậy cao) sau khi đã kiểm tra bốn nhóm rủi ro và capacity (năng lực thực hiện khả dụng). Theo Inspired.

2. Shaping: đủ giải quyết, chưa thiết kế thay đội

Shaping (định hình công việc trước cam kết) nằm giữa ý tưởng thô và delivery plan (kế hoạch giao hàng) chi tiết. Shaped work (công việc đã được định hình) cần ba thuộc tính từ Shape Up:

  • Rough (thô, chưa khóa chi tiết): còn chỗ cho đội thiết kế và kỹ thuật quyết định.
  • Solved (đã có hướng giải quyết): các yếu tố chính kết nối được; không chỉ là khẩu hiệu.
  • Bounded (có ranh giới): có appetite (ngân sách thời gian đáng đầu tư), no-gos (phần cố ý không làm) và phạm vi vấn đề cụ thể.

Quá mơ hồ, đội phải khám phá toàn bộ dưới áp lực giao hàng. Quá chi tiết, đội chỉ thi công solution (giải pháp) của người khác. Cả hai đều làm suy yếu empowered product team (đội sản phẩm được trao quyền tìm giải pháp).

Bước 1: Đặt ranh giới

Xác định:

  • Customer problem (vấn đề khách hàng) cụ thể.
  • Business objective (mục tiêu kinh doanh) và outcome (thay đổi có giá trị sau phát hành).
  • Target user (người dùng mục tiêu).
  • Baseline (mức hiện tại dùng để so sánh).
  • Appetite (ngân sách thời gian đáng đầu tư).
  • Constraint (ràng buộc) pháp lý, thương mại, kỹ thuật hoặc vận hành.

Khuyến nghị ghép nguồn:

  • Dùng opportunity assessment (bản đánh giá cơ hội tối thiểu) của Inspired để ghi business objective (mục tiêu kinh doanh), key result (kết quả then chốt đo được), customer problem (vấn đề khách hàng) và target market (thị trường mục tiêu).
  • Thêm appetite (ngân sách thời gian đáng đầu tư) của Shape Up để đặt trần đầu tư.
  • Thêm team boundary (ranh giới trách nhiệm của đội) và dependency (phụ thuộc cần đội khác) từ Team Topologies để kiểm tra khả năng sở hữu.

Không nhận các grab-bag project (dự án gom nhiều cải tiến không có điểm dừng) như "nâng cấp khu vực báo cáo". Tách thành vấn đề có hành vi và kết quả cụ thể, như "người quản lý không nhận ra tài khoản nào cần can thiệp trước".

Bước 2: Phác giải pháp ở độ phân giải đúng

Hai kỹ thuật từ Shape Up:

  • Breadboard (sơ đồ nơi chốn, tương tác và kết nối không có thiết kế trực quan): dùng tên màn hình, hành động và luồng.
  • Fat-marker sketch (phác thảo nét thô để tránh khóa chi tiết): mô tả bố cục và ý tưởng giao diện lớn.

Đầu ra không phải specification (đặc tả đầy đủ). Đầu ra là các solution elements (yếu tố cốt lõi của giải pháp): người dùng đi đâu, làm gì, hệ thống phản hồi ra sao, phần nào tạo giá trị.

PM (người chịu trách nhiệm giá trị và kết quả sản phẩm) không nên tự khóa interaction design (thiết kế tương tác) rồi giao designer (người thiết kế trải nghiệm) tô màu. Inspired yêu cầu PM (người chịu trách nhiệm giá trị và kết quả sản phẩm), designer (người thiết kế trải nghiệm) và engineer (kỹ sư xây và vận hành sản phẩm) cộng tác trong Discovery (khám phá để giảm rủi ro trước khi xây). Vì vậy, shaping group (nhóm định hình công việc) nên có đủ góc nhìn sản phẩm, thiết kế và kỹ thuật; không nhất thiết mọi thành viên delivery team (đội giao sản phẩm) đều tham gia toàn thời gian.

Bước 3: Tìm rabbit holes và rủi ro

Rabbit hole (chi tiết ẩn có thể hút hết thời gian) khác rủi ro thông thường ở tác động tới appetite (ngân sách thời gian đáng đầu tư). Ví dụ:

  • Quyền truy cập phức tạp hơn dự kiến.
  • Dữ liệu lịch sử không đủ sạch.
  • API (Application Programming Interface — giao diện lập trình ứng dụng) của đội khác thiếu khả năng cần thiết.
  • Luồng ngoại lệ buộc thay kiến trúc.
  • Thiết kế hoạt động với dữ liệu mẫu nhưng hỏng khi có dữ liệu thật.
  • Legal (pháp lý) hoặc security (an toàn thông tin) có quyền chặn release (lần phát hành).

Dùng taxonomy (hệ phân loại) của Inspired để kiểm tra:

Rủi ro Câu hỏi Cách giảm rủi ro
Value risk (rủi ro khách hàng không muốn hoặc không dùng) Người dùng có đổi hành vi hoặc trả chi phí chuyển đổi không? Interview, demand test, costly signal
Usability risk (rủi ro người dùng không dùng được) Người dùng có hiểu và hoàn thành tác vụ không? User prototype, usability test
Feasibility risk (rủi ro không thể xây trong điều kiện hiện có) Kiến trúc, kỹ năng, thời gian và dependency có cho phép không? Feasibility prototype, engineer investigation
Business viability risk (rủi ro giải pháp không phù hợp doanh nghiệp) Sales, finance, legal, security và vận hành có chấp nhận không? Stakeholder walkthrough, constraint review
Ethical risk (rủi ro gây hại dù hợp pháp) Outcome có tạo tác hại không mong muốn không? Harm review, metric bảo vệ, phương án thay thế

Sau đó dùng câu hỏi từ Team Topologies:

  • Đội sở hữu thay đổi có phải đợi quá nhiều đội khác không?
  • Dependency (phụ thuộc cần đội khác) là tạm thời hay cấu trúc?
  • API (Application Programming Interface — giao diện lập trình ứng dụng) hoặc platform (nền tảng nội bộ phục vụ đội khác) có đủ self-service (tự phục vụ không cần chờ người xử lý) không?
  • Cognitive load (tải nhận thức phải xử lý) của đội có vượt khả năng không?
  • Có phần nào nên được sở hữu bởi complicated-subsystem team (đội quản lý tiểu hệ thống cần chuyên môn sâu) không?

Nếu rủi ro lớn chưa có lời giải, không tô đẹp pitch (bản đề xuất đã định hình). Quay lại Discovery (khám phá để giảm rủi ro trước khi xây), giảm ambition (mức tham vọng), đổi solution (giải pháp), hoặc không đặt cược.

Bước 4: Viết pitch

Pitch (bản đề xuất đã định hình) theo Shape Up gồm:

  1. Problem (vấn đề và hiện trạng kém hiệu quả).
  2. Appetite (ngân sách thời gian đáng đầu tư).
  3. Solution (các yếu tố giải pháp cốt lõi).
  4. Rabbit holes (chi tiết ẩn có thể hút hết thời gian).
  5. No-gos (phần cố ý không làm).

Để tránh pitch (bản đề xuất đã định hình) trở thành feature brief (bản mô tả tính năng), thêm ba trường từ Inspired và Team Topologies:

  1. Outcome evidence (bằng chứng dùng để đánh giá kết quả): baseline (mức hiện tại dùng để so sánh), target (mức muốn đạt), instrumentation (cơ chế ghi nhận dữ liệu).
  2. Risk status (trạng thái rủi ro): bằng chứng đã có, điều còn chưa biết.
  3. Ownership and interaction (quyền sở hữu và cách đội phối hợp): đội chịu trách nhiệm, dependency (phụ thuộc cần đội khác), interaction mode (chế độ tương tác giữa đội).

3. Appetite tạo sáng tạo, không thay Discovery

Fixed time, variable scope (thời gian cố định, phạm vi linh hoạt) hoạt động khi đội có quyền:

  • Bỏ nice-to-have (phần có thì tốt nhưng không cần để tạo giá trị cốt lõi).
  • Đổi cách triển khai mà vẫn bảo vệ outcome (thay đổi có giá trị sau phát hành).
  • Triển khai lát cắt nhỏ hơn.
  • Từ chối scope creep (phạm vi tăng ngoài quyết định ban đầu).
  • Dừng khi bet (cược đầu tư có giới hạn) không còn hợp lý.

Nó không hoạt động khi:

  • Ngày, scope (phạm vi cần làm), chất lượng và nguồn lực đều cố định.
  • No-go (phần cố ý không làm) bị stakeholder (bên liên quan có quyền hoặc lợi ích) âm thầm đưa lại.
  • Đội không sở hữu production (môi trường vận hành thật), testing (kiểm thử) hoặc release (lần phát hành).
  • Mọi thay đổi phải xin nhiều cấp phê duyệt.
  • Appetite (ngân sách thời gian đáng đầu tư) được dùng để ép overtime (làm thêm giờ).
  • Công việc chịu deadline (hạn chót) pháp lý không thể đổi nhưng chưa có contingency (phương án dự phòng).

Trong các trường hợp này, "linh hoạt scope (phạm vi cần làm)" chỉ là khẩu hiệu. Governance (cơ chế phân quyền và kiểm soát) phải ghi rõ ai có quyền cắt gì, điều gì không được cắt (quality floor - ngưỡng chất lượng tối thiểu), và khi nào cần escalation (đưa quyết định lên cấp có thẩm quyền).

4. Betting: quyết định đầu tư, không xếp hàng yêu cầu

Betting (chọn khoản đầu tư có giới hạn) khác backlog prioritization (xếp thứ tự danh sách việc tồn đọng):

  • Backlog (danh sách việc chờ xử lý) dễ biến mọi ý tưởng thành nghĩa vụ.
  • Bet (cược đầu tư có giới hạn) chỉ tồn tại khi tổ chức chủ động cấp thời gian và đội.
  • Ý tưởng không được chọn có thể bị bỏ; không cần nuôi vô hạn.
  • Downside (mức thiệt hại tối đa) được chặn bằng appetite (ngân sách thời gian đáng đầu tư).

Betting table (diễn đàn chọn khoản đầu tư) nên trả lời:

  1. Vấn đề có quan trọng với strategy (chiến lược lựa chọn nơi và cách thắng) không?
  2. Outcome (thay đổi có giá trị sau phát hành) có đo hoặc quan sát được không?
  3. Bằng chứng Discovery (khám phá để giảm rủi ro trước khi xây) đủ cho quy mô bet (cược đầu tư có giới hạn) chưa?
  4. Appetite (ngân sách thời gian đáng đầu tư) có hợp giá trị và bất định không?
  5. Solution (giải pháp) có hấp dẫn nhưng vẫn bounded (có ranh giới) không?
  6. Đội nào có ownership (quyền sở hữu) phù hợp?
  7. Dependency (phụ thuộc cần đội khác) và cognitive load (tải nhận thức phải xử lý) có làm bet (cược đầu tư có giới hạn) phi thực tế không?
  8. Vì sao làm lúc này thay vì cơ hội khác?
  9. Nếu thất bại, tổ chức học được gì và mất tối đa gì?

Shape Up đặt quyết định này vào một nhóm lãnh đạo nhỏ. Inspired cảnh báo leadership (lãnh đạo) phải chọn problem (vấn đề) và outcome (thay đổi có giá trị sau phát hành), không áp solution (giải pháp). Kết hợp đúng: lãnh đạo quyết định đầu tư và constraint (ràng buộc); đội giữ quyền giải pháp trong ranh giới đã thống nhất.

5. Đưa bet vào đúng cấu trúc đội

Stream-aligned team (đội căn chỉnh theo luồng giá trị) từ Team Topologies là nơi mặc định để nhận bet (cược đầu tư có giới hạn). Đội này cần đủ năng lực để thiết kế, xây, kiểm thử, triển khai và vận hành thay đổi trong một customer journey (hành trình khách hàng) hoặc business domain (miền nghiệp vụ).

Ba loại đội khác hỗ trợ, không trở thành hàng đợi trung tâm:

  • Enabling team (đội giúp đội khác học và nâng năng lực): hỗ trợ tạm thời khi đội thiếu kỹ năng.
  • Complicated-subsystem team (đội quản lý tiểu hệ thống cần chuyên môn sâu): sở hữu phần đòi hỏi chuyên môn hiếm.
  • Platform team (đội cung cấp nền tảng nội bộ như sản phẩm): cung cấp self-service (tự phục vụ không cần chờ người xử lý), giảm cognitive load (tải nhận thức phải xử lý).

Ba interaction mode (chế độ tương tác giữa đội):

  • Collaboration (hai đội cùng khám phá sát nhau): dùng khi lĩnh vực mới, ranh giới chưa rõ; tốn thời gian, phải có thời hạn.
  • X-as-a-Service (một đội tiêu thụ dịch vụ chuẩn của đội khác): dùng khi interface (giao diện tương tác) ổn định.
  • Facilitating (một đội giúp đội khác học): dùng khi thiếu năng lực, không dùng để chiếm quyền sở hữu.

P5.3 - Shaping, appetite và delivery không biến thành feature factory — diagram 2

Source mermaid — có thể chỉnh sửa 
flowchart TB
    A{"Stream-aligned team có ownership customer journey hoặc business domain<br/>và giao được end-to-end không?"}
    B["Giao bet cho stream-aligned team<br/>có ownership customer journey hoặc business domain."]
    C{"Điểm thiếu nằm ở đâu?"}
    D["Enabling team dùng Facilitating có thời hạn.<br/>Ownership vẫn ở stream-aligned team."]
    E{"Interface dịch vụ đã ổn định chưa?"}
    F["Platform team hoặc đội cung cấp giữ ownership dịch vụ.<br/>Stream-aligned team tiêu thụ qua X-as-a-Service."]
    G["Dùng Collaboration có thời hạn<br/>để làm rõ interface dịch vụ."]
    J{"Tiểu hệ thống có cần chuyên môn sâu không?"}
    H["Complicated-subsystem team giữ ownership<br/>phần cần chuyên môn sâu."]
    I["Stream-aligned team giao bet qua<br/>ranh giới ownership đã xác lập."]
    K{"Miền mới hoặc ranh giới chưa rõ?"}
    N["Dùng Collaboration có thời hạn<br/>để khám phá miền và ranh giới."]
    P{"Collaboration phát hiện bet<br/>hoặc ranh giới chưa phù hợp?"}
    L["Định hình lại bet hoặc sửa ranh giới đội<br/>trước cam kết."]

    A -- "Có" --> B
    A -- "Không" --> C

    C -- "Thiếu năng lực" --> D
    D --> A

    C -- "Thiếu dịch vụ" --> E
    E -- "Có" --> F
    E -- "Không" --> G
    G --> E
    F --> B

    C -- "Thiếu ownership" --> J
    J -- "Có" --> H
    H --> I
    I --> B
    J -- "Không" --> K
    K -- "Có" --> N
    N --> P
    P -- "Không" --> A
    P -- "Có" --> L
    K -- "Không" --> L
    L --> A

Nếu một pitch (bản đề xuất đã định hình) cần năm đội cùng giao trong sáu tuần, vấn đề có thể nằm ở team topology (cấu trúc đội và cách tương tác), không nằm ở kỹ năng planning (lập kế hoạch). Không nên che vấn đề cấu trúc bằng thêm coordinator (người điều phối), status meeting (họp trạng thái) và dependency tracker (bảng theo dõi phụ thuộc).

6. Delivery: giao dự án, không giao task

Theo Shape Up, đội nhận pitch (bản đề xuất đã định hình), không nhận task list (danh sách tác vụ) hoàn chỉnh. Đội tự:

  • Khám phá task (tác vụ) cần thiết.
  • Chia scope (phạm vi cần làm) theo cấu trúc sản phẩm.
  • Chọn technical design (thiết kế kỹ thuật).
  • Cắt scope (phạm vi cần làm).
  • Tích hợp testing (kiểm thử) và deployment (triển khai) trong cycle (chu kỳ thực hiện cố định).

Theo Inspired, quyền này đi cùng accountability (trách nhiệm giải trình) cho outcome (thay đổi có giá trị sau phát hành), product quality (chất lượng đủ chuẩn vận hành) và business constraint (ràng buộc kinh doanh). Autonomy (quyền tự chủ chọn cách giải mục tiêu) không phải quyền bỏ qua security (an toàn thông tin), privacy (quyền riêng tư), reliability (độ tin cậy) hoặc cam kết pháp lý.

Bắt đầu bằng vertical slice

Vertical slice (lát cắt hoạt động từ giao diện tới dữ liệu và vận hành) giúp lộ rủi ro sớm hơn việc chia theo chức năng.

Lát đầu nên:

  • Core (nằm ở giá trị cốt lõi).
  • Small (đủ nhỏ để tích hợp sớm).
  • Novel (chứa phần mới hoặc bất định).

Đừng tổ chức "designer (người thiết kế trải nghiệm) xong toàn bộ màn hình, backend xong toàn bộ API (Application Programming Interface — giao diện lập trình ứng dụng), frontend ghép sau". Cách đó tạo nhiều task (tác vụ) hoàn thành nhưng chưa có sản phẩm chạy được. Shape Up khuyên hoàn thành một phần end-to-end (từ đầu tới cuối) sớm; Team Topologies củng cố bằng mục tiêu giảm hand-off (bàn giao giữa nhóm).

Map scope theo cấu trúc sản phẩm

Scope (nhóm công việc tích hợp theo phần sản phẩm) được khám phá trong lúc xây. Ví dụ:

  • Chọn đối tượng.
  • Cấu hình điều kiện.
  • Xem kết quả.
  • Quyền truy cập.
  • Instrumentation (cơ chế ghi nhận dữ liệu).

Đánh dấu nice-to-have (phần có thì tốt nhưng không cần để tạo giá trị cốt lõi) từ đầu. Khi thời gian ép, đội biết nơi cắt trước.

Hiển thị bất định bằng Hill Chart

Hill Chart (biểu đồ tiến độ theo mức bất định) chia công việc thành:

  • Uphill (đang tìm cách làm, bất định còn cao).
  • Downhill (đã hiểu cách làm, chủ yếu còn thực thi).

Điểm nằm lâu ở uphill (đang tìm cách làm, bất định còn cao) là tín hiệu cần hỗ trợ shaping (định hình công việc trước cam kết), kỹ thuật hoặc stakeholder (bên liên quan có quyền hoặc lợi ích), không phải tín hiệu ép người làm "tăng tốc".

Hill Chart (biểu đồ tiến độ theo mức bất định) không thay observability (khả năng quan sát hệ thống), chất lượng, outcome metric (chỉ số đo kết quả) hoặc dependency tracking (theo dõi phụ thuộc). Nó chỉ làm rõ loại tiến độ mà phần trăm task (tác vụ) hoàn thành thường che giấu.

7. Scope hammering và circuit breaker

Scope hammering (gọt phạm vi liên tục để giữ trần thời gian) dùng các câu hỏi:

  • Phần này có trực tiếp tạo payout (kết quả mong đợi của khoản cược) không?
  • Có thể ship (phát hành cho người dùng) mà thiếu nó không?
  • Có phiên bản thủ công hoặc ít tự động hơn không?
  • Có thể giảm trường hợp ngoại lệ không?
  • Có thể giới hạn persona (nhóm người dùng mục tiêu), dữ liệu, quyền hoặc kênh phát hành không?
  • Có thể dùng platform capability (khả năng nền tảng) sẵn có thay vì xây mới không?

Không được cắt:

  • Security control (kiểm soát an toàn thông tin) bắt buộc.
  • Privacy obligation (nghĩa vụ quyền riêng tư).
  • Data integrity (tính toàn vẹn dữ liệu).
  • Accessibility (khả năng tiếp cận cho người khuyết tật) bắt buộc.
  • Điều kiện khiến sản phẩm gây hại hoặc không thể vận hành.
  • Instrumentation (cơ chế ghi nhận dữ liệu) tối thiểu cần để biết outcome (thay đổi có giá trị sau phát hành).

Circuit breaker (cơ chế ngắt khoản đầu tư khi hết trần thời gian) của Shape Up quy định dự án không tự động được gia hạn. Gia hạn chỉ hợp lý khi:

  • Phần còn lại đều must-have (phần bắt buộc để tạo giá trị hoặc vận hành an toàn).
  • Phần còn lại đều downhill (đã hiểu cách làm, chủ yếu còn thực thi).
  • Không còn rabbit hole (chi tiết ẩn có thể hút hết thời gian).
  • Giá trị cơ hội vẫn giữ nguyên.
  • Chi phí cơ hội của gia hạn được người có quyền đầu tư chấp nhận.

Nếu phần quan trọng vẫn uphill (đang tìm cách làm, bất định còn cao), quay lại shaping (định hình công việc trước cam kết) hoặc Discovery (khám phá để giảm rủi ro trước khi xây). Không gọi thêm thời gian là "chỉ hoàn thiện nốt".

8. Done không đồng nghĩa successful

Shape Up dùng "done means deployed" — hoàn thành nghĩa là đã triển khai. Đây là chuẩn delivery (xây, kiểm thử, phát hành đạt chuẩn vận hành), không phải chuẩn thành công sản phẩm.

Inspired bổ sung lớp còn thiếu:

  • Deployed (đã triển khai) chứng minh output (đầu ra).
  • Adopted (được dùng) chứng minh một phần value (giá trị).
  • Outcome achieved (đạt thay đổi mong muốn) mới chứng minh khoản đầu tư tạo kết quả.
  • Sustained outcome (kết quả duy trì) mới cho thấy thay đổi không phải hiệu ứng ngắn hạn hoặc gây tác dụng phụ.

Sau release (lần phát hành), tránh knee-jerk reaction (phản ứng vội theo phản hồi đầu tiên). Nhưng "để cơn bão đi qua" từ Shape Up không có nghĩa bỏ qua incident (sự cố vận hành), security issue (vấn đề an toàn thông tin), data loss (mất dữ liệu) hoặc harm signal (tín hiệu gây hại). Các trường hợp đó cần xử lý ngay theo severity (mức nghiêm trọng).

Applied — đi qua một tình huống sản phẩm

Lưu ý: Case dưới đây là tình huống mô phỏng (simulated case) để minh họa cách áp dụng khái niệm. Số liệu, tên vai trò và diễn biến là giả định, không phải dữ liệu thật của một công ty cụ thể.

Bối cảnh

Công ty cung cấp phần mềm quản lý tài khoản B2B. Customer Success (bộ phận giúp khách hàng đạt giá trị sau bán) yêu cầu "xây dashboard sức khỏe khách hàng đầy đủ". Sales (bộ phận bán hàng) muốn thêm dự báo gia hạn. Finance (tài chính) muốn doanh thu dự kiến. Executive (lãnh đạo điều hành) muốn giao trong quý.

Dữ liệu chưa hoàn hảo:

  • Đội biết Customer Success Manager (CSM — người quản lý thành công khách hàng) đang xuất ba báo cáo rồi ghép bằng spreadsheet (bảng tính).
  • Chưa biết chỉ số sức khỏe nào dự báo churn (khách hàng rời bỏ) tốt.
  • Dữ liệu usage (mức sử dụng) cập nhật theo ngày; dữ liệu billing (thanh toán) nằm ở hệ khác.
  • Platform team (đội cung cấp nền tảng nội bộ như sản phẩm) chưa có API (Application Programming Interface — giao diện lập trình ứng dụng) tổng hợp billing (thanh toán).
  • Stream-aligned team (đội căn chỉnh theo luồng giá trị) sở hữu hành trình Customer Success nhưng đang mang thêm hai domain (miền nghiệp vụ).

Nếu tiếp nhận yêu cầu theo tên gọi, "dashboard đầy đủ" trở thành grab-bag project (dự án gom nhiều cải tiến không có điểm dừng): score, chart, filter, export, alert, forecast, notes và quyền tùy chỉnh.

Facts → Current behavior → Underlying need

Facts (sự thật quan sát được): CSM xuất ba báo cáo riêng (usage, ticket hỗ trợ, ngày gia hạn) và ghép bằng spreadsheet mỗi tuần. Không có định nghĩa thống nhất về "tài khoản rủi ro". Billing API tổng hợp chưa tồn tại. Ba stakeholder (Sales, Finance, Executive) đưa ba yêu cầu khác nhau dưới một tên gọi chung.

Current behavior (hành vi hiện tại): CSM tốn thời gian ghép dữ liệu thủ công trước khi ra quyết định can thiệp; quyết định không nhất quán giữa các CSM vì mỗi người tự đặt ngưỡng riêng.

Underlying need (nhu cầu thật sự bên dưới yêu cầu): CSM cần biết nhanh, đầu tuần, tài khoản nào cần chú ý trước — không phải một dashboard đầy đủ tính năng, không phải mô hình dự báo churn chính xác.

Framing và Discovery

PM (người chịu trách nhiệm giá trị và kết quả sản phẩm), designer (người thiết kế trải nghiệm) và tech lead (kỹ sư dẫn dắt kỹ thuật) gặp các CSM (Customer Success Manager — người quản lý thành công khách hàng), quan sát quy trình hiện tại và rà dữ liệu.

Learning (hiểu biết thu được từ bằng chứng):

  • Công việc cấp bách không phải dự báo chính xác churn (khách hàng rời bỏ).
  • CSM (Customer Success Manager — người quản lý thành công khách hàng) cần biết sáng thứ Hai nên xem tài khoản nào trước.
  • Họ tin ba tín hiệu: usage (mức sử dụng) giảm, ticket hỗ trợ tăng và ngày gia hạn gần.
  • Billing forecast (dự báo thanh toán) không cần cho quyết định đầu tiên.
  • Một health score (điểm sức khỏe tổng hợp) có vẻ hấp dẫn nhưng chưa có bằng chứng về trọng số.

Theo Inspired, đội tránh productization (đưa mẫu thử lên chuẩn vận hành) sớm. Họ dùng prototype (mẫu thử để học) chứa danh sách tài khoản có ba tín hiệu riêng, không gộp thành score (điểm tổng hợp). Usability test (kiểm tra người dùng có dùng được) cho thấy CSM (Customer Success Manager — người quản lý thành công khách hàng) hiểu danh sách và muốn mở tài khoản từ đó. Value signal (tín hiệu giá trị) vẫn chưa đủ để hứa giảm churn (khách hàng rời bỏ), nhưng đủ để kiểm tra outcome (thay đổi có giá trị sau phát hành) gần hơn: giảm thời gian tìm tài khoản cần can thiệp và tăng tỷ lệ tài khoản rủi ro được xem.

Options → Decision criteria → Decision → Authority

Options (các lựa chọn đã xét):

  1. Xây "dashboard đầy đủ" theo đúng yêu cầu gộp của ba stakeholder (score, forecast, alert, export, notes).
  2. Xây health score tổng hợp bằng machine learning ngay từ đầu.
  3. Xây danh sách tài khoản có ba tín hiệu rời, không gộp điểm, giới hạn trong một cycle.

Decision criteria (tiêu chí quyết định): Mức bằng chứng hiện có về trọng số tín hiệu; appetite hợp lý so với độ bất định; khả năng đội sở hữu end-to-end mà không phụ thuộc cứng vào Billing API chưa tồn tại; khả năng đo được outcome gần (thời gian tìm tài khoản, tỷ lệ tài khoản rủi ro được xem) trước khi cam kết outcome xa (giảm churn).

Decision (quyết định): Chọn phương án 3. Từ chối phương án 1 vì đây là grab-bag project không có appetite rõ. Từ chối phương án 2 vì chưa có bằng chứng về trọng số tín hiệu — xây health score lúc này là cam kết giả trên nền value risk chưa giảm.

Authority (thẩm quyền quyết định): Betting table chọn bet và appetite; PM cùng shaping group chịu trách nhiệm nội dung pitch; stakeholder (Sales, Finance, Executive) được thông báo no-go và lý do, không có quyền phủ quyết phạm vi đã được betting table chốt.

Shaping và appetite

Nhóm shaping (định hình công việc trước cam kết) đặt appetite (ngân sách thời gian đáng đầu tư) một cycle (chu kỳ thực hiện cố định), vì cơ hội có giá trị nhưng mô hình dự báo chưa được chứng minh.

Pitch (bản đề xuất đã định hình) ghi:

Problem (vấn đề): CSM (Customer Success Manager — người quản lý thành công khách hàng) ghép nhiều báo cáo để xác định tài khoản cần chú ý; quy trình chậm và không nhất quán.

Outcome (thay đổi có giá trị sau phát hành): CSM (Customer Success Manager — người quản lý thành công khách hàng) tìm được nhóm tài khoản cần xem đầu tuần bằng một luồng duy nhất. Chưa cam kết giảm churn (khách hàng rời bỏ), vì quan hệ nhân quả chưa được chứng minh.

Appetite (ngân sách thời gian đáng đầu tư): Một cycle (chu kỳ thực hiện cố định).

Solution elements (yếu tố cốt lõi của giải pháp):

  • Danh sách tài khoản có tín hiệu rủi ro.
  • Ba tín hiệu hiển thị riêng.
  • Sắp xếp theo mức ưu tiên quy tắc.
  • Bộ lọc theo owner (người phụ trách).
  • Liên kết tới trang tài khoản.
  • Instrumentation (cơ chế ghi nhận dữ liệu) cho lượt xem, lọc và mở tài khoản.

Rabbit holes (chi tiết ẩn có thể hút hết thời gian):

  • Billing API (Application Programming Interface — giao diện lập trình ứng dụng cho dữ liệu thanh toán) chưa sẵn.
  • Quyền truy cập theo khu vực.
  • Dữ liệu usage (mức sử dụng) đến muộn.
  • Định nghĩa "ticket tăng" khác nhau theo nhóm khách hàng.

No-gos (phần cố ý không làm):

  • Không health score (điểm sức khỏe tổng hợp) bằng machine learning (học máy).
  • Không dự báo churn (khách hàng rời bỏ).
  • Không tùy chỉnh trọng số.
  • Không gửi email alert (cảnh báo email).
  • Không export (xuất dữ liệu).
  • Không xây billing aggregation (tổng hợp thanh toán) mới trong cycle (chu kỳ thực hiện cố định).

Betting và team interaction

Betting table (diễn đàn chọn khoản đầu tư) chọn pitch (bản đề xuất đã định hình), nhưng phát hiện dependency (phụ thuộc cần đội khác) vào platform team (đội cung cấp nền tảng nội bộ như sản phẩm).

Theo Team Topologies, họ không tạo collaboration (hai đội cùng khám phá sát nhau) toàn cycle (chu kỳ thực hiện cố định). Platform team (đội cung cấp nền tảng nội bộ như sản phẩm) chưa có dịch vụ ổn định; phối hợp chặt cả cycle (chu kỳ thực hiện cố định) sẽ làm hai đội mất tập trung.

Options → Decision criteria → Decision → Authority → Artifact → Consequence if wrong cho phần dependency này:

Options: (a) Chờ Billing API hoàn thành trước khi bắt đầu bet; (b) Yêu cầu platform team ưu tiên xây Billing API trong cùng cycle như một collaboration; (c) Loại billing signal khỏi phiên bản đầu, dùng ngày gia hạn đã có sẵn trong hệ thống hiện tại.

Decision criteria: Mức outcome đạt được nếu thiếu billing signal; rủi ro trễ toàn bộ bet nếu chờ đội khác; cognitive load của platform team nếu bị ép ưu tiên giữa cycle.

Decision: Chọn phương án (c).

  • Stream-aligned team (đội căn chỉnh theo luồng giá trị) sở hữu toàn bộ outcome (thay đổi có giá trị sau phát hành).
  • Tạm bỏ billing signal (tín hiệu thanh toán) khỏi phiên bản đầu.
  • Dùng ngày gia hạn đã có trong hệ thống hiện tại.
  • Platform team (đội cung cấp nền tảng nội bộ như sản phẩm) tiếp tục đánh giá Billing API (Application Programming Interface — giao diện lập trình ứng dụng cho dữ liệu thanh toán) như khoản đầu tư riêng, không trở thành blocker (điểm chặn) của bet (cược đầu tư có giới hạn).

Authority: Betting table xác nhận quyết định loại billing signal; stream-aligned team giữ quyền ownership toàn bộ outcome.

Artifact: Pitch đã cập nhật no-go (thêm "không tích hợp billing trong cycle này"); ghi chú dependency riêng cho platform team để theo dõi như cơ hội độc lập.

Consequence if wrong: Nếu ngày gia hạn từ hệ thống hiện tại kém chính xác hơn dự kiến, outcome "tìm tài khoản cần xem" sẽ yếu hơn kỳ vọng — nhưng vẫn đo được và điều chỉnh được ở cycle sau, thay vì làm trễ toàn bộ bet vì chờ một đội khác.

Trade-off (đánh đổi): tín hiệu rủi ro yếu hơn, nhưng ownership (quyền sở hữu) rõ và khả năng giao cao hơn.

Delivery

Tuần đầu, đội không chia thành "designer (người thiết kế trải nghiệm) làm dashboard", "backend làm data pipeline" và "frontend chờ API (Application Programming Interface — giao diện lập trình ứng dụng)". Họ chọn vertical slice (lát cắt hoạt động từ giao diện tới dữ liệu và vận hành):

  • Một CSM (Customer Success Manager — người quản lý thành công khách hàng).
  • Một nhóm tài khoản.
  • Một tín hiệu usage (mức sử dụng).
  • Danh sách hoạt động end-to-end (từ đầu tới cuối).
  • Event tracking (ghi nhận sự kiện sử dụng) tối thiểu.

Scope (nhóm công việc tích hợp theo phần sản phẩm) sau đó hình thành:

  1. Tạo danh sách ứng viên.
  2. Giải thích tín hiệu rủi ro.
  3. Lọc theo owner (người phụ trách).
  4. Điều hướng tới tài khoản.
  5. Kiểm soát quyền.
  6. Đo usage (mức sử dụng).

Giữa cycle (chu kỳ thực hiện cố định), scope (nhóm công việc tích hợp theo phần sản phẩm) "giải thích tín hiệu" còn uphill (đang tìm cách làm, bất định còn cao). Dữ liệu có nhiều ngoại lệ. Đội không thêm ngày. Họ dùng scope hammering (gọt phạm vi liên tục để giữ trần thời gian):

  • Bỏ mô tả nguyên nhân tự động.
  • Hiển thị dữ liệu thô đã chuẩn hóa.
  • Giới hạn hai loại tín hiệu.
  • Đánh dấu dữ liệu trễ.
  • Giữ quyền truy cập và instrumentation (cơ chế ghi nhận dữ liệu), vì đây không phải nice-to-have (phần có thì tốt nhưng không cần để tạo giá trị cốt lõi).

Artifact → Consequence if wrong (toàn bet)

Artifact chính của bet này: Pitch đã chốt (problem, outcome, appetite, solution elements, rabbit holes, no-gos, ownership); instrumentation plan cho lượt xem, lọc, mở tài khoản; Hill Chart cập nhật theo tuần trong cycle.

Consequence if wrong: Nếu đội đánh giá sai rabbit hole "định nghĩa ticket tăng khác nhau theo nhóm khách hàng" và không phát hiện kịp trong cycle, hệ quả là scope "giải thích tín hiệu" không kịp hoàn thành đúng chuẩn — nhưng vì no-go đã loại bỏ health score và forecast, thiệt hại giới hạn ở một scope phụ, không lan sang toàn bộ bet. Đây là lý do bounded scope và no-go rõ quan trọng hơn ước tính chính xác.

Hậu quả

Đội deploy (triển khai) đúng cycle (chu kỳ thực hiện cố định). Release (lần phát hành) chưa được gọi là thành công. PM (người chịu trách nhiệm giá trị và kết quả sản phẩm) theo dõi:

  • Bao nhiêu CSM (Customer Success Manager — người quản lý thành công khách hàng) mở danh sách.
  • Bao nhiêu tài khoản được mở từ danh sách.
  • Thời gian từ vào trang tới chọn tài khoản.
  • Tỷ lệ quay lại theo tuần.
  • Tín hiệu unintended consequence (hậu quả không chủ ý): đội có bỏ quên tài khoản không bị thuật toán chọn không.

Nếu adoption (mức chấp nhận và sử dụng) thấp, đội kiểm tra value risk (rủi ro khách hàng không muốn hoặc không dùng) và usability risk (rủi ro người dùng không dùng được), không mặc định thêm feature. Nếu adoption (mức chấp nhận và sử dụng) tốt nhưng quyết định can thiệp không cải thiện, giả thuyết sản phẩm cần đổi. Nếu kết quả tốt, billing signal (tín hiệu thanh toán) hoặc alert (cảnh báo) mới quay lại shaping (định hình công việc trước cam kết) và cạnh tranh với cơ hội khác.

Tình huống tránh được feature factory (tổ chức đo thành công bằng số tính năng đã giao) vì:

  • Yêu cầu "dashboard đầy đủ" được chuyển thành problem (vấn đề).
  • Outcome (thay đổi có giá trị sau phát hành) được đặt trước solution (giải pháp).
  • Appetite (ngân sách thời gian đáng đầu tư) giới hạn đầu tư.
  • No-go (phần cố ý không làm) bảo vệ ranh giới.
  • Team topology (cấu trúc đội và cách tương tác) được xét trước commitment (cam kết có trách nhiệm).
  • Đội có quyền cắt scope (phạm vi cần làm).
  • Release (lần phát hành) không được tính là outcome (thay đổi có giá trị sau phát hành).

Senior Lens — ra quyết định trong điều kiện không hoàn hảo

1. Decision rights: ai quyết định gì

Trao quyền thất bại khi mọi người cùng "có tiếng nói" nhưng không ai biết ai quyết định.

Quyết định Quyền chính Input bắt buộc Nguồn
Strategy (chiến lược lựa chọn nơi và cách thắng), objective (mục tiêu cần đạt), phân bổ đầu tư Product leadership và business leadership Product, technology, design, finance, market Inspired
Appetite (ngân sách thời gian đáng đầu tư) Người phân bổ portfolio (danh mục đầu tư) cùng shaping group (nhóm định hình công việc) Đội thực hiện, dữ liệu, cơ hội thay thế Shape Up
Solution direction (hướng giải pháp) trong shaping (định hình công việc trước cam kết) Nhóm sản phẩm, thiết kế và kỹ thuật senior Stakeholder constraint, customer evidence Shape Up, Inspired
Có đặt bet (cược đầu tư có giới hạn) hay không Nhóm governance (cơ chế phân quyền và kiểm soát) danh mục nhỏ Pitch, risk, capacity, team fit Shape Up
Technical design (thiết kế kỹ thuật) Engineer (kỹ sư xây và vận hành sản phẩm) Product constraint, architecture, operations Inspired
Scope cut (quyết định cắt phạm vi) trong cycle (chu kỳ thực hiện cố định) Delivery team (đội giao sản phẩm) Outcome, no-go, quality floor Shape Up
Team boundary (ranh giới trách nhiệm của đội) và interaction mode (chế độ tương tác giữa đội) Product và technology leadership Cognitive load, dependency, architecture Team Topologies, Inspired
Gia hạn hoặc ngắt bet (cược đầu tư có giới hạn) Người cấp đầu tư, không phải delivery team (đội giao sản phẩm) tự quyết Hill state, must-have, opportunity cost Shape Up
Release readiness (mức sẵn sàng phát hành) Đội chịu trách nhiệm vận hành; stakeholder có veto trong phạm vi constraint Security, legal, quality, operations Inspired

PM (người chịu trách nhiệm giá trị và kết quả sản phẩm) không là sếp của designer (người thiết kế trải nghiệm) hoặc engineer (kỹ sư xây và vận hành sản phẩm). PM (người chịu trách nhiệm giá trị và kết quả sản phẩm) dẫn bằng customer knowledge (hiểu biết khách hàng), data knowledge (hiểu biết dữ liệu), business knowledge (hiểu biết kinh doanh) và evidence (bằng chứng), theo Inspired.

2. Governance tối thiểu cần có

Hệ vận hành cần sáu điểm kiểm soát:

  1. Outcome gate (cổng kiểm tra kết quả): Mọi bet (cược đầu tư có giới hạn) phải gắn vấn đề và outcome (thay đổi có giá trị sau phát hành), không chỉ feature.
  2. Evidence gate (cổng kiểm tra bằng chứng): Quy mô Discovery (khám phá để giảm rủi ro trước khi xây) tỷ lệ với rủi ro và mức đầu tư.
  3. Appetite gate (cổng kiểm tra trần đầu tư): Trần thời gian được đặt trước; không dùng estimate (ước tính công sức hoặc thời gian) làm lý do mở scope (phạm vi cần làm).
  4. Topology gate (cổng kiểm tra cấu trúc đội): Ownership (quyền sở hữu), dependency (phụ thuộc cần đội khác) và interaction mode (chế độ tương tác giữa đội) rõ trước commitment (cam kết có trách nhiệm).
  5. Circuit breaker review (đánh giá ngắt khoản đầu tư): Không tự động gia hạn.
  6. Outcome review (đánh giá kết quả): Sau release (lần phát hành), xem usage (mức sử dụng), business result (kết quả kinh doanh), tác dụng phụ và learning (hiểu biết thu được từ bằng chứng).

Không cần thêm committee (ủy ban) cho từng gate (cổng kiểm tra). Một betting forum (diễn đàn chọn đầu tư), một pitch (bản đề xuất đã định hình) tốt và một outcome review (đánh giá kết quả) ngắn có thể đủ. Mục tiêu: quyết định rõ, không tạo bureaucracy (quan liêu quy trình).

3. Điểm giống và mâu thuẫn giữa ba nguồn

Điểm giống

Cả ba nguồn cùng phản đối:

  • Giao task (tác vụ) cho cá nhân như đơn vị tối ưu.
  • Chia công việc theo silo (nhóm chức năng tách biệt).
  • Khóa solution (giải pháp) trước khi product, design và engineering cộng tác.
  • Xem release (lần phát hành) là thành công.
  • Quản lý bằng priority change (thay đổi ưu tiên) liên tục.
  • Giữ đội như nguồn lực có thể tháo lắp theo project (dự án).

Cả ba cùng cần đội ổn định, đa chức năng, có ownership (quyền sở hữu) và đủ bối cảnh để tự giải quyết.

Khác biệt về điểm bắt đầu

Shape Up bắt đầu từ delivery risk (rủi ro không giao được trong trần thời gian). Nó mạnh ở appetite (ngân sách thời gian đáng đầu tư), shaping (định hình công việc trước cam kết), scope hammering (gọt phạm vi liên tục để giữ trần thời gian) và circuit breaker (cơ chế ngắt khoản đầu tư khi hết trần thời gian).

Inspired bắt đầu từ product risk (rủi ro sản phẩm không có giá trị hoặc không khả thi). Nó mạnh ở Discovery (khám phá để giảm rủi ro trước khi xây), empowered product team (đội sản phẩm được trao quyền tìm giải pháp), outcome (thay đổi có giá trị sau phát hành) và high-integrity commitment (cam kết độ tin cậy cao).

Team Topologies bắt đầu từ flow (luồng thay đổi tạo giá trị), cognitive load (tải nhận thức phải xử lý) và Conway's Law (kiến trúc phản ánh cấu trúc giao tiếp). Nó mạnh ở team boundary (ranh giới trách nhiệm của đội), ownership (quyền sở hữu) và interaction mode (chế độ tương tác giữa đội).

Không nguồn nào thay hai nguồn còn lại.

Căng thẳng: shaped solution với empowered team

Shape Up cho nhóm senior shape (định hình) hướng giải pháp trước khi đội xây nhận dự án. Inspired nhấn mạnh đội sở hữu vấn đề và tự khám phá solution (giải pháp). Nếu áp cực đoan, hai cách mâu thuẫn:

  • Shaping (định hình công việc trước cam kết) quá sâu biến đội thành mercenary team (đội thi công theo lệnh).
  • Empowerment (quyền tự chủ tìm giải pháp) không ranh giới khiến đội lặp lại Discovery (khám phá để giảm rủi ro trước khi xây), vượt appetite (ngân sách thời gian đáng đầu tư) hoặc rời strategy (chiến lược lựa chọn nơi và cách thắng).

Phạm vi dung hòa:

  • Leadership (lãnh đạo) giao problem (vấn đề), outcome (thay đổi có giá trị sau phát hành), appetite (ngân sách thời gian đáng đầu tư) và constraint (ràng buộc).
  • Shaping group (nhóm định hình công việc) chứng minh ít nhất một hướng giải khả thi và chỉ rõ rabbit hole (chi tiết ẩn có thể hút hết thời gian).
  • Delivery team (đội giao sản phẩm) có quyền đổi chi tiết, chia scope (phạm vi cần làm) và tìm giải pháp tốt hơn trong cùng outcome (thay đổi có giá trị sau phát hành), appetite (ngân sách thời gian đáng đầu tư) và no-go (phần cố ý không làm).
  • Với vấn đề mới và value risk (rủi ro khách hàng không muốn hoặc không dùng) cao, đội bền vững nên tham gia shaping (định hình công việc trước cam kết) sớm hơn.

Căng thẳng: no backlog với nhu cầu doanh nghiệp lớn

Shape Up chủ trương không nuôi backlog (danh sách việc chờ xử lý) dài. Inspired vẫn nói tới validated product backlog (danh sách việc đã có bằng chứng đáng xây), đồng thời thừa nhận roadmap (lộ trình ưu tiên và cam kết) cần phục vụ minh bạch ưu tiên và planning (lập kế hoạch).

Decision rule (quy tắc quyết định):

  • Không dùng backlog (danh sách việc chờ xử lý) như kho nghĩa vụ vô hạn.
  • Giữ repository (kho lưu) evidence (bằng chứng), customer insight (hiểu biết khách hàng), risk (rủi ro) và constraint (ràng buộc).
  • Chỉ đưa shaped pitch (bản đề xuất đã định hình) hoặc validated item (hạng mục đã có bằng chứng) vào vùng quyết định gần.
  • Với doanh nghiệp cần regulatory planning (lập kế hoạch tuân thủ), sales coordination (phối hợp bán hàng) hoặc partner commitment (cam kết đối tác), giữ roadmap (lộ trình ưu tiên và cam kết) ở mức outcome (thay đổi có giá trị sau phát hành) và high-integrity commitment (cam kết độ tin cậy cao), không biến mọi ý tưởng thành ngày giao.

4. Khi không nên áp cycle sáu tuần máy móc

Chu kỳ sáu tuần là thiết kế của Shape Up, không phải định luật.

Không áp nguyên dạng khi:

  • Incident response (ứng phó sự cố) cần thời gian phản hồi theo phút hoặc giờ.
  • Regulatory deadline (hạn tuân thủ pháp lý) cố định, scope (phạm vi cần làm) bắt buộc.
  • Hardware (phần cứng) có lead time (thời gian chờ) sản xuất dài và chi phí đảo ngược cao.
  • Research and Development (R&D — nghiên cứu và phát triển) chưa có output (đầu ra) xác định; mục tiêu chính là learning (hiểu biết thu được từ bằng chứng).
  • Migration (chuyển đổi hệ thống) nhiều giai đoạn cần kiểm soát dữ liệu và rollback (quay lại trạng thái trước).
  • Đội vận hành platform (nền tảng nội bộ phục vụ đội khác) có demand (nhu cầu) không đồng đều và service-level objective (mục tiêu mức dịch vụ).

Vẫn giữ nguyên tắc:

  • Có trần đầu tư.
  • Chia decision point (điểm ra quyết định).
  • Không tự động gia hạn.
  • Làm rõ learning objective (mục tiêu học hỏi) hoặc delivery outcome (kết quả giao hàng).
  • Giữ circuit breaker (cơ chế ngắt khoản đầu tư khi hết trần thời gian).

5. Dấu hiệu cảnh báo

Dấu hiệu Chẩn đoán khả dĩ Phản ứng
Mọi pitch đều vừa đúng appetite Scope bị ép giả hoặc appetite được chọn sau estimate Kiểm tra lại value, no-go và bằng chứng kỹ thuật — Shape Up
Đội luôn cắt testing hoặc instrumentation Quality floor không được governance bảo vệ Ghi rõ phần không được cắt — Inspired
Nhiều scope nằm uphill sát cuối cycle Shaping yếu, rabbit hole chưa xử lý Ngắt, định hình lại; không ép overtime — Shape Up
Một bet cần nhiều đội đồng thời Team boundary hoặc platform thiếu self-service Sửa topology hoặc interaction mode — Team Topologies
Platform team nhận hàng trăm ticket Platform đang là service desk, không là sản phẩm Xây self-service và thinnest viable platform — Team Topologies
PM dành phần lớn thời gian cập nhật tiến độ PM bị biến thành project manager Tách delivery coordination khi quy mô cần; trả PM về customer, data và strategy — Inspired
Release đúng hạn nhưng không ai dùng Output bị nhầm với outcome Chạy value review, không mặc định thêm feature — Inspired
Stakeholder đưa no-go trở lại giữa cycle Decision rights yếu Escalate qua người cấp bet, không thương lượng ngầm — Shape Up, Inspired
Priority đổi liên tục Leadership chưa bảo vệ commitment Tạo intake khẩn cấp rõ và giữ đội không bị gián đoạn — Shape Up, Inspired
Đội "tự chủ" nhưng phải xin mọi thay đổi Autonomy không có architecture và ownership hỗ trợ Sửa team boundary, Team API và platform — Team Topologies

6. Feature factory không được sửa bằng đổi tên artifact

Các anti-pattern (mẫu hành vi gây hại):

  • Đổi epic (nhóm công việc lớn) thành bet (cược đầu tư có giới hạn) nhưng vẫn khóa scope (phạm vi cần làm).
  • Đổi deadline (hạn chót) thành appetite (ngân sách thời gian đáng đầu tư) nhưng vẫn phạt đội khi cắt feature.
  • Gọi requirement document (tài liệu yêu cầu) là pitch (bản đề xuất đã định hình) dù không có no-go (phần cố ý không làm).
  • Gọi component team (đội sở hữu thành phần kỹ thuật) là platform team (đội cung cấp nền tảng nội bộ như sản phẩm) dù không có self-service (tự phục vụ không cần chờ người xử lý).
  • Gọi squad (đội nhỏ đa chức năng) là empowered product team (đội sản phẩm được trao quyền tìm giải pháp) nhưng leadership (lãnh đạo) vẫn quyết solution (giải pháp).
  • Dùng Hill Chart (biểu đồ tiến độ theo mức bất định) để giám sát cá nhân.
  • Dùng cycle (chu kỳ thực hiện cố định) để tăng utilization (tỷ lệ thời gian con người luôn bận), thay vì giảm work in progress (WIP — lượng việc đang làm dở) và bảo vệ focus (tập trung).
  • Ăn mừng số bet đã ship thay vì outcome (thay đổi có giá trị sau phát hành).

Tên mới không đổi quyền quyết định, luồng tiền, ranh giới đội hoặc hệ thống khen thưởng. Inspired nhấn mạnh thứ tổ chức thưởng sẽ tạo văn hóa thật; Team Topologies nhấn mạnh cấu trúc giao tiếp tạo kiến trúc thật; Shape Up nhấn mạnh giới hạn chỉ có tác dụng khi đội thực sự được bảo vệ khỏi gián đoạn.

7. Escalation: khi nào và lên đâu

Ranh giới escalation (đưa quyết định lên cấp có thẩm quyền) cần rõ trước khi xảy ra, không phải được phát minh giữa khủng hoảng.

Tình huống Escalate tới Vì sao không tự xử lý ở cấp đội
Stakeholder yêu cầu đưa lại no-go giữa cycle Người/nhóm đã cấp bet (betting table hoặc tương đương) Scope đã được bet chốt; đội không có quyền đơn phương mở lại phạm vi đã thống nhất
Rabbit hole lớn đe dọa appetite toàn bộ Betting table hoặc shaping group Cần quyết định định hình lại hoặc ngắt bet, vượt quyền scope cut thường ngày của đội
Áp lực cắt security, privacy hoặc data integrity để kịp cycle Chủ sở hữu quality floor (thường là security/legal leadership) Đây là ranh giới không được cắt theo governance; đội không có quyền tự miễn trừ
Dependency cấu trúc lặp lại giữa nhiều bet Product và technology leadership Đây là vấn đề team topology, cần thay đổi cấu trúc, không phải xử lý theo từng bet
Outcome không đổi sau nhiều cycle liên tiếp Product leadership Có thể cần đổi strategy hoặc giả thuyết sản phẩm, vượt quyền một delivery team

Nguyên tắc chung: đội tự quyết trong ranh giới pitch đã chốt (scope, kỹ thuật, cách triển khai); mọi thay đổi ranh giới đó (outcome, appetite, no-go, quality floor) phải đi qua đúng người đã tạo ra ranh giới.

Quick reference

Checklist trước khi đặt bet

Kiểm tra Điều kiện tối thiểu Nguồn
Problem Có tình huống và hiện trạng cụ thể Shape Up, Inspired
Outcome Có thay đổi mong muốn, không chỉ output Inspired
Evidence Rủi ro lớn đã có bằng chứng tương xứng Inspired
Appetite Có trần đầu tư đặt trước Shape Up
Solution Có hướng giải kết nối được nhưng chưa khóa chi tiết Shape Up
Rabbit holes Ẩn số lớn đã được nêu và xử lý hoặc loại bỏ Shape Up
No-gos Phần cố ý không làm được ghi rõ Shape Up
Ownership Một đội chịu trách nhiệm end-to-end Team Topologies, Inspired
Interaction Dependency và interaction mode rõ Team Topologies
Measurement Có instrumentation, baseline và tín hiệu tác dụng phụ Inspired
Circuit breaker Có quy tắc dừng hoặc định hình lại Shape Up

Checklist trong cycle

  • Bảo vệ đội khỏi gián đoạn — Shape Up.
  • Tạo vertical slice (lát cắt hoạt động từ giao diện tới dữ liệu và vận hành) sớm — Shape Up.
  • Tổ chức việc theo scope (nhóm công việc tích hợp theo phần sản phẩm), không theo chức danh — Shape Up.
  • Theo dõi phần uphill (đang tìm cách làm, bất định còn cao), không chỉ số task (tác vụ) xong — Shape Up.
  • Cắt nice-to-have (phần có thì tốt nhưng không cần để tạo giá trị cốt lõi) trước — Shape Up.
  • Không cắt security, privacy, data integrity, accessibility và khả năng đo tối thiểu — Inspired.
  • Giữ interaction mode (chế độ tương tác giữa đội) đúng mục đích và có thời hạn — Team Topologies.
  • Escalate khi no-go (phần cố ý không làm), outcome (thay đổi có giá trị sau phát hành) hoặc quality floor (ngưỡng chất lượng tối thiểu) bị đe dọa.

Quy tắc cuối cycle

Trạng thái Quyết định
Core value đã hoạt động, phần còn lại là nice-to-have Cắt và deploy
Phần còn lại đều must-have và downhill Có thể xin gia hạn ngoại lệ
Must-have vẫn uphill Ngắt và shape lại
Outcome không còn quan trọng Dừng
Dependency cấu trúc chặn liên tục Sửa team topology trước bet mới
Đã deploy nhưng chưa có dữ liệu outcome Chưa tuyên bố thành công

Thuật ngữ sử dụng trong chương

Thuật ngữ tiếng Anh Acronym Giải nghĩa tiếng Việt Ngữ cảnh sử dụng
Product Manager PM Người chịu trách nhiệm giá trị và kết quả sản phẩm Vai trò sản phẩm
Feature factory — Tổ chức đo thành công bằng số tính năng đã giao Chẩn đoán operating model
Operating model — Cách tổ chức phân quyền, ra quyết định và giao giá trị Thiết kế hệ vận hành
Outcome — Thay đổi có giá trị sau phát hành Mục tiêu đầu tư
Output — Thứ đã xây hoặc phát hành Không đồng nghĩa kết quả
Discovery — Khám phá để giảm rủi ro trước khi xây Kiểm tra giá trị và giải pháp
Delivery — Xây, kiểm thử và phát hành đạt chuẩn vận hành Đưa giải pháp vào production
Shaping — Định hình công việc trước cam kết Chuẩn bị khoản đầu tư
Appetite — Ngân sách thời gian đáng đầu tư Trần đầu tư
Estimate — Ước tính công sức hoặc thời gian Dự báo, không phải trần
Pitch — Bản đề xuất đã định hình Đầu vào betting
Bet — Khoản đầu tư có giới hạn Quyết định danh mục
Betting table — Diễn đàn chọn khoản đầu tư Governance danh mục
Scope — Phạm vi hoặc nhóm công việc tích hợp Điều chỉnh trong delivery
Scope hammering — Gọt phạm vi để giữ trần thời gian Giao đúng cycle
Circuit breaker — Cơ chế ngắt khi hết trần đầu tư Chống gia hạn tự động
Rabbit hole — Chi tiết ẩn có thể hút hết thời gian Rủi ro shaping
No-go — Phần cố ý không làm Bảo vệ ranh giới
Breadboard — Sơ đồ nơi chốn, tương tác và kết nối Phác giải pháp
Fat-marker sketch — Phác thảo nét thô, tránh khóa chi tiết Phác giao diện
Vertical slice — Lát cắt chạy từ giao diện tới dữ liệu và vận hành Tích hợp sớm
Hill Chart — Biểu đồ tiến độ theo mức bất định Theo dõi uphill/downhill
Stream-aligned team — Đội căn chỉnh theo luồng giá trị Đội sở hữu outcome
Enabling team — Đội giúp đội khác học và nâng năng lực Facilitating tạm thời
Complicated-subsystem team — Đội sở hữu tiểu hệ thống cần chuyên môn sâu Giảm cognitive load
Platform team — Đội cung cấp nền tảng nội bộ như sản phẩm Tạo self-service
Cognitive load — Tải nhận thức đội phải xử lý Thiết kế ranh giới đội
Conway's Law — Kiến trúc phản ánh cấu trúc giao tiếp Thiết kế tổ chức
Collaboration — Hai đội cùng khám phá sát nhau Miền mới, bất định
X-as-a-Service — Đội này tiêu thụ dịch vụ chuẩn từ đội khác Tương tác ít
Facilitating — Đội giúp đội khác học hoặc gỡ trở ngại Nâng năng lực
Team API API Giao diện và quy ước tương tác của đội Làm rõ cách phối hợp
Work in progress WIP Lượng việc đang làm dở Quản trị flow
High-integrity commitment — Cam kết sau khi đã giảm đủ rủi ro Ngày giao đáng tin
Value risk — Rủi ro khách hàng không muốn hoặc không dùng Discovery
Usability risk — Rủi ro người dùng không dùng được Discovery
Feasibility risk — Rủi ro không thể xây trong điều kiện hiện có Discovery
Business viability risk — Rủi ro không phù hợp doanh nghiệp Discovery
Ethical risk — Rủi ro giải pháp gây hại dù hợp pháp Governance sản phẩm
Instrumentation — Cơ chế ghi nhận dữ liệu sử dụng và vận hành Đo outcome
Baseline — Mức hiện tại dùng để so sánh Đánh giá thay đổi
Empowered product team — Đội được trao quyền tìm cách đạt outcome Chống feature factory
Autonomy — Quyền tự chủ chọn cách giải mục tiêu Đi cùng accountability
Accountability — Trách nhiệm giải trình cho kết quả Governance
Dependency — Phụ thuộc cần đội hoặc hệ thống khác Planning và topology
Hand-off — Bàn giao công việc giữa người hoặc đội Nguồn chậm và mất bối cảnh
Self-service — Tự dùng dịch vụ không chờ người xử lý Platform
Productization — Đưa giải pháp lên chuẩn vận hành thật Delivery
Prototype — Mẫu thử nhanh để học Discovery
Release — Lần phát hành sản phẩm Output, chưa chắc outcome

Nguồn và giới hạn

Shape Up — Ryan Singer

Đóng góp chính:

  • Appetite (ngân sách thời gian đáng đầu tư).
  • Shaping (định hình công việc trước cam kết).
  • Pitch (bản đề xuất đã định hình), rabbit hole (chi tiết ẩn có thể hút hết thời gian) và no-go (phần cố ý không làm).
  • Bet (cược đầu tư có giới hạn) thay backlog (danh sách việc chờ xử lý) vô hạn.
  • Cycle (chu kỳ thực hiện cố định), scope hammering (gọt phạm vi để giữ trần thời gian), Hill Chart (biểu đồ tiến độ theo mức bất định) và circuit breaker (cơ chế ngắt khi hết trần đầu tư).
  • Giao dự án cho đội, không giao task (tác vụ) định sẵn.

Giới hạn:

  • Xuất phát từ Basecamp: đội nhỏ, senior, độ tin cậy cao và dependency (phụ thuộc cần đội khác) tương đối thấp.
  • Chu kỳ sáu tuần không phù hợp máy móc với incident (sự cố), hardware (phần cứng), compliance deadline (hạn tuân thủ) hoặc R&D (Research and Development — nghiên cứu và phát triển).
  • Ít nhấn mạnh `quantita