Org Design for Product

Cấu trúc đội quyết định sản phẩm ra sao — không phải ngược lại

Có một quan sát đã cũ và vẫn đúng: sản phẩm bạn làm ra sẽ có hình dạng giống cách các đội của bạn giao tiếp với nhau. Ba đội làm một luồng thanh toán thì gần như chắc chắn sẽ ra một luồng thanh toán có ba mảnh ghép vụng về ở chỗ giáp ranh.

Hệ quả cho người làm sản phẩm: khi bạn thấy một vấn đề dai dẳng mà sửa mãi không hết — bàn giao chậm, chất lượng chỗ giáp ranh kém, không ai chịu trách nhiệm cuối — rất có thể đó không phải vấn đề con người hay quy trình. Đó là vấn đề đường ranh giới.

Và vì điều đó đúng theo cả hai chiều, bạn dùng được nó một cách chủ động: vẽ ranh giới đội theo hình dạng sản phẩm bạn muốn có.

Ba kiểu chia đội — và cái giá của từng kiểu

Mặc định nên chọn: chia theo hành trình hoặc lĩnh vực. Nó là kiểu duy nhất cho phép một đội tự đi từ ý tưởng tới tay người dùng mà không phải xin ai. Đội nền tảng chỉ nên lập khi nhiều đội đã thật sự đau vì làm lại cùng một thứ — lập quá sớm thì nó dựng thứ chưa ai cần.

Dấu hiệu cấu trúc đang sai — đọc từ triệu chứng ngược về nguyên nhân

Kích thước và ranh giới — vài con số thực tế

• Năm tới chín người một đội. Dưới năm thì mong manh khi có người nghỉ; trên chín thì số cặp giao tiếp tăng nhanh hơn số người và đội tự tách thành phe.
• Một đội nên tự giao được một thứ có giá trị mà không cần xin đội khác. Đây là phép thử quan trọng nhất. Nếu không đạt, ranh giới đang sai.
• Một chủ sở hữu cho mỗi vùng. Hai chủ nghĩa là không chủ.
• Mỗi đội một chỉ số kết quả mà họ tác động được thật. Chỉ số họ không điều khiển được sẽ bị lờ đi trong vòng một quý.
• Phụ thuộc chéo là chi phí, hãy đếm nó. Mỗi sprint ghi lại số lần một đội phải chờ đội khác. Con số này là bằng chứng để đề xuất tái cấu trúc.

Hai tình huống thực tế

Công ty 30 người, chia theo lớp kỹ thuật, mọi thứ đều chậm. Triệu chứng: tính năng nào cũng cần cả ba đội, mỗi bàn giao mất một sprint. Cách sửa: gom thành ba đội theo hành trình (thu hút, kích hoạt, giữ chân), mỗi đội có đủ frontend, backend và một designer. Cái giá chấp nhận: một chút trùng lặp kỹ thuật trong 6 tháng đầu. Cái được: mỗi đội tự giao được, và số cuộc họp điều phối giảm mạnh.

Công ty 120 người, các đội tự chủ nhưng dựng lại cùng một thứ ba lần. Ba đội tự làm ba hệ thống gửi thông báo. Cách sửa: lập đội nền tảng — bây giờ mới đúng lúc, vì nỗi đau đã có thật và đã đo được. Điều kiện bắt buộc: đội nền tảng phải cung cấp dịch vụ tự phục vụ, không phải trở thành hàng đợi mà các đội khác xếp hàng.

Đổi cấu trúc — làm cho đúng

• Đừng đổi quá hai lần một năm. Mỗi lần đổi khiến đội mất khoảng một quý để lấy lại nhịp. Đổi liên tục thì không bao giờ ra được hiệu suất.
• Nói lý do bằng vấn đề, không bằng sơ đồ. "Chúng ta đang mất một sprint cho mỗi lần bàn giao" thuyết phục hơn một hình vẽ ô vuông mới.
• Đổi ranh giới thì phải đổi cả quyền quyết. Vẽ lại sơ đồ mà quyền vẫn nằm chỗ cũ thì không gì thay đổi cả — đây là sai lầm phổ biến nhất.
• Có người ghét việc đổi, và cần được nói chuyện riêng. Tái cấu trúc luôn là chuyện con người trước khi là chuyện sơ đồ.
• Định trước cách đo xem đổi có ăn thua không: thời gian từ ý tưởng tới phát hành, số phụ thuộc chéo mỗi sprint. Đo trước khi đổi, nếu không sẽ không bao giờ biết kết quả.

