Đừng chỉ viết code: Vì sao hiểu loại dự án (Fixed Price vs T&M) quyết định sự nghiệp của một Developer?

Nhiều developer có thói quen nhảy ngay vào code khi nhận dự án: dựng thư viện gì, xài architecture nào, setup CI/CD ra sao. Nhưng có một yếu tố nằm ngoài file package.json hay docker-compose.yml lại định hình trực tiếp cách bạn viết code hằng ngày: Model kinh doanh của dự án đó.

Phổ biến nhất trong mảng phần mềm là hai mô hình: Fixed Price (Trọn gói / Package) và Time & Materials (T&M - Theo thời gian & chi phí thực tế).

Nếu nghĩ đây là chuyện riêng của PM hay Sales, rất có thể bạn sẽ rơi vào cảnh: làm Fixed Price nhưng refactor code như thể có vô hạn thời gian, hoặc làm T&M nhưng lại tiếc công không dám thử nghiệm giải pháp mới.

1. Fixed Price: Trận chiến của Scope và Deadline

Ở mô hình Fixed Price, khách hàng chốt một phạm vi công việc (Scope) cố định với một số tiền cố định. Nếu team làm xong sớm, công ty lời. Nếu phát sinh lỗi hoặc trễ deadline, công ty tự chịu chi phí phát sinh.

Góc nhìn Kỹ thuật & Bối cảnh thực tế

Làm dự án Fixed Price giống như việc bạn đi xây một căn nhà theo bản vẽ có sẵn. Bạn không thể giữa chừng bảo "tôi muốn đập tường ra làm phòng khách rộng hơn" mà không tốn thêm tiền.

Nhiều dev hay than phiền rằng dự án Fixed Price rất chán vì công nghệ cũ kỹ hoặc quy trình ngột ngạt. Nhưng thực tế, mục tiêu tối thượng của loại dự án này là Tính dự đoán được (Predictability) và Giảm thiểu rủi ro (Risk Mitigation).

Dev cần lưu ý gì khi nhảy vào Fixed Price?

• Keep It Simple & Proven: Đừng mang framework "mới nhú trên GitHub" vào một dự án Fixed Price chỉ để học công nghệ. Tốc độ và độ ổn định là ưu tiên số một. Hãy xài những stack mà team hiểu rõ nhất.
• Cảnh giác cao độ với "Change Request" (CR): Khi khách hàng nói "Nút này đổi màu một chút và thêm giúp tôi cái popup nhỏ nhé", về mặt code có thể mất 10 phút, nhưng về mặt hệ thống và quy trình nó là một yêu cầu thay đổi scope. Nếu bạn tự ý sửa mà không thông qua PM, bạn đang làm hỏng bài toán chi phí của dự án.
• Ưu tiên Pragmatic Code hơn Over-Engineering: Yêu cầu bài toán ghi A, hãy làm A. Đừng cố đoán tương lai rằng "chắc mai mán họ sẽ cần B" rồi viết abstraction layer quá dày. Thời gian bạn dành để chuẩn bị cho "tương lai" đó chính là chi phí công ty phải gánh.

2. Time & Materials (T&M): Sự linh hoạt đi kèm áp lực Minh bạch

Ngược lại với Fixed Price, T&M là mô hình mà bên thuê trả tiền dựa trên giờ làm việc thực tế và tài nguyên (nhân sự, hạ tầng) mà team dev bỏ ra. Scope của dự án T&M thường không cố định ngay từ đầu mà thay đổi linh hoạt theo từng Sprint.

Góc nhìn Kỹ thuật & Bối cảnh thực tế

Nếu Fixed Price là xây nhà theo bản vẽ, thì T&M giống như việc thuê một team thi công theo ngày để cải tạo nhà dần dần. Tuần này làm phòng khách, tuần sau thấy cần đổi ý thì chuyển sang sửa bếp.

Model này cực kỳ phù hợp cho các sản phẩm Startup hoặc các dự án Agile, nơi tính năng cần liên tục thay đổi dựa trên feedback của thị trường.

Dev cần lưu ý gì khi làm T&M?

• Chất lượng code và Technical Debt là ưu tiên hàng đầu: Vì dự án T&M kéo dài và scope thay đổi liên tục, nếu bạn viết code "mì ăn liền" cho xong việc ở Sprint 1, chính bạn sẽ trả giá bằng việc trễ tiến độ ở Sprint 5. Đôi khi dành thêm 2 ngày để refactor architecture trong T&M lại là một quyết định hoàn toàn hợp lý.
• Minh bạch về mặt thời gian (Time Tracking & Effort Estimation): Trong T&M, 1 giờ làm việc của bạn là 1 giờ khách hàng trả tiền. Việc estimate thiếu chính xác hoặc không giải thích được lý do "tại sao task này mất 3 ngày" sẽ làm suy giảm niềm tin nghiêm trọng. Hãy hình thành thói quen log work rõ ràng và giao tiếp sớm nếu gặp blocker.
• Tư duy Product-Mindset: Khách hàng chọn T&M vì họ muốn tư vấn chuyên môn từ bạn, chứ không chỉ muốn một người "bảo gì làm nấy". Đừng ngại đề xuất một giải pháp đơn giản hơn để tiết kiệm ngân sách giờ làm cho khách hàng.

Bảng so sánh nhanh dưới góc nhìn Developer

Tóm lại: Thay đổi góc nhìn để làm việc thông minh hơn

Không có mô hình nào tốt hơn mô hình nào tuyệt đối, chỉ có mô hình phù hợp với bài toán kinh doanh tại thời điểm đó.

Một Senior Developer không chỉ là người viết ra những dòng code tối ưu thuật toán, mà là người biết điều chỉnh tư duy kỹ thuật tương thích với bức tranh tài chính của dự án:

• Khi làm Fixed Price, hãy là một người kỷ luật: Viết code đủ tốt, bám sát requirement, tối ưu thời gian giao hàng và quản lý tốt các rủi ro phát sinh scope.
• Khi làm T&M, hãy là một đối tác tư vấn: Viết code sạch, thiết kế hệ thống linh hoạt, minh bạch trong tiến độ và luôn đặt trải nghiệm người dùng cuối lên trên hết.