Kế hoạch dự án phần mềm
Theo nhiều nghiên cứu, phần lớn những người quản lí phần mềm đã KHÔNg nhận được đào tạo về quản lí dự án CHÍNH THỨC và nhiều giáo trình quản lí dự án tại đại học KHÔNG thích hợp do thiếu “khía cạnh thực hành”. Phần lớn các giáo sư đều tập trung vào lí thuyết hàn lâm mà không có thực hành công nghiệp. Đó là lí do tại sao nhiều dự án phần mềm đã liên tục bị vượt quá ngân sách, lâu hơn là mong đợi, và không cung cấp mức độ chất lượng và chức năng mà người dùng mong đợi.
Áp dụng các lí thuyết quản lí dự án hàn lâm vào dự án phần mềm đã không đạt tới thành công bởi vì dự án phần mềm khác về nền tảng với các dự án trong các ngành công nghiệp khác. Những khác biệt này làm cho quản lí dự án phần mềm thành khó hơn quản lí các kiểu dự án khác. Nhiều trong số những khác biệt nền tảng này có liên quan tới ‘tính thấy được’ hay khả năng của người quản lí dự án xác quyết về việc hoàn thành của một nhiệm vụ bằng việc nhìn vào kết quả của nhiệm vụ đó. Việc thiếu tính thấy được mà người quản lí dự án phần mềm có trong các pha khác nhau của dự án phần mềm điển hình tạo ra khó khăn để làm việc quản lí tốt.
Trong lí thuyết hàn lâm, phát triển sản phẩm phần mềm tương tự như xây nhà. Yêu cầu được xây dựng nên, ước lượng về lịch biểu và chi phí được thực hiện rồi công việc kiến trúc, thiết kế và xây dựng có thể bắt đầu. Một vấn đề với điều này là trong khi làm nhà thì có công cụ và kí pháp vật lí để mô tả trực quan nó và hầu hết mọi người đều có thể hiểu được chúng (to thế nào, cao thế nào, rộng thế nào), người làm phần mềm bị giới hạn trong những kí pháp mà họ có thể mô tả sản phẩm cho khách hàng. (Không ai thực sự biết cần bao nhiêu dòng mã, bao nhiêu cấu phần, hay đối tượng hay bao nhiêu giao diện v.v.) Phần lớn những người quản lí chỉ lệ thuộc vào các biểu đồ mức cao để mô tả những khái niệm này cho khách hàng. Bởi vì khách hàng không thực sự hiểu những biểu đồ này rõ, họ thường đổi ý kiến về điều họ thực sự muốn. Bên cạnh đó, không có chi phí được chấp nhận rõ ràng theo tính năng hay cách đo chi phí theo số dòng mã mà người quản lí có thể dùng làm cơ sở cho việc ước lượng chi phí ban đầu. Với cái nhà, kiến trúc sư có thể tính toán cần bao nhiêu gạch, bao nhiêu xi măng, bao nhiêu gỗ, thanh thép, v.v và đi tới chi phí xây dựng. Tuy nhiên, không có những điều như vậy trong phần mềm.
Tất cả những điều này có nghĩa gì với sinh viên? Nó nghĩa là sinh viên quản lí dự án phần mềm cần hiểu qui trình “lập kế hoạch mơ hồ” này. Họ cần học cách xây dựng bản mẫu cho giao diện người dùng hay dùng các công cụ trực quan như UML theo cách khách hàng của họ có thể hiểu được. Họ cần có kĩ năng kĩ nghệ yêu cầu để cho họ có thể đi từ các yêu cầu mức cao tới kiến trúc chi tiết. Họ cần lập kế hoạch dự án tương ứng với các pha phục vụ như tuyến cơ sở và tiếp tục lập kế hoạch khi mọi sự thay đổi. Điều quan trọng nhất, họ cần học cách thương lượng với khách hàng về lịch biểu, chi phí và chất lượng. Không may là những điều này KHÔNG được dạy trong hầu hết các môn đại học.
Lập kế hoạch dự án phần mềm yêu cầu rằng mọi dự án đều phải bắt đầu bằng bản kế hoạch dự án, điều trả lời cho các câu hỏi: Tổ lập kế hoạch để làm cái gì? Việc đó được diễn ra như thế nào? Ai sẽ làm từng việc? Khi nào từng nhiệm vụ được thực hiện xong? Nó sẽ tốn bao nhiêu? Nếu bản kế hoạch không chứa câu trả lời cho những câu hỏi này, nó không phải là bản kế hoạch tốt. Phần có giá trị nhất của bản kế hoạch là QUI TRÌNH mà mọi thành viên tổ đều phải đi qua để trả lời cho những câu hỏi này. Qui trình đó cung cấp cơ hội lớn cho các thành viên tổ biết lẫn nhau và đạt tới thoả thuận về bản kế hoạch này. Không may là quan điểm hàn lâm là duy nhất người quản lí dự án tạo ra bản kế hoạch và chỉ đạo các thành viên tổ tuân theo bất kì cái gì người quản lí vạch ra. Nguyên tắc hàn lâm về người quản lí “quản lí” còn thành viên tổ “tuân theo” thực sự không có tác dụng trong dự án phần mềm. Bởi vì bản kế hoạch dự án như vậy mà trả lời cho cho những câu hỏi này không bao giờ được tạo ra, tổ cảm thấy rằng họ đã bị khách hàng trao cho yêu cầu bắt buộc mà họ KHÔNG THỂ thay đổi hay chẳng có liên quan gì tới công việc đáng phải làm. Về căn bản họ KHÔNG có ý tưởng ai sẽ làm từng nhiệm vụ. Bởi vì người quản lí dự án quá bận rộn làm việc trên bản kế hoạch dự án, ‘công việc thực’ không bao giờ được bắt đầu chừng nào người quản lí còn chưa hoàn thành bản kế hoạch này.
Không có sự tham gia sớm sủa của các thành viên tổ, KHÔNG có ý kiến từ các thành viên tổ về cách từng nhiệm vụ được phân công và ai sẽ làm chúng, thì chỉ một biểu đồ cấu trúc mức cao được tạo ra như bản kế hoạch dự án. Quan điểm về tổ là “Làm bất kì cái gì có thể được” thay vì hỗ trợ tích cực cho việc lập kế hoạch dự án. Không hiểu khía cạnh mấu chốt, sẽ có nhiều thay đổi khi tổ khám phá ra “sai lỗi” trong qui trình lập kế hoạch. Khi có thay đổi, bản kế hoạch cũng phải được thay đổi nhưng vì người quản lí đã có thoả thuận với khách hàng, khó mà thay đổi được lịch biểu hay chi phí. Đến cuối cùng, tổ bị mắc kẹt với “bản kế hoạch” có lịch biểu cứng ngắc và chức năng mơ hồ.
Việc tạo ra bản kế hoạch tốt trả lời cho mọi câu hỏi nêu trên yêu cầu nhiều nỗ lực. Ngày nay, trong công nghiệp phần mềm, lập kế hoạch dự án là nỗ lực tổ nơi các thành viên tổ cùng làm việc với nhau để tạo ra bản kế hoạch sơ bộ. Trong thời gian đó, các thành viên tổ sẽ xây dựng một danh sách các yêu cầu mức cao. Họ sẽ lập đại cương, chi tiết nhất có thể được, các nhiệm vụ cần được hoàn thành. Họ sẽ xác định mối quan hệ thích hợp giữa các nhiệm vụ, đưa ra nỗ lực đầu tiên về ai sẽ làm từng việc nào, ước lượng thời hạn cho từng nhiệm vụ, lập lịch biểu cho những nhiệm vụ đó và tạo ra lịch biểu dự án tổng thể. Trong khi một số thành viên tổ đang làm việc về các chi tiết của những nhiệm vụ này, các thành viên khác của tổ hội tụ vào ước lượng và ngân sách của kế hoạch. Với dự án kích cỡ trung bình, phần lớn công việc có thể được thực hiện trong một tuần, dự án lớn hơn có thể yêu cầu ba tới năm tuần để lập kế hoạch xảy ra nhưng việc lập kế hoạch bao giờ cũng là hoạt động tổ.
Quan điểm hàn lâm KHÔNG phải bao giờ cũng đồng ý với quan điểm này. Có nhiều thảo luận về phần mềm như việc xây nhà, chỉ kiến trúc sư và người quản lí được tham gia vào còn công nhân xây dựng KHÔNG được phép tham gia. Tuy nhiên, như tôi đã nói rằng xây nhà và làm phần mềm là KHÔNG như nhau do “khía cạnh thấy được”. Bạn có thể thấy ngôi nhà đang được xây và biết kích cỡ, chi phí cũng như việc hoàn thành (30% được hoàn thành hay 50% được hoàn thành) nhưng bạn KHÔNG thể thấy được cái gì với phát triển phần mềm. Thiếu tính thấy được là vấn đề lẫn lộn nhất cho nên một mình người quản lí dự án KHÔNG thể lập kế hoạch dự án được cho nên điều bản chất là CÓ sự tham gia của tổ. Bằng cách làm việc cùng nhau đi tới bản kế hoạch dự án, từng thành viên tổ sẽ thực sự hiểu điều họ cần làm nhiệm vụ nào họ phải hoàn thành trước ngày tháng nào đó, và tổ hợp nhiệm vụ của họ vào một danh sách toàn diện mọi điều cho nên người quản lí có thể dùng danh sách này để thương lượng với khách hàng. Người quản lí dự án phần mềm giỏi nên là người tạo điều kiện, người huấn luyện viên, người lãnh đạo và người thương lượng giỏi. Đây là những kĩ năng phải được dạy trong mọi lớp quản lí dự án phần mềm.
Ngày nay, phần lớn sinh viên trong môn quản lí dự án phần mềm KHÔNG được dạy để làm việc trong tổ và để tạo ra bản kế hoạch dự án theo cách cộng tác như vậy. Tôi tin rằng đào tạo quản lí dự án nên tập trung vào các khía cạnh thực hành này bằng việc cho sinh viên cơ hội để tạo ra ‘bản kế hoạch dự án thực’ bằng cách làm việc trong tổ. Tôi tin rằng mọi môn học quản lí dự án phần mềm cần chứa các bài tập cho phép sinh viên kinh nghiệm như qui trình lập kế hoạch. Trong đào tạo của chúng tôi ở Carnegie Mellon, phần lớn sinh viên hoàn thành quãng hai tới ba bài tập như vậy trong môn học một học kì và tổ trung bình hoàn thành bản kế hoạch như vậy trong xấp xỉ 10 giờ trọn vẹn. Điều này cho sinh viên kinh nghiệm và thuyết phục có hiệu quả họ rằng bản kế hoạch dự án có thể được thực hiện bằng tổ chỉ trong vài ngày và đây là điều công nghiệp phần mềm thực sự cần.
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
