# Escaping the Build Trap: cuốn sách giúp FDE đo việc mình làm bằng kết quả của khách, không bằng số tính năng

> Melissa Perri viết cho product manager, nhưng người đáng đọc cuốn sách năm 2018 này nhất lại là kỹ sư ngồi ở văn phòng khách hàng và mỗi tuần phải chọn build gì tiếp theo.

Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-escaping-the-build-trap-melissa-perri/

Một đội kỹ sư có thể giao đủ mọi tính năng đúng lịch mà vẫn thất bại. Melissa Perri đặt tên cho tình trạng này là "build trap": những công ty sống chết theo output, cứ thế đẩy tính năng ra cho kịp tiến độ.

Cuốn sách của bà, *Escaping the Build Trap: How Effective Product Management Creates Real Value*, do O'Reilly xuất bản năm 2018. Nhìn bìa thì đây là sách product management. Nhưng nếu bạn đang nhắm tới vai trò FDE, nó đúng hơn là một cuốn sách dạy cách không biến thành xưởng làm tính năng theo đơn đặt hàng của khách.

Khi bạn ngồi ngay tại công ty khách và build sát người dùng, tốc độ là thứ dễ thấy nhất. Chính vì thế mà cái bẫy càng khó nhận ra: càng nhiều thứ được ship thì càng dễ có cảm giác dự án đang chạy tốt.

## Vấn đề nằm ở thước đo chứ không ở sự chăm chỉ

Định nghĩa trong sách rất gọn: build trap là khi tổ chức mắc kẹt trong việc đo thành công bằng output thay vì outcome. Bản tóm tắt của getAbstract diễn đạt cùng ý theo cách khác: các công ty thường đặt những gì mình ship lên trên giá trị mà khách thực sự nhận được.

Output là những gì đội làm ra, như tính năng, API hay màn hình. Outcome là những gì thay đổi ở phía khách nhờ các thứ đó. Perri không bảo output là xấu. Tại ProductCon 2022, bà nói output là phương tiện để đạt mục đích. Theo ghi chép của Dragonboat, cái bẫy chỉ xuất hiện khi không có mục tiêu rõ, và đội cứ "build rồi build rồi build".

Thử hình dung bạn là FDE triển khai hệ thống xử lý hóa đơn cho một công ty logistics. Sau sáu tuần, báo cáo ghi chín tính năng đã giao và không trễ hạn lần nào. Nhưng kế toán viên vẫn mất khoảng 40 phút cho mỗi hóa đơn, y như trước khi bạn đến. Xét theo output, dự án thành công. Xét theo outcome, chưa có gì thay đổi.

Giờ đặt lại mục tiêu ngay từ tuần đầu: giảm thời gian xử lý một hóa đơn từ 40 phút xuống 15 phút. Rất có thể chỉ ba trong chín tính năng kia thực sự cần, còn sáu tuần ấy lẽ ra nên dùng để ngồi cạnh kế toán viên và xem họ tắc ở bước nào.

**Điểm mấu chốt:** Số tính năng đã giao không cho biết khách hàng đã khá hơn hay chưa.

## Chiến lược là bộ lọc, không phải bản kế hoạch

Ý thứ hai đáng giá với FDE nằm ở cách sách định nghĩa chiến lược. Theo Perri, chiến lược là một khung ra quyết định có thể đem ra dùng ngay, giúp đội hành động để đạt outcome mong muốn. Nó không phải một bản kế hoạch liệt kê việc cần làm.

Ở công ty khách, khác biệt này rất thực tế. Quay lại ví dụ hóa đơn: giữa tuần, trưởng phòng tài chính xin thêm nút xuất báo cáo ra PDF. Nếu chỉ có kế hoạch, bạn sẽ hỏi việc này có nằm trong scope không.

Nếu có một khung quyết định, bạn sẽ hỏi việc này có giúp kéo con số 40 phút xuống không. Nếu không giúp, bạn có lý do rõ ràng để đẩy nó xuống sau, và lý do đó khách cũng hiểu được.

Đó là lý do bài học này hợp với FDE hơn cả với product manager trong văn phòng. FDE nghe yêu cầu trực tiếp mỗi ngày, và mỗi lần gật đầu là thêm một output. Không có bộ lọc thì backlog sẽ thành danh sách mong muốn của người nói to nhất trong phòng họp.

