Dự án phần mềm chậm tiến độ: 5 dấu hiệu và cách xử lý

Một dự án phần mềm chậm tiến độ hiếm khi hỏng trong một ngày. Nó trượt dần, trong khi báo cáo hằng tuần vẫn ghi là mọi thứ ổn.

Bài viết nêu các dấu hiệu nhận biết một dự án phần mềm chậm tiến độ từ sớm, việc nên làm ngay, và cách quyết định giữa tiếp tục hay dừng lại. Nội dung dành cho người đặt hàng phần mềm, không cần kiến thức kỹ thuật.

Trả lời ngắn: xử lý dự án phần mềm chậm tiến độ

Một dự án phần mềm chậm tiến độ hiếm khi trượt trong một ngày. Nó trượt dần, trong khi báo cáo hằng tuần vẫn ghi là mọi thứ ổn.

Khi đã nghi ngờ, có ba việc nên làm ngay trong tuần: yêu cầu một bản chạy được dù phạm vi nhỏ, lấy mã nguồn và quyền truy cập về tay mình, và ghi lại hiện trạng theo ba nhóm — chạy được, đang lỗi, chưa bắt đầu.

Quyết định tiếp tục hay dừng nên dựa trên ba câu hỏi: lý do ban đầu còn đúng không, phần còn lại cần bao lâu theo tốc độ thật đã quan sát, và số tiền còn phải bỏ ra có nhỏ hơn giá trị thu về không.

Vì sao dự án phần mềm chậm tiến độ mà không ai báo

Trước hết cần biết đây không phải trường hợp cá biệt. Nghiên cứu của McKinsey cùng Đại học Oxford trên hơn 5.400 dự án công nghệ thông tin cho thấy các dự án lớn vượt ngân sách trung bình 45% và mang lại giá trị thấp hơn dự kiến 56%.

Điều đáng nói hơn là cơ chế khiến tin xấu về một dự án phần mềm chậm tiến độ đến muộn. Báo cáo giữ màu xanh vì báo màu vàng sẽ kéo theo một loạt câu hỏi mà không ai muốn đối mặt. Người làm trực tiếp thường biết vấn đề từ tuần thứ ba, nhưng điều đó chỉ được thừa nhận ở tuần thứ mười một, khi mọi lựa chọn còn lại đều đắt.

Vì vậy việc của người đặt hàng không phải là chờ được báo, mà là tạo ra cơ chế để tự nhìn thấy.

Năm dấu hiệu nhận biết dự án phần mềm chậm tiến độ từ sớm

1. Báo cáo đúng tiến độ nhưng không có gì để xem

Dấu hiệu quan trọng nhất và cũng dễ kiểm tra nhất. Tỷ lệ hoàn thành là con số do người làm tự đưa ra; một bản chạy được thì không giả được.

2. Phần trăm hoàn thành tăng đều, ngày demo lùi mãi

Khi hai con số này đi ngược nhau, con số đáng tin là ngày demo.

3. Yêu cầu phát sinh không được ghi lại chi phí thời gian

Mỗi yêu cầu thêm đều nhỏ và hợp lý. Vấn đề không nằm ở yêu cầu mà ở chỗ không ai ghi lại nó tốn thêm bao nhiêu ngày, ngay tại lúc thống nhất. Đến cuối dự án thì không truy được vì sao lệch.

4. Người làm chính đổi giữa chừng mà không bàn giao

Thay người là chuyện bình thường. Thay người mà không có thời gian bàn giao thì toàn bộ hiểu biết về bài toán phải xây lại từ đầu, và chi phí đó không ai tính vào.

5. Không ai chủ động báo rủi ro của dự án phần mềm chậm tiến độ

Hỏi mới trả lời là dấu hiệu nặng nhất. Nó cho thấy vấn đề đã tồn tại nhưng chưa được nói ra.

Ba việc nên làm ngay khi nghi ngờ dự án phần mềm chậm tiến độ

• Yêu cầu một bản chạy được trong vòng một tuần. Phạm vi nhỏ cũng được, miễn là mở ra xem được. Nếu một tuần không có gì để xem, đó chính là câu trả lời.
• Lấy mã nguồn và quyền truy cập về tay mình. Việc này nên làm kể cả khi dự án đang tốt. Nếu nhà cung cấp trì hoãn, đó là dấu hiệu cần chú ý hơn cả tiến độ.
• Ghi lại hiện trạng. Cái gì chạy được, cái gì lỗi, cái gì chưa bắt đầu. Danh sách này là căn cứ cho mọi quyết định sau đó.

Tiếp tục hay dừng lại

Khi một dự án phần mềm chậm tiến độ đã kéo dài, ba câu hỏi sau nên được trả lời bằng dữ kiện chứ không bằng cảm giác:

• Lý do ban đầu làm dự án này còn đúng không? Thị trường và ưu tiên của doanh nghiệp có thể đã đổi trong sáu tháng qua.
• Phần còn lại cần bao lâu, theo tốc độ thật đã quan sát? Không dùng ước lượng ban đầu, dùng tốc độ thực tế của mấy tháng vừa rồi.
• Số tiền còn phải bỏ ra có nhỏ hơn giá trị thu về không?

Bẫy lớn nhất ở đây là tiếc tiền đã bỏ ra. Khoản đó không lấy lại được dù có làm tiếp hay không, nên nó không nên tham gia vào quyết định. Chỉ có chi phí còn lại và giá trị còn lại mới đáng cân nhắc.

Nếu quyết định làm tiếp, hãy làm lại phần nền trước: ước lượng lại một lần dựa trên tốc độ thật, cắt phạm vi thay vì cắt chất lượng, và chia thành các mốc hai đến bốn tuần mà mỗi mốc đều có thứ chạy được. Bài vì sao dự án phần mềm vượt ngân sách phân tích kỹ hơn phần này.

