Chu kỳ Build – Measure – Learn là gì?

Chu kỳ gồm ba hoạt động liên kết: Build biến giả định thành sản phẩm hoặc thử nghiệm; Measure biến hành vi và phản hồi thực tế thành dữ liệu; Learn biến dữ liệu thành kết luận để quyết định bước tiếp theo. Kết quả của Learn lại trở thành đầu vào cho vòng Build kế tiếp, vì vậy Build – Measure – Learn không phải quy trình thực hiện một lần mà là một vòng lặp liên tục.

Điểm quan trọng nhất của chu kỳ không phải là xây dựng sản phẩm nhanh hơn theo nghĩa đơn thuần, mà là rút ngắn thời gian cần thiết để thu được phản hồi có giá trị và học được điều gì đó về giả định đang kiểm tra. Eric Ries mô tả mục tiêu của hệ thống là giảm tổng thời gian đi qua toàn bộ vòng phản hồi, thay vì chỉ tối ưu riêng tốc độ của từng công đoạn.

Build – Measure – Learn hoạt động như thế nào?

Về bề mặt, chu kỳ vận hành theo trình tự:

Ý tưởng/Giả định → Build → Sản phẩm hoặc thử nghiệm → Measure → Dữ liệu → Learn → Kiến thức → Giả định tiếp theo

Tuy nhiên, cách thiết kế một vòng thử nghiệm hiệu quả thường bắt đầu từ câu hỏi cần học. Nhóm phải xác định mình muốn kiểm chứng điều gì, dữ liệu nào có thể xác nhận hoặc bác bỏ giả định đó, sau đó mới quyết định cần xây dựng thứ gì để tạo ra dữ liệu cần thiết.

Điều này giải thích tại sao Build không đồng nghĩa với việc bắt tay vào lập trình càng sớm càng tốt. Nếu chưa xác định được điều cần học và cách đo lường, nhóm có thể xây rất nhanh nhưng vẫn không thu được bằng chứng hữu ích.

Mỗi vòng lặp vì thế có thể được hiểu như một thí nghiệm:

1.    Đặt giả định về khách hàng, vấn đề, giải pháp hoặc hành vi

2.    Xây dựng thử nghiệm đủ để kiểm tra giả định

3.    Quan sát và đo lường phản ứng thực tế

4.    Đối chiếu dữ liệu với giả định ban đầu

5.    Rút ra bài học và quyết định tiếp tục hay thay đổi

6.    Đưa kiến thức mới vào vòng thử nghiệm tiếp theo

Khi chu kỳ được lặp lại, sản phẩm không chỉ được cải tiến dựa trên ý kiến chủ quan mà ngày càng được định hình bởi những gì nhóm thực sự học được từ thị trường.

Build: Xây dựng thứ nhỏ nhất có thể kiểm chứng giả định

Build là giai đoạn chuyển một giả định thành thứ có thể đưa ra kiểm tra trong thực tế. Trong Lean Startup, công cụ thường gắn với bước này là Minimum Viable Product – MVP, tức phiên bản sản phẩm cho phép kiểm tra một hoặc nhiều giả định quan trọng với mức nỗ lực cần thiết tối thiểu.

Mục tiêu vì vậy không phải:

“Làm thế nào để xây được nhiều tính năng nhất?”

mà gần hơn với:

“Cần xây tối thiểu điều gì để kiểm tra giả định này?”

Ví dụ, một nhóm tin rằng người dùng sẵn sàng trả tiền cho công cụ tự động lập báo cáo. Nếu xây toàn bộ hệ thống trước khi kiểm chứng nhu cầu, nhóm có thể dành nhiều tháng cho một giả định chưa được xác nhận.

Theo logic Build – Measure – Learn, nhóm có thể bắt đầu bằng một phiên bản rất giới hạn chỉ thực hiện chức năng cốt lõi cho một nhóm người dùng nhỏ. Phiên bản này phải đủ để tạo ra phản ứng thực tế có thể đo được.

Điều đó cũng cho thấy một hiểu lầm phổ biến về MVP: MVP không đơn giản là sản phẩm kém hoàn thiện hoặc sản phẩm bị cắt càng nhiều tính năng càng tốt. Giá trị của MVP nằm ở khả năng tạo ra bằng chứng phục vụ việc học. Một phiên bản rất nhỏ nhưng không kiểm tra được giả định quan trọng vẫn có thể là một thử nghiệm kém.

Measure: Đo dữ liệu có khả năng kiểm chứng giả định

Measure là giai đoạn thu thập và phân tích dữ liệu được tạo ra khi người dùng tương tác với sản phẩm hoặc thử nghiệm.