## Áp dụng sai thì outcome cũng thành cái bẫy

Lỗi dễ mắc nhất khi vừa đọc xong là biến outcome thành tấm khiên để từ chối mọi yêu cầu. Nút PDF kia có thể là thứ trưởng phòng tài chính cần để trình số liệu lên cấp trên, tức nó phục vụ một vấn đề thật mà bạn chưa nghe tới. Trước khi nói "chưa", hãy hỏi họ cần nút đó để làm gì.

Lỗi tiếp theo là chọn một outcome không đo được, kiểu "khách hài lòng hơn". Con số 40 phút có ích chính vì đo được trước và sau. Một mục tiêu không đo được thì không lọc được việc nào cả.

Lỗi cuối cùng là tự đặt outcome rồi giữ trong đầu. Nếu khách chưa đồng ý với mốc 15 phút, bộ lọc của bạn chỉ là ý kiến cá nhân, và mỗi lần từ chối sẽ thành một cuộc tranh cãi. Hãy chốt con số đó cùng khách ngay tuần đầu.

Trang sách trên website của Perri gọi đích đến là xây một văn hóa lấy khách hàng làm trung tâm, tập trung vào outcome hơn output. Một FDE không thay được văn hóa của cả công ty khách. Nhưng bạn có thể đem cách nghĩ đó vào từng buổi họp, từng ticket và từng báo cáo tuần.

## Ai nên đọc, và đọc theo cách nào

Cuốn này hợp nhất với developer có từ hai đến tám năm kinh nghiệm, quen nhận ticket và hoàn thành ticket, nay muốn chuyển sang vai trò phải tự quyết định nên làm gì. Nên đọc trước khi đi dự án triển khai đầu tiên, vì cái bẫy dễ sập nhất trong vài tuần đầu, lúc bạn đang cần chứng minh mình làm được việc.

Đừng đọc một mạch rồi gấp sách lại. Đọc xong phần định nghĩa build trap, mở backlog của dự án bạn đang làm và ghi bên cạnh mỗi đầu việc một outcome đo được. Đọc đến phần chiến lược, thử viết một câu mô tả mục tiêu cho khách hiện tại đủ cụ thể để dùng làm bộ lọc.

Khi đọc mô tả công việc FDE, để ý xem họ nói về tác động lên khách hay chỉ liệt kê công nghệ cần biết. Trong CV, đổi "xây 12 endpoint" thành một dòng có con số trước và sau ở phía người dùng. Một dòng như vậy cho người đọc CV thấy bạn đã quen nghĩ theo outcome, đúng thứ cuốn sách này dạy.

Ở công ty khách, không ai nhớ bạn đã giao bao nhiêu tính năng. Người ta nhớ việc gì đã nhanh hơn, rẻ hơn hoặc bớt đau đầu hơn kể từ khi bạn đến.

**Thử ngay tuần này:**

- Lấy năm ticket đang mở trong dự án hiện tại, viết bên cạnh mỗi ticket nó làm thay đổi con số nào của khách. Ticket nào để trống thì đánh dấu để hỏi lại
- Sửa một dòng trong CV từ 'đã xây X tính năng' thành 'đã giảm hoặc tăng chỉ số Y từ A xuống B'
- Trước buổi họp kế tiếp với khách, chuẩn bị một câu hỏi về outcome: 'Nếu việc này xong, điều gì ở phía anh chị sẽ khác đi?'

## Nguồn

- [Escaping the Build Trap. How Effective Product Management Creates Real Value - Melissa Perri (Helion)](https://helion.pl/ksiazki/escaping-the-build-trap-how-effective-product-management-creates-real-value-melissa-perri,e_11lg.htm)

- [Melissa Perri – Escaping the Build Trap (author's book page)](https://melissaperri.com/book)

- [Escaping the Build Trap – getAbstract summary](https://www.getabstract.com/en/summary/escaping-the-build-trap/44962)

- [Our Favorite Moments From ProductCon 2022 (Dragonboat)](https://dragonboat.io/?p=714)

- [Lessons from Melissa Perri (Antoine Buteau)](https://www.antoinebuteau.com/lessons-from-melissa-perri.md)