Tài liệu Quản lý dự án phần mềm

Kinh nghiệm quản lý dự án phần mềm Tác giả: John Vũ Người dịch và biên tập: Ngô Trung Việt Hà Nội, 12/2012 Nguồn tư liệu: John Vu, Carnegie Mellon University http://www.science-technology.vn Mục lục 1. Quản lí dự án phần mềm ...................................... 1 Quản lí dự án-1 ........................................................................ 1 Quản lí dự án-2 ........................................................................ 3 Quản lí dự án-3 ........................................................................ 5 Quản lí dự án và quản trị văn phòng ........................................ 7 Quản lí dự án phần mềm-1 ...................................................... 9 Quản lí dự án phần mềm-2 .................................................... 14 Quản lí dự án phần mềm-3 .................................................... 17 Quản lí dự án phần mềm-4 .................................................... 20 Mục đích của quản lí dự án phần mềm .................................. 23 Phương pháp quản lí dự án mới ............................................ 25 Thành công của dự án phần mềm ......................................... 31 Dự án phần mềm thành công ................................................. 34 Vấn đề với dự án phần mềm .................................................. 35 Vấn đề với dự án phần mềm lớn ........................................... 39 Thất bại dự án ........................................................................ 41 Cách giúp cho một dự án thất bại. ......................................... 43 Tránh thất bại dự án phần mềm ............................................. 45 Cách ngăn ngừa thất bại dự án ............................................. 47 Công việc dự án sớm ............................................................. 50 2. Người quản lí dự án ............................................ 53 Người quản lí dự án-1 ............................................................ 53 Người quản lí dự án-2 ............................................................ 55 Người quản lí dự án-3 ............................................................ 58 Người quản lí dự án hiệu quả ................................................ 61 Người quản lí dự án kém nhất ............................................... 63 Người quản lí dự án giỏi nhất ................................................ 67 i Chất lượng của người quản lí dự án ...................................... 68 Kĩ năng của người quản lí dự án-1 ........................................ 70 Kĩ năng của người quản lí dự án-2 ........................................ 73 Lời khuyên cho người quản lí dự án-1 ................................... 76 Lời khuyên cho người quản lí dự án-2 ................................... 87 Lời khuyên cho người quản lí dự án-3 ................................... 89 Đào tạo người quản lí dự án .................................................. 94 Ưu tiên của người quản lí dự án phần mềm .......................... 97 Người quản lí dự án trong miền mới .................................... 101 Phụ nữ trong quản lí dự án .................................................. 102 Kinh nghiệm quản lí dự án ................................................... 106 Lãnh đạo kĩ thuật .................................................................. 109 3. Tổ dự án ............................................................. 113 Kĩ năng con người ................................................................ 113 Làm việc theo tổ ................................................................... 115 Làm việc theo tổ và làm việc theo nhóm .............................. 118 Làm việc trong tổ dự án lớn ................................................. 121 Làm việc tổ của dự án .......................................................... 123 Làm việc tổ trong lập kế hoạch dự án phần mềm ................ 125 Lập kế hoạch làm việc tổ ...................................................... 127 Cách động viên tổ................................................................. 130 Làm việc nhóm và làm việc tổ .............................................. 133 Tương tác với các thành viên tổ .......................................... 136 Công nhân có kĩ năng cho công việc dự án ......................... 138 4. Quản lí dự án theo kế hoạch ............................ 143 Vòng đời phát triển phần mềm và Vòng đời quản lí dự án .. 143 Qui trình cho dự án phần mềm ............................................ 145 Qui trình đơn giản cho dự án nhỏ ........................................ 151 Lập kế hoạch dự án phần mềm-1 ........................................ 155 Lập kế hoạch dự án phần mềm-2 ........................................ 159 Lập kế hoạch dự án phần mềm: Qui trình "mười bước" ...... 164 Qui trình lập kế hoạch dự án ................................................ 167 Ước lượng dự án-1 .............................................................. 170 Ước lượng dự án-2 .............................................................. 173 Ước lượng dự án-3 .............................................................. 176 Ước lượng dự án-4 .............................................................. 178 Kiến trúc hệ thống ................................................................ 179 ii Vòng đời kiểm thử ................................................................ 182 Cách đo ................................................................................ 184 Cách đo và độ đo ................................................................. 186 Quản lí rủi ro-1...................................................................... 187 Quản lí rủi ro-2...................................................................... 192 Chất lượng phần mềm-1 ...................................................... 194 Chất lượng phần mềm-2 ...................................................... 196 Chất lượng phần mềm-3 ...................................................... 199 Chất lượng phần mềm-4 ...................................................... 204 Chất lượng phần mềm-5 ...................................................... 206 Chất lượng phần mềm-6 ...................................................... 207 Cải tiến chất lượng phần mềm ............................................. 208 Đảm bảo chất lượng phần mềm .......................................... 210 Kiểm điểm phần mềm .......................................................... 213 Kiểm thử chất lượng............................................................. 216 Kiểm thử chấp nhận của người dùng................................... 220 Trắc nghiệm và kiểm nghiệm ............................................... 222 Thoả mãn của khách hàng ................................................... 224 Khi nào khách hàng phần mềm xây nhà .............................. 226 Nói chuyện với khách hàng .................................................. 228 Một khảo cứu về dự án phần mềm ...................................... 230 5. Phương pháp quản lí Agile .............................. 233 Agile ...................................................................................... 233 Dự án Agile ........................................................................... 235 Một số sự kiện về cách tiếp cận Agile .................................. 237 Quản lí dự án Agile............................................................... 240 Người kiểm thử trong dự án Agile ........................................ 243 Phát triển phần mềm Agile ................................................... 245 Một số sự kiện về cách tiếp cận Agile .................................. 249 Agile và kích cỡ dự án.......................................................... 251 Người quản lí dự án trong môi trường Agile ........................ 253 Người kiểm thử trong dự án Agile ........................................ 255 SCRUM ................................................................................ 257 6. Dự án Capstone................................................. 263 Dự án Capstone ................................................................... 263 Hướng dẫn dự án Capstone - phần 1 .................................. 266 Hướng dẫn dự án Capstone - phần 2 .................................. 272 iii Hướng dẫn dự án Capstone - phần 3 .................................. 275 Hướng dẫn dự án Capstone - phần 4 .................................. 280 Một số vấn đề trong dự án Capstone ................................... 285 Học trong dự án Capstone ................................................... 288 Đối thoại về làm việc tổ ........................................................ 292 iv 1. Quản lí dự án phần mềm Quản lí dự án-1 Quản lí dự án phần mềm là việc khó: Là người quản lí dự án, bạn phải lấy được yêu cầu từ khách hàng, lịch biểu kế hoạch, tài nguyên và thiết kế tất cả các đường găng, các cột mốc, các hạn chót để chắc chắn rằng bạn đáp ứng yêu cầu cũng như tạo ra các kiểm thử nội bộ, kiểm thử chấp nhận. Bạn cũng ban hành các chỉ dẫn, thiết lập các giao thức thông tin, báo cáo trạng thái, họp và giải quyết lỗi, vấn đề, tình huống khẩn trương và mọi tài liệu. Tuy nhiên, sau nhiều năm quản lí cả các dự án nhỏ và lớn, tôi có thể nói rằng nhân tố quan trọng nhất đem dự án tới thành công là "vấn đề con người." Theo kinh nghiệm riêng của tôi, phần lớn các dự án phần mềm không bao giờ đi theo đúng kế hoạch bởi vì khách hàng bao giờ cũng thay đổi các yêu cầu nhưng không bao giờ thay đổi lịch biểu hay chi phí. Họ bao giờ cũng phàn nàn rằng dự án phần mềm bị chậm, đắt và không cung cấp cho họ điều họ muốn. Tuy nhiên, phần lớn dự án tôi quản lí bao giờ cũng thành công đầy đủ, tới mức độ nào đó, bởi vì những yếu tố "con người" trong những dự án đó. Đó là lí do tại sao tôi nghĩ 1 con người là khía cạnh quan trọng nhất của tất cả các dự án phần mềm. Khi dự án lâm vào vấn đề nghiêm trọng, phương pháp hay công cụ quản lí tốt nhất sẽ không có ích bởi vì chúng không được thiết kế để giải quyết loại vấn đề này. (Không công cụ nào có thể sửa chữa được phàn nàn của khách hàng và phương pháp quản lí được dạy trong đại học không bao quát các vấn đề về thay đổi yêu cầu - Bao nhiêu giáo sư đã từng thay đổi bài tập lớn cho học sinh?) Chỉ những người tận tuỵ, cam kết, có tính đổi mới cao với năng lực, kinh nghiệm và tri thức của họ mới có thể giúp bạn giải quyết được những vấn đề này. Tôi không nói rằng chỉ người giỏi mới làm cho các dự án phần mềm thành công nhưng không có con người giỏi thì dự án không thể được thực hiện. Tôi đã thấy nhiều nhân viên làm việc cần mẫn để sửa chữa vấn đề không đòi hỏi bao nhiêu ngày trong tuần hay bao nhiêu giờ trong ngày, nếu cần thì từ 14 tới 16 giờ là chuyện thường. Họ sẽ thảo luận về điều được cần tới và điều có thể được thực hiện để giúp cho người quản lí dự án của họ tránh thất bại. Một số người có thể làm việc nhiều tuần để sửa hệ thống quan trọng nhất khi nó bị hỏng. Nhiều người ít ngủ hay không ngủ chút nào mà không phàn nàn gì. Cho nên để đảm bảo thành công, người quản lí phải hỏi câu hỏi: Tôi phải tìm những người như thế ở đâu đây? Câu trả lời là ở trong hành vi của bạn bởi vì chính nhân viên giỏi sẽ tìm người quản lí xứng đáng để làm việc cùng chứ không theo cách khác. Phần lớn các bài giảng về quản lí không bao giờ đề cập tới việc khen thưởng hành vi tốt đẹp bạn muốn được lặp lại bởi vì phương pháp của người quản lí ít ảnh hưởng tới nhân viên và hành vi của họ. (Phần lớn các giáo sư chẳng bao giờ làm việc trong công nghiệp hay đòi có người làm việc cho họ để cho họ ra lệnh chứ không phải là khen thưởng hay 2 thừa nhận) cho nên họ dạy rằng bạn là ông chủ và có quyền đòi hỏi nhân viên làm việc cần mẫn hơn và nhiều hơn thay vì hiểu rằng việc bó buộc đó không đem tới hành vi tốt nhất của nhân viên. Để là người quản lí giỏi, đặc biệt là người quản lí phần mềm bạn phải hỏi: 1) Tôi có phải cảm ơn những người làm việc tốt không? 2) Cá nhân tôi có nên viết bức thư ngắn hay email "cám ơn" mọi người về hiệu năng của họ không? 3) Tôi có nên áp dụng hiệu năng của nhân viên làm cơ sở cho đề bạt không? 4) Cá nhân tôi có nên thừa nhận công khai hiệu năng tốt của mọi người không? 5) Tôi có nên tổ chức họp tôn vinh sự thành công của các nhân viên không? 6) Tôi có phải yêu cầu chủ tịch công ti thưởng cho những người có hiệu năng tốt không? Nếu câu trả lời là KHÔNG thì tốt hơn cả là bạn hãy học những điều này thật nhanh bởi vì người nhân viên tốt bao giờ cũng có cơ hội chọn lựa nơi làm việc tốt và những người quản lý giỏi. Quản lí dự án-2 Một người viết cho tôi: “Tôi làm việc cho một công ti chế tạo nhỏ với vài trăm nhân viên. Làm sao tôi áp dụng kĩ thuật quản lí dự án cho môi trường cơ xưởng được?" 3 Đáp: Quản lí dự án là nguyên lí doanh nghiệp được dùng trong nhiều ngành công nghiệp và công ti. Để áp dụng kĩ thuật quản lí dự án trong công ti của bạn, bạn có thể bắt đầu với vài điều cơ bản như quản lí thời gian, cộng tác làm việc tổ, làm tài liệu và trao đổi. Bạn có thể khuyến khích tổ dự án của bạn làm tài liệu thời gian của họ từng ngày. Điều đó sẽ giúp họ thấy cách thời gian của họ được dùng; mất bao nhiêu thời gian để hoàn thành những nhiệm vụ nào đó. Điều này cũng sẽ giúp cho bạn ước lượng thời gian phân bổ cho nhiệm vụ và dự án tương lai. Bạn có thể thúc đẩy nhiều cộng tác và làm việc tổ giữa các thành viên tổ. Đừng cho phép họ làm việc ở chỗ cô lập mà để họ làm việc trong các nhóm nhỏ nơi họ có thể học được lẫn nhau. Trong phần lớn các cơ xưởng, công việc được phân công dựa trên kĩ năng và kinh nghiệm. Đào tạo là không chính thức và thường được truyền từ công nhân có kinh nghiệm sang công nhân ít kinh nghiệm hơn. Điều đơn giản và dễ dàng cho người này có thể là lẫn lộn và khó với người khác. Bằng việc để mọi người cùng làm việc và quan sát lẫn nhau, họ có thể học nhanh hơn và trao đổi ý tưởng nhanh hơn giữa bản thân họ. Bạn nên bắt đầu tạo ra và làm tài liệu cho qui trình trong toàn công ti dựa trên thực hành tốt nhất. Để những công nhân có kinh nghiệm nhất giải thích điều họ làm và cách họ làm nó cho bạn để cho bạn có thể làm tài liệu chúng thay vì để tri thức bị giữ trong đầu của ai đó. Điều quan trọng là thiết lập tài liệu dự án chính thức với mục đích, mục tiêu, cách đo và qui trình giám sát rõ ràng trước khi công việc bắt đầu. Điều then chốt của quản lí dự án là đảm bảo mọi người trong dự án đều rõ ràng về vai trò, trách nhiệm của họ và điều phải làm trong dự án để cho công việc của họ có thể được nhất quán hơn. Một khi dự án được bắt đầu, bạn cần họp hàng tuần với khách hàng và thành viên tổ để chia sẻ thông tin về tiến bộ và giải quyết bất kì vấn đề nào. Ích lợi của những cuộc họp này sẽ giúp cho công 4 nhân hiểu cách dự án tiến triển, liệu nó có đáp ứng lịch biểu hay không và liệu có những vấn đề không được giải quyết không. Ngay cả ở mức cơ sở của nó, quản lí dự án có thể dường như tràn đầy quá mức, đó là vì đấy là lần đầu tiên bạn làm nó theo cách mới, không cùng cách như công ti vận hành. Chừng nào bạn giải thích rõ ràng cho mọi người về ích lợi của quản lí dự án như cách tốt hơn để quản lí và làm mọi sự rõ ràng, khách quan, và đo được với các vai trò, trách nhiệm được xác định rõ, tôi nghĩ mọi người sẽ thích nó. Quản lí dự án-3 Nhiều người quản lí dự án bận rộn với những điều tầm thường như họp công ti và công việc giấy tờ và thường không giám sát tiến bộ dự án. Họ dựa chủ yếu vào các báo cáo tình trạng từ các thuộc cấp thay vì quan sát cá nhân. Đây là chỗ “những ngạc nhiên” xuất hiện vì họ không biết điều gì xảy ra trong dự án của họ. Nhiều thành viên tổ dự án không biết báo cáo tin xấu cho nên họ che giấu chúng mãi cho tới khi họ không thể giấu thêm được nữa. Đến lúc đó đã quá trễ để làm được gì. Ba mươi năm qua, khi tôi làm việc ở Hewlett Packard (HP), công ti này đã yêu cầu mọi người quản lí phải tự cá nhân mình đi tới dự án và nói chuyện với các thành viên tổ quãng hai lần một ngày. Phương pháp này có tên là “Quản lí bằng đi quanh” tại đó người quản lí phải đi tới chỗ làm việc một cách ngẫu nhiên, để kiểm tra công việc đang tiếp diễn. Người chủ công ti, ông David Packard tin rằng cách tốt nhất cho những người quản lí để biết về các dự án của họ là bằng việc kiểm điểm ngẫu nhiên công việc trên cơ sở hàng ngày. Vào lúc đó, 5 tôi còn ngần ngại mãi cho tới khi tôi rời khỏi HP để sang làm việc cho GE thì tôi mới nhận ra trí huệ của ông Packard. Kể từ đó và trong cả nghề nghiệp của tôi, tôi bao giờ cũng tuân theo thực hành này và thấy thông tin có giá trị bởi việc làm điều đó. Bằng việc gặp ngẫu nhiên với các thành viên tổ trên cơ sở hàng ngày, tôi xây dựng mối quan hệ tốt với họ. Một khi tin cậy được xây dựng, tôi nhận được thông tin chính xác về dự án. Các thành viên tổ có thể nói cho tôi về bất kì cái gì họ muốn mà không lo lắng về liệu tôi có thích nó hay không. Điều đó cũng làm cho việc của tôi như người quản lí được hiệu quả hơn vì tôi có thể nhanh chóng ra quyết định dựa trên điều tôi biết. Nếu có "vấn đề nhạy cảm" mà thành viên tổ không muốn thảo luận ở chỗ làm việc, họ có thể tới văn phòng của tôi để thảo luận ở chỗ riêng tư. Phần lớn các vấn đề nhạy cảm đều là vấn đề cá nhân thay vì kĩ thuật. Bằng việc hiểu điều đó, tôi có thể giải quyết nó nhanh chóng nhất có thể được cho nên nó sẽ không tràn sang toàn thể dự án. Vấn đề cá nhân thường xảy ra khi các thành viên tổ không đồng ý về cái gì đó và nó gây ra xúc động. Trong trường hợp đó, điều quan trọng nhất là nhận diện tất cả các sự kiện để xác định nguyên nhân của xung đột. Khi các thành viên tổ bất đồng, họ muốn người khác về phe với họ và không có giải pháp nhanh chóng; điều đó có thể leo thang thành vấn đề nghiêm trọng. Đây là chỗ "kĩ năng lắng nghe" của người quản lí là quan trọng. Kĩ thuật của tôi là lắng nghe các luận cứ của họ ở chỗ riêng tư, không ở trước tổ. Bằng việc lắng nghe cẩn thận mà không có bình luận nào, tôi cho phép họ giảm bớt giận dữ và bình tĩnh lại. Khi cả hai bên đều bình tĩnh, sẽ dễ thảo luận về một giải pháp cho cả đôi bên. Nhiều người quản lí dự án không thích giải quyết xung đột cá nhân. Tuy nhiên, thỉnh thoảng xung đột là điều tốt. Đặc biệt nếu nó mở ra cái gì đó cần được giải quyết. Nó có thể "đánh thức" các thành viên tổ nếu họ không đủ tích cực trong công việc dự án. Lấy thông tin từ 6 thảo luận xung đột có thể làm cho các thành viên tổ nghĩ nhiều hơn về các vấn đề liên quan tới dự án. Mọi công ti đều yêu cầu tổ dự án báo cáo về tình trạng dự án dựa trên cơ sở hàng tuần. Báo cáo trạng thái hàng tuần là tài liệu về tiến bộ của dự án và nó có ích cho người quản lí cấp cao theo dõi tiến bộ liệu cái gì đó đi sai không. Tuy nhiên, nếu bạn thực hành "đi vòng quanh" hàng ngày và giải quyết vấn đề ngay lập tức, ít nhất bạn không có mấy trong báo cáo tuần. Nó cũng có nghĩa là dự án tiến triển êm thấm. Chính trách nhiệm của người quản lí dự án là lãnh đạo. Nếu họ không quản lí và giúp đỡ tổ đạt được kết quả mong đợi, họ không làm việc của họ. Người quản lí dự án phải chắc chắn rằng họ biết cái gì được cần, khi nào thì tham gia, khi nào thì lắng nghe, khi nào thì có hành động, và quản lí tích cực mọi thứ trong dự án. Trong hầu hết các công tí, khi dự án thất bại, họ đuổi người quản lí dự án. Quản lí dự án và quản trị văn phòng Một sinh viên mới tốt nghiệp viết cho tôi: “Em làm việc trong một công ti nơi người quản lí dự án có chứng chỉ quản lí trưng ra trong văn phòng họ nhưng họ không quản lí cái gì cả. Họ dành nhiều thời gian vào họp hành, viết đề án, kiểm điểm chi tiêu và ngân sách, và viết báo cáo hàng tháng. Họ hiếm khi gặp người phát triển nhưng vẫn yêu cầu báo cáo về các hoạt động hàng tuần để cho họ có thể báo cáo cho ông chủ của họ. Khi chúng em nêu ra mối quan tâm, họ bảo chúng em rằng họ biết quản lí dự án vì bằng chứng là chứng chỉ của họ. Em bị lẫn lộn về kiểu quản lí dự án này. Thầy có gợi ý gì?" 7 Đáp: Có khác biệt giữa biết và làm. Người quản lí dự án giỏi có cả tri thức và kĩ năng để quản lí dự án. Tri thức tới từ việc học nhưng kĩ năng tới từ kinh nghiệm thực tế trong thực hiện nó. Người quản lí dự án giỏi có kinh nghiệm trong lập kế hoạch, ước lượng, giữ cân bằng các sức ép khác nhau, làm việc với khách hàng, quản lí thay đổi, và loại bỏ chướng ngại cho tổ dự án của họ. Có thể là người quản lí của bạn có đào tạo như bằng chứng về chứng chỉ của họ nhưng chưa bao giờ thực hiện nó trong dự án thực. Nếu họ chỉ hội tụ vào việc tạo ra báo cáo hiện trạng, đệ trình ngân sách, kiểm tra chi tiêu, kiểm điểm chi phí, và làm bài trình bày mà chỉ là các hoạt động hành chính thì họ là người quản trị văn phòng, không phải là người quản lí dự án. Người quản lí dự án giỏi hiểu vòng đời dự án và theo dõi cẩn thận qui trình để quản lí dự án. Họ phân tích ích lợi mà dự án đặc biệt sẽ đem lại cho công ti trước khi cam kết với bất kì chi tiêu nào. Trong dự án, nếu mọi sự thay đổi và trở nên rõ ràng rằng ích lợi không còn khả thi, họ cắt bỏ dự án cho nên không tiền nào bị phí hoài. Người quản lí dự án giỏi biết rằng người phát triển cho dự án cần hiểu vai trò và trách nhiệm của họ để cho họ phân công nhiệm vụ cho từng người tương ứng. Không có vai trò và trách nhiệm rõ ràng, không ai biết họ được giả định làm gì. Trong trường hợp đó, họ sẽ đổ lỗi cho nhau khi cái gì đó đi sai và dự án có thể không hoàn thành thành công. Người quản lí dự án giỏi biết cách phân chia dự án thành các nhiệm vụ nhỏ hơn cho từng pha bằng việc dùng kĩ thuật Cấu trúc phân việc Work Breakdown Structure (WBS). Từng pha được kiểm điểm cẩn thận và báo cáo để cho người quản lí cấp cao có thể quyết định. Chẳng hạn, dự án có đúng hạn không, trong ước lượng chi phí không? Rủi ro có chấp nhận được không? Phân chia dự án thành các pha, và phân tích mọi 8 rủi ro và ích lợi trước khi tiếp tục là cách tiếp cận khác mà cho phép người quản lí dự án quản lí dự án được tốt hơn. Người quản lí dự án giỏi bao giờ cũng hội tụ vào kết quả cuối cùng hay sản phẩm thậm chí trước khi dự án bắt đầu. Họ có viễn kiến về sản phẩm cuối sẽ là gì. Họ hiểu rõ yêu cầu của họ, và phát triển kế hoạch đạt tới được mà sẽ làm cho dự án dễ quản lí. Họ thường xuyên học khi nào quản lí dự án. Nếu họ phạm sai lầm, họ học từ nó để cho họ không phạm cùng sai lầm hai lần. Khả năng học từ sai lầm làm giầu có cho kinh nghiệm của họ cũng như kĩ năng quản lí của họ. Về căn bản, kinh nghiệm và kĩ năng thực sự phân biệt một người quản trị văn phòng với người quản lí dự án. Cũng như khác biệt giữa người có thể đọc bản đồ trong văn phòng và người dùng bản đồ để du hành khoảng cách xa và đã làm nhiều chuyến đi. Quản lí dự án phần mềm-1 Tuần trước, tôi có cuộc họp với vài sinh viên thuộc chương trình thạc sĩ về quản trị kinh doanh (MBA). Họ hỏi tôi tại sao nhiều dự án phần mềm thất bại và liệu người quản lí doanh nghiệp tốt nghiệp từ chương trình MBA có thể quản lí dự án phần mềm được không. Trước khi trả lời họ, tôi hỏi ý kiến của họ. Họ tin rằng vì họ được đào tạo về quản lí, họ có thể quản lí mọi thứ và đó là điều họ được dạy trong trường kinh doanh. Tôi KHÔNG đồng ý với quản điểm đó nên sau đây là thảo luận của tôi về quản lí dự án phần mềm: Có nhiều lí do cho dự án phần mềm thất bại nhưng lí do hiển nhiên nhất là người quản lí dự án không có kinh nghiệm hay kĩ năng quản lí dự án. Nhiều người quản lí dự án hứa với 9 khách hàng bất kì cái gì chỉ để làm hài lòng họ mà không thực sự biết sẽ mất bao nhiêu thời gian và cần bao nhiêu nỗ lực. Họ chấp nhận “lịch biểu phi thực tế” từ khách hàng rồi buộc tổ dự án phải tuân theo. Tất nhiên, đây là công thức cho thất bại bởi vì việc cần sáu tháng nhưng khách hàng chỉ cho bạn ba tháng thì bạn không thể hoàn thành được nó bằng làm việc cần cù hơn. Nhiều người quản lí không lập kế hoạch mà nhảy ngay vào viết mã để chứng minh cho người quản lí cấp cao rằng họ "rất tích cực”. Không lập kế hoạch cẩn thận, họ sẽ bỏ lỡ nhiều điều quan trọng và họ phải "làm lại từ đầu" cho chúng. Việc thiếu lập kế hoạch này làm tốn nhiều tiền cho công ti khi dự án phải chi tiêu nhiều hơn nó đáng phải chi tiêu. Câu hỏi của tôi là: Chương trình MBA có dạy ước lượng phần mềm và lập kế hoạch phần mềm không? Bởi vì nhiều người quản lí dự án không biết cách ước lượng lịch biểu, họ “lập lịch ngược” từ hạn chót đã cho và hi vọng mọi sự sẽ tốt. Chẳng hạn dự án bắt đầu từ tháng giêng và khách hàng cho họ sáu tháng thì bản kế hoạch sẽ trông như thế này: Tháng sáu: Chuyển giao phần mềm, Tháng năm: Kiểm thử phần mềm; Tháng ba và bốn: Viết mã; Tháng hai: Thiết kế và tháng giêng: Xây dựng tổ. Họ thêm ngày vào bản kế hoạch mà không biết gì về cách ước lượng thời gian cần cho từng pha. Thỉnh thoảng họ dùng kĩ thuật “lạc quan” từ các sách giáo khoa kinh doanh hàn lâm như ước chi phí bằng việc dùng công thức: Chi phí = Kích cỡ x độ phức tạp/năng suất. Đây là lí thuyết đúng nhưng KHÔNG THỂ cáp dụng được vào "dự án thực" bởi vì nó có ba nhân tố không biết: Kích cỡ, độ phức tạp và năng suất. Trong lớp học, các giáo sư cho sinh viên những nhân tố đó để tính chi phí nhưng trong thực tế, đặc biệt lúc bắt đầu dự án, khó mà ước lượng kích cỡ hay độ phức tạp của mã. Trong bất kì biến cố nào, mọi ước lượng chi phí đều có may rủi tiềm năng, không được kiểm điểm và điều chỉnh, công ti có thể 10 đi tới ước lượng thấp cho phí và mất tiền. Điều này xảy ra nhiều trong công nghiệp ngày nay. Câu hỏi của tôi là: Chương trình MBA có dạy lập lịch phần mềm và điều chỉnh ước lượng chi phí không? Nhiều người quản lí dự án KHÔNG biết cách thu được yêu cầu từ khách hàng. Họ tin điều khách hàng nói cho họ là "đủ tốt”. Không trắc nghiệp hay tuân theo phương pháp phân tích yêu cầu để nhận diện điều khách hàng thực sự cần, họ sẽ làm việc với các yêu cầu được cho. Tất nhiên, khách hàng thay đổi ý của họ và thường thêm nhiều chức năng vào yêu cầu của họ. Những điều này gây ra nhiều thay đổi trong dự án và đến lượt nó, gây ra nhiều việc làm lại, nhiều thời gian, và cuối cùng làm chậm trễ dự án. Dự án phần mềm KHÔNG chỉ là lập trình mà đi tới giải pháp cho vấn đề doanh nghiệp. Để hiểu các yêu cầu phần mềm, người quản lí phải hiểu yêu cầu doanh nghiệp, các yêu cầu hệ thống, yêu cầu phần cứng bởi vì các yêu cầu phần mềm vận hành trên ba mức này. Câu hỏi của tôi là: Chương trình MBA có dạy việc phát triển yêu cầu, vấn đề người dùng, vấn đề phần cứng, trắc nghiệm và kiểm nghiệm yêu cầu không? Nó có các kĩ thuật mô hình hoá bằng việc dùng công cụ phần mềm không? Nhiều người quản lí dự án không được đào tạo về ước lượng tài nguyên như số người được cần tới, kĩ năng được cần tới của họ, cho nên họ lất bất kì ai sẵn có vào làm việc cho dự án. Khi dự án có người sai với kĩ năng hạn chế, năng suất sẽ bị ảnh hưởng. Nhiều người quản lí không biết cách thuê và giữ người then chốt, họ không biết về tất cả những kĩ năng cần để phát triển phần mềm nhưng nghĩ về những người phần mềm là những người lập trình. Không có tri thức kĩ thuật chi tiết về kiến trúc, thiết kế, phần cứng và giao diện hệ thống, họ có thể phân công người sai cho các nhiệm vụ mà những người này không đủ phẩm chất và kết quả có thể là thảm hoạ. Không có 11 hồ sơ về con người với tri thức chuyên gia nào đó được cần để thực hiện công việc dự án sẽ thất bại. Sai lầm thông thường khác là nhiều người quản lí không cho đủ thời gian cần thiết cho các thành viên tổ học về dự án trước khi họ bắt đầu. Học về các yêu cầu của dự án đòi hỏi thời gian và nên được xem xét trong kế hoạch dự án. Nhiều công ti có nhiều dự án yêu cầu kĩ năng tương tự cho nên họ dịch chuyển người then chốt của mình từ dự án này sang dự án khác dựa trên ưu tiên giữa các dự án. Kĩ thuật quản lí "luân chuyển người" này là phí hoài năng suất quí giá bởi vì các thành viên tổ mất thời gian để làm quen với dự án họ được phân công. Thực hành này cũng làm nảy sinh một dự án phải dừng làm việc tạm thời cho tới khi thành viên tổ quay lại từ dự án khác. Điều này đặc biệt mấu chốt khi một kĩ năng then chốt cần được tham gia vào và điều đó làm chậm lịch biểu dự án và đóng góp thêm vào việc làm mòn mỏi nhân viên vì mọi người phải làm quá nhiều thứ trong một thời kì kéo dài. Nhiều người quản lí bận rộn thế và họ không theo dõi điều người của họ làm từng ngày. Họ không biết về hoạt động của nhân viên để cho họ có thể thúc bẩy các kĩ năng nhân viên cho có năng suất. Họ phân công người làm việc trên các nhiệm vụ tương ứng theo lịch biểu; chừng nào họ còn đáp ứng được lịch biểu thì không có vấn đề gì. Tuy nhiên, có các thành viên có thể hoàn tất nhiệm vụ 5 ngày trong 2 ngày và người khác có thể không hoàn thành được nhiệm vụ 3 ngày trong ít nhất 10 ngày do kĩ năng của họ và việc phân công. Không kiểm điểm các hoạt động trên cơ sở hàng ngày hay hàng tuần, người quản lí không biết ai cần giúp đỡ và ai không cần giúp đỡ cho tới khi vấn đề nảy sinh. Hiểu biết về phân phối công việc, về phân công nhiệm vụ và tri thức về kĩ năng là mấu chốt trong mọi dự án phần mềm. 12 Câu hỏi của tôi là: Chương trình MBA có dạy qui trình phát triển phần mềm, đào tạo kĩ năng, nhận diện kĩ năng và phân công công việc không? Điều gì sẽ xảy ra khi cái gì đó xấu xuất hiện trong dự án phần mềm? Không có đào tạo đúng, nhiều người quản lí trở nên giận dữ, thay vì lãnh đạo và hỗ trợ tổ dự án, họ làm nản lòng nhân viên bởi yêu cầu rằng nhân viên phải làm những điều nào đó hay buộc tội nhân viên không làm việc chăm chỉ hơn. Điều này sẽ thêm sức ép cho môi trường làm việc linh động và làm giảm năng suất hay thành viên tổ, đến lượt mình sẽ làm chậm trễ dự án thêm nữa. Khi họ thấy rằng gần tới hạn chuyển giao nhưng tổ của họ vẫn còn đang viết mã, họ ra lệnh cho nhân viên bỏ qua vài thứ như kiểm điểm hay kiểm thử để tiết kiệm thời gian. Thiếu kiểm thử, phần mềm sẽ có nhiều lỗi rồi công ti phải sửa các lỗi này. Điều này sẽ yêu cầu nhiều thời gian hơn, nhiều nỗ lực hơn, nhiều tiền hơn và nhiều chậm trễ hơn. Tất nhiên, khách hàng KHÔNG hài lòng và có thể không muốn làm kinh doanh với công ti trong tương lai. Khi các vấn đề nảy xảy ra, nhiều người quản lí buộc tổ làm việc nhiều giờ hơn trong một thời gian kéo dài để sửa lỗi của lịch biểu không thực tế cho nên nhiều thành viên tổ rời khỏi dự án trước khi dự án được hoàn thành. Câu hỏi của tôi là: Chương trình MBA có dạy cách quản lí người kĩ thuật không? Cách phối hợp công việc tổ? Cách nuôi dưỡng tổ thay vì lạm dụng họ? Chúng ta có thể làm gì để tránh những sai lầm này? Câu trả lời hiển nhiên là: Cung cấp đào tạo tốt hơn cho người quản lí phần mềm nhưng riêng một mình đào tạo có đủ không? Liệu có thể cho ai đó KHÔNG có tri thức phần mềm làm quản lí dự án phần mềm không? Liệu có thể cho một người kinh doanh tốt nghiệp MBA quản lí dự án phần mềm không? 13 Người quản lí được đào tạo về doanh nghiệp có thể quản lí được mọi thứ không? Tôi tin người quản lí phần mềm tốt PHẢI có cả kinh nghiệm kĩ thuật và doanh nghiệp. Họ phải làm việc trong phát triển phần mềm trong nhiều năm để họ hiểu mọi hoạt động bên trong một dự án. Họ phải nhận được đào tạo về ước lượng thời gian, nỗ lực và lập lịch biểu và thực tế thực hiện những việc này trong các dự án thực để cải tiến kĩ năng của họ. Họ phải hiểu rằng lập kế hoạch không bao giờ đứng yên nhưng thường xuyên phải được cập nhật vì mọi sự luôn thay đổi. Người quản lí tốt bao giờ cũng học cách thương lượng với khách hàng và không bao giờ phạm sai lầm uỷ nhiệm "ngày tháng lịch biểu không thực”. Bởi vì những yêu cầu này, người quản lí phần mềm GIỎI là rất khó tìm ra và đó là lí do tại sao nhiều công ti phần mềm toàn cầu sẵn lòng trả lương cao cho họ. Quản lí dự án phần mềm-2 Chìa khoá cho thành công của bất kì dự án phần mềm nào là thiết lập các yêu cầu tốt. Từ những yêu cầu này, người quản lí dự án có thể đặt ra mục đích, chiều hướng, và trao đổi chúng với thành viên tổ. Điều quan trọng là cả người dùng và người phát triển đều hiểu rõ ràng các yêu cầu cũng như mong đợi. Tất nhiên, người quản lí dự án phải chắc chắn rằng các yêu cầu là đầy đủ, đúng đắn, chính xác, nhất quán, kiểm thử được và theo dõi dấu vết được. Trong công việc phần mềm, lập kế hoạch dự án là rất quan trọng vì nó là cơ sở để quản lí dự án. Khả năng của người quản lí dự án kiểm soát và quản lí dự án phụ thuộc cao độ và sự chính xác của kế hoạch. Bản kế hoạch dự án tốt phải bao gồm ước lượng dự án, lịch biểu, tài nguyên, yêu cầu kĩ năng, công 14