Lập kế hoạch dự án phần mềm
Một người phát triển phần mềm tới gặp tôi: “Tôi được đề bạt làm quản lí một dự án nhỏ. Ông chủ của tôi bảo tôi hội tụ vào viết mã chứ KHÔNG lập kế hoạch bởi vì lập kế hoạch là phí thời gian. Viết mã sẽ cho tổ nhiều thời gian hơn để hoàn thành dự án. Câu hỏi của tôi là làm sao lập kế hoạch cho dự án mà không phí thời gian và vẫn đạt tới thành công?”
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.
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
