Product Owner trong dự án EdTech là một trong những vai trò ảnh hưởng lớn nhất đến tốc độ và chất lượng ra quyết định của sản phẩm. Tuy nhiên, trong nhiều dự án outsource, đây cũng là vai trò thường bị thiếu hoặc không có đủ quyền quyết định cuối cùng.
Theo trải nghiệm của tôi, nguyên nhân nhiều khi không nằm ở năng lực team. EdTech là một lĩnh vực phức tạp, nhưng độ phức tạp của ngành chưa phải phần làm dự án kẹt lâu nhất.
Phần khó hơn nằm ở cách dự án được tổ chức. Cụ thể hơn, trong nhiều dự án outsource, phía khách hàng không có một Product Owner đủ quyền ra quyết định.
Product Owner trong dự án Edtech không chỉ là người nhận yêu cầu rồi chuyển lại cho team phát triển. Đó phải là người hiểu bài toán, hiểu ưu tiên của các bên và có quyền quyết định sản phẩm nên đi theo hướng nào. Khi vai trò này không rõ, team kỹ thuật sẽ phải làm việc với rất nhiều người có ảnh hưởng, nhưng lại không có một điểm ra quyết định cuối cùng.
Requirement chậm vì thiếu Product Owner đủ quyền quyết định
> Requirement có thể hiểu đơn giản là những yêu cầu mà hệ thống cần đáp ứng: người dùng cần làm được gì, luồng xử lý đi qua những bước nào, dữ liệu nào cần được ghi nhận, quyền của từng vai trò ra sao và các trường hợp ngoại lệ sẽ được xử lý thế nào. Với EdTech, requirement thường gắn trực tiếp với cách trường vận hành tuyển sinh, thu phí, xếp lớp và quản lý học sinh hằng ngày.
Trong dự án EdTech đó, team phát triển không làm việc với một đầu mối duy nhất. Mỗi khi cần xác nhận requirement, chúng tôi phải trao đổi với nhiều nhóm khác nhau.
Bộ phận vận hành dùng hệ thống hằng ngày nên hiểu rất rõ quy trình thực tế. Họ thường muốn hệ thống mới giữ lại cách làm quen thuộc để hạn chế xáo trộn. Ban giám hiệu ở từng cơ sở lại có góc nhìn riêng, vì mỗi trường có một số đặc thù trong tuyển sinh, xếp lớp, thu phí hoặc chăm sóc phụ huynh. Cố vấn chuyên môn nhìn bài toán từ hướng dài hạn hơn, đưa ra những yêu cầu có tính chiến lược, dù không phải lúc nào cũng sát với khả năng triển khai trước mắt. Bộ phận tài chính tập trung vào thanh toán, đối soát, công nợ; logic của họ nhiều lúc đi theo một ưu tiên khác với logic vận hành.
Không bên nào sai, vì mỗi bên đều đang bảo vệ một phần rất thật của nghiệp vụ.
Điểm gây khó nằm ở chỗ không ai có vai trò tổng hợp các góc nhìn đó thành một quyết định sản phẩm rõ ràng. Khi thiếu người chịu trách nhiệm quyết định cuối cùng, requirement dễ bị kéo qua kéo lại sau mỗi vòng rà soát. Team kỹ thuật nghe thêm một ý kiến, sửa lại một phần, rồi lại phát hiện ý kiến đó mâu thuẫn với một bên khác.
Nhìn từ ngoài, nhiều bên liên quan cùng tham gia rà soát requirement có vẻ là điều tích cực. Với một hệ thống EdTech có nhiều nghiệp vụ đan xen, team đúng là cần lắng nghe đủ các bên. Tuy vậy, lắng nghe nhiều bên khác với việc để mọi bên cùng quyết định.
Khi nhiều người có quyền góp ý mà không có ai chịu trách nhiệm với quyết định cuối cùng, sản phẩm rất dễ rơi vào trạng thái sở hữu chung trên danh nghĩa. Đến lúc tính năng gặp vấn đề, trách nhiệm bị pha loãng. Mỗi người đều có thể nói rằng mình chỉ góp ý từ góc nhìn chuyên môn; còn quyết định cuối cùng thuộc về tập thể.
Trong phát triển sản phẩm, một quyết định thuộc về tập thể nhưng không có người chịu trách nhiệm thường là một quyết định không có owner thật sự.
Một tính năng bị kéo ngược về điểm xuất phát sau vòng rà soát
Bộ phận vận hành đã xác nhận luồng xử lý nên team bắt đầu thiết kế, viết API và dựng UI. Ở thời điểm đó, mọi thứ nhìn khá rõ ràng.
Đến vòng demo cho cố vấn chuyên môn, luồng xử lý bắt đầu đổi hướng. Team nhận thêm yêu cầu phụ huynh phải phê duyệt trước khi đăng ký được xác nhận. Khi chuyển sang bộ phận tài chính rà soát, luồng thanh toán tiếp tục được điều chỉnh: hệ thống không thể gom cả năm, mà phải tách thanh toán theo từng kỳ.
Từ một luồng xử lý tưởng như đã ổn, tính năng bị kéo ngược về gần điểm xuất phát. Team mất gần 3 ngày chỉ để chờ các bên thống nhất lại cách xử lý. Phần UI đã dựng không còn phù hợp, API phải thiết kế lại, một phần logic nghiệp vụ cũng phải rà soát lại để tránh lệch giữa vận hành, chuyên môn và tài chính.
Chi phí lớn nhất ở đây không phải là vài màn hình hay vài API phải làm lại, mà là thời gian của cả team bị treo. Dev không thể đi tiếp, kế hoạch sprint bắt đầu lệch, trong khi quyết định quan trọng nhất lại xuất hiện sau khi team đã bước vào triển khai.
Khi nhìn lại, rất khó xác định ai chịu trách nhiệm cho sự chậm trễ này. Bộ phận vận hành xác nhận theo góc nhìn vận hành. Cố vấn chuyên môn bổ sung theo góc nhìn chương trình. Tài chính điều chỉnh theo logic thanh toán. Ai cũng có lý trong phần việc của mình.
Phần còn thiếu là một người đủ quyền đứng ra quyết định: cuối cùng, sản phẩm sẽ đi theo luồng nào?
Dự án mất nhịp vì chờ quyết định
Trong dự án phần mềm, lãng phí không chỉ đến từ code sai, bug nhiều hoặc tính năng phải làm lại. Có một loại lãng phí âm thầm hơn, khó đo hơn, nhưng tôi thấy xuất hiện rất rõ trong dự án này: thời gian chờ.
Có những ngày team chỉ xoay quanh việc chờ: chờ xác nhận bản phác thảo màn hình, chờ duyệt phương án, chờ vận hành và tài chính thống nhất, rồi lại chờ một cơ sở đồng ý với logic mà cơ sở khác đã thấy ổn. Từng khoảng chờ nhìn riêng lẻ có vẻ không lớn, nhưng khi cộng lại, chúng làm team mất nhịp rất nhanh.
Mỗi lần một quyết định bị treo, bề ngoài dự án vẫn có vẻ đang chạy. Task trên board nằm ở trạng thái đang rà soát, báo cáo vẫn ghi là đang trao đổi hoặc chờ phản hồi. Còn ở phía team phát triển, dev không biết nên đi tiếp theo luồng nào, sprint bắt đầu lệch khỏi kế hoạch, deadline dần bị dồn về cuối.
Đến giai đoạn sau, team thường phải tăng tốc để bù lại khoảng thời gian đã mất. Áp lực lúc đó không xuất phát từ độ khó kỹ thuật, mà từ một luồng ra quyết định bị nghẽn quá lâu.
Tôi gọi đó là độ trễ quyết định. Đây là loại chi phí ẩn rất khó nhìn thấy trong báo cáo tiến độ. Nó không xuất hiện ngay dưới dạng một lỗi kỹ thuật cụ thể: mã nguồn chưa sai, giao diện chưa phát sinh lỗi, hệ thống cũng chưa ghi nhận sự cố nào. Nhưng sau vài vòng chờ phản hồi, kế hoạch đã bắt đầu lệch. Đến khi team nhận ra, phần thời gian dự phòng gần như đã bị dùng hết cho những cuộc trao đổi chưa đi đến quyết định.
Với team phát triển, điều đáng tiếc nhất là khoảng thời gian tốt nhất để làm sản phẩm một cách bình tĩnh và chắc chắn lại trôi qua trong trạng thái chờ phản hồi.
Với EdTech, chậm một giai đoạn có thể lỡ cả năm học
Ở một số lĩnh vực, requirement chậm thêm vài tuần thường chỉ làm kế hoạch phát hành bị dời lại. Với EdTech, tác động dễ lớn hơn nhiều, vì hệ thống phải chạy theo nhịp năm học.
Mùa tuyển sinh, khai giảng, thu phí, xếp lớp hay chuyển cơ sở đều diễn ra theo những mốc thời gian cố định. Nếu tính năng đăng ký nhập học chưa sẵn sàng trước mùa tuyển sinh, sản phẩm có thể mất cơ hội được dùng trong cả một năm học. Lúc đó, vấn đề không còn nằm ở một sprint bị trễ, mà ở việc hệ thống bỏ lỡ đúng thời điểm nghiệp vụ cần nó nhất.
Việc phát hành bổ sung sau đó cũng chỉ giải quyết được một phần. Khi phụ huynh đã đăng ký bằng quy trình thủ công, dữ liệu đã nằm ở nơi khác và nhân sự vận hành đã quen với cách xử lý tạm, việc kéo mọi thứ quay lại hệ thống sẽ tốn thêm rất nhiều công.
Đó là điểm khiến deadline trong EdTech trở nên rất khác. Deadline trong EdTech đi theo nhịp vận hành tự nhiên của ngành giáo dục: tuyển sinh, khai giảng, thu phí, xếp lớp, bảo lưu, kết thúc năm học. Những mốc này đến đúng lịch, dù requirement đã rõ hay chưa.
Vì vậy, một quyết định bị trì hoãn trong dự án EdTech có thể khiến sản phẩm lỡ mất thời điểm quan trọng nhất để tạo ra giá trị.
Team kỹ thuật buộc phải gánh thêm phần việc của sản phẩm
Khi nhận ra phía khách hàng chưa thể có một Product Owner chính thức trong ngắn hạn, team không thể tiếp tục chờ requirement hoàn chỉnh. Dự án vẫn phải đi tiếp, nên chúng tôi buộc phải chủ động hơn trong cách làm rõ bài toán và dẫn dắt các vòng trao đổi.
Thay vì hỏi chung chung rằng các bên muốn hệ thống hoạt động như thế nào, team bắt đầu đưa ra một phương án cụ thể để mọi người cùng xem xét. Luồng này đã đúng với vận hành chưa, phần nào cần điều chỉnh theo góc nhìn tài chính, phần nào còn thiếu ở góc nhìn chuyên môn. Khi có một bản mẫu để phản hồi, cuộc trao đổi bớt mơ hồ hơn, còn feedback cũng cụ thể và dễ xử lý hơn.
Team cũng bổ sung bước dựng bản phác thảo màn hình hoặc bản mẫu mô phỏng trước khi bắt đầu lập trình. Trước đây, chỉ cần requirement tương đối rõ, team đã dễ chuyển thẳng sang giai đoạn phát triển. Sau vài lần phải sửa lại quá nhiều, chúng tôi nhận ra cần có một bước trung gian để các bên cùng nhìn thấy luồng xử lý trước khi lập trình viên bắt tay vào làm. Nhiều mâu thuẫn nghiệp vụ lộ ra ngay ở bước này, khi chi phí chỉnh sửa vẫn còn thấp hơn rất nhiều so với lúc giao diện và phần xử lý phía sau đã hoàn thành.
Phần khó hơn là các lập trình viên nhiều kinh nghiệm phải làm thêm một phần việc của chuyên viên phân tích nghiệp vụ. Khi không có người phân tích nghiệp vụ đủ sâu hoặc người phụ trách sản phẩm đủ quyền, họ phải tự đi hỏi nghiệp vụ, tự gom thông tin từ nhiều phòng ban, tự phát hiện điểm mâu thuẫn và tự viết lại thành tài liệu giải pháp.
Cách làm này giúp dự án tiếp tục chạy, đồng thời tạo thêm tải cho team kỹ thuật. Lập trình viên bị kéo ra khỏi công việc phát triển nhiều hơn. Trưởng nhóm kỹ thuật phải xử lý nhiều câu hỏi liên quan đến sản phẩm hơn. Trách nhiệm sản phẩm bắt đầu lệch sang những người không có đầy đủ bối cảnh kinh doanh và cũng không có quyền quyết định thay khách hàng.
Trong ngắn hạn, team kỹ thuật có thể giúp làm rõ bài toán, đề xuất phương án và chỉ ra các điểm mâu thuẫn. Về lâu dài, nếu mọi quyết định sản phẩm đều bị đẩy về phía team kỹ thuật, dự án sẽ phụ thuộc vào một cơ chế rất mong manh: những người đang xây hệ thống cũng phải tự đoán xem sản phẩm nên đi theo hướng nào.
Thiếu Product Owner trong dự án Edtech là thiếu cơ chế ra quyết định
Sau dự án đó, tôi nhìn vai trò Product Owner khác đi khá nhiều.
Thiếu Product Owner trong dự án Edtech đồng nghĩa với việc dự án thiếu một cơ chế ra quyết định rõ ràng cho sản phẩm. Với các dự án EdTech có nhiều cơ sở, nhiều bên liên quan và deadline theo năm học, cơ chế này quan trọng không kém năng lực kỹ thuật. Một team phát triển mạnh vẫn có thể bị kẹt nếu mỗi thay đổi nhỏ đều phải đi qua nhiều vòng ý kiến mà thiếu người chịu trách nhiệm quyết định cuối cùng.
Bài học lớn nhất tôi rút ra là dự án không nhất thiết phải có đủ mọi vai trò theo sách vở, vì thực tế triển khai hiếm khi lý tưởng như vậy. Nhưng dự án bắt buộc phải có một người, hoặc một cơ chế đủ rõ, để biến nhiều góc nhìn khác nhau thành một quyết định sản phẩm có thể triển khai được.
Nếu thiếu cơ chế đó, yêu cầu sản phẩm sẽ tiếp tục trôi, team sẽ tiếp tục chờ, và đến một lúc nào đó, team kỹ thuật sẽ phải gánh cả phần việc của Product Owner chỉ để dự án còn có thể đi tiếp.
Ngay cả khi đã xử lý được vấn đề về con người và quyền ra quyết định, độ phức tạp của hệ thống EdTech vẫn còn ở phía sau. Trong dự án này, mỗi trường có một số biểu mẫu riêng, quy trình riêng và cách vận hành riêng. Câu hỏi lúc đó chuyển sang một bài toán kỹ thuật khác: hệ thống nên viết cố định theo từng trường, hay thiết kế linh hoạt ngay từ đầu?
Ở bài tiếp theo, tôi sẽ đi sâu vào lựa chọn này và cái giá đi kèm với từng hướng triển khai. Cùng theo dõi BiPlus để đón chờ các bài tiếp theo nhé!
Về tác giả
Loi Le – BU Director
Tôi là một Technical Leader với hơn 12 năm kinh nghiệm trong phát triển backend, chuyên sâu về các hệ thống xây dựng trên nền tảng Java, trải dài trong các lĩnh vực FinTech, thương mại điện tử và viễn thông. Tôi đã dẫn dắt nhiều team kỹ sư trong việc thiết kế và triển khai các hệ thống có khả năng mở rộng cao, hiệu năng tốt, đồng thời phối hợp chặt chẽ với các bộ phận liên chức năng và đối tác bên ngoài.
Thế mạnh cốt lõi của tôi bao gồm thiết kế hệ thống và kiến trúc microservices, tối ưu hiệu năng và thiết kế cơ sở dữ liệu, cũng như xây dựng và vận hành các hệ thống phân tán sử dụng các công nghệ như Kafka, Redis và các nền tảng tương tự.
Hiện tại, tôi đang tập trung phát triển theo hướng Solution Architect, với mục tiêu thiết kế các hệ thống end-to-end cân bằng giữa nhu cầu kinh doanh, khả năng mở rộng và tính dễ bảo trì trong dài hạn.
Tôi cũng thường xuyên chia sẻ những góc nhìn và bài học rút ra từ các dự án thực tế. Rất sẵn lòng kết nối và trao đổi về system design, architecture hoặc engineering leadership. Let’s connect!
