Đào tạo phần mềm
Theo nhiều nghiên cứu, phần lớn dự án phần mềm thất bại vì cả người quản lí dự án và người phát triển phần mềm đều KHÔNG nhận được đào tạo thích hợp. Người quản lí điển hình nên có năm tới bẩy năm kinh nghiệm phát triển phần mềm và nhận đào tạo thêm về quản lí dự án phần mềm. Người phát triển phần mềm điển hình tốt nghiệp từ đại học nên dành một tới hai năm trong kiểm thử và hỗ trợ phần mềm trước khi chuyển vào phát triển. Không may là nhiều người phát triển chưa bao giờ dành thời gian vào kiểm thử hay hỗ trợ và nhiều người quản lí chỉ dành thời gian tối thiểu vào phát triển phần mềm rồi được đề bạt mà không có đào tạo thêm nào. Thiếu đào tạo và kinh nghiệm là hai yếu tố chính dẫn tới thất bại dự án phần mềm.
Với dự án phần mềm, động viên là yếu tố quan trọng nhất trong xác định thành công. Nhiều người quản lí dự án không biết cách động viên tổ của họ mà thay vào đó lại ra lệnh nghiêm khắc, điều làm xói mòn tinh thần tổ. Họ ra lệnh rằng tổ phải hoàn thành các nhiệm vụ bằng cách làm việc vất vả hơn, yêu cầu nhiều thời gian thêm trong khi người quản lí dành hầu hết thời gian vào hội họp, không chú ý tới điều đang diễn ra trong dự án. Việc giám sát chặt của cấp quản lí là cần thiết trong mọi dự án phần mềm kể cả lập kế hoạch hiện thực, kiểm soát thay đổi để giữ cho dự án tiến triển tương ứng. Không có quản lí dự án hiệu quả, tổ bị buộc chấp nhận lịch biểu không hiện thực hay làm những thay đổi mà không có phân tích thích hợp, điều làm xói mòn dự án và đảm bảo thất bại. Lịch biểu không hiện thực là sai lầm thông thường nhất mà người quản lí dự án thường phạm phải. Điều này là do thiếu kĩ năng ước lượng của người quản lí dự án. Ngay cả khi các thành viên tổ nói lên ý kiến của mình rằng họ KHÔNG thể hoàn thành được dự án theo lịch đã cho, người quản lí vẫn tin rằng nếu mọi người làm việc chăm chỉ, và với may mắn, họ vẫn có thể hoàn thành dự án đúng hạn.
Một sai lầm thông thường nữa là người quản lí dự án nghĩ các hoạt động và trách nhiệm phối hợp giữa các thành viên tổ là phí thời gian và tổ càng dành nhiều thời gian vào viết mã, dự án càng có thể hoàn thành tốt hơn. Kiểm thử là cái gì đó khi bạn có thời gian, bạn có thể làm nó, nếu không bạn có thể chữa nó về sau. Không có vai trò được xác định rõ ràng, trách nhiệm và nhiệm vụ phối hợp giữa các thành viên tổ, dự án sẽ rơi vào tình huống hỗn độn nơi các thành viên phản ứng với bất kì cái gì xảy ra cho họ. Khi tổ đang nói rằng phải mất nhiều nỗ lực để đáp ứng ngày chuyển giao, người quản lí vẫn tin rằng họ có thể dàn xếp về sau bằng việc bỏ qua vài bước hay làm việc thêm giờ. Loại thái độ này thực tế giống như nhắm mắt với thực tại và hi vọng cái gì đó sẽ có tác dụng. Thái độ rằng lịch biểu là quan trọng mà không có bất kì ước lượng nào là không hợp lí. Niềm tin rằng là người quản lí, bạn có thể ra lệnh cho mọi người làm bất kì cái gì bạn muốn là “thái độ xấu”.
Thỉnh thoảng, khi dự án đang khủng hoảng, người quản lí quyết định thêm nhiều người để tăng tốc mọi thứ. Đây có lẽ là sai lầm thông thường nhất bởi vì thêm người mới có thể kéo năng suất xuống từ các thành viên tổ hiện có. Vì người mới sẽ cần học về dự án và cần giúp đỡ từ các thành viên khác trong tổ, họ sẽ lấy đi thời gian quí giá của các thành viên hiện có trong tổ để huấn luyện các thành viên mới thay vì làm công việc có năng suất cho nên thêm nhiều người vào dự án bị chậm sẽ làm cho dự án càng chậm hơn.
Trong dự án phần mềm, có tình huống thành viên tổ KHÔNG thể hoà hợp được. Xung đột cá nhân là thông thường, đặc biệt lúc bắt đầu dự án. Người quản lí dự án giỏi bao giờ cũng lập kế hoạch để có nhiều thời gian hơn cho xây dựng tổ nhưng đôi khi mọi sự có thể không có tác dụng tốt. Có thể có những người gây ra vấn đề, những người sẽ không khớp vào trong dự án, những người phá vỡ hài hoà của tổ. Chính trách nhiệm của người quản lí dự án là giải quyết vấn đề này. Không giải quyết được người gây vấn đề sẽ gây nguy hiểm cho phát triển dự án. Không giải quyết được với người gây ra vấn đề là phàn nàn thông thường nhất mà các thành viên tổ có với người quản lí dự án. Ngược lại với người hay gây vấn đề là “nhân viên anh hùng”. Đây là những người có thể làm việc tốt, có kĩ năng tốt nhưng chỉ muốn tự mình làm mọi thứ. Nhiều người quản lí dự án thích anh hùng và tin rằng họ là có ích và thích thưởng cho họ về điều họ làm. Nhưng hội tụ vào “hành vi anh hùng” thực sự có hại hơn là có lợi. Đầu tiên điều đó phá huỷ cách làm việc tổ vì mọi người sẽ vào “thế thủ” và giữ mọi thứ cho riêng mình thay vì chia sẻ thông tin hay giúp lẫn nhau. Kết quả có thể là không thông tin nào sẽ được báo cáo cho người quản lí nếu điều xấu xảy ra mãi cho tới phút cuối cùng. Mọi người sẽ buộc tội lẫn nhau về việc phạm sai lầm bởi vì không ai thừa nhận rằng họ có vấn đề và khi tổ không trong hài hoà, dự án sẽ thất bại.
Phát triển phần mềm KHÔNg phải chỉ là viết mã mà thực tế là thiết kế. Viết mã là dễ, thiết kế không dễ và nó yêu cầu kinh nghiệm. Khi sinh viên tốt nghiệp và bắt đầu làm việc, họ sẽ cần dành chút thời gian vào khu vực kiểm thử để học nhiều hơn về thiết kế. Bằng cách làm việc trong khu vực thiết kế, họ có thể quan sát cách người khác thiết kế phần mềm, cách các chức năng được chia thành các mảnh nhỏ hơn, cách các cấu phần làm việc với nhau, cách kiến trúc hệ thống được lập kế hoạch. Đây thực sự là thời gian học tập để xây dựng kĩ năng của họ trước khi họ thực tế có cơ hội tự mình thiết kế hệ thống. Gần như mọi sinh viên đã tốt nghiệp có thể viết mã tốt nhưng kiến trúc và thiết kế thường KHÔNG được dạy chi tiết trong hầu hết các đại học. Bằng việc dành thời gian vào khu vực kiểm thử, sinh viên có thể cải tiến các kĩ năng này và trở thành nhà chuyên môn phần mềm giỏi hơn. Nhiều sinh viên KHÔNG thích làm việc như người kiểm thử để sửa lỗi của ai đó mà muốn làm việc như người phát triển ngay lập tức. Bởi vì họ đã không kinh nghiệm sai lầm của người khác, tự họ sẽ phạm cùng sai lầm.
Vấn đề thông thường khác trong dự án phần mềm là xích mích giữa người phát triển và người dùng. Phần lớn người dùng có vấn đề mà họ muốn người phát triển đi tới giải pháp ngay lập tức cho nên họ bao giờ cũng đòi hỏi lịch biểu chặt chẽ tương ứng với điều họ muốn. Khi người phát triển không chuyển giao theo lịch biểu đó họ trở nên giận dữ. Người phát triển thường cảm thấy rằng người dùng không biết điều họ muốn và đòi hỏi cái gì đó không hợp lí rồi thường xuyên đổi ý của họ sau khi yêu cầu đã được thiết lập. Vấn đề then chốt của xích mích này là kém trao đổi, và yêu cầu được xác định sơ sài. Người phát triển có kinh nghiệm nên học về kĩ nghệ yêu cầu để cho họ biết cách làm việc với người dùng, biết cách trao đổi hiệu quả với họ để có thể đi tới các yêu cầu tốt, thiết kế giao diện người dùng tốt, và có qui trình được xác định tốt để giải quyết các thay đổi yêu cầu. Thiếu kĩ năng này sẽ tạo ra nhiều xích mích hơn và đôi khi chúng còn nghiêm trọng tới mức người quản lí phải cắt bỏ dự án. Kĩ nghệ yêu cầu là kĩ năng mấu chốt và được yêu cầu trong mọi chương trình kĩ nghệ phần mềm nhưng thường không được dạy trong chương trình khoa học máy tính.
Bằng việc có đào tạo đúng cho người quản lí dự án và người phát triển phần mềm, công ti có thể được lợi bằng việc có nhiều cơ hội tốt hơn cho thành công và tránh các vấn đề với dự án phần mề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
