Theo nhiều nghiên cứu, phần lớn dự án phần mềm thất bại vì cả người quản lí dự án và người phát triển phần mềm đều KHÔNG nhận được đào tạo thích hợp.

Người quản lí điển hình nên có năm tới bẩy năm kinh nghiệm phát triển phần mềm và nhận đào tạo thêm về quản lí dự án phần mềm. Người phát triển phần mềm điển hình tốt nghiệp từ đại học nên dành một tới hai năm trong kiểm thử và hỗ trợ phần mềm trước khi chuyển vào phát triển. Không may là nhiều người phát triển chưa bao giờ dành thời gian vào kiểm thử hay hỗ trợ và nhiều người quản lí chỉ dành thời gian tối thiểu vào phát triển phần mềm rồi được đề bạt mà không có đào tạo thêm nào. Thiếu đào tạo và kinh nghiệm là hai yếu tố chính dẫn tới thất bại dự án phần mềm.

Với dự án phần mềm, động viên là yếu tố quan trọng nhất trong xác định thành công. Nhiều người quản lí dự án không biết cách động viên tổ của họ mà thay vào đó lại ra lệnh nghiêm khắc, điều làm xói mòn tinh thần tổ. Họ ra lệnh rằng tổ phải hoàn thành các nhiệm vụ bằng cách làm việc vất vả hơn, yêu cầu nhiều thời gian thêm trong khi người quản lí dành hầu hết thời gian vào hội họp, không chú ý tới điều đang diễn ra trong dự án. Việc giám sát chặt của cấp quản lí là cần thiết trong mọi dự án phần mềm kể cả lập kế hoạch hiện thực, kiểm soát thay đổi để giữ cho dự án tiến triển tương ứng. Không có quản lí dự án hiệu quả, tổ bị buộc chấp nhận lịch biểu không hiện thực hay làm những thay đổi mà không có phân tích thích hợp, điều làm xói mòn dự án và đảm bảo thất bại. Lịch biểu không hiện thực là sai lầm thông thường nhất mà người quản lí dự án thường phạm phải. Điều này là do thiếu kĩ năng ước lượng của người quản lí dự án. Ngay cả khi các thành viên tổ nói lên ý kiến của mình rằng họ KHÔNG thể hoàn thành được dự án theo lịch đã cho, người quản lí vẫn tin rằng nếu mọi người làm việc chăm chỉ, và với may mắn, họ vẫn có thể hoàn thành dự án đúng hạn.

Một sai lầm thông thường nữa là người quản lí dự án nghĩ các hoạt động và trách nhiệm phối hợp giữa các thành viên tổ là phí thời gian và tổ càng dành nhiều thời gian vào viết mã, dự án càng có thể hoàn thành tốt hơn. Kiểm thử là cái gì đó khi bạn có thời gian, bạn có thể làm nó, nếu không bạn có thể chữa nó về sau. Không có vai trò được xác định rõ ràng, trách nhiệm và nhiệm vụ phối hợp giữa các thành viên tổ, dự án sẽ rơi vào tình huống hỗn độn nơi các thành viên phản ứng với bất kì cái gì xảy ra cho họ. Khi tổ đang nói rằng phải mất nhiều nỗ lực để đáp ứng ngày chuyển giao, người quản lí vẫn tin rằng họ có thể dàn xếp về sau bằng việc bỏ qua vài bước hay làm việc thêm giờ. Loại thái độ này thực tế giống như nhắm mắt với thực tại và hi vọng cái gì đó sẽ có tác dụng. Thái độ rằng lịch biểu là quan trọng mà không có bất kì ước lượng nào là không hợp lí. Niềm tin rằng là người quản lí, bạn có thể ra lệnh cho mọi người làm bất kì cái gì bạn muốn là “thái độ xấu”.

Thỉnh thoảng, khi dự án đang khủng hoảng, người quản lí quyết định thêm nhiều người để tăng tốc mọi thứ. Đây có lẽ là sai lầm thông thường nhất bởi vì thêm người mới có thể kéo năng suất xuống từ các thành viên tổ hiện có. Vì người mới sẽ cần học về dự án và cần giúp đỡ từ các thành viên khác trong tổ, họ sẽ lấy đi thời gian quí giá của các thành viên hiện có trong tổ để huấn luyện các thành viên mới thay vì làm công việc có năng suất cho nên thêm nhiều người vào dự án bị chậm sẽ làm cho dự án càng chậm hơn.

