Trước khi trả lời họ, tôi hỏi ý kiến của họ. Họ tin rằng vì họ được đào tạo về quản lí, họ có thể quản lí mọi thứ và đó là điều họ được dạy trong trường kinh doanh. Tôi KHÔNG đồng ý với quản điểm đó nên sau đây là thảo luận của tôi về quản lí dự án phần mềm:
Có nhiều lí do cho dự án phần mềm thất bại nhưng lí do hiển nhiên nhất là người quản lí dự án không có kinh nghiệm hay kĩ năng quản lí dự án. Nhiều người quản lí dự án hứa với khách hàng bất kì cái gì chỉ để làm hài lòng họ mà không thực sự biết sẽ mất bao nhiêu thời gian và cần bao nhiêu nỗ lực. Họ chấp nhận “lịch biểu phi thực tế” từ khách hàng rồi buộc tổ dự án phải tuân theo. Tất nhiên, đây là công thức cho thất bại bởi vì việc cần sáu tháng nhưng khách hàng chỉ cho bạn ba tháng thì bạn không thể hoàn thành được nó bằng làm việc cần cù hơn. Nhiều người quản lí không lập kế hoạch mà nhảy ngay vào viết mã để chứng minh cho người quản lí cấp cao rằng họ “rất tích cực”. Không lập kế hoạch cẩn thận, họ sẽ bỏ lỡ nhiều điều quan trọng và họ phải “làm lại từ đầu” cho chúng. Việc thiếu lập kế hoạch này làm tốn nhiều tiền cho công ti khi dự án phải chi tiêu nhiều hơn nó đáng phải chi tiêu.
Câu hỏi của tôi là: Chương trình MBA có dạy ước lượng phần mềm và lập kế hoạch phần mềm không?
Bởi vì nhiều người quản lí dự án không biết cách ước lượng lịch biểu, họ “lập lịch ngược” từ hạn chót đã cho và hi vọng mọi sự sẽ tốt. Chẳng hạn dự án bắt đầu từ tháng giêng và khách hàng cho họ sáu tháng thì bản kế hoạch sẽ trông như thế này: Tháng sáu: Chuyển giao phần mềm, Tháng năm: Kiểm thử phần mềm; Tháng ba và bốn: Viết mã; Tháng hai: Thiết kế và tháng giêng: Xây dựng tổ. Họ thêm ngày vào bản kế hoạch mà không biết gì về cách ước lượng thời gian cần cho từng pha. Thỉnh thoảng họ dùng kĩ thuật “lạc quan” từ các sách giáo khoa kinh doanh hàn lâm như ước chi phí bằng việc dùng công thức: Chi phí = Kích cỡ x độ phức tạp/năng suất. Đây là lí thuyết đúng nhưng KHÔNG THỂ cáp dụng được vào “dự án thực” bởi vì nó có ba nhân tố không biết: Kích cỡ, độ phức tạp và năng suất. Trong lớp học, các giáo sư cho sinh viên những nhân tố đó để tính chi phí nhưng trong thực tế, đặc biệt lúc bắt đầu dự án, khó mà ước lượng kích cỡ hay độ phức tạp của mã. Trong bất kì biến cố nào, mọi ước lượng chi phí đều có may rủi tiềm năng, không được kiểm điểm và điều chỉnh, công ti có thể đi tới ước lượng thấp cho phí và mất tiền. Điều này xảy ra nhiều trong công nghiệp ngày nay.
Câu hỏi của tôi là: Chương trình MBA có dạy lập lịch phần mềm và điều chỉnh ước lượng chi phí không?
Nhiều người quản lí dự án KHÔNG biết cách thu được yêu cầu từ khách hàng. Họ tin điều khách hàng nói cho họ là “đủ tốt”. Không trắc nghiệp hay tuân theo phương pháp phân tích yêu cầu để nhận diện điều khách hàng thực sự cần, họ sẽ làm việc với các yêu cầu được cho. Tất nhiên, khách hàng thay đổi ý của họ và thường thêm nhiều chức năng vào yêu cầu của họ. Những điều này gây ra nhiều thay đổi trong dự án và đến lượt nó, gây ra nhiều việc làm lại, nhiều thời gian, và cuối cùng làm chậm trễ dự án. Dự án phần mềm KHÔNG chỉ là lập trình mà đi tới giải pháp cho vấn đề doanh nghiệp. Để hiểu các yêu cầu phần mềm, người quản lí phải hiểu yêu cầu doanh nghiệp, các yêu cầu hệ thống, yêu cầu phần cứng bởi vì các yêu cầu phần mềm vận hành trên ba mức này.
Câu hỏi của tôi là: Chương trình MBA có dạy việc phát triển yêu cầu, vấn đề người dùng, vấn đề phần cứng, trắc nghiệm và kiểm nghiệm yêu cầu không? Nó có các kĩ thuật mô hình hoá bằng việc dùng công cụ phần mềm không?
Nhiều người quản lí dự án không được đào tạo về ước lượng tài nguyên như số người được cần tới, kĩ năng được cần tới của họ, cho nên họ lất bất kì ai sẵn có vào làm việc cho dự án. Khi dự án có người sai với kĩ năng hạn chế, năng suất sẽ bị ảnh hưởng. Nhiều người quản lí không biết cách thuê và giữ người then chốt, họ không biết về tất cả những kĩ năng cần để phát triển phần mềm nhưng nghĩ về những người phần mềm là những người lập trình. Không có tri thức kĩ thuật chi tiết về kiến trúc, thiết kế, phần cứng và giao diện hệ thống, họ có thể phân công người sai cho các nhiệm vụ mà những người này không đủ phẩm chất và kết quả có thể là thảm hoạ. Không có hồ sơ về con người với tri thức chuyên gia nào đó được cần để thực hiện công việc dự án sẽ thất bại.
Sai lầm thông thường khác là nhiều người quản lí không cho đủ thời gian cần thiết cho các thành viên tổ học về dự án trước khi họ bắt đầu. Học về các yêu cầu của dự án đòi hỏi thời gian và nên được xem xét trong kế hoạch dự án. Nhiều công ti có nhiều dự án yêu cầu kĩ năng tương tự cho nên họ dịch chuyển người then chốt của mình từ dự án này sang dự án khác dựa trên ưu tiên giữa các dự án. Kĩ thuật quản lí “luân chuyển người” này là phí hoài năng suất quí giá bởi vì các thành viên tổ mất thời gian để làm quen với dự án họ được phân công. Thực hành này cũng làm nảy sinh một dự án phải dừng làm việc tạm thời cho tới khi thành viên tổ quay lại từ dự án khác. Điều này đặc biệt mấu chốt khi một kĩ năng then chốt cần được tham gia vào và điều đó làm chậm lịch biểu dự án và đóng góp thêm vào việc làm mòn mỏi nhân viên vì mọi người phải làm quá nhiều thứ trong một thời kì kéo dài.
Nhiều người quản lí bận rộn thế và họ không theo dõi điều người của họ làm từng ngày. Họ không biết về hoạt động của nhân viên để cho họ có thể thúc bẩy các kĩ năng nhân viên cho có năng suất. Họ phân công người làm việc trên các nhiệm vụ tương ứng theo lịch biểu; chừng nào họ còn đáp ứng được lịch biểu thì không có vấn đề gì. Tuy nhiên, có các thành viên có thể hoàn tất nhiệm vụ 5 ngày trong 2 ngày và người khác có thể không hoàn thành được nhiệm vụ 3 ngày trong ít nhất 10 ngày do kĩ năng của họ và việc phân công. Không kiểm điểm các hoạt động trên cơ sở hàng ngày hay hàng tuần, người quản lí không biết ai cần giúp đỡ và ai không cần giúp đỡ cho tới khi vấn đề nảy sinh. Hiểu biết về phân phối công việc, về phân công nhiệm vụ và tri thức về kĩ năng là mấu chốt trong mọi dự án phần mềm.
Câu hỏi của tôi là: Chương trình MBA có dạy qui trình phát triển phần mềm, đào tạo kĩ năng, nhận diện kĩ năng và phân công công việc không?
Điều gì sẽ xảy ra khi cái gì đó xấu xuất hiện trong dự án phần mềm? Không có đào tạo đúng, nhiều người quản lí trở nên giận dữ, thay vì lãnh đạo và hỗ trợ tổ dự án, họ làm nản lòng nhân viên bởi yêu cầu rằng nhân viên phải làm những điều nào đó hay buộc tội nhân viên không làm việc chăm chỉ hơn. Điều này sẽ thêm sức ép cho môi trường làm việc linh động và làm giảm năng suất hay thành viên tổ, đến lượt mình sẽ làm chậm trễ dự án thêm nữa. Khi họ thấy rằng gần tới hạn chuyển giao nhưng tổ của họ vẫn còn đang viết mã, họ ra lệnh cho nhân viên bỏ qua vài thứ như kiểm điểm hay kiểm thử để tiết kiệm thời gian. Thiếu kiểm thử, phần mềm sẽ có nhiều lỗi rồi công ti phải sửa các lỗi này. Điều này sẽ yêu cầu nhiều thời gian hơn, nhiều nỗ lực hơn, nhiều tiền hơn và nhiều chậm trễ hơn. Tất nhiên, khách hàng KHÔNG hài lòng và có thể không muốn làm kinh doanh với công ti trong tương lai. Khi các vấn đề nảy xảy ra, nhiều người quản lí buộc tổ làm việc nhiều giờ hơn trong một thời gian kéo dài để sửa lỗi của lịch biểu không thực tế cho nên nhiều thành viên tổ rời khỏi dự án trước khi dự án được hoàn thành.
Câu hỏi của tôi là: Chương trình MBA có dạy cách quản lí người kĩ thuật không? Cách phối hợp công việc tổ? Cách nuôi dưỡng tổ thay vì lạm dụng họ?
Chúng ta có thể làm gì để tránh những sai lầm này?
Câu trả lời hiển nhiên là: Cung cấp đào tạo tốt hơn cho người quản lí phần mềm nhưng riêng một mình đào tạo có đủ không? Liệu có thể cho ai đó KHÔNG có tri thức phần mềm làm quản lí dự án phần mềm không? Liệu có thể cho một người kinh doanh tốt nghiệp MBA quản lí dự án phần mềm không? Người quản lí được đào tạo về doanh nghiệp có thể quản lí được mọi thứ không?
Tôi tin người quản lí phần mềm tốt PHẢI có cả kinh nghiệm kĩ thuật và doanh nghiệp. Họ phải làm việc trong phát triển phần mềm trong nhiều năm để họ hiểu mọi hoạt động bên trong một dự án. Họ phải nhận được đào tạo về ước lượng thời gian, nỗ lực và lập lịch biểu và thực tế thực hiện những việc này trong các dự án thực để cải tiến kĩ năng của họ. Họ phải hiểu rằng lập kế hoạch không bao giờ đứng yên nhưng thường xuyên phải được cập nhật vì mọi sự luôn thay đổi. Người quản lí tốt bao giờ cũng học cách thương lượng với khách hàng và không bao giờ phạm sai lầm uỷ nhiệm “ngày tháng lịch biểu không thực”. Bởi vì những yêu cầu này, người quản lí phần mềm GIỎI là rất khó tìm ra và đó là lí do tại sao nhiều công ti phần mềm toàn cầu sẵn lòng trả lương cao cho họ.
Last week, I had a meeting with several students from the Master of Business Administration (MBA) program. They asked me why so many software projects failed and whether a business manager graduate from the MBA program could manage software projects. Before answering them, I asked about their opinions. They believe that since they are trained in management, they could manage anything and that is what they are taught in business schools. I do NOT agree with that view so following are my discussion on software project management:
There are many reasons for software project failure but the most obvious reason is project managers do not have the experiences or the skills to manage the projects. Many project managers promise customers anything just to please them without really knows how long it will take and how much efforts are required. They accept an “unrealistic schedules” from customers then force project teams to follow. Of course, this is a formula for failure because if it needs six months but customer only give you three months then you can not complete it by working harder. Many managers do not plan but jump quickly into code to prove to their senior managers that they are “very active”. Without careful planning, they will miss many important things and then have to “redo” them. This lack of planning costs a lot of money for the company as the project spends more than it makes.
My question is: Does the MBA program teach software estimates and software planning?
Because many project managers do not know how to estimate schedule, they “schedule backward” from the given dateline and hope things will be fine. For example project starts in January and customers give them six months then the plan will look like this: June: Deliver software, May: Test software; March and April: Coding; February: Design and January: Build team. They just add the date in a plan without knowing anything about how to estimate the time required for each phase. Sometime they use “optimistic” technique from academic business text book such as cost estimate using the formula: Cost = Size x complexity/productivity. This is correct in theory but CAN NOT applies in “Real project” because it has three unknown factors: Size, Complexity, and Productivity. In classrooms, professors give students those factors to calculate cost but in reality, especially at the beginning of project, it is difficult to estimate size or complexity of the code. In any event, all initial cost estimates are potential risk, without carefully reviewed and adjustment, the company may end up underestimate the costs and lose money. This happens a lot in software industry today.
My question is: Does the MBA program teach software scheduling and cost estimates adjustment?
Many project managers do NOT know how to obtain requirements from customers. They believe what customers tell them is “Good enough”. Without verification or follow requirement analysis method to identify what customers really need, they will work with the given requirements. Of course, customers always change their minds and often add more functionality to their requirements. These will cause more changes in the project and in turn, causes more reworks, more times, and eventually delay the project. A software project is NOT just programming but come up with a solution for a business problem. To understand software requirements, managers must understand business requirements, system requirements, hardware requirements because software requirements operate on these three levels.
My question is: Does the MBA program teach requirements development, user issues, hardware issues, requirements verification and validation? Does it modeling techniques using software tools?
Many project managers are not trained in estimate resources such as the number of people needed, their required skills, so they just get anybody available to work on the project. When project has wrong person with limited skill, productivity will suffer. Many managers do not know how to hire and retaining key people, they do not know about all the skills needed to develop software but think all software people are programmers. Without technical knowledge in detail architect, design, hardware and system interfaces, they may assign the wrong people to the task that they do not qualify and the result could be a disaster. Without a profile of people with certain expertise needed to perform work the project will fail.
Another common mistake that many managers do not allow sufficient time required for team members to learn about the project before they start. Learning about project‘s requirements takes time and should be considered into the project plans. Many companies are having several projects requiring similar skills so they shift their key people from one project to another based on the priority among the projects. This “moving people around” management technique wastes precious productivity because it takes team members time to get acquainted with the project they are being assigned to. This practice also results in one project having to stop work temporary until the team member comes back to the project. This is particularly critical when a key skill is involved and it slowdown project schedule and contributes to employee burnout as people have to work too many things for extended periods.
Many managers are so busy and they do not track what their people do each day. They do not know about their activities so they can leverage their skills for productivity. They assign people to work on tasks according to a schedule; as long as they meet the schedule then there is no problem. However, there are members who could finish a 5 days task in 2 days and other who could not complete a 3 day task for at least 10 days due to their skills and the assignment. Without review activities on a daily or weekly basis, managers do not know who needs help and who do not until problem happens. The understanding of work distribution, of assignment of tasks and the knowledge about skills are critical in every software project.
My question is: Does the MBA program teach software development process, skill training, skill identification, and works assignment?
What will happen when something bad occurs in software project? Without proper training, many managers become angry, instead of leading and supporting the project team, they discourage them by demand that they must do certain things or accuse them for not working harder. This will add pressures to the volatile working environment and reduce productivity or team members, which in turn will delay project furthermore. When they see that it is near the delivery date but their team is still coding, they order them to skip a few things such as reviews or tests to save time. In the absence of testing, software will have many defects then the company has to correct them. This will require more times, more efforts, more money and more delays. Of course, customers are NOT happy and may not want to do business with the company in the future. When problems happen, many managers force the team to work more hours for extended periods to fix mistakes of unrealistic schedule so many team members quit before the project is completed.
My question is: Does the MBA program teach how to manage technical people? How to coordinate teamwork? How to nurture the team rather than abuse them?
What can we do to avoid these mistakes?
The obvious answer is: Provide better training to software managers but is training alone be sufficient enough? Is it possible for someone who does NOT have software knowledge to manage software project? Is it possible for an MBA graduated business person to manage software project? Can a business trained manager manage everything?
I believe good software managers MUST have both technical and business experiences. They must work in software development for many years so they understand all the activities within a project. They must receive training in estimation of time; efforts and planning schedules and actually perform these works in real projects to improve their skills. They must understand that planning never stop but constantly updated as things always change. A good project manager always learns how to negotiate with customers and never make mistake of mandate the “unrealistic schedule date”. Because of these requirements, a GOOD software manager is very hard to find and that is why many global software companies are willing to pay top salary for them.
