Lập kế hoạch dự án phần mềm: Qui trình “mười bước”
Một số người quản lí dự án phần mềm (PM) không biết cách xây dựng bản kế hoạch dự án. Họ thậm chí không lập kế hoạch mà chỉ dùng lịch biểu được khách hàng trao cho họ. Họ không xây dựng viễn kiến cho dự án hay ước lượng nỗ lực dự án. Logic của họ là yêu cầu bao giờ cũng thay đổi, sao bận tâm tới lập kế hoạch cho cái gì đó mà sẽ thay đổi? Họ không hiểu mục đích hay ích lợi của bản kế hoạch dự án.
Bản kế hoạch dự án là tài liệu được dùng để trao đổi thông tin giữa người quản lí dự án với tổ dự án và khách hàng. Bước thứ nhất trong xây dựng kế hoạch dự án là đặt chiều hướng cho dự án. Khi dự án bắt đầu, tổ không biết phải làm gì; họ cần “la bàn” để hướng dẫn họ. Viễn kiến dự án là la bàn chỉ cho họ về chiều hướng được người quản lí dự án lập ra. Viễn kiến này giải thích cho họ thành công sẽ là gì; dự án sẽ giải quyết vấn đề gì cho khách hàng; mục đích và mục tiêu là gì và mong đợi của khách hàng là gì. Viễn kiến giữ cho nỗ lực của tổ được gióng thẳng với yêu cầu của khách hàng và mục tiêu dự án.
Bước thứ hai là mô tả vấn đề mà dự án được dự định giải quyết. Các thành viên tổ cần hiểu vấn đề, cũng như giải pháp thành công có thể là gì. Họ cần biết về khách hàng và người dùng. Dự án có thể có một khách hàng hay nhiều khách hàng với các yêu cầu khác nhau. Trong trường hợp này, tổ cần biết cách giữ cân bằng nhiều yêu cầu khác nhau và vẫn đáp ứng được như cầu của khách hàng.
Bước thứ ba là mô tả sản phẩm phần mềm. Cách tốt nhất để làm điều này là dùng Biểu đồ hoàn cảnh, trong đó người quản lí dự án xác định cách phần mềm tương tác với khách hàng hay người dùng, và cách thông tin chảy bên trong và ngoài hệ thống. Biểu đồ này sẽ cho tổ một tổng quan về phần mềm.
Bước thứ tư là mô tả chức năng mức cao của sản phẩm phần mềm. Người quản lí dự án phải mô tả từng chức năng dựa trên các yêu cầu của khách hàng. Nếu phần mềm là lớn và phức tạp, một số chức năng có thể được chia thành các chức năng con cho dễ mô tả. Điều quan trọng là người quản lí dự án kiểm nghiệm các yêu cầu chức năng này với khách hàng để đảm bảo rằng chúng là chính xác điều khách hàng cần.
Bước thứ năm là chia nhỏ các yêu cầu chức năng này thành các nhiệm vụ nhỏ hơn (Cấu trúc phân việc - Work Breakdown Structure) và liệt kê những nhiệm vụ này để cho các thành viên tổ có thể thấy mọi nhiệm vụ mà họ phải làm. Vì các yêu cầu thường xuyên thay đổi do nhu cầu phụ thêm, thông tin mới, hay thỉnh thoảng khách hàng quyết định thay đổi yêu cầu. Những thay đổi này sẽ ảnh hưởng tới mọi thứ trong dự án. Do đó dự án cần có bản kế hoạch để đảm bảo rằng chỉ các yêu cầu đúng là được thực hiện. Bằng việc giữ danh sách hiện thời của mọi nhiệm vụ, thành viên tổ biết nhiệm vụ nào đã bị thay đổi hay sửa đổi, và cách chúng tác động tới công việc của họ. Khi dự án bắt đầu, các thành viên tổ không biết mọi thông tin mà khách hàng muốn cho nên họ dựa hầu hết trên danh sách các nhiệm vụ này. Điều quan trọng là giữ cho danh sách này được cập nhật dựa trên thông tin phụ thêm. Bản kế hoạch dự án sẽ xác định cách giải quyết với các thay đổi, cách thay đổi sẽ được kiểm điểm, và cách danh sách các nhiệm vụ sẽ được cập nhật để đảm bảo rằng dự án sẽ đáp ứng nhu cầu của khách hàng.
Bước thứ sáu là xác định vai trò, trách nhiệm của từng thành viên tổ và phân công cho họ các nhiệm vụ dựa trên kĩ năng và kinh nghiệm của họ. Bằng việc nhận diện các thành viên tổ qua kĩ năng, người quản lí dự án sẽ biết kĩ năng nào sẵn có cho nhiệm vụ nào và kĩ năng nào được cần. Người quản lí dự án có thể nhận diện các thành viên tổ có những kĩ năng này, nếu không người đó có thể phải đi thuê người phụ với kĩ năng đặc biệt để hoàn thành dự án. Điều này là quan trọng bởi vì một số người quản lí dự án thường dựa vào số người sẵn có cho dự án thay vì kĩ năng của họ. Họ lấy cán bộ cho dự án theo số người được cần chứ không theo kĩ năng được cần. Chẳng hạn, nếu dự án cần 10 người thì họ thuê 10 người bất kể tới kĩ năng của họ. Đây là một trong các lí do mà nhiều dự án thất bại. Người quản lí dự án có kinh nghiệm bao giờ cũng lấy cán bộ cho dự án dựa trên kĩ năng chứ không trên số người được cần. Trong bước này, người quản lí dự án cũng nhận diện phần cứng, phần mềm, và trang thiết bị được cần cho dự án và cách chúng sẽ được thu nhận.
Bước thứ bẩy là ước lượng nỗ lực được cần để hoàn thành các nhiệm vụ này. Điều được khuyến cáo là người quản lí dự án làm việc cùng các thành viên tổ mà đã được phân công cho các nhiệm vụ để đi tới một ước lượng cho công việc của họ. Người quản lí dự án phải lấy từng nhiệm vụ và đặt chúng vào trật tự theo đó chúng sẽ được thực hiện rồi tóm tắt chúng trong thời gian được ước lượng toàn thể cần để hoàn thành mọi nhiệm vụ. Bằng việc dùng thông tin này, người quản lí dự án có thể thương lượng với khách hàng về lịch biểu dự án. Lịch biểu dự án nên căn cứ trên thoả thuận dựa trên lịch biểu mong đợi của khách hàng và tóm tắt về thời gian được ước lượng được cần để hoàn thành mọi nhiệm vụ. Người quản lí dự án có thể yêu cầu thay đổi lịch biểu nếu có khác biệt lớn về thời gian được lên lịch và thời gian được ước lượng; hay yêu cầu nhiều người hơn, hay yêu cầu giảm chức năng. Một khi thương lượng này được hoàn thành, người quản lí dự án sẽ cập nhật danh sách các nhiệm vụ và phân ngày tháng để bắt đầu và hoàn thành từng nhiệm vụ cũng như cập nhật ngân sách của dự án (tiền được cấp cho dự án).
Bước thứ tám là lập kế hoạch về chất lượng sản phẩm. Chất lượng không tự xảy ra; nó cần được xây dựng nên. Người quản lí dự án cần nhận diện chuẩn chất lượng theo đó dự án sẽ được đo và cách các thành viên tổ sẽ đo chúng. Chẳng hạn, chất lượng có thể được xác định như việc đáp ứng mọi yêu cầu của khách hàng; có ít lỗi (không quá 1 lỗi trên mười nghìn dòng mã); đáp ứng chi phí và lịch biểu v.v. Chất lượng phải được xác định rõ ràng và được kiểm điểm với cả khách hàng và người quản lí cấp cao để đảm bảo rằng dự án đang tạo ra sản phẩm chất lượng.
Bước thứ chín là quản lí rủi ro. Vì không phải mọi thứ xảy ra bên trong dự án phần mềm đều được biết hết, mọi sự có thể xảy ra bất ngờ vì chúng không thể được dự đoán. Những điều bất định là rủi ro và chúng phải được quản lí. Người quản lí dự án cần nhận diện rủi ro dự án, khả năng xuất hiện của chúng, cách giảm nhẹ chúng và cách trao đổi về chúng cho các thành viên tổ, nếu chúng xuất hiện.
Bước thứ mười là xác định tài liệu dự án. Tuỳ theo độ phức tạp và yêu cầu của khách hàng, dự án có thể được yêu cầu cung cấp tài liệu hỗ trợ như một phần của vật chuyển giao của dự án. Tài liệu bao gồm tài liệu sử dụng của người dùng, trợ giúp trực tuyến, tài liệu cài đặt, v.v.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
