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ì:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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ả”.
8. 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ả.
9. 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ứ.
10. 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.
11. 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.
12. 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”.
13. 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.
14. 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.
15. 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 đó.
16. 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!

—-English version—-

The worst project manager

Last week, a student asked me: “You have taught us how to succeed in managing a software project but not mentioned about things that make the project fail? What are things that we must avoid? What are things that a project manager should never do? How do we know a good project manager from the “Worst” project manager?

After think about that for a while, I come up with  a list of things that will GUARANTEE TO FAIL any software project and what “THE WORST” project manager would do:

1. Skip project planning: Planning a software project is difficult. It takes effort to estimate many things when you can code instead. Besides, things always change and you have to re-plan anyway. Why wasting time to plan a project when you can code and finish the project faster.
2. Skip the estimates: Estimate time, efforts, and costs for a software project takes time. Why bother to do it when customer already give you a final date to deliver the software. Just accept that date and plan everything backward from that date to today date then you have a schedule. Divide the schedule into phases such as design, code, test and deliver software then you have a project plan. As long as the date of delivery of software is the same date the customer want then you are successful.
3. Skip customer meeting: Customers do not know what they want, they do not understand software. They always ask many things and slow the project down. Project manager already has a schedule given by customer so why meet with the customer again? The more you meet with them, the more they will tell you how to do your job and waste your time.
4. Skip team building: You never have enough time for the project. Why bother with team building exercises? Just select team members who are your friends, you know them and they know you so everybody can work together. If your friends have difficulty then add more of their friends later because friends always work together.
5. Skip the training: Why worry about project training? People always help each other anyway. If one have difficulty other will help. They all have college degrees which means they have skills and do not need more training. Training is expensive and takes time away from “real work”. We must save money and finish the project.
6. Skip team meeting: Team meeting is a waste of time, team members may ask questions that you may not be able to answer. The team’s job is to code, not to ask question. Project manager should discourage members to ask questions. Without meeting, the team has more time to work because their job is to work, not to bother the project manager.
7. Skip the break: Most software project are difficult and require long hours. The job of the project manager is to make sure that the team works hard. There is no time to waste. Break time will give the team time to relax and not focus on work. People may gossip about things not related to the project and forget about what they are supposed to do. Weekend also keep their minds away from the project so it may be necessary to force them to work through the weekend to get thing done and be the “effective manager”.
8. Skip the report to managers: Why bother to check progress and report project status to senior managers? Do not tell them anything that make them worry. Senior managers have more things to do than worry about the project. That is not their job but mine. Just tell them everything is good, we are making progress then they will be happy. Nobody like bad new anyway.
9. Skip review with customer: Customer should not interfere in the project. There is no reason to tell them anything until the project is complete. If they ask, just tell them everything is fine. A good project manager should use the time to get the job done and not allow customer to get involved. They must “trust” the project manager to do the “right thing”.
10. Skip the change process: Change control makes customer unhappy. We should allow customer to make change at any time. The more change, the more they are happy and customer satisfaction is the “right thing” to do. We can eliminate the software configuration management and save money for the project. We should eliminate change board and change documentation to reduce “Bureaucracy”. Afterall we should be more “Agile”.
11. Skip quality review: Quality should be part of what the team does. Quality Assurance does not add value to the project, they bother developers and slow down project works. We should not waste of time on quality reviews. If we skip quality reviews, we can save more money. If software has defects, we can fix them later.
12. Skip personnel review: People always move so staff turnover is a normal thing. If team members leave, let them go and hire another. There are many people who need jobs. No one is “irreplaceable”.
13. Skip risk management: Everything can happen WILL happen. Why bother about thing you cannot control. No project is perfect, if it happens then the project will deal with it. If we cannot deal with it, senior managers will have to fix it. That is their jobs. The project should not worry too much about risks.
14. Skip monitoring the progress: If you do NOT check for progress, you do not discover that the project is slipping. Less pressure and less stress for the project manager.
15. Skip the worry: If the project has technical problems, a project manager can blame the technical lead. Maybe firing the technical lead will make the team scare and work harder. If the project has many defects, project manager should blame some developers and threaten them with “laid-off” then they will have to fix the defects. An “effective manager” should be able to do that.
16. If the project fail, there are many other projects. Since I am a relative of the company owner, my job is always safe.

Basically, follow the above “logic” I will GUARANTEE that the software project, or any project WILL FAIL. As a “smart” rule, if you meet this type of manager, prepare your resume and quickly find another job or else you will learn “BAD HABBIT”. Guaranteed!