Ở dự án doanh nghiệp lớn, project manager làm việc với một bộ máy có sẵn: phía khách hàng có business analyst, có ban kiểm soát thay đổi, có đội kiểm thử chấp nhận, có người chuyên trách dự án. Ở dự án cho doanh nghiệp vừa và nhỏ, không có gì trong số đó. Người ra quyết định thường là chính giám đốc, và họ ra quyết định giữa hai cuộc họp bán hàng. Đây là khác biệt gốc, và mọi khác biệt còn lại đều sinh ra từ nó.
Bốn vai PM buộc phải kiêm ở dự án SME
- Phân tích nghiệp vụ. Khách hàng mô tả mong muốn chứ không mô tả quy trình. Câu nói hệ thống cần duyệt đơn tự động không chứa thông tin nào dùng được cho tới khi PM ngồi hỏi ra ai duyệt, duyệt theo ngưỡng nào, ai duyệt thay khi người đó nghỉ.
- Ban kiểm soát thay đổi. Không có hội đồng nào họp hàng tuần. PM là người duy nhất nói không, và phải nói kèm con số ảnh hưởng tới lịch và chi phí ngay tại chỗ, chứ không phải hẹn trả lời sau.
- Quản lý kỳ vọng nội bộ phía khách hàng. Nhân viên vận hành thường biết về dự án sau khi hợp đồng đã ký, và họ là người sẽ dùng hệ thống mỗi ngày. Nếu PM không kéo họ vào từ sớm, giai đoạn nghiệm thu sẽ biến thành phiên phản đối tập thể.
- Người giữ trí nhớ dự án. Sau sáu tháng, không ai còn nhớ vì sao chọn phương án B. Nếu không ai chép lại, đội sẽ bàn lại đúng cuộc bàn đó lần thứ ba.
Zalo là kênh dự án thật, đừng chống lại nó
Nhiều PM cố ép khách hàng dùng công cụ quản lý dự án chuyên dụng và thất bại sau hai tuần. Giám đốc doanh nghiệp SME sẽ không mở thêm một ứng dụng nữa để trả lời một câu hỏi mà họ trả lời được trong ba giây trên Zalo. Cách làm hiệu quả không phải là đổi kênh, mà là chấp nhận kênh và thêm đúng một bước.
textQD-014 | 12/03/2026 | Anh Hung (GD)
Noi dung: Bo yeu cau dong bo ton kho theo thoi gian thuc.
Chuyen sang dong bo dinh ky 15 phut mot lan.
Ly do: Chi phi tich hop realtime voi phan mem kho cu
vuot 3 tuan cong, khong kip moc go-live thang 5.
Anh huong: Giam 3 tuan khoi lich. Bao cao ton kho co
do tre toi da 15 phut, da thong bao bo phan kinh doanh.
Nguon: Nhom Zalo du an, tin nhan 12/03 luc 14:20.Sổ quyết định không cần công cụ đắt tiền. Một trang tài liệu chia sẻ là đủ, miễn là nó có số hiệu tăng dần và không ai được sửa dòng cũ, chỉ được thêm dòng mới đính chính.
Điều khoản nghiệm thu: nơi hỏng nhiều dự án nhất
Câu chữ hay gặp trong hợp đồng: nghiệm thu khi hệ thống vận hành ổn định và đáp ứng yêu cầu của bên A. Câu này không đo được, nên trên thực tế nó có nghĩa là nghiệm thu khi bên A hài lòng, và mốc đó có thể lùi vô hạn.
Thay bằng một danh sách kịch bản nghiệm thu viết trước khi bắt đầu code, mỗi kịch bản có dạng: người dùng ở vai trò nào, làm những bước nào, kết quả quan sát được là gì. Đạt hết danh sách thì nghiệm thu, không phụ thuộc cảm nhận.
- Kịch bản viết bằng ngôn ngữ nghiệp vụ, không có từ kỹ thuật. Người ký nghiệm thu phải tự đọc hiểu được.
- Số lượng vừa phải, tập trung vào luồng chính và các trường hợp tiền bạc. Một danh sách hai trăm mục sẽ không ai chạy hết và cuối cùng lại quay về nghiệm thu bằng cảm nhận.
- Ghi rõ dữ liệu thử dùng cái nào. Nghiệm thu trên dữ liệu mẫu ba dòng rồi go-live với tám nghìn khách hàng là cách tự tạo sự cố.
- Phân biệt lỗi chặn nghiệm thu và lỗi ghi nhận xử lý sau. Không phân biệt thì một lỗi lệch màu nút bấm cũng đủ giữ khoản thanh toán giai đoạn.
Kiểm thử chấp nhận với người không có thời gian
Gửi một đường liên kết kèm lời nhắn anh chị test giúp em là cách chắc chắn không nhận được phản hồi nào cho tới tuần cuối, và khi đó phản hồi sẽ đến cùng lúc và toàn là yêu cầu lớn.
Cách hiệu quả hơn: đặt lịch một buổi 90 phút, ngồi cùng phòng hoặc gọi có chia sẻ màn hình, để chính người dùng thao tác còn PM ngồi im quan sát và ghi màn hình. Chỗ họ dừng lại ba giây để tìm nút chính là chỗ giao diện có vấn đề, và họ sẽ không bao giờ báo cáo điều đó bằng văn bản.
Lịch dự án ở Việt Nam: bốn cái bẫy thời gian
- Tết Nguyên đán. Tính cả tuần chuẩn bị trước và tuần lấy lại nhịp sau, thực tế mất khoảng ba tuần. Không đặt mốc nghiệm thu hay go-live sát hai đầu kỳ nghỉ.
- Mùa quyết toán thuế đầu năm. Kế toán không tham gia được vào UAT, mà kế toán thường là người duyệt phần quan trọng nhất.
- Cao điểm bán hàng cuối năm. Kinh doanh và kho không có người rảnh. Nếu buộc phải triển khai, cắt phạm vi chứ đừng cắt thời gian kiểm thử.
- Kỳ nghỉ dài của một người duy nhất biết một quy trình. Hỏi trước lịch nghỉ của những người này ngay ở buổi khởi động dự án.
Ước lượng: ba cách giảm sai số mà không cần công cụ
- Ước lượng ba điểm cho mọi hạng mục lớn: trường hợp thuận lợi, trường hợp hay xảy ra, trường hợp xấu. Nếu khoảng cách giữa thuận lợi và xấu lớn hơn ba lần, hạng mục đó chưa đủ rõ để ước lượng, cần một buổi làm rõ yêu cầu trước.
- Tách riêng phần tích hợp với hệ thống bên thứ ba và cộng hệ số rủi ro rõ ràng. Phần này phụ thuộc tài liệu và thời gian phản hồi của bên ngoài, tức là nằm ngoài tầm kiểm soát của đội.
- Đừng gộp thời gian sửa lỗi vào thời gian phát triển. Tách thành hạng mục riêng có thể nhìn thấy, vì khi nó bị ẩn thì nó luôn là phần bị ăn mất khi lịch căng.
Bàn giao: danh sách bắt buộc, kiểm từng dòng
Bàn giao không phải là gửi mã nguồn. Đây là danh sách tối thiểu, và PM nên đi qua từng dòng cùng khách hàng trong một buổi có biên bản:
- Tên miền: đang đăng ký ở nhà cung cấp nào, tài khoản đứng tên ai, ngày hết hạn.
- Bản ghi DNS: ai có quyền sửa, và bản chụp cấu hình hiện tại.
- Tài khoản hạ tầng và cơ sở dữ liệu, đứng tên pháp nhân doanh nghiệp.
- Mã nguồn kèm quyền quản trị kho mã, không chỉ quyền đọc.
- Danh mục biến môi trường và nơi lưu giá trị bí mật.
- Chứng chỉ bảo mật và cơ chế gia hạn tự động, kèm cách kiểm tra khi nó hỏng.
- Tài khoản cổng thanh toán, tài khoản nhà cung cấp hóa đơn điện tử, tài khoản official account trên Zalo.
- Quy trình sao lưu: chạy lúc nào, lưu ở đâu, giữ bao lâu, và ai đã thử khôi phục lần gần nhất.
Ba chỉ số PM nên theo, và một chỉ số nên bỏ
Nên theo:
- Tuổi của câu hỏi đang chờ khách hàng trả lời. Câu hỏi treo quá năm ngày làm việc là rủi ro lịch, và nó luôn xuất hiện trước khi lịch trượt chứ không phải sau.
- Số yêu cầu thay đổi phát sinh mỗi tuần. Xu hướng tăng đều nghĩa là phạm vi ban đầu chưa được hiểu đúng, cần dừng lại làm rõ chứ không phải cố chạy tiếp.
- Tỷ lệ kịch bản nghiệm thu đã chạy qua thành công. Đây là thước đo tiến độ trung thực hơn phần trăm hoàn thành do đội tự khai.
Nên bỏ: tốc độ hoàn thành điểm story ở dự án SME một đội nhỏ. Phạm vi thay đổi liên tục và số lượng hạng mục quá ít để con số này có ý nghĩa thống kê. Nó tạo cảm giác đo lường mà không dẫn tới quyết định nào khác đi.
Tổng kết
PM ở dự án SME không phải là người điều phối nghi thức agile. Đó là người thay thế cho toàn bộ bộ máy phân tích, kiểm soát thay đổi và kiểm thử mà khách hàng không có, đồng thời là người duy nhất giữ trí nhớ của dự án. Ba việc tạo ra khác biệt lớn nhất: chép lại mọi quyết định trong 24 giờ, viết kịch bản nghiệm thu trước khi viết dòng mã đầu tiên, và kiểm quyền sở hữu tài khoản ngay từ tuần đầu thay vì lúc bàn giao.
Đội ALODEV áp dụng đúng ba việc này ở mọi dự án, và sẵn sàng chia sẻ mẫu sổ quyết định cùng mẫu danh sách kịch bản nghiệm thu nếu bạn cần dùng cho dự án đang chạy.