# The Lean Startup của Eric Ries: cuốn sách giúp FDE biến pilot AI thành một thí nghiệm có tiêu chí dừng

> Cuốn sách viết cho các nhà sáng lập từ năm 2011 vẫn trả lời được câu hỏi mà FDE nào cũng gặp ở giữa một pilot: tiếp tục hay đổi hướng?

Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-the-lean-startup-eric-ries-pilot-ai-nhu-mot-thi-nghiem/

Thử hình dung một kịch bản: demo chạy tốt, khách hàng gật đầu, rồi tuần nọ nối tuần kia mà không ai dám nói pilot đã thành công hay thất bại. Trong kịch bản đó, vấn đề không nằm ở model. Nó nằm ở chỗ ngay từ đầu không ai viết ra thế nào thì gọi là thất bại.

Eric Ries viết *The Lean Startup* cho người lập công ty chứ không phải cho kỹ sư triển khai AI. Bản Mỹ, do Crown Business xuất bản, mang phụ đề "How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses"; bản Anh của Portfolio Penguin, phát hành ngày 06/10/2011, dùng phụ đề "How Constant Innovation Creates Radically Successful Businesses".

Penguin cho biết sách đã bán hơn một triệu bản. Với FDE, lý do đáng đọc lại nằm ở chỗ khác: cuốn sách rèn đúng kỹ năng bạn cần tại khách hàng, đó là thiết kế pilot như một thí nghiệm có giả thuyết, có số đo và có điểm dừng.

## Vòng lặp nào đứng sau cuốn sách?

Hạt nhân của phương pháp là vòng Build-Measure-Learn. Theo các nguyên tắc Ries công bố, việc cốt lõi của startup là biến ý tưởng thành sản phẩm, đo cách khách hàng phản ứng, rồi học từ đó để quyết định pivot hay persevere. Thay "sản phẩm" bằng "pilot AI" là bạn có ngay quy trình làm việc của một FDE.

Trang Principles cũng nói thẳng rằng bạn không cần làm việc trong gara mới được coi là đang ở một startup. Nói cách khác, một FDE đang triển khai agent trong văn phòng của một hãng bảo hiểm cũng đang làm đúng loại việc mà cuốn sách mô tả.

## Ý thứ nhất: tiến độ là điều đã kiểm chứng, không phải điều đã giao

Ries đề xuất validated learning làm thước đo tiến độ. Với FDE, điều này thay đổi hẳn cách viết báo cáo tuần. Câu "đã tích hợp xong API và dựng xong pipeline RAG" chỉ cho biết bạn bận rộn, chưa cho biết bạn học được gì.

Thử hình dung một pilot agent phân loại ticket hỗ trợ cho một công ty bảo hiểm. Báo cáo kiểu validated learning sẽ là: "Sau hai tuần, trong 500 ticket thuộc nhóm đang thử, agent xử lý đúng 120 ticket mà không cần người can thiệp". Con số đó cho biết một giả định đúng hay sai; một danh sách việc đã làm thì không.

## Ý thứ hai: chỉ build thứ đủ để đo

Nếu vòng lặp bắt đầu bằng Build và mục đích của Build là để Measure, thì bản dựng đầu tiên chỉ cần đủ để đo một giả định.

Áp vào ví dụ trên, giả định đáng thử không phải "LLM đọc được ticket", vì điều đó gần như chắc chắn đúng. Giả định thật là đội hỗ trợ của khách hàng sẽ tin kết quả của agent đến mức bỏ bước kiểm tra lại.

Vì thế, bản dựng đầu tiên có thể chỉ là một bảng gợi ý phân loại đặt cạnh hàng đợi ticket, kèm số liệu đo xem nhân viên chấp nhận bao nhiêu gợi ý. Dựng nhiều hơn thế là bỏ công khi chưa biết việc đó có đáng làm hay không.

**Điểm mấu chốt:** Pilot không trả lời câu hỏi "có chạy được không" mà trả lời "giả định nào đúng".

## Ý thứ ba: quyết định dừng phải được viết ra trước

Mỗi vòng Build-Measure-Learn kết thúc bằng một quyết định: pivot, tức đổi hướng, hay persevere, tức đi tiếp. Trang sách chính thức mô tả cuốn sách có hẳn một phương pháp để ra quyết định này.

Quyết định đó chỉ có giá trị khi đi kèm innovation accounting, phần mà các nguyên tắc của Lean Startup gọi là "những thứ nhàm chán": cách theo dõi tiến độ và buộc người làm thí nghiệm chịu trách nhiệm về kết quả. Tristan Kromer của Kromatic cụ thể hóa điều này bằng hai chỉ số đặt trước: một tiêu chí thành công và một điều kiện thất bại.

Lý do, theo Kromer, là đặt tiêu chí rõ ràng trước khi bằng chứng hiện ra giúp giảm thiên kiến khi đã nhìn thấy dữ liệu. Ông cũng cho rằng quyết định có bốn kết cục chứ không chỉ hai: ngoài pivot và persevere còn có scale và kill.