Điểm quyết định không phải là có thật nhiều dữ liệu, mà là đo đúng dữ liệu liên quan đến giả định đang được kiểm tra. Các nghiên cứu ứng dụng Build – Measure – Learn cũng nhấn mạnh rằng chỉ số đo cần có quan hệ có ý nghĩa với giả định cần kiểm chứng.

Giả sử nhóm muốn kiểm tra giả định:

Người dùng có nhu cầu đủ lớn để sử dụng tính năng báo cáo tự động thường xuyên.

Chỉ số phù hợp có thể liên quan đến tỷ lệ người dùng thực sự sử dụng tính năng, tần suất sử dụng hoặc mức độ quay lại sử dụng sau lần đầu.

Ngược lại, số lượt truy cập website tăng không nhất thiết chứng minh giả định trên. Traffic cho biết có người đến website, nhưng chưa chắc cho biết họ coi chức năng báo cáo tự động là có giá trị.

Vì vậy, Measure phải duy trì quan hệ:

Giả định → Hành vi cần quan sát → Chỉ số → Dữ liệu → Kết luận

Nếu chỉ số không liên quan trực tiếp đến giả định, vòng lặp có thể tạo ra rất nhiều số liệu nhưng rất ít kiến thức.

Một phép đo tốt phải giúp nhóm phân biệt được ít nhất hai khả năng: bằng chứng đang ủng hộ giả định hay đang cho thấy giả định cần được xem xét lại.

Learn: Biến dữ liệu thành quyết định

Learn là bước diễn giải dữ liệu để xác định giả định ban đầu được hỗ trợ đến mức nào và nhóm nên làm gì tiếp theo.

Đây là bước khiến Build – Measure – Learn khác với một chu kỳ đơn thuần kiểu “làm sản phẩm – xem kết quả – sửa sản phẩm”. Mục tiêu của Learn là tạo ra validated learning – học hỏi được kiểm chứng, tức sử dụng bằng chứng thu được từ thử nghiệm để định hướng quá trình phát triển tiếp theo.

Kết quả có thể dẫn tới hai hướng quyết định quan trọng.

Persevere nghĩa là bằng chứng đủ để nhóm tiếp tục theo hướng hiện tại và tiến hành các vòng cải tiến tiếp theo.

Pivot nghĩa là bằng chứng cho thấy một giả định quan trọng cần thay đổi, vì vậy nhóm điều chỉnh một phần đáng kể trong cách tiếp cận thay vì tiếp tục đầu tư theo hướng cũ.

Pivot không có nghĩa rằng mọi kết quả không tốt đều buộc doanh nghiệp phải thay đổi toàn bộ sản phẩm. Ngược lại, persevere cũng không có nghĩa là sản phẩm đã hoàn thiện. Hai lựa chọn chỉ có ý nghĩa khi được đặt trong mối quan hệ với giả định và bằng chứng mà vòng thử nghiệm đang kiểm tra.

Sau quyết định đó, kiến thức thu được trở thành cơ sở hình thành giả định mới, và một vòng Build – Measure – Learn khác bắt đầu.

Vì sao Build – Measure – Learn cần được lặp lại nhanh?

Startup và các sản phẩm mới thường hoạt động trong điều kiện có nhiều giả định chưa được kiểm chứng: khách hàng là ai, vấn đề nào thực sự quan trọng, giải pháp nào tạo giá trị và người dùng sẽ phản ứng như thế nào.

Trong môi trường như vậy, xây dựng một kế hoạch chi tiết không tự động loại bỏ sự bất định. Một nhóm có thể thực thi kế hoạch rất tốt nhưng vẫn phát triển thứ mà thị trường không cần.

Build – Measure – Learn xử lý vấn đề này bằng cách biến giả định thành các vòng kiểm chứng ngắn hơn. Lean Startup coi hoạt động cơ bản của startup là biến ý tưởng thành sản phẩm, đo phản ứng của khách hàng và học xem nên pivot hay persevere; quá trình phát triển vì thế cần hướng tới việc tăng tốc toàn bộ vòng phản hồi.

Giá trị của tốc độ ở đây là tốc độ học, không đơn thuần là tốc độ sản xuất.

Một đội ngũ có thể Build trong ba ngày nhưng mất hai tháng mới Measure và Learn được thì vòng phản hồi vẫn chậm. Ngược lại, việc giảm phạm vi thử nghiệm để có bằng chứng đáng tin cậy sớm hơn có thể giúp nhóm loại bỏ một giả định sai trước khi đầu tư thêm nguồn lực.

Do đó, tối ưu Build – Measure – Learn cần nhìn vào thời gian của toàn vòng, thay vì chỉ cố làm cho riêng bước Build nhanh hơn.

Những điều dễ hiểu sai về Build – Measure – Learn