Nếu quyết định đổi nhà cung cấp

Với một dự án phần mềm chậm tiến độ đã kéo dài, đổi nhà cung cấp không mất tất cả như nhiều người lo. Phân biệt rõ hai phần:

• Giữ được: mã nguồn nếu hợp đồng có điều khoản chuyển giao, dữ liệu, quyền truy cập hạ tầng, và toàn bộ hiểu biết về bài toán mà đội của bạn đã tích lũy.
• Mất: khoảng hai đến bốn tuần để đội mới đọc hiểu mã nguồn cũ, phần việc làm dở không dùng lại được, và chi phí kiểm tra lại chất lượng phần đã bàn giao.

Khoảng thời gian hai đến bốn tuần nên được đưa vào kế hoạch ngay từ đầu, thay vì trở thành bất ngờ khó chịu sau khi đã ký với bên mới.

Khi làm việc với nhà cung cấp mới, nên hỏi trước các câu về quyền sở hữu, trách nhiệm sau bàn giao và cách nhìn thấy tiến độ. Danh sách câu hỏi đầy đủ nằm trong bài chọn phần mềm và nhà cung cấp và ước lượng dự án phần mềm.

Phòng ngừa dự án phần mềm chậm tiến độ cho dự án tiếp theo

• Mốc đầu tiên không quá ba tuần, và phải có thứ chạy được.
• Mỗi yêu cầu phát sinh ghi kèm số ngày ngay tại lúc thống nhất.
• Một người duy nhất chịu trách nhiệm về kết quả kinh doanh, có quyền dừng dự án.
• Thỏa thuận ngay từ đầu: mã nguồn và dữ liệu thuộc về ai, lấy ra bằng cách nào.
• Người báo rủi ro sớm phải được ghi nhận, không bị hỏi vặn.

Về chi phí, nên có một mức tham chiếu trước khi đàm phán với bất kỳ bên nào. Anh chị có thể xem mức giá thuê ngoài phát triển phần mềm tại Việt Nam được công bố công khai.

Ai nên chịu trách nhiệm khi dự án phần mềm chậm tiến độ

Trong phần lớn doanh nghiệp, ngân sách thuộc về người ký hợp đồng, còn tiến độ thuộc về người quản lý đội làm. Khoảng trống giữa hai vai này là nơi dự án trượt, vì không ai sở hữu câu hỏi quan trọng nhất: việc này còn đáng làm nữa không.

Cách sắp xếp tốt hơn là chỉ định một người chịu trách nhiệm về kết quả kinh doanh, không phải về sản phẩm bàn giao. Người đó duyệt mọi thay đổi phạm vi, nhìn thấy nhật ký thay đổi, và có quyền dừng dự án. Thiếu quyền dừng thì vai trò đó chỉ là báo cáo, không phải chịu trách nhiệm.

Một cách kiểm tra nhanh: thử hỏi ai sẽ phải đồng ý nếu ngày mai muốn dừng dự án. Nếu câu trả lời mất hơn vài giây, trách nhiệm đang bị chia cho đủ nhiều người để không ai thực sự giữ nó.

Chi phí thật của việc kéo dài một dự án phần mềm chậm tiến độ

Chi phí dễ thấy là tiền trả thêm cho mỗi tháng kéo dài. Ba khoản khó thấy hơn thường lớn hơn khoản đó:

• Cơ hội thị trường. Sản phẩm ra sau đối thủ sáu tháng bước vào một thị trường khác với thị trường lúc bắt đầu.
• Thời gian của đội nội bộ. Mỗi cuộc họp tiến độ, mỗi lần kiểm thử lại đều lấy đi thời gian của người đang có việc khác.
• Niềm tin nội bộ. Sau một dự án kéo dài, đề xuất công nghệ tiếp theo sẽ khó được duyệt hơn, kể cả khi đó là đề xuất tốt.

Nói cách khác, một dự án phần mềm chậm tiến độ nên được quyết định bằng chi phí còn lại để hoàn thành, không bằng số tiền đã bỏ ra.

Câu hỏi thường gặp

Dấu hiệu nào cho thấy dự án phần mềm chậm tiến độ?

Năm dấu hiệu sớm: báo cáo luôn đúng tiến độ nhưng không có bản chạy được để xem; tỷ lệ hoàn thành tăng đều trong khi ngày demo lùi mãi; yêu cầu phát sinh không được ghi lại chi phí thời gian; người làm chính đổi giữa chừng không bàn giao; và không ai chủ động báo rủi ro.

Dự án phần mềm chậm tiến độ thì nên làm gì trước tiên?

Yêu cầu một bản chạy được trong vòng một tuần, dù phạm vi nhỏ đến đâu. Một bản demo thật nói nhiều hơn mọi báo cáo phần trăm. Sau đó mới ước lượng lại dựa trên tốc độ thực tế đã quan sát.

Dự án phần mềm chậm tiến độ: khi nào nên đổi nhà cung cấp?

Khi đã yêu cầu bản chạy được hai lần mà không nhận được, khi không ai trả lời được còn bao nhiêu việc, hoặc khi nhà cung cấp từ chối bàn giao mã nguồn và quyền truy cập. Ba dấu hiệu này cho thấy vấn đề nằm ở năng lực hoặc thiện chí, không phải ở độ khó kỹ thuật.

Tóm lại: dự án phần mềm chậm tiến độ không phải chuyện hiếm, và dấu hiệu luôn xuất hiện sớm hơn thời điểm nó được thừa nhận. Dự án gần nhất của anh chị có dấu hiệu nào trong năm dấu hiệu trên?