Quay lại ví dụ: trước khi bắt đầu, bạn và khách hàng thống nhất rằng sau hai tuần, agent phải tự xử lý ít nhất 40% số ticket thuộc nhóm đang thử thì mới mở rộng, và dưới 20% thì dừng. Kết quả 120 trên 500 ticket trong cùng hai tuần đó là 24%: không đủ để scale, nhưng chưa chạm điều kiện kill.

Lúc đó không còn tranh luận cảm tính nữa. Bạn pivot, chẳng hạn thu hẹp sang một loại ticket mà agent làm tốt, rồi chạy lại một vòng hai tuần với cùng cách đo.

## Tiêu chí dừng hỏng ở đâu?

Lỗi phổ biến nhất là dời ngưỡng sau khi thấy số. Kết quả ra 24%, ai đó đề nghị "thật ra 20% đã là tốt rồi", và ngưỡng 40% lặng lẽ biến mất. Đây chính là thiên kiến mà Kromer muốn chặn: một khi đã nhìn thấy dữ liệu, ai cũng có lý do để đọc nó theo hướng mình muốn.

Lỗi thứ hai là quay về đếm việc đã giao. Khi số liệu chưa đẹp, báo cáo rất dễ trượt sang "đã thêm ba connector, đã tinh chỉnh prompt". Những dòng đó có thể đúng, nhưng chúng không thay được câu trả lời cho giả định, và validated learning đòi hỏi đúng câu trả lời ấy.

Lỗi thứ ba khó thấy hơn: ngưỡng và kết quả đo trên hai khung thời gian khác nhau. Đặt ngưỡng cho hai tuần nhưng báo cáo số của một tuần, hoặc ngược lại, thì phép so sánh 24% với 40% mất nghĩa.

Một cách phòng hợp lý là gửi email chốt ngưỡng, khung thời gian và bốn kết cục cho khách hàng trước khi chạy, để không ai sửa được sau.

## Nên đọc thế nào, và ai nên đọc?

Cuốn sách hợp nhất với kỹ sư đã từng chạy ít nhất một pilot kéo dài không có hồi kết. Nên đọc phần về vòng Build-Measure-Learn và validated learning trước khi gặp khách hàng, phần innovation accounting khi soạn kế hoạch pilot, còn phần pivot hay persevere thì đọc trước buổi review giữa kỳ.

Tài liệu chính thức diễn đạt bằng ngôn ngữ startup, nên bạn phải tự dịch "khách hàng của startup" thành "người dùng cuối tại công ty khách hàng". Nếu khách hàng của bạn là tập đoàn lớn, đọc tiếp *The Startup Way* (2017), cuốn sau của Ries mà Penguin Random House mô tả là hướng tới các doanh nghiệp như GE và Toyota.

Về sự nghiệp, kỹ năng này dễ chứng minh hơn bạn nghĩ. Khi đọc một job description FDE, hãy xem vai trò đó có giao cho bạn việc định phạm vi pilot và đặt tiêu chí thành công hay không; nếu có, hãy đưa kỹ năng này lên đầu CV.

Một dòng kiểu "đặt ngưỡng 40%, đo được 24%, thu hẹp phạm vi và chạy lại vòng hai" nặng ký hơn mười dòng liệt kê công nghệ.

## Bài tập: viết phiếu thí nghiệm cho pilot của bạn

Lấy pilot bạn đang làm hoặc vừa làm, rồi viết lên một trang giấy năm dòng. Dòng một là giả định rủi ro nhất, diễn đạt bằng hành vi của người dùng cuối. Dòng hai là chỉ số sẽ đo và khung thời gian duy nhất áp cho mọi con số.

Dòng ba là ngưỡng để scale, dòng bốn là điều kiện để kill. Dòng năm ghi trước bạn sẽ pivot theo hướng nào nếu kết quả rơi vào khoảng giữa. Gửi trang đó cho khách hàng trước khi có số liệu, và khi kết quả về, chỉ được so với chính trang đó.

Một FDE giỏi không phải người không bao giờ dừng pilot, mà là người biết từ ngày đầu mình sẽ dừng khi nào.

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

- Với pilot bạn đang chạy, viết ra một câu: giả định nào mà nếu sai thì cả dự án sụp đổ.
- Thống nhất với khách hàng một ngưỡng thành công, một điều kiện thất bại và một khung thời gian duy nhất cho cả hai.
- Thêm vào CV một dòng mô tả một pilot bạn đã dừng hoặc đổi hướng dựa trên số liệu, kèm con số cụ thể.

## Nguồn

- [The Lean Startup (official book page)](https://theleanstartup.com/book)

- [The Lean Startup by Eric Ries – Penguin Books UK](https://www.penguin.co.uk/books/185058/the-lean-startup-by-ries-eric/9780670921607)

- [Principles – The Lean Startup](https://theleanstartup.com/principles)

- [The Lean Startup (official site)](https://theleanstartup.com/)

- [Why the Lean Start-Up Changes Everything – Harvard Business Review](https://hbr.org/2013/05/why-the-lean-start-up-changes-everything)

- [Pivot or Persevere Decision: The 4 Outcomes You Need to Know](https://kromatic.com/blog/how-to-make-pivot-or-persevere-decisions-in-your-innovation-accounting)

- [The Startup Way by Eric Ries – Penguin Random House](https://www.penguinrandomhouse.com/books/250646/the-startup-way-by-eric-ries/)