Có một quyết định trong dự án EdTech nghe rất hợp lý ở thời điểm nó được đưa ra: cứ làm trước phần đã biết, phần còn lại sẽ làm rõ sau. Timeline đã cam kết, nhân sự đã được phân bổ, đội nghiệp vụ cần thấy tiến độ, còn mùa vận hành của trường thì không chờ team kỹ thuật.
Tôi từng đồng ý với cách làm đó. Sau này nhìn lại, vấn đề nằm ở chỗ team đã bắt đầu xây khi nghiệp vụ cốt lõi chưa đủ rõ.
Với EdTech, nghiệp vụ cốt lõi trải rộng qua năm học, chương trình học, dịch vụ, học phí, trạng thái học sinh, chuyển cơ sở, bảo lưu, hoàn phí, báo cáo tài chính và rất nhiều ngoại lệ vận hành. Nếu hệ thống phục vụ nhiều cơ sở hoặc nhiều thương hiệu giáo dục, một thay đổi nhỏ ở một nơi có thể ảnh hưởng đến nhiều nơi khác.
Khi phần cốt lõi chưa rõ, code càng sớm thì chi phí làm lại càng lớn. Team vẫn có thể xây ra một tính năng chạy được, demo được, thậm chí release được. Nhưng tính năng đó có thể đang giải sai bài toán vận hành thật ở trường, trung tâm hoặc từng cơ sở.
Nhìn qua thì đủ rõ để code nhưng bắt tay vào mới thấy không phải
Trong dự án phần mềm, phần đã biết đôi khi tạo ra cảm giác an toàn giả. Có vài màn hình, vài luồng xử lý chính, một số quy tắc nghiệp vụ ban đầu, backlog nhìn qua đã đủ để chia task cho dev. Nhưng với EdTech, cái rõ ở bề mặt thường chưa đủ để thiết kế hệ thống đúng.
Một tính năng tưởng đơn giản như đăng ký dịch vụ cho học sinh có thể kéo theo rất nhiều câu hỏi. Học sinh đang học bình thường, đang bảo lưu hay đang chuyển cơ sở? Dịch vụ áp dụng theo năm học nào? Có phụ thuộc vào chương trình học không? Nếu học sinh đổi chương trình giữa chừng thì tính lại thế nào? Vận hành muốn một cách quản lý, tài chính cần một cách ghi nhận, đội chuyên môn lại có logic riêng. Hệ thống sẽ ưu tiên hướng nào?
Những câu hỏi này thường xuất hiện muộn, khi team đi sâu vào thiết kế hoặc khi sản phẩm đã được demo cho người dùng thật. Lúc đó, một quy tắc tưởng nhỏ có thể chạm vào cách tổ chức dữ liệu, trạng thái nghiệp vụ, phân quyền, logic tính phí, báo cáo và cả quy trình vận hành sau này.
Một ví dụ rất điển hình là logic lấy trạng thái hiện tại của học sinh. Nghe qua thì đơn giản: hệ thống cần biết học sinh đang ở trạng thái nào. Nhưng trong thực tế, dữ liệu trạng thái có thể nằm ở nhiều bảng, nhiều màn hình hoặc nhiều điểm xử lý khác nhau. Có những nơi vẫn hiển thị dữ liệu, nhưng thực ra là dữ liệu cũ đã hết giá trị sử dụng. Tài liệu lại không ghi rõ điều này.
Người mới vào dự án rất dễ đọc nhầm nguồn dữ liệu và dùng sai logic. Đây là kiểu logic nghiệp vụ ngầm rất nguy hiểm trong EdTech. Nó nằm trong lịch sử vận hành của hệ thống, qua nhiều năm và nhiều lần chỉnh sửa. Chỉ những người đã sống đủ lâu với hệ thống mới biết đâu là dữ liệu thật sự còn giá trị, đâu là phần chỉ còn tồn tại vì lịch sử để lại.
Khi một giả định nhỏ làm lệch cả mô hình hệ thống
Dự án phần mềm hiếm khi có đủ 100% thông tin trước khi bắt đầu. Vấn đề là phải phân biệt được giả định nào có thể sửa sau và giả định nào sẽ phá vào nền móng của hệ thống.
Câu chữ trên màn hình, thứ tự hiển thị vài trường thông tin hay cách trình bày một bước trong luồng thao tác thường có thể chỉnh sau. Giả định về trạng thái nghiệp vụ, vòng đời của một đối tượng chính, quan hệ dữ liệu, quy tắc tài chính hoặc người có quyền quyết định trong một luồng xử lý thì cần được kiểm chứng kỹ trước khi đi vào code.
> Trong EdTech, mô hình dữ liệu là quan hệ giữa học sinh, năm học, chương trình học, dịch vụ và học phí. State machine là cách hệ thống quản lý trạng thái và điều kiện chuyển trạng thái của một đối tượng. Mỗi lần chuyển trạng thái có thể kéo theo thay đổi về học phí, dịch vụ, báo cáo và quyền truy cập.
Nếu những phần này được xây trên giả định sai, hệ thống vẫn có thể chạy trong giai đoạn đầu. Giao diện vẫn lên, demo vẫn có thứ để trình bày, sprint vẫn đóng task đều. Chỉ cần luồng nghiệp vụ thay đổi, những phần từng được làm vội sẽ quay lại dưới dạng chi phí sửa chữa: sửa cơ sở dữ liệu, đổi trạng thái xử lý, viết lại logic, cập nhật báo cáo và kiểm thử lại hàng loạt trường hợp liên quan.
Khi đó, team đang sửa lại cách mình đã hiểu sai bài toán ngay từ đầu. Với hệ thống EdTech nhiều cơ sở hoặc nhiều thương hiệu, rủi ro còn lớn hơn. Một logic tưởng như chỉ phục vụ một cơ sở có thể đang được dùng chung bởi nhiều nơi khác. Nếu không hiểu rõ phạm vi ảnh hưởng, một thay đổi nhỏ có thể làm đúng cho nhóm này nhưng làm sai cho nhóm khác.
Áp lực tiến độ đẩy rủi ro về phía team phát triển
Ai cũng biết nguyên tắc: yêu cầu chưa rõ thì đừng code. Vấn đề là dự án thật luôn phức tạp hơn.
Trong giáo dục, deadline có tính mùa vụ rất rõ. Đến mùa tuyển sinh, có những tính năng gần như bắt buộc phải hoàn thành đúng thời điểm. Nếu không kịp, tính năng đó có thể phải chờ đến năm học tiếp theo mới thật sự được dùng.
Khi deadline gần như không còn không gian thương thảo, team kỹ thuật rất dễ bị đẩy vào trạng thái chạy trước, làm rõ sau. Vấn đề còn nằm ở cách lấy thông tin và duyệt giải pháp. Với các tổ chức giáo dục có nhiều cơ sở, một thay đổi có thể cần đi qua vận hành, tài chính, chuyên môn, quản lý và người dùng cuối. Mỗi bên nhìn sản phẩm từ một góc khác nhau, và góc nào cũng có lý do riêng.
Nếu quá trình này thiếu cơ chế chốt từng bước, phần mơ hồ sẽ bị đẩy dồn về phía sau cho team phát triển. Tech lead thường đứng đúng ở điểm căng nhất: nghiệp vụ chưa đủ rõ, nhưng vẫn phải biến nó thành phần mềm chạy được.
Cái khó là việc code sớm không sai ngay lập tức. Team vẫn rất bận, sprint nào cũng full task, release vẫn đều, mỗi tuần đều có thứ mới để show. Bận rộn trông giống tiến độ, nhưng có giai đoạn tôi nhìn lại và thấy phần lớn công sức của team đang dùng để sửa những quyết định đã được đưa ra quá sớm.
Đó là lúc tôi thấy rõ: code sớm không giúp dự án nhanh hơn. Nó khiến team đi sai sớm hơn, sâu hơn và tốn kém hơn.
Sprint nào cũng full task, nhưng phần lớn là sửa lỗi
Agile giúp team chia nhỏ phạm vi và thích nghi với thay đổi. Nhưng chia nhỏ không có nghĩa là đưa vào sprint những thứ chưa ai hiểu rõ. Khi logic cốt lõi chưa rõ, trường hợp ngoại lệ quan trọng chưa được nhìn thấy, và chưa có người chịu trách nhiệm chốt quyết định sản phẩm, đưa yêu cầu vào sprint chỉ là chuyển rủi ro từ giai đoạn phân tích sang giai đoạn phát triển.
> DoR (Definition of Ready): Các tiêu chí mà một công việc phải đạt được trước khi đội ngũ có thể bắt đầu làm việc.
DoR phải đủ chặt ở những phần nền móng: mô hình dữ liệu, trạng thái nghiệp vụ, logic tính phí, phân quyền. Giao diện có thể chỉnh sau, nhưng những quyết định này thì không.
Cách tốt hơn là cải tiến chính giai đoạn làm rõ bài toán. Thay vì chờ design xong mới đưa cho các bên review, team nên chốt từng phần nhỏ hơn, làm POC sớm hơn để kiểm chứng logic nghiệp vụ phức tạp trước khi đầu tư phát triển đầy đủ. Bản mẫu mô phỏng giúp người dùng và các bên liên quan nhìn, bấm thử và phản hồi về luồng xử lý ngay, thay vì chờ đến lúc hệ thống đã được xây xong. Hai cách này giúp team nhận phản hồi sớm hơn và giảm rủi ro dồn toàn bộ sai lệch về cuối.
Muốn đi nhanh, phải biết phần nào chưa được phép vội
Nếu được quay lại dự án đó, tôi sẽ không yêu cầu team dừng hết để phân tích trong nhiều tháng. Điều đó không thực tế. Tôi sẽ tách rõ phần có thể thử sớm và phần bắt buộc phải hiểu sâu trước khi đưa vào phát triển.
Những phần ít rủi ro, ít phụ thuộc vào nghiệp vụ cốt lõi có thể làm sớm để lấy phản hồi: bản mẫu giao diện, luồng tổng quan, dữ liệu giả để mô phỏng hoặc các module tương đối độc lập. Mục tiêu là học nhanh hơn, không phải khóa sớm thiết kế kỹ thuật khi nghiệp vụ còn chưa ổn định.
Những phần chạm vào nghiệp vụ cốt lõi cần được làm rõ kỹ hơn. Tôi sẽ dành nhiều thời gian hơn để vẽ lại vòng đời của các đối tượng chính và làm rõ ngoại lệ sớm hơn. Ví dụ: học sinh đã đóng phí nhưng đổi chương trình giữa kỳ, hoặc đang bảo lưu nhưng vẫn còn dịch vụ chưa hết hạn. Mục tiêu là phân biệt trường hợp nào xử lý thủ công được, trường hợp nào phải mô hình hóa trong hệ thống.
Quan trọng nhất, tôi sẽ làm rõ vai trò Product Owner ngay từ đầu. Trong dự án có nhiều bên liên quan, Product Owner không thể chỉ là người ghi nhận yêu cầu. Vai trò này cần đủ gần bài toán vận hành, đủ hiểu người dùng và đủ thẩm quyền để chốt rằng với luồng này, hệ thống sẽ đi theo hướng nào.
Nếu thiếu người như vậy, team kỹ thuật sẽ bị kéo vào vị trí rất nguy hiểm: tự diễn giải nghiệp vụ rồi biến cách hiểu đó thành hệ thống. Vận hành muốn một kiểu, tài chính muốn một kiểu, chuyên môn muốn một kiểu. Bên nào cũng có lý do đúng từ góc nhìn của họ. Nhưng sản phẩm không thể được thiết kế bằng cách cộng trung bình mong muốn của tất cả mọi người.
Đi nhanh không có nghĩa là code trước khi hiểu đúng
Sau dự án đó, tôi không còn xem việc bắt đầu code sớm như một dấu hiệu của tốc độ. Tốc độ thật là khi team đi nhanh mà không phải liên tục quay lại sửa nền móng.
Với các hệ thống nghiệp vụ phức tạp, đặc biệt là EdTech, một mô hình nghiệp vụ sai được code hóa quá sớm thường tốn kém hơn nhiều so với một bug. Agile giúp team thích nghi với thay đổi, nhưng thích nghi là dựa trên những gì đã hiểu rõ để điều chỉnh, không phải xây trên những giả định còn mơ hồ. Có những phần có thể cải tiến sau, và cũng có những phần cần được hiểu đúng trước khi viết dòng code đầu tiên.
Ở bài tiếp theo, tôi muốn chia sẻ tiếp một vấn đề rất liên quan: điều gì xảy ra khi dự án có quá nhiều bên liên quan, nhưng lại thiếu một Product Owner thực thụ.
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!
