Tư duy "Product, not Project" & Hành trình nhìn lại với Microservices
Tính ra thì mình đã bắt đầu tiếp cận với microservices cách đây khoảng 10 năm, khi còn là một developer làm trong một công ty outsource. Khi đó, khái niệm này với mình chỉ đơn thuần là một kiểu kiến trúc: chia nhỏ hệ thống thành các service riêng biệt để dễ bảo trì, triển khai độc lập, scale tốt hơn. Mọi thứ khá hấp dẫn ở góc độ kỹ thuật. Mình thích sự rõ ràng, thích cảm giác “gọn gàng” khi từng phần của hệ thống có thể tách rời và hoạt động độc lập. Nhưng phải thừa nhận, lúc đó mình chưa hiểu rằng microservices không chỉ là câu chuyện về code.
Càng đi sâu hơn vào vai trò kỹ thuật – từ developer lên techlead – rồi dần chuyển sang vai trò quản lý sản phẩm công nghệ (TechPM), mình bắt đầu thấy rõ hơn những điều mà trước đây mình bỏ qua. Mình bắt đầu nhận ra rằng, điều khiến microservices phát huy sức mạnh thật sự không chỉ nằm ở kiến trúc, mà còn ở cách tổ chức con người xung quanh nó.
Trước hết ở những công ty outsource, nơi mình từng làm, đa phần mọi thứ được vận hành theo tư duy "project": có một scope rõ ràng, deadline cố định, và một đội được "triệu tập" để làm cho xong rồi chuyển đi. Rất nhiều lần, khi sản phẩm đi vào vận hành, team phát triển ban đầu đã không còn ai ở lại. Mọi hiểu biết về hệ thống, về nghiệp vụ, về bối cảnh khách hàng… cũng theo đó mà rơi rụng dần. Dù team có làm tốt đến đâu, hệ thống được release cũng giống như một cỗ máy tinh vi mà không ai thực sự có trách nhiệm vận hành dài hạn.
Để minh họa rõ hơn sự khác biệt trong cách tổ chức và vận hành giữa hai mô hình này, đây là một bảng so sánh trực quan:
| Tiêu chí | Mô hình Project | Mô hình Product |
|---|---|---|
| Mục tiêu chính | Hoàn thành dự án đúng tiến độ, ngân sách | Phát triển và cải tiến sản phẩm lâu dài |
| Vòng đời đội ngũ | Ngắn hạn, giải tán sau dự án | Ổn định, gắn bó dài hạn với sản phẩm |
| Trách nhiệm sau khi release | Thường không rõ ràng hoặc không còn trách nhiệm | Chịu trách nhiệm xuyên suốt, từ phát triển đến vận hành |
| Mức độ hiểu biết domain | Hạn chế, chỉ đủ để hoàn thành task | Sâu sắc, tích lũy dần theo thời gian |
| Khả năng phản hồi với thay đổi | Chậm do thiếu continuity | Nhanh, do team luôn đồng hành cùng sản phẩm |
| Tư duy phát triển | "Làm xong là xong", ngắn hạn | "Cùng lớn lên với sản phẩm", dài hạn |
Rồi mình chuyển sang làm cho một công ty product – nơi xây dựng và sở hữu sản phẩm của chính mình. Lúc này, cách làm việc thay đổi hoàn toàn. Chúng mình không còn "chạy nước rút để release", mà "đồng hành lâu dài để phát triển". Team không còn là tập hợp ngẫu nhiên những người giỏi, mà là một nhóm gắn bó, hiểu sản phẩm, hiểu người dùng, và quan trọng hơn: chịu trách nhiệm toàn diện cho một phần của hệ thống.
Chính trong môi trường này, microservices mới thật sự phát huy ý nghĩa. Mỗi service không chỉ là một khối kỹ thuật độc lập, mà còn là một "sản phẩm nhỏ" nằm trong tổng thể lớn – và team phụ trách service đó có quyền, có trách nhiệm, có cả động lực để làm cho nó tốt hơn mỗi ngày. Đây cũng là lúc mình thấy rõ giá trị của tư duy “Product, not Project” mà Martin Fowler từng nói tới: hãy thôi nghĩ đến việc “làm xong rồi giao”, hãy nghĩ đến việc “xây dựng và vận hành lâu dài”.
Nếu nhìn từ bên ngoài, microservices có vẻ rất “kỹ thuật”, rất “developer”. Nhưng từ trải nghiệm của mình, nó là một bước ngoặt để tổ chức thay đổi tư duy: từ chia module sang chia quyền sở hữu, từ tối ưu kiến trúc sang tối ưu đội ngũ. Và mình nghĩ, sẽ là chưa đủ nếu tổ chức chỉ áp dụng microservices ở tầng hệ thống, mà không có một sự thay đổi tương ứng ở tầng con người.
Cuối cùng, mình nhận ra rằng việc chuyển từ mô hình project-based sang product-based không chỉ là thay đổi cách làm việc – mà là thay đổi cách chúng ta nhìn nhận giá trị của một team. Đó là một hành trình không dễ, nhưng hoàn toàn xứng đáng để theo đuổi.