Trong dự án phần mềm, có tình huống thành viên tổ KHÔNG thể hoà hợp được. Xung đột cá nhân là thông thường, đặc biệt lúc bắt đầu dự án. Người quản lí dự án giỏi bao giờ cũng lập kế hoạch để có nhiều thời gian hơn cho xây dựng tổ nhưng đôi khi mọi sự có thể không có tác dụng tốt. Có thể có những người gây ra vấn đề, những người sẽ không khớp vào trong dự án, những người phá vỡ hài hoà của tổ. Chính trách nhiệm của người quản lí dự án là giải quyết vấn đề này. Không giải quyết được người gây vấn đề sẽ gây nguy hiểm cho phát triển dự án. Không giải quyết được với người gây ra vấn đề là phàn nàn thông thường nhất mà các thành viên tổ có với người quản lí dự án. Ngược lại với người hay gây vấn đề là “nhân viên anh hùng”. Đây là những người có thể làm việc tốt, có kĩ năng tốt nhưng chỉ muốn tự mình làm mọi thứ. Nhiều người quản lí dự án thích anh hùng và tin rằng họ là có ích và thích thưởng cho họ về điều họ làm. Nhưng hội tụ vào “hành vi anh hùng” thực sự có hại hơn là có lợi. Đầu tiên điều đó phá huỷ cách làm việc tổ vì mọi người sẽ vào “thế thủ” và giữ mọi thứ cho riêng mình thay vì chia sẻ thông tin hay giúp lẫn nhau. Kết quả có thể là không thông tin nào sẽ được báo cáo cho người quản lí nếu điều xấu xảy ra mãi cho tới phút cuối cùng. Mọi người sẽ buộc tội lẫn nhau về việc phạm sai lầm bởi vì không ai thừa nhận rằng họ có vấn đề và khi tổ không trong hài hoà, dự án sẽ thất bại.

Phát triển phần mềm KHÔNg phải chỉ là viết mã mà thực tế là thiết kế. Viết mã là dễ, thiết kế không dễ và nó yêu cầu kinh nghiệm. Khi sinh viên tốt nghiệp và bắt đầu làm việc, họ sẽ cần dành chút thời gian vào khu vực kiểm thử để học nhiều hơn về thiết kế. Bằng cách làm việc trong khu vực thiết kế, họ có thể quan sát cách người khác thiết kế phần mềm, cách các chức năng được chia thành các mảnh nhỏ hơn, cách các cấu phần làm việc với nhau, cách kiến trúc hệ thống được lập kế hoạch. Đây thực sự là thời gian học tập để xây dựng kĩ năng của họ trước khi họ thực tế có cơ hội tự mình thiết kế hệ thống. Gần như mọi sinh viên đã tốt nghiệp có thể viết mã tốt nhưng kiến trúc và thiết kế thường KHÔNG được dạy chi tiết trong hầu hết các đại học. Bằng việc dành thời gian vào khu vực kiểm thử, sinh viên có thể cải tiến các kĩ năng này và trở thành nhà chuyên môn phần mềm giỏi hơn. Nhiều sinh viên KHÔNG thích làm việc như người kiểm thử để sửa lỗi của ai đó mà muốn làm việc như người phát triển ngay lập tức. Bởi vì họ đã không kinh nghiệm sai lầm của người khác, tự họ sẽ phạm cùng sai lầm.

Vấn đề thông thường khác trong dự án phần mềm là xích mích giữa người phát triển và người dùng. Phần lớn người dùng có vấn đề mà họ muốn người phát triển đi tới giải pháp ngay lập tức cho nên họ bao giờ cũng đòi hỏi lịch biểu chặt chẽ tương ứng với điều họ muốn. Khi người phát triển không chuyển giao theo lịch biểu đó họ trở nên giận dữ. Người phát triển thường cảm thấy rằng người dùng không biết điều họ muốn và đòi hỏi cái gì đó không hợp lí rồi thường xuyên đổi ý của họ sau khi yêu cầu đã được thiết lập. Vấn đề then chốt của xích mích này là kém trao đổi, và yêu cầu được xác định sơ sài. Người phát triển có kinh nghiệm nên học về kĩ nghệ yêu cầu để cho họ biết cách làm việc với người dùng, biết cách trao đổi hiệu quả với họ để có thể đi tới các yêu cầu tốt, thiết kế giao diện người dùng tốt, và có qui trình được xác định tốt để giải quyết các thay đổi yêu cầu. Thiếu kĩ năng này sẽ tạo ra nhiều xích mích hơn và đôi khi chúng còn nghiêm trọng tới mức người quản lí phải cắt bỏ dự án. Kĩ nghệ yêu cầu là kĩ năng mấu chốt và được yêu cầu trong mọi chương trình kĩ nghệ phần mềm nhưng thường không được dạy trong chương trình khoa học máy tính.

