Một dự án công nghệ nhiều khả năng đang đốt tiền khi ba chuyện cùng xảy ra: hạn chót cứ lùi mà không chỉ ra được nguyên nhân cụ thể, mấy tuần gần đây không ai cho mình xem được thứ gì dùng thử được, và yêu cầu mới cứ đổ thêm vào trong khi không có ai đủ quyền nói "không". Thấy các dấu hiệu này thì nên tạm dừng, đòi xem bản chạy thật và một kế hoạch thu gọn, thay vì rót thêm tiền và hy vọng.
Dự án tốt dần dần thành dự án tốn kém như thế nào
Hiếm dự án nào đổ vỡ trong một khoảnh khắc. Chúng trôi dần. Lần trễ hạn đầu có lý do nghe hợp lý, lần thứ hai nghe na ná, tới lần thứ ba thì mọi người đã quen. Trong khi đó đội làm vẫn bận rộn, báo cáo đầy ắp hoạt động, còn chủ doanh nghiệp thấy hỏi gắt những người rành công nghệ hơn mình thì vừa ngại vừa sợ sai.
Một điểm khởi đầu quen thuộc là đặt viết riêng một phần mềm cho việc mà phần mềm làm sẵn đã làm khá ổn. Viết riêng nghe hấp dẫn vì hứa sẽ "may đo" vừa khít công ty. Nhưng mỗi yêu cầu đặc thù đều thêm việc thiết kế, lập trình, kiểm thử, và về sau mỗi lần công ty đổi cách làm lại phải trả tiền thêm. Dự án biến thành một khoản phụ thuộc lâu dài chứ không còn là món mua một lần.
Kiểu thứ hai là mục tiêu cứ dịch chuyển. Đang làm giữa chừng, chủ doanh nghiệp thấy app của đối thủ và muốn có tính năng tương tự; một trưởng phòng xin thêm báo cáo; ai đó muốn chạy được cả trên điện thoại. Mỗi yêu cầu nhỏ thôi, nhưng cộng lại thì khối lượng gấp đôi, còn hạn chót ban đầu chưa bao giờ được điều chỉnh theo.
Khó nhất là cảm giác tiếc tiền đã bỏ. Chi một khoản lớn rồi, dừng lại giống như thừa nhận mình phí. Nhưng tiền đã chi thì đằng nào cũng mất. Câu hỏi thật duy nhất là khoản tiếp theo có mua được thứ gì dùng được không.
Những dấu hiệu cần để ý
Tiến độ được đo bằng hoạt động chứ không bằng kết quả. Báo cáo kể số buổi họp, số giờ làm, nhưng mình không bấm thử được thứ gì chạy thật.
Hạn chót lùi mà không có lý do cụ thể. "Gặp chút vấn đề kỹ thuật" không phải lý do. Lý do thật phải gọi tên vấn đề và cách xử lý.
Không ai cho xem được bản chạy thử. Dự án khoẻ mạnh giao từng phần nhỏ dùng được sau mỗi vài tuần. Nhiều tháng liền "cuối cùng sẽ ráp lại hết" là rủi ro.
Tài liệu phạm vi cứ dày thêm. Tính năng mới được thêm vào, không bỏ bớt cái gì, còn ngân sách và tiến độ trên giấy vẫn y nguyên.
Chỉ một người hiểu hệ thống. Nếu một lập trình viên nghỉ là mọi thứ đứng hình, dự án đang rất mong manh.
Nhân viên chưa ai đụng vào. Những người sẽ dùng hệ thống hằng ngày chưa thử gì cả, nên ý kiến phản đối của họ sẽ đến muộn và tốn kém.
Hỏi gì cũng nhận về một rừng thuật ngữ. Đội làm tốt giải thích được vấn đề bằng lời thường. Lúc nào cũng mù mờ kỹ thuật thường là đang che giấu sự không chắc chắn.
Tiền trả đi trước hàng nhận về. Đã thanh toán phần lớn giá trị hợp đồng nhưng nhận chưa tới một nửa chức năng đã thoả thuận.
Không có danh sách việc đã xong. Không có danh sách rõ ràng những gì đã hoàn thành thì không ai đánh giá được dự án thật sự đi tới đâu.
Cách "khởi động lại" một dự án đang trật đường ray
Khởi động lại không phải để phạt ai. Làm bình tĩnh, nó thường cứu được nửa hữu ích của dự án.
- Tạm dừng ngắn. Ngưng làm tính năng mới một đến hai tuần. Giữ nguyên đội, nhưng dồn sức cho việc làm rõ.
- Đòi xem chạy thật. Không phải slide. Đội làm trình bày cái đang chạy được hôm nay, trên thiết bị thật, với dữ liệu gần giống thật.
- Kê ra cái đã xong, xong một nửa, chưa bắt đầu. Viết bằng lời lẽ mà nhân viên của mình đọc hiểu.
- Cắt phạm vi về bản nhỏ nhất còn dùng được. Chọn những tính năng mà thiếu nó thì hệ thống vô dụng, phần còn lại để sau.
- Cử một người phía mình cầm quyết định. Người này duyệt hay bác mọi yêu cầu mới và được quyền nói không.
- Lập lại kế hoạch theo chu kỳ ngắn. Thống nhất mỗi hai đến bốn tuần giao một phần dùng được, thanh toán gắn với phần đã giao.
- Đặt sẵn điều kiện dừng. Ghi trước kết quả nào, tới ngày nào thì sẽ dừng, để sau này không phải quyết trong hoảng loạn.
Khi nào dừng hẳn là đúng
Nên dừng khi đợt rà lại cho thấy phiên bản nhỏ nhất dùng được vẫn còn rất xa, khi đội làm không giải thích nổi phần việc còn lại, hoặc khi giờ đã có phần mềm làm sẵn đáp ứng được phần lớn nhu cầu. Lúc đó, làm tiếp thường là trả tiền thêm lần nữa cho cùng một sự mơ hồ.
Trước khi dừng, giữ chắc những gì đã trả tiền. Đòi nhận mã nguồn, file thiết kế, cấu trúc cơ sở dữ liệu, quyền truy cập máy chủ và tài liệu, ở tình trạng nào cũng nhận. Xem hợp đồng nói gì về quyền sở hữu và bàn giao; chỗ nào không rõ thì nhờ luật sư tư vấn quyền lợi của mình.
Sau đó tìm phần giá trị còn giữ lại được. Nhiều khi phần dữ liệu đã làm sạch, sơ đồ quy trình hay danh sách yêu cầu trong dự án còn đáng giá hơn cả mã nguồn, vì chúng giúp lần làm sau, hoặc việc chọn phần mềm làm sẵn, nhanh hơn rất nhiều.
Cũng nên viết một bản rút kinh nghiệm ngắn, không đổ lỗi, khi mọi chuyện còn nhớ rõ. Mình đã đòi những gì mà thật ra không cần? Dấu hiệu nào xuất hiện đầu tiên, và vì sao không ai ra tay? Quyết định nào nếu làm lại sẽ chọn khác? Hai trang ghi chép thật lòng bảo vệ công ty tốt hơn nhiều so với một cảm giác chung chung kiểu "làm công nghệ rủi ro lắm".
Cuối cùng, nói chuyện thẳng thắn với nhân viên. Một dự án bị huỷ để lại sự mệt mỏi và hoài nghi. Giải thích đã học được gì, sắp tới làm gì sẽ ngăn sự hoài nghi đó giết luôn dự án sau, dự án được chọn kỹ hơn.
Làm tiếp, khởi động lại hay dừng: bảng quyết nhanh
Dùng sau buổi xem chạy thật và bản kê tình trạng trung thực.
| Tình huống | Quyết định hợp lý | Vì sao |
|---|---|---|
| Tính năng cốt lõi chạy được, phần phụ trễ | Làm tiếp với phạm vi thu gọn | Phần hữu ích đã có, phần còn lại để sau |
| Một phần cốt lõi chạy được, kế hoạch mù mờ | Khởi động lại theo chu kỳ ngắn | Có giá trị nhưng cần kiểm soát |
| Nhiều tháng vẫn chưa có gì dùng được | Cân nhắc nghiêm túc việc dừng | Tiền thêm chỉ mua thêm mơ hồ |
| Phần mềm làm sẵn giờ đáp ứng gần hết | Dừng hoặc chuyển hướng | Viết riêng không còn đáng tiền |
| Lập trình viên chính đã nghỉ, không có tài liệu | Tạm dừng, đánh giá bàn giao trước | Rủi ro quá cao để làm tiếp |
Câu hỏi thường gặp
Dự án phần mềm nên cho xem kết quả chạy thật bao lâu một lần?
Với phần lớn dự án doanh nghiệp, hai đến bốn tuần một lần là nhịp khoẻ. Mỗi lần giao không cần hoàn chỉnh, nhưng phải là thứ người thật dùng thử được.
Dự án công nghệ vượt ngân sách có phải chuyện bình thường?
Vượt một phần thì khá thường gặp, nhất là khi yêu cầu ban đầu mơ hồ. Điều không bình thường là vượt mà không giải thích được, hoặc ngân sách cứ tăng trong khi kết quả giao ra vẫn đứng yên.
Có nên đổi đơn vị làm giữa chừng?
Chỉ nên đổi sau khi đã nhận đủ bàn giao mã nguồn, tài khoản, tài liệu, và đội mới đã đánh giá những gì họ nhận. Đổi mà không bàn giao sạch thường là phải làm lại từ đầu.
Từ chối yêu cầu thêm tính năng của các quản lý thế nào?
Giữ một danh sách công khai những ý tưởng để sau, hứa sẽ xem lại khi hệ thống cốt lõi chạy ổn. Người ta dễ chấp nhận "chưa phải lúc" hơn "không bao giờ", và khi đã dùng thật, danh sách đó thường tự ngắn lại.
Trong công ty nhỏ, ai nên cầm dự án công nghệ?
Một người phía nghiệp vụ hiểu công việc hằng ngày và có quyền quyết, có người kỹ thuật tư vấn bên cạnh. Giao hẳn cho bên phát triển bên ngoài thì không ai bảo vệ thứ tự ưu tiên của công ty.
