Vài năm trước đây khi tôi dạy quản lí dự án phần mềm ở châu Á, tôi thấy rằng có lẫn lộn giữa “quản lí dự án” và “quản lí dự án phần mềm”.

Một số đại học đã dùng sách “Quản lí dự án” được viết cho công nghiệp xây dựng và các công nghiệp khác nhưng không cho phần mềm. Chẳng hạn, khi họ ước lượng nỗ lực, nhiều người bắt đầu với 5% trong pha quan niệm và khởi đầu, 10% trong pha kiến trúc và thiết kế, 75% trong pha thực hiện, và rồi 10% về bảo hành. Điều này là đúng cho công nghiệp xây dựng. Bạn không cần nhiều người khi làm việc với người chủ để hiểu nhu cầu yêu cầu. Lập kế hoạch xây dựng chủ yếu là công việc hậu cần và quản trị. Bạn không cần nhiều người trong pha kiến trúc và thiết kế. Kiến trúc sư thiết kế ra việc xây dựng với một tổ nhỏ và khi bản kế hoach kiến trúc được hoàn thành, nó không bao giờ thay đổi. Nỗ lực chính xảy ra trong pha xây dựng khi bạn cần nhiều công nhân để xây nhà. Sẽ có nỗ lực nhỏ nào đó trong pha bảo trì  (Sơn và trang hoàng làm đẹp).

Trong dự án phần mềm, pha quan trọng nhất là hai pha đầu. Lập kế hoạch là mấu chốt và kiến trúc cùng thiết kế là bản chất. Vì yêu cầu phần mềm thường thay đổi, thường muộn trong dự án; các thành viên tổ phải tham gia sớm vào hiểu nhu cầu doanh nghiệp, phân tích và trắc nghiệm các yêu cầu để làm giảm rủi ro của thay đổi yêu cầu. Nỗ lực được cần tới phải ít nhất là 20% trong pha yêu cầu, 20% trong pha lập kế hoạch, và 20% trong pha kiến trúc và thiết kế. Bằng việc có ít nhất 60% thành viên tổ tham gia vào trong dự án từ sớm, tổ có thể làm việc với khách hàng để thu thập yêu cầu rồi chia các yêu cầu thành các cấu phần nhỏ hơn nơi họ có thể ước lượng chính xác hơn. Biết nỗ lực và thời gian cần để thực hiện, họ có thể lập kế hoạch dự án tương ứng. Tổ tổ chức các cấu phần này tương ứng theo kiến trúc để cho đến cuối chúng tất cả khớp đúng. Chỉ khi những việc này được làm xong tổ mới có thể thiết kế từng cấu phần về chi tiết hơn. Bằng việc làm hầu hết công việc sớm hơn và chắc rằng các yêu cầu là được tính tới; việc xây dựng và kiểm thử sẽ dễ dàng hơn. Dự án phần mềm không thất bại vì người lập trình không thể viết mã được; nó thường thất bại vì yêu cầu kém, lập kế hoạch kém, và quản lí dự án kém.

Bởi vì lẫn lộn về “quản lí dự án” và “quản lí dự án phần mềm”, một số người quản lí không chú ý đủ tới các pha sớm của phát triển phần mềm làm phát sinh nhiều thất bại. Ở một số nước, quản lí dự án phần mềm không được dạy trong chương trình đại học nên sinh viên không hiểu khái niệm và vòng đời quản lí dự án phần mềm. Phần lớn các lớp quản lí dự án được dạy trong trường kinh doanh nơi sinh viên không có tri thức về phát triển phần mềm. Không có tri thức đúng về phần mềm, không có đào tạo dự án phần mềm đúng, nhiều người quản lí đi theo phương pháp thông dụng về “Viết mã & Sửa lỗi”. Phương pháp này bỏ qua yêu cầu và thiết kế để thiên về cách đơn giản viết mã trước rồi sửa lỗi sau. Lập kế hoạch dự án được thực hiện bởi người quản lí dự án mà không có việc tham gia của các thành viên tổ. Không có tri thức đúng về phần mềm, ước lượng dự án được dựa trên lịch biểu do khách hàng đưa cho mặc dù khách hàng thực sự không biết phải mất bao lâu để hoàn thành dự án. Bản kế hoạch dự án được dựa trên ngân sách do người quản lí cấp mà không có ước lượng đúng. Khi nó được chấp thuận, nó không bao giờ được cập nhật cho dù yêu cầu đã thay đổi. Tổ dành hầu hết nỗ lực vào viết mã và sửa lỗi. Họ sửa càng nhiều lỗi họ thêm vào, họ càng phải sửa nó lần nữa. Vòng viết mã và sửa cứ liên tục cho tới cuối. Kết quả là, dự án phần mềm tốn kém, không đáp ứng lịch biểu, và thường có chất lượng kém. Không may, phương pháp này vẫn được dùng ở nhiều chỗ.