Chạy một buổi vẽ lại ranh giới — nửa ngày, sáu bước

Tái cấu trúc thường được quyết trong phòng kín rồi công bố, và đó là lý do nó hay bị chống đối. Buổi làm việc dưới đây đưa chính những người bị ảnh hưởng vào việc vẽ.

• Bước 1 (30 phút) — Vẽ luồng giá trị thật. Lấy ba tính năng gần nhất, dán lên tường từng chặng nó đã đi qua, ghi rõ đội nào chạm vào và chờ bao lâu ở mỗi lần bàn giao. Dùng việc đã xảy ra, không dùng quy trình trên giấy.
• Bước 2 (20 phút) — Đếm lần bàn giao. Mỗi lần công việc đổi tay là một gạch. Con số này thường làm cả phòng im lặng, và nó là dữ kiện mạnh hơn mọi lập luận.
• Bước 3 (40 phút) — Khoanh vùng đau. Chỗ nào chờ lâu nhất, chỗ nào lỗi hay rơi vào, chỗ nào không ai nhận trách nhiệm. Đánh dấu ba chỗ tệ nhất.
• Bước 4 (40 phút) — Thử ranh giới mới trên giấy. Vẽ hai phương án chia đội khác nhau, rồi cho ba tính năng cũ chạy lại qua từng phương án. Đếm lại số lần bàn giao. Phương án nào giảm nhiều nhất thì thắng.
• Bước 5 (30 phút) — Kiểm bằng phép thử tự chủ. Với mỗi đội mới, hỏi: đội này tự giao được một thứ có giá trị mà không xin ai chứ? Nếu không, ranh giới vẫn sai, quay lại bước 4.
• Bước 6 (20 phút) — Chốt quyền quyết và cách đo. Mỗi đội mới được quyền quyết gì mà trước đây phải xin? Ghi số đo hôm nay — thời gian từ ý tưởng tới phát hành, số phụ thuộc chéo mỗi sprint — để ba tháng nữa so lại.

Vì sao bước 2 và bước 5 là hai bước không được bỏ: bước 2 biến cảm giác "mọi thứ chậm" thành một con số tranh luận được; bước 5 là phép thử duy nhất phân biệt một sơ đồ đẹp với một cấu trúc chạy được.

Ví dụ một lần vẽ lại — công ty fintech 45 người

Trước: bốn đội theo lớp kỹ thuật — web, mobile, backend, dữ liệu. Một tính năng "nhắc nợ tự động" đi qua cả bốn đội, sáu lần bàn giao, mất hai tháng cho phần việc mà ai cũng đồng ý là ba tuần.

Bước 2 cho ra con số: ba tính năng gần nhất trung bình 5,7 lần bàn giao, thời gian chờ chiếm 61% tổng thời gian. Không ai lười — mọi người đều bận, chỉ là bận chờ nhau.

Sau: ba đội theo lĩnh vực — mở tài khoản, giao dịch, thu hồi nợ — mỗi đội có web, mobile, backend và một người dữ liệu. Đội dữ liệu cũ giải thể, người chia về ba đội.

Cái giá đã chấp nhận và nói trước: ba đội sẽ viết lại vài đoạn xử lý dữ liệu giống nhau trong 6 tháng đầu; một người dữ liệu sẽ mất người cùng chuyên môn để trao đổi, nên lập một nhóm nghề gặp nhau hai tuần một lần để bù.

Đo sau ba tháng: số lần bàn giao trung bình còn 1,8; thời gian từ ý tưởng tới phát hành giảm còn khoảng một phần ba. Phần trùng lặp kỹ thuật có xảy ra thật và được chấp nhận vì đã tính trước — đó là khác biệt giữa một đánh đổi và một tai nạn.

Vì sao vai trò của bạn cần cái này

Definition of done

• Mỗi đội tự giao được một thứ có giá trị mà không phải xin đội khác.
• Mỗi vùng có đúng một chủ sở hữu, kể cả vùng giáp ranh xấu xí.
• Mỗi đội có một chỉ số kết quả họ thật sự tác động được.
• Số phụ thuộc chéo mỗi sprint được đếm và theo dõi.
• Đội nền tảng chỉ tồn tại khi nỗi đau trùng lặp đã đo được, và nó tự phục vụ chứ không thành hàng đợi.
• Mỗi lần đổi cấu trúc có kèm đổi quyền quyết và có cách đo trước/sau.