Lựa chọn nền tảng thử nghiệm: Nhìn lại

Khoa học dữ liệu Lựa chọn nền tảng thử nghiệm: Nhìn lại Cách tiếp cận của tôi trong việc hướng dẫn lựa chọn giữa Eppo và Statsig, cùng những bài học kinh nghiệm. Alejandro Alvarez Perez Ngày 6/6/2026 14 phút đọc Chia sẻ Liệu đường ống tốt có cung cấp nước sạch? Trong mỗi công ty mong muốn tạo ra những sản phẩm được khách hàng yêu thích, sẽ có một thời điểm mà câu nói "chúng ta nên thử nghiệm nhiều hơn" trở thành "chúng ta không thể tiếp tục thử nghiệm theo cách này nữa". Các nhóm thử nghiệm được điều chỉnh thủ công; các yêu cầu phân bổ lưu lượng truy cập luân chuyển giữa các quản lý sản phẩm (PM) và kỹ sư; lịch làm việc của các nhà phân tích bị đặt kín lịch trước hàng tuần. Mong muốn được định hướng bởi dữ liệu dường như vượt quá khả năng của bộ máy được thiết lập để thực hiện điều đó. Đó là tình hình của chúng tôi tại ManyChat vào năm ngoái. Chúng tôi đã chọn Eppo, nhưng quyết định đó chỉ là một phần nhỏ của câu chuyện, và là phần ít có thể áp dụng cho công ty của bạn nhất. Thay vào đó, tôi muốn chia sẻ quy trình mà tôi đã thực hiện để đi đến quyết định đó, những gì tôi đã làm sai trên đường đi, và những gì đã làm tôi ngạc nhiên sau khi ký hợp đồng. Một lưu ý về thời điểm. Chúng tôi đã chọn Eppo vào một thời điểm đặc biệt thú vị trong ngành, khi bản đồ các nhà cung cấp đang thay đổi trong quá trình đánh giá của chúng tôi. Bản thân Eppo đã được Datadog mua lại vài tháng trước đó. Statsig gần đây đã được OpenAI mua lại, và sau đó sẽ được bán cho Amplitude. Tôi không nghĩ bất kỳ điều gì tôi mô tả dưới đây phụ thuộc vào chu kỳ tin tức cụ thể đó, nhưng tôi muốn thừa nhận rằng một số điều trong số đó đã định hình tâm trạng của chúng tôi khi chúng tôi đưa ra quyết định. Tôi chia những gì sau đây thành ba phần: trước khi quyết định, trong quá trình quyết định, và sau khi quyết định. Trước khi quyết định Hãy để tôi đưa bạn vào tâm trạng mà chúng tôi đã trải qua trước khi mọi thứ xảy ra. Khi tôi mới gia nhập công ty, một kỹ sư đã nói với tôi rằng nếu có hai cơ hội chạy thử nghiệm đồng thời, nhóm của anh ấy sẽ đơn giản là hoãn ý tưởng thứ hai sang một sprint sau vì sự phức tạp kỹ thuật trong việc cấu hình hai phân bổ. Rủi ro mắc lỗi cuối cùng đã lớn hơn sự háo hức muốn thử nghiệm. Điều này đúng nghĩa là: tốt nhất là chống lại tốc độ; tệ nhất là không có thử nghiệm nào. Và đối với một thử nghiệm được cấu hình, việc sao chép logic phân bổ mẫu là công việc thường ngày của họ. Một nhà phân tích ở phía bên kia của cùng một đường ống đã tự mô tả mình là một "microservice con người"; cô ấy muốn nói đến các nhóm thử nghiệm được xác định thủ công, làm mới thủ công, chuyển cho kỹ sư, v.v... một cơ hội thú vị để trải nghiệm toàn bộ quy trình dưới góc nhìn người thứ nhất, quả thực. Nhưng, bỏ qua sự mỉa mai, đó là thời điểm mà việc cần một nền tảng không còn là điều trừu tượng nữa. Tôi đã từng chứng kiến những tình huống tương tự trước đây. Tại Marktplaats, vài năm trước, tôi đã viết các thư viện Python nội bộ nhằm giải quyết những vấn đề này, và chúng tôi đã thấy thời gian để có được thông tin giảm từ vài ngày xuống còn vài giờ, trong những trường hợp đặc biệt. Tôi đã chứng kiến cuộc tranh luận "tự xây dựng hay mua" tương tự diễn ra một lần nữa tại Adevinta, trên phạm vi toàn cầu, với quy mô lớn hơn, nơi họ quyết định tự xây dựng thay vì mua. May mắn cho chúng tôi tại Manychat, đến cuối năm 2025, các giải pháp nền tảng đã đủ trưởng thành để, đối với một công ty có quy mô như chúng tôi và vào thời điểm đó, việc mua là một động thái rõ ràng. Chúng tôi muốn công cụ mang lại cho chúng tôi cơ hội tốt nhất để đưa chương trình thử nghiệm của mình đến nơi chúng tôi mong muốn: thống kê tiên tiến, vâng, nhưng quan trọng hơn là một công cụ thúc đẩy người dùng của nó hướng tới các thử nghiệm có kết luận theo mặc định; bao gồm cả các quản lý sản phẩm. Hai vấn đề đã cản trở chúng tôi đưa ra lựa chọn. Vấn đề đầu tiên khá đơn giản: chúng tôi đã xác định được vấn đề, nhưng thông tin chỉ mang tính giai thoại. Ban lãnh đạo đã có một ý tưởng (rất tốt) về những gì đang trục trặc, và tôi đã nghe các nhà phát triển và quản lý sản phẩm phàn nàn về hệ thống hiện tại khi tôi mới gặp họ. Tuy nhiên, tất cả những điều đó không giống như một danh sách yêu cầu của nhà cung cấp. Cho đến khi chúng tôi có thể đặt hai bên cạnh nhau, chúng tôi không thể biết khả năng nào là tiện ích bổ sung và khả năng nào là trọng tâm. Vấn đề thứ hai khó hơn. Quyết định này mang nhiều trọng lượng vì dù nói thế nào đi nữa, luôn có một yếu tố ràng buộc đối với bất kỳ nền tảng nào; về mặt văn hóa, nếu không phải về mặt kỹ thuật. Và nguồn lực có hạn: chúng tôi không thể thực hiện POC (Proof of Concept - Chứng minh Khái niệm) cho mọi nền tảng trên thị trường. Chưa kể đến chi phí cơ hội khi phải đảo ngược quyết định và bắt đầu lại. Việc chọn một nền tảng để đặt cược, trong một lần, không có cơ hội điều chỉnh, sẽ là một sai lầm. Và với các sản phẩm tương tự nhau ở hầu hết các khía cạnh, việc tìm ra sản phẩm tốt nhất cho chúng tôi đòi hỏi sự chính xác. Chúng tôi cần một cách để chia một quyết định quan trọng thành các quyết định nhỏ hơn, ít rủi ro hơn, xây dựng dựa trên nhau. Phỏng vấn và giảm thiểu rủi ro quyết định Tôi bắt đầu bằng các cuộc phỏng vấn. Các quản lý sản phẩm (PM), nhà phân tích sản phẩm, kỹ sư, nhà tiếp thị. Mục đích là chuyển đổi thông tin giai thoại thành thứ mà chúng tôi có thể đối chiếu với danh sách tính năng của nhà cung cấp. Câu chuyện về lịch của kỹ sư, "microservice con người" của nhà phân tích, PM đã từ bỏ việc chạy các thử nghiệm nguyên tử và thay vào đó gộp các thay đổi vào các bản phát hành lớn hơn, trì hoãn một số hoàn toàn: tất cả những điều này đã trở thành mô tả công việc cho công cụ. Tôi không thể nói quá nhiều về việc điều này đã mang lại lợi ích cho tôi sau này như thế nào. Mỗi khi quá trình đi chệch hướng, và nó đã đi chệch hướng, các cuộc phỏng vấn là điểm tựa mà chúng tôi quay lại. Chúng cũng là điều làm cho toàn bộ nỗ lực trở nên đáng tin cậy trong tổ chức: nói với CPO của tôi lý do chúng tôi đang triển khai POC là một cuộc trò chuyện khác khi tôi có thể trích dẫn một vấn đề cụ thể cho cô ấy. Đối với vấn đề đơn lẻ, chúng tôi đã phân chia quá trình khám phá thành ba lớp, mỗi lớp tập trung vào mức độ sâu tiếp theo trong đánh giá: Nghiên cứu tài liệu. Đọc tài liệu của nhà cung cấp, phác thảo một danh sách dài. Hầu hết các nền tảng tự loại bỏ ở đây, trước khi chúng tôi mở một kênh bán hàng. Rất nhiều mã Claude cũng ở bước này. Thuyết trình. Một cuộc trò chuyện tập trung với từng nhà cung cấp được chọn. Chắc chắn có một chút quảng cáo bán hàng, nhưng chủ yếu là chúng tôi thăm dò các lĩnh vực mà chúng tôi đã quyết định là quan trọng nhất. POC. Trực tiếp sử dụng các nền tảng, với dữ liệu thực và người đánh giá thực, chỉ dành cho hai ứng cử viên cuối cùng. Mỗi lớp thu hẹp phạm vi và cung cấp cho chúng tôi thông tin với một "mức giá".