Người quản lí dự án kém nhất
Tuần trước, một sinh viên hỏi tôi: “Thầy đã dạy chúng em cách thành công trong quản lí dự án phần mềm nhưng không nhắc gì tới những điều làm cho dự án thất bại? Những điều gì chúng em phải tránh? Những điều gì người quản lí dự án không bao giờ nên làm? Làm sao chúng em biết người quản lí dự án giỏi từ người quản lí dự án “kém nhất”?”
Sau khi nghĩ một chốc, tôi đi tới một danh sách những điều sẽ ĐẢM BẢO THẤT BẠI cho bất kì dự án phần mềm nào và người quản lí dự án “kém nhất” sẽ làm gì:
- Bỏ qua lập kế hoạch dự án: Lập kế hoạch dự án phần mềm là khó. Nó cần nỗ lực để ước lượng nhiều điều trong khi bạn có thể viết mã thay vào đó. Bên cạnh đó, mọi sự bao giờ cũng thay đổi và bạn đằng nào cũng phải lập kế hoạch lại. Sao phí thời gian vào lập kế hoạch dự án khi bạn có thể viết mã và kết thúc dự án nhanh hơn.
- Bỏ qua ước lượng: Ước lượng thời gian, công sức và chi phí cho dự án phần mềm cần thời gian. Sao bận tâm làm nó khi khách hàng đã cho bạn ngày cuối cùng phải chuyển giao phần mềm. Cứ nhận ngày đó và lập kế hoạch mọi thứ lùi lại từ ngày đó tới hôm nay và chuyển giao phần mềm rồi bạn có kế hoạch dự án. Chừng nào ngày chuyển giao phần mềm vẫn là cùng ngày khách hàng muốn thì bạn thành công.
- Bỏ qua gặp gỡ khách hàng: Khách hàng không biết họ muốn gì, họ không hiểu phần mềm. Họ bao giờ cũng đòi hỏi nhiều thứ và làm chậm dự án. Người quản lí dự án đã có lịch biểu do khách hàng cho, nên tại sao phải gặp khách hàng nữa? Bạn càng gặp họ, họ sẽ càng bảo bạn cách làm việc của bạn và phí thời gian của bạn.
- Bỏ qua xây dựng tổ: Bạn chưa bao giờ có đủ thời gian cho dự án. Sao bận tâm tới luyện tập xây dựng tổ? Cứ chọn các thành viên tổ là bạn bè của bạn, bạn biết họ rồi và họ biết bạn cho nên mọi người có thể làm việc cùng nhau. Nếu bạn của bạn có khó khăn thì thêm nhiều bạn nữa về sau bởi vì bạn bè bao giờ cũng làm việc cùng nhau.
- Bỏ qua đào tạo: Sao lo nghĩ về đào tạo dự án? Đằng nào thì mọi người bao giờ cũng giúp đỡ lẫn nhau. Nếu người này có khó khăn người khác sẽ giúp. Họ tất cả đều có bằng đại học điều có nghĩa là họ có kĩ năng và không cần đào tạo thêm. Đào tạo là tốn kém và lấy đi thời gian khỏi “công việc thực”. Chúng ta phải tiết kiệm tiền và kết thúc dự án.
- Bỏ qua họp tổ: Họp tổ là phí thời gian, các thành viên tổ có thể hỏi các câu hỏi mà bạn có thể không có khả năng trả lời. Việc của tổ là viết mã, không phải hỏi các câu hỏi. Người quản lí dự án phải không khuyến khích các thành viên tổ hỏi câu hỏi. Không họp, tổ có nhiều thời gian hơn để làm việc bởi vì việc của họ là làm việc, không làm bận tâm người quản lí dự án.
- Bỏ qua nghỉ giải lao: Phần lớn dự án phần mềm là khó và yêu cầu giờ làm việc lâu. Việc của người quản lí dự án là chắc chắn rằng tổ làm việc chăm chỉ. Không có thời gian để phí hoài. Thời gian giải lao sẽ cho tổ thời gian để thảnh thơi và không tập trung vào công việc. Mọi người có thể tán gẫu về những điều không có liên quan tới dự án và quên mất điều họ được cho là phải làm. Nghỉ cuối tuần cũng làm cho tân trí họ xa khỏi dự án cho nên có thể cần buộc họ làm việc cả ngày nghỉ cuối tuần để cho mọi sự được thực hiện và là “người quản lí hiệu quả”.
- Bỏ qua báo cáo với người quản lí: Tại sao bận tâm tới kiểm tra tiến độ và báo cáo tình trạng dự án cho người quản lí cấp cao? Đừng nói cho họ cái gì làm cho họ lo lắng. Người quản lí cấp cao có nhiều thứ phải làm hơn là lo nghĩ về dự án này. Điều đó không phải là việc của họ mà là của tôi. Cứ bảo họ mọi sự đều tốt, chúng ta đang có tiến bộ thì họ sẽ sung sướng. Đằng nào thì chẳng ai thích tin xấu cả.
- Bỏ qua kiểm điểm với khách hàng: Khách hàng không nên can thiệp vào dự án. Không có lí do gì để nói cho họ cái gì chừng nào dự án còn chưa hoàn tất. Nếu họ hỏi, cứ bảo họ mọi sự đều tốt. Người quản lí dự án giỏi nên dùng thời gian để làm cho việc được thực hiện và không cho phép khách hàng được tham gia vào. Họ phải “tin cậy” người quản lí dự án làm “điều đúng” chứ.
- Bỏ qua qui trình thay đổi: Kiểm soát thay đổi làm cho khách hàng không hài lòng. Chúng ta nên cho phép khách hàng thay đổi mọi lúc. Càng thay đổi nhiều, họ càng hài lòng hơn và sự thoả mãn của khách hàng là “điều đúng” cần làm. Chúng ta có thể khử bỏ quản lí cấu hình phần mềm và tiết kiệm tiền cho dự án. Chúng ta nên khử bỏ ban thay đổi và làm tài liệu thay đổi để giảm “quan liêu”. Sau rốt chúng ta nên làm kiểu “Agile- mau lẹ″ hơn.
- Bỏ qua kiểm điểm chất lượng: Chất lượng nên là một phần của điều tổ làm. Đảm bảo chất lượng không tăng thêm giá trị cho dự án, chúng làm cho người phát triển bị bận tâm và làm chậm công việc dự án. Chúng ta không nên phí thời gian vào kiểm điểm chất lượng. Nếu chúng ta bỏ qua kiểm điểm chất lượng, chúng ta có thể tiết kiệm nhiều tiền. Nếu phần mềm có lỗi, chúng ta có thể sửa chúng về sau.
- Bỏ qua kiểm điểm nhân sự: Mọi người bao giờ cũng di chuyển cho nên việc đổi cán bộ là chuyện bình thường. Nếu thành viên tổ ra đi, cứ để họ đi và thuê người khác. Có nhiều người cần việc làm. Không ai là “không thể thay được”.
- Bỏ qua quản lí rủi ro: Mọi thứ có thể xảy ra SẼ xảy ra. Tại sao bận tâm về những điều bạn không thể kiểm soát được. Không dự án nào là hoàn hảo, nếu nó xảy ra thế thì dự án sẽ giải quyết nó. Nếu chúng ta không thể giải quyết được nó, người quản lí cấp cao sẽ phải sửa nó. Đó là việc của họ. Dự án phải không lo nghĩ quá nhiều về rủi ro.
- Bỏ qua giám sát tiến độ: Nếu bạn KHÔNG kiểm tra tiến độ, bạn không phát hiện ra rằng dự án bị trượt. Ít sức ép và ít căng thẳng cho người quản lí dự án.
- Bỏ qua lo nghĩ: Nếu dự án có vấn đề kĩ thuật, người quản lí dự án có thể đổ cho người lãnh đạo kĩ thuật. Có thể việc sa thải người lãnh đạo kĩ thuật sẽ làm cho tổ hoảng sợ và làm việc cần mẫn hơn. Nếu dự án có nhiều lỗi, người quản lí dự án phải trách những người phát triển và đe doạ họ bởi “sa thải” thì họ sẽ phải sửa lỗi. “Người quản lí hiệu quả” nên có khả năng làm điều đó.
- Nếu dự án thất bại, có nhiều dự án khác. Vì tôi có quan hệ với người chủ công ti, việc làm của tôi bao giờ cũng an toàn.
Về căn bản, tuân theo “logic” trên tôi sẽ ĐẢM BẢO rằng dự án phần mềm, hay bất kì dự án nào SẼ THẤT BẠI. Là một qui tắc “thông minh”, nếu bạn gặp kiểu người quản lí này, chuẩn bị bản lí lịch của bạn nhanh chóng đi tìm việc làm khác nếu không bạn sẽ học “THÓI QUEN XẤU”. Bảo đảo đấy!
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