Một số sinh viên hỏi tôi: “Tại sao dự án phần mềm khác với dự án không phần mềm?” Điều đó là đơn giản, dự án phần mềm giải quyết với “công việc trí tuệ” trong khi các dự án khác giải quyết “công việc vật lí”. Bạn có thể nhìn vào công việc vật lí như xây nhà và biết bao nhiêu phần của nó đã được hoàn thành. Chẳng hạn, 10% hay 50% nhưng khó làm được điều đó với sản phẩm vẫn còn nằm trong đầu của người phát triển. Người quản lí xây dựng tốt biết sẽ mất bao lâu để xây nhà, người đó có thể tính toán kích cỡ, vật tư, và nỗ lực lao động. Khó tính toán kích cỡ và nỗ lực của dự án phần mềm, đặc biệt trong các pha sớm. Đó là lí do tại sao cần cách tiếp cận và phương pháp khác để quản lí dự án phần mềm.

Tôi thường hỏi sinh viên: “Người không làm phần mềm (như sinh viên trường kinh doanh) có thể quản lí dự án phần mềm không?” Tôi đã viết về chủ đề này vài lần trong blog của tôi. Tôi thường dùng nó như chủ điểm để thảo luận trong lớp quản lí dự án phần mềm của tôi và nó bao giờ cũng tạo ra thảo luận thú vị trong các sinh viên.

Câu hỏi của tôi với bạn: Bạn làm gì trong dự án phần mềm của bạn? Tôi chắc rằng bạn không lập kế hoạch cho thất bại, nhưng nếu bạn đã thất bại trước đây, có lẽ đây là lúc bạn học thêm về quản lí dự án phần mềm hay lấy môn đào tạo chuyên nghiệp về chủ đề này.

—-English version—-

Software project management

Few years ago when I taught software project management in Asian, I found that there was confusion between “project management” and “software project management”. Some universities used “Project Management” books which were written for construction industry and other industries but not software. For example, when they estimated efforts, many began with 5% in conceptual and initiating phase, 10% in architect and design phase, 75% in implementation phase, and then 10% on maintenance. This is correct for construction industry. You do not need a lot of people when working with owner to understand requirement needs. Construction planning is mostly logistic and administration works. You do not need a lot of people during architecture and design phases. The architect designs the construction with a small team and when the architecture plan is complete, it never changes. The major efforts happen during construction phase when you need a lot of workers to build the house. There will be some small efforts in the maintenance phase (Painting and cosmetic decoration).

In software project, the most important phases are the first two. Planning is critical and architect and design are essential. Since software requirements often change, often late in the project; team members must involve early to understand the business needs, analyze and verify requirements to reduce the risk of requirements change. The effort needed should be at least 20% in requirements phase, 20% in planning phase, and 20% in architect and design phase. By having at least 60% of team members involve in the project early, the team can work with customers to collect requirements then breakdowns requirements into smaller components where they can estimate more accurately. Knowing the effort and time required to implement, they can plan the project accordingly. The team organizes these components according to architecture so in the end they all fit correctly. Only when these works are done the team could design each component in more detail. By doing most of the work earlier and make sure that all requirements are accounted for; construction and testing would be easier. Software project does not fail because developers cannot code; it often fails because of bad requirements, bad planning, and bad project management.

Because of the confusion about “project management” and “software project management”, some managers do not pay enough attention to the early phases of software development resulting in many failure. In some countries, software project management is not taught in undergraduate program so students do not understand the concept and the software project management life cycle. Most project management class is taught in business school where students do not have knowledge of software development. Without proper knowledge of software, without proper software project training, many managers follow the common method of “Code & Fix”. This method ignores requirements and design in favor of a simple way to code first then fixing later. Project planning is done by the project manager without the participation of team members. Without proper knowledge of software, project estimate is based on the schedule given by customer even customer really do not know how long would take to complete the project. The project plan is based on a budget given by manager without proper estimation. When it is approved, it never been updated even requirements have changed. The team spends most efforts on coding and fixing. The more they fix the more defects they add so they have to fix it again. The cycle of code and fix continues until the end. As a result, software project is costly, does not meet schedule, and often has poor quality. Unfortunately, this method is still being used in many places.

Some students asked me: “Why software differs from non-software project? It is simple, software project deals with “intellectual work” when the other deals with “physical work”. You can look at a physical work like the construction of a house and know that how much it has been completed. For example, 10% or 50% but it is difficult to do that with a product which is still in the mind of developers. A good construction manager know how long it will take to build a house, he can calculate the size, the materials, and the labor efforts. It is difficult to calculate the size and effort of a software project, especially during early phases. That is why it needs a different approach and method to manage software project.

I often ask students: “Can a non-software person (e.g., students from business school) manage a software project? I have written about this topic several times in my blog. I often use it as a topic for discussion in my software project management class and it always create interesting discussions among students.

My question to you: What are you doing on your software projects? I am sure that you do not plan to fail, but if you have failed before, perhaps it is time for you to learn more about software project management or take a professional training course on this topic.