Bằng việc có đào tạo đúng cho người quản lí dự án và người phát triển phần mềm, công ti có thể được lợi bằng việc có nhiều cơ hội tốt hơn cho thành công và tránh các vấn đề với dự án phần mềm.

—-English version—-

Software training

According to several studies, most software projects failed because both people who manage the projects and people who develop the software have NOT received adequate trainings. A typical project manager should have five to seven years of software development experience and take additional training in the management of software project. A typical software developer graduated from university should spend one to two years in software testing and supporting before moving into developing. Unfortunately, many developers never spend time in testing or supporting and many project managers only spend a minimum of time in software development then get promoted without any additional training. Lacking of training and experience are two major factors leading to software project failures.

For software project motivation is the most important factor in determine success. Many project managers do not know how to motivate their teams but instead giving strict orders that undermined morale of the team. They give orders that the team must complete their tasks by working harder, requiring more overtime while managers spent most time in meetings, not paying attention of what is going on in projects. Strong management monitoring is needed in every software projects including realistic planning, change control to keep projects progresses accordingly. Without an effective project management, the team is forced to accept unrealistic schedules or make changes without adequate analysis that undermine projects and guarantees failure. Unrealistic schedule is the most common mistake that project managers often make. This is due to the lack of estimate skill of project managers. Even when team members voice their opinions that they can NOT complete the project according to the schedule given, managers believe that if everyone worked hard, and with luck, they can still finish projects on time.

Another common mistake is project managers think coordinate activities and responsibilities among team members is wasting of time and the more the team spend in coding, the better the project can complete. Testing is something that when you have time, you can do it or else you can fix it later. Without clearly defined roles, responsibilities and coordination tasks among team members, the project will fell into chaotic situation where members are reacting to whatever happens to them. When the team is saying that it will take a lot of effort to meet the delivery date, managers believe that they can make up later by skipping few steps or working overtime. This kind of attitude is actually like closing eyes to reality and hoping something will works. The attitude that schedule is important without any estimates are unreasonable. The belief that as manager you can order people to do whatever you wish is a “bad attitude”.

Sometime, when the project is in crisis, managers decide to add more people to speed thing up. This is perhaps the most common mistakes because adding new people can take more productivity away from existing team members. As new members will need to learn about the project and need help from other team members, they will take away precious time from existing team members to train new members rather than do productive work so adding more people to late project will make the project more later.

In software project, there is situation when team members can NOT get along. Personal conflicts are common, especially in the beginning of the project. A good project manager always plan to have more time to build up the team but occasionally thing may not work well. There may be some problem employees, people who will not fit into the project, people who disrupt the harmony of the team. It is the responsibility of project manager to solve this problem. Failure to deal with problem personnel will jeopardize project development. Failure to deal with a problem employee is the most common complaint that team members have about project managers. In contrast to problem employee is the “heroic employees”. These are people who can do good job, have good skills but only want to do everything by themselves. Many project managers like heroes and believe that they are beneficial and like to reward them for what they do. But focusing on “heroic behavior” does more harm than good. First it destroys the teamwork as people will go into “defense positions” and keep things for themselves rather than sharing information or helping each others. The result can be no information will be reported to manager if bad thing happened until the last minutes. People will accuse each others of making mistake because no one would admit that they are having trouble and when the team is in disharmony, project will fail.

Develop software is NOT just coding but actually designing. Coding is easy, designing is not and it requires experience. As students graduated and begin to work, they will need to spend sometime in testing area to learn more about designing. By work in testing area, they can observe how other people design software, how functions are broken down into smaller pieces, how components work together, how the system architect is planed. This is really learning time to build up their skills before they actually get a chance to design the system themselves. Almost every graduated student can code well but architecture and designing are usually NOT taught in detail in most universities. By spending time in testing area students can improve these skills and become better software professionals. Many students do NOT like to work as tester to fix somebody defects but want to work as developer immediately. Because they have not experienced other people mistakes, they will make the same mistake themselves.

Another common problem in software project is the friction between developers and users. Most users have problems that they want to have developers to come up with solutions immediately so they always demand a strict schedule according to what they need. When developers fail to deliver on that schedule they become angry. Developers often feel that users do not know what they want and demand something unreasonably then often change their minds after requirements have been set. The key issue of this friction is poor communication, and poorly defined requirements. Experienced developers should learn about requirements engineering so they know how to work with users, know how to communicate effectively with them so they can come up with good requirements, good user-interface design, and have a well defined process to handle requirements change. Lacking of this skill will create more frictions and sometime they are so severe that managers have to cancel the project. Requirement engineering is a critical skill and required in all software engineering programs but often not taught in computer science program.

By having the right training for project managers and software developers, company can benefit by having much better chance for success and avoid problems with software project.