Một sai lầm phổ biến là xem chu kỳ như công thức “làm nhanh – lấy feedback – sửa nhanh”. Cách hiểu này thiếu yếu tố trung tâm là giả định cần kiểm chứng.

Feedback chỉ có giá trị khi giúp trả lời một câu hỏi cụ thể. Nếu nhóm thu thập hàng trăm ý kiến nhưng không biết mình đang kiểm tra giả định nào, dữ liệu có thể dẫn tới việc bổ sung tính năng liên tục mà không tạo ra validated learning.

Sai lầm thứ hai là đồng nhất Build với xây sản phẩm hoàn chỉnh. Trong chu kỳ này, thứ được xây chỉ cần đủ để tạo ra phép thử phù hợp với điều cần học.

Sai lầm thứ ba là cho rằng Measure nghĩa là theo dõi càng nhiều KPI càng tốt. Một dashboard có hàng chục chỉ số vẫn có thể không trả lời được giả định cốt lõi. Measure chỉ hữu ích khi dữ liệu có khả năng dẫn đến Learn.

Sai lầm thứ tư là xem Learn như bước tổng kết. Learn thực tế phải tác động đến quyết định tiếp theo. Nếu dữ liệu được thu thập nhưng nhóm vẫn tiếp tục kế hoạch cũ bất kể kết quả, vòng phản hồi chưa thực sự hoàn thành.

Cuối cùng, Build – Measure – Learn không đảm bảo rằng mọi thử nghiệm đều thành công. Một thử nghiệm cho thấy giả định sai vẫn có giá trị nếu nó cung cấp bằng chứng đủ sớm để ngăn nhóm tiếp tục đầu tư vào một hướng không hiệu quả. Giá trị của vòng lặp nằm ở chất lượng và tốc độ của việc học, không phải ở việc mọi vòng đều xác nhận ý tưởng ban đầu.

Cách áp dụng Build – Measure – Learn trong thực tế

Một vòng Build – Measure – Learn có thể bắt đầu bằng việc viết rõ giả định thay vì bắt đầu bằng danh sách tính năng.

Ví dụ:

Giả định: Khách hàng mục tiêu cần một công cụ tự động tạo báo cáo hằng tuần và sẵn sàng sử dụng nó thường xuyên.

Từ đó thiết kế ngược vòng lặp.

Learn: Nhóm cần biết người dùng có thực sự coi chức năng tự động hóa báo cáo là đủ giá trị để sử dụng lặp lại hay không.

Measure: Xác định trước hành vi và chỉ số có thể phản ánh giả định, chẳng hạn số người kích hoạt chức năng, tỷ lệ sử dụng lại hoặc hành vi tiếp tục sử dụng trong khoảng thời gian thử nghiệm.

Build: Chỉ xây phiên bản tối thiểu đủ để những người dùng mục tiêu thực hiện hành vi cần đo.

Sau khi thử nghiệm, nhóm phân tích dữ liệu. Nếu bằng chứng hỗ trợ giả định, vòng tiếp theo có thể kiểm tra một giả định sâu hơn. Nếu dữ liệu đi ngược giả định, nhóm cần xác định phần nào phải thay đổi trước khi tiếp tục đầu tư.

Cách làm này tạo ra một nguyên tắc quan trọng:

Đừng Build trước rồi mới nghĩ xem cần Measure gì. Hãy xác định cần Learn điều gì, từ đó xác định cần Measure gì, rồi mới quyết định cần Build gì.

Khi được vận hành đúng, mỗi vòng Build – Measure – Learn phải tạo ra một thay đổi trong trạng thái hiểu biết của đội ngũ: một giả định được củng cố, bị bác bỏ hoặc được điều chỉnh. Chính kiến thức mới đó trở thành đầu vào cho vòng tiếp theo.

Build – Measure – Learn vì vậy không chỉ là ba bước phát triển sản phẩm mà là một hệ thống học hỏi bằng thử nghiệm. Build tạo ra phương tiện kiểm chứng, Measure tạo ra dữ liệu, còn Learn biến dữ liệu thành quyết định. Sau mỗi vòng, kiến thức mới lại được đưa trở lại quá trình xây dựng.

Điểm cốt lõi không phải “xây càng nhanh càng tốt”, mà là đi qua toàn bộ vòng phản hồi đủ nhanh và đủ chính xác để giảm sự bất định trước khi đầu tư lớn hơn. Khi Build gắn với một giả định rõ ràng, Measure sử dụng dữ liệu có ý nghĩa và Learn thực sự dẫn đến quyết định, chu kỳ này giúp đội ngũ phát triển sản phẩm dựa trên bằng chứng thay vì chỉ dựa trên dự đoán.