Tôi bảo anh ta: “Tôi biết một số người quản lí thích để người của họ viết mã sớm nhất có thể được. Họ tin “Phần mềm là mã” cho nên viết mã nghĩa là người của họ đang làm việc. Đó là sai lầm lớn bởi vì họ không hiểu giá trị của lập kế hoạch. Lập kế hoạch dự án là bản lộ trình về cách quản lí dự án và đạt tới mục đích. Không có lập kế hoạch bạn chỉ phản ứng với bất kì cái gì xảy ra và không bao giờ có khả năng kiểm soát dự án của bạn. Dự án thành công khi nó đáp ứng nhu cầu của khách hàng. Bạn KHÔNG BAO GIỜ nên viết mã trước khi bạn thực sự hiểu khách hàng cần cái gì. Cách tốt nhất để làm điều này là bằng tiến hành phỏng vấn khách hàng để hiểu “NHU CẦU THỰC”. Khách hàng thường nói nhiều thứ, một số thứ là “nhu cầu” nhưng một số thứ chỉ là “ước ao” mà có thể không quan trọng, Bạn phải tìm ra cái gì là “nhu cầu thực” mà bạn phải làm và cái gì là “ước ao” mà bạn có thể làm nó nếu bạn có thời gian.”
Anh ta dường như ngạc nhiên: “Tôi đã không biết phỏng vấn khách hàng là một phần của lập kế hoạch dự án?”
Tôi giải thích: “Vâng, lập kế hoạch bao giờ cũng bắt đầu với hiểu nhu cầu của khách hàng. Không có hiểu biết này, bạn không thể lập kế hoạch cho bất kì cái gì và điều đó là phí thời gian. Một khi bạn có mọi nhu cầu hay yêu cầu từ khách hàng thì bước tiếp là ưu tiên hoá chúng. Bạn phải liệt kê mọi yêu cầu từ những khoản mục quan trọng nhất tới ít quan trọng nhất rồi thẩm tra danh sách này với khách hàng để chắc chắn họ đồng ý với bạn. Từ danh sách được ưu tiên hoá, bước tiếp là phát triển một tập các mục đích có thể đo được cho từng khoản mục. Điều này sẽ giúp bạn giám sát tiến độ dự án khi từng lúc một mục đích được đạt tới. Một khi bạn đã thiết lập một tập các mục đích, bạn có thể làm tài liệu chúng trong kế hoạch dự án.”
Anh ta bình luận: “Vậy lập kế hoạch dự án là về làm tài liệu mục đích dự án. Tôi cần làm gì khác nữa?”
Tôi giải thích: “Thành công của bạn là đạt tới những mục đích này nhưng lập kế hoạch còn nhiều hơn điều đó. Bước tiếp là dùng những mục đích này để xác định danh sách các mục bạn phải làm để đáp ứng các mục đích đó. Một khoản mục có thể là một chức năng, một tính năng, một vật chuyển giao, hay một tài liệu v.v. Bằng việc có những khoản mục này được xác định rõ ràng bạn có thể ước lượng bạn cần hoàn thành chúng trong bao lâu. Điều này về căn bản là kĩ thuật Cấu trúc phân việc (WBS) chia nhỏ các yêu cầu thành nhiều khoản mục mà có thể ánh xạ vào trong mục đích của dự án. Với từng khoản mục, bạn phải nhận diện mọi nhiệm vụ cần được thực hiện để hoàn thành khoản mục này. Một khoản mục cần vài nhiệm vụ, một nhiệm vụ là khối lượng công việc có thể được phân công cho một người trong một thời kì thời gian. Bạn phải ước lượng khối lượng nỗ lực (giờ hay ngày) cần để hoàn thành nhiệm vụ này và cần bao nhiêu người phát triển để thực hiện mọi nhiệm vụ này. Nếu bạn biết khối lượng nỗ lực cho từng nhiệm vụ và số nhiệm việc cần hoàn thành một khoản mục thì bạn có thể tính được mọi nỗ lực cần cho khoản mục đó. Cuối cùng, bạn có thể tính tổng nỗ lực cần cho mọi khoản mục để cho đến cuối, bạn có nỗ lực hay thời gian chính xác để hoàn thành toàn thể dự án.”
Anh ta lắc đầu: “Điều đó có vẻ khó và nhiều việc.”
Tôi tiếp tục: “Lập kế hoạch dự án là về ước lượng khối lượng công việc và thời gian cần để hoàn thành dự án. Để làm cho điều đó được dễ dàng hơn, bạn có thể dùng phần mềm như Microsoft “Project” mà tổ chức công việc của bạn. Bạn có thể đặt vào đó tất cả các khoản mục, nhiệm vụ, thời hạn và tài nguyên được cần để hoàn thành dự án. Với mọi dự án, khách hàng sẽ cho người quản lí dự án một lịch biểu thời gian mà họ nghĩ là hợp lí. Đây là thời gian bạn phải so sánh với ước lượng lịch biểu riêng của mình và ngày chuyển giao được yêu cầu của khách hàng. Nếu có khác biệt, thì bạn phải thương lượng về lịch biểu ngay lập tức. Nếu bạn KHÔNG lập kế hoạch, bạn không bao giờ biết liệu lịch biểu của khách hàng có là đúng hay không. Đó là lí do tại sao tôi nghĩ lập kế hoạch dự án là rất quan trọng và không bao giờ được nhảy qua.
Anh ta lưỡng lự: “Nhưng điều gì xảy ra nếu khách hàng không đồng ý với lịch biểu của tôi?”
Tôi giải thích: “Là người quản lí dự án, bạn phải biết cách thương lượng. Bạn có ba tuỳ chọn: Đòi thêm thời gian để hoàn thành dự án dựa trên ước lượng riêng của bạn. Đòi thêm người (tài nguyên) để làm việc cho dự án. Đòi khách hàng rút bớt chức năng hay yêu cầu (phạm vi). Bạn phải chỉ cho khách hàng qui trình về cách bạn đi tới ước lượng của bạn bằng việc dùng Cấu trúc phân việc (WBS) và mục đích dự án chi tiết, khoản mục, nhiệm vụ, nỗ lực v.v. Điều này cũng chỉ cho khách hàng rằng bạn biết cách lập kế hoạch và cách quản lí dự án. Theo kinh nghiệm của riêng tôi, khách hàng sẽ bị ấn tượng với năng lực của bạn. Hầu hết mọi lần, khách hàng chỉ “phỏng đoán” lịch biểu mà không biết chi tiết cho nên có qui trình logic để chia nhỏ mọi sự mà bạn phải làm sẽ cho khách hàng tin tưởng hơn vào kĩ năng của bạn. Họ có thể đồng ý với bạn hay nếu không họ sẽ thương lượng tuỳ chọn nào đó.”
Anh ta gật đầu: “Bây giờ thì tôi hiểu, vậy lập kế hoạch là đi tới một ước lượng logic để thương lượng lại với khách hàng.”
Tôi bảo anh ta: “Chính xác, nhưng nó còn nhiều hơn chỉ là ước lượng. Nó cũng giúp bạn xây dựng tổ dự án của bạn. Bằng việc hiểu mọi nhiệm vụ về chi tiết, bạn biết kiểu kĩ năng nào bạn sẽ cần cho nên bạn có thể nhận diện những người nào đó với tri thức chuyên gia nào đó cho tổ của bạn. Tri thức và kĩ năng của tổ dự án sẽ xác định thành công hay thất bại của dự án cho nên bạn phải chọn các thành viên tổ một cách cẩn thận. Bạn phải mô tả vai trò và trách nhiệm của từng thành viên trên kế hoạch dự án để tránh bất kì xung đột cá nhân nào trong các thành viên tổ.
Anh ta hỏi: “Còn gì khác mà tôi phải làm không?”
Tôi giải thích: “Bước tiếp là nhận diện mọi rủi ro bạn có thể gặp phải trong dự án. Quản lí rủi ro là phần quan trọng của quản lí dự án phần mềm. Bạn phải nhận diện nhiều nhất có thể được về các rủi ro cho dự án của bạn. Rủi ro thông thường nhất là ước lượng thời gian của bạn có thể quá lạc quan. Cho dù bạn có thể làm hết sức mình nhưng không có nhiều kinh nghiệm, bạn có thể không ước lượng đúng. Trong trường hợp đó, bạn có thể cần sự giúp đỡ từ các thành viên tổ. Bạn có thể yêu cầu họ cung cấp cái vào sau khi bạn phân công nhiệm vụ cho họ. Thu thập mọi thông tin từ họ và so sánh với ước lượng riêng của bạn thì bạn có thể có ý tưởng nào đó về ước lượng lịch biểu của bạn chính xác thế nào. Rủi ro khác có thể là khách hàng đổi ý thường xuyên sau khi dự án bắt đầu và thêm nhiều yêu cầu. Trong trường hợp đó bạn phải lập kế hoạch lại ước lượng và thương lượng lại để thêm thời gian. Một khi bạn nhận diện ra rủi ro, bạn phải tìm giải pháp để ngăn cản chúng xảy ra hay làm giảm tác động của chúng tới dự án. Bạn phải viết ra điều bạn sẽ làm nếu rủi ro xuất hiện, và điều bạn sẽ làm để ngăn ngừa nó khỏi xuất hiện. Bạn phải thảo luận với tổ về mọi rủi ro và kiểm điểm chúng trên cơ sở đều đặn, bổ sung thêm những rủi ro mới khi chúng xuất hiện trong cuộc đời của dự án. Nhớ lấy, khi rủi ro bị bỏ qua chúng không đi mất đâu. Bạn cũng phải cập nhật bản kế hoạch của mình, mọi sự bao giờ cũng thay đổi trong dự án phần mềm. Khi dự án bắt đầu, bạn phải giám sát tiến bộ của mình theo kế hoạch và nếu mọi sự không xảy ra như đã lập kế hoạch thì bạn phải có hành động sửa chữa chúng. Đó là điều người quản lí dự án phần mềm tốt phải làm.
A software developer came to see me: “I was promoted to manage a small project. My boss told me to focus on coding NOT planning because planning is a wasting of time. Coding will give the team more time to complete the project. My question is how to plan a project without wasting time and still achieve success?”
I told him: “I know some managers like to have their people to code as soon as possible. They believe “Software is Code” so coding means their people are working. That is a big mistake because they do not understand the value of planning. Project planning is the roadmap on how to manage the project and achieve the goals. Without planning you just react to whatever happen and never be able to control your project. A project is successful when it meets the needs of the customers. You should NEVER code before you really understand what the customer needs. The best way to do this is by conducting customer interviews to understand the “TRUE NEEDS”. Customer often talk about many things, some are “needs” but some are only “wishes” which may not be important. You must find out what are the “real needs” that you must do and what are the “wishes” that you may do if you have time”.
He seemed surprised: “I did not know interview customer is a part of project planning?”
I explained: “Yes, planning always start with the understand of customer’s needs. Without this understanding, you cannot plan anything and it is a waste of time. Once you have all the needs or requirements from the customer then the next step is to prioritize them. You must list all requirements from the most important items to the least important then verify this list with the customer to make sure they agree with you. From the prioritized list, the next step is develop a set of goals that can be measured for each item. This will help you to monitor the progress of the project when each time a goal is achieved. Once you have established a set of goals, you can document them in the project plan.
He commend: “So project planning is about document project goals. What else do I need to do?”
I explained: “Your success is to achieve these goals but planning is more than that. The next step is to using these goals to define a list of items that you must do to meet those goals. An item can be a function, a feature, a deliverable, or a document etc. By having these items clearly defined then you can estimate how long do you need to complete them. This is basically a Work Breakdown Structure (WBS) technique that breakdown the requirements into many items that can map into the goal of the project. For each item, you must identify all tasks that need to be done to complete the item. One item may need several tasks, a task is the amount of work that can be assigned to a person within a period of time. You must estimate the amount of effort (hours or days) required to complete the task and how many developer (Resource) needed to do all these tasks. If you know the amount of effort for each task and the number of tasks to complete an item then you can calculate all efforts required for each item. Eventually, you can calculate the total effort to complete all items so in the end, you have an accurate efforts or time to complete the entire project”.
He shook his head: “That sound difficult and is a lot of works.”
I continued: “Project planning is about estimate the amount of works and the time it take to complete the project. To make it easier, you could use a software such as Microsoft “Project” to organize your works. You could put in all the items, tasks, durations and resources needed to complete the project. For every project, the customer would give the project manager a time schedule that they think is reasonable. This is the time that you should compare your own schedule estimates and the customer’s required delivery date. If there is a difference, then you must negotiate the schedule immediately. If you do NOT plan, you never know whether the customers’ schedule is correct or not. That is why I think project planning is very important and should never be skipped.
He hesitated: “But what if the customer do not agree with my schedule?”
I explained: “As project manager, you must know how to negotiate. You have three options: Asking for more time to complete the project based on your own estimates. Asking for more people (Resources) to work on the project. Asking customer to reduce functionality or requirements (scope). You must show the customer the process of how do you come up with your estimates using Work Breakdown Structure (WBS) and the detailed project goals, items, tasks, efforts etc. This also show the customer that you know how to plan and how to manage the project. From my own experience, the customer would be impressed with your ability. Most of the time, customer just “Guessing” a schedule without knowing the detail so having a logic process to breakdown things that you must do would give the customer more confidence in your skills. They may agree with you or if not they would negotiate certain options.
He nodded: “I understand now, so planning is to come up with a logical estimates for renegotiation with customer”.
I told him: “Exactly, but it is much more than just estimate. It also help you to build your project team. By understand all the tasks in detail, you know what type of skills that you will need so you can identify certain people with certain expertise for your team. The knowledge and skills of project team will determine the success or failure of the project so you must chose team members carefully. You must describe each member’s roles and responsibilities on the project plan to avoid any personal conflict among team members.
He asked: “is there anything else that I must do?”
I explained: “The next step is to identify any risk that you may encounter in the project. Risk management is an important part of software project management. You must identify as many risks to your project as possible. The most common risk is your time estimates maybe too optimistic. Even you may do your best but without a lot of experience, you may not estimate correctly. In that case, you may need help from team members. You may ask them to provide inputs after you assign then their tasks. Collect all information from them and compare with your own estimates than you may have some idea about how accurate is your schedule estimates. Another risk could be customer change their minds often after the project started and adding more requirements. In that case you must re-plan the estimates and re-negotiate for more time. Once you identify risks, you must find a solution to prevent them from happening or reduce the impact of them to the project. You must write down what you will do if the risk occurs, and what you will do to prevent it from occurring. You must discuss with the team about all risks and review them on a regular basis, adding new risks as they occur during the life of the project. Remember, when risks are ignored they don’t go away. You also must update your plan as the project progresses, things always change in software project. When the project starts, you must monitor your progress against the plan and if things do not happen as planned than you must take actions to correct them. That is what a good software project manager should do.
