Thứ Ba, 4/10/2022, 00:56
28 C
Ho Chi Minh City

Đặt báo in

Thông tin quảng cáo

Thông tin quảng cáo

Các nguyên nhân làm dự án phần mềm thất bại

Kinh tế Sài Gòn Online

Kinh tế Sài Gòn Online

Các nguyên nhân làm dự án phần mềm thất bại

Ngô Văn Toàn (Công ty Global CyberSoft Việt Nam)

(TBVTSG) – Trong thực tế có rất nhiều nguyên nhân gây ra các khó khăn trong một dự án phần mềm. Những khó khăn này nếu không được xử lý sẽ dẫn đến việc chi phí dự án tăng vọt và trượt thời hạn cam kết, làm cho dự án thất bại giữa chừng, hoặc vẫn “hoàn thành” nhưng không đạt một phần hoặc thậm chí toàn bộ các mục tiêu đặt ra.

Như đã nói ở bài viết “Quản trị dự án và vai trò của giám đốc dự án” (TBVTSG số 3/2010, phát hành ngày 25-2), không có định nghĩa giống nhau về sự thành công hay thất bại của các dự án, mà nó phụ thuộc vào việc các mục tiêu riêng biệt đặt ra cho từng dự án có đạt được hay không. Tuy nhiên, một cách tổng quát, những dấu hiệu tiềm ẩn của một dự án chứa nhiều yếu tố thất bại ta có thể thấy được qua một số biểu hiện phổ biến sau:

Làm ngoài giờ, đặc biệt trong giai đoạn hoàn thiện sản phẩm, kể cả các sản phẩm trung gian trước khi giao cho khách hàng. Biểu hiện phổ biến trong giai đoạn này là làm ngoài giờ để hiệu chỉnh các lỗi trước khi bàn giao. Cá biệt có một số dự án, làm ngoài giờ xuất hiện ngay từ các chặng đầu của dự án.

Tăng nhân lực, có thể xảy ra đồng thời hoặc để thay thế cho việc làm ngoài giờ, tùy tình huống dự án. Tăng nhân lực xảy ra ở mức gián tiếp lẫn trực tiếp. Gián tiếp bao gồm những hỗ trợ chéo giữa các dự án, hoặc từ các chuyên gia từ bên ngoài dự án. Trực tiếp bao gồm việc bổ sung thêm người mới, hoặc thay người cũ bằng người mới có trình độ tốt hơn (chi phí cao hơn).

Tỷ lệ lỗi tăng đột biến, tăng ở mức cao hơn rất nhiều so với mức độ trung bình (của các dự án tương tự) ở một chặng nào đó, đặc biệt lỗi dồn vào giai đoạn cuối, ở chặng tích hợp (Integration) và kiểm định mức hệ thống (System Test). Dấu hiệu này kéo theo tình trạng thời gian sửa lỗi hoặc viết lại code gia tăng đáng kể

Mất kiểm soát tiến độ dự án, xuất hiện sự sai lệnh và thiếu đồng nhất về dữ liệu giữa tiến độ thực của dự án và tiến độ báo cáo, giữa tiến độ chung và tiến độ các nhóm trong dự án. Tình trạng này thường xuất hiện ở những dự án lớn, phức tạp, hoặc ở giai đoạn căng thẳng khi có quá nhiều lỗi, hoặc yêu cầu thay đổi quá nhanh.

Mất kiểm soát các thay đổi trong dự án, đặc biệt khi dự án hiểu sai yêu cầu, hoặc khi khách hàng yêu cầu thay đổi quá nhiều và liên tục nhưng quy tắc kiểm soát yếu kém. Dấu hiệu của tình trạng một số yêu cầu bị “bỏ quên”, “hiểu sai”, hoặc các yêu cầu đã làm cho phạm vi dự án bị thay đổi vượt mức cho phép.

Tinh thần làm việc của nhân viên xuống thấp, với các dấu hiệu tâm lý nhân viên mệt mỏi, chán nản xuất hiện cục bộ và ngày càng lan rộng. Dấu hiệu xuất hiện rất đa dạng như mất tập trung, bất tuân quy trình hoặc công việc được chỉ định, phối hợp kém, lỗi gia tăng. Cao điểm là tình trạng nghỉ dài ngày, nghỉ bệnh hoặc nghỉ việc xảy ra trong dự án.

Khách hàng phàn nàn, dù dự án chưa kết thúc nhưng khách hàng đã phàn nàn không hài long về kết quả phối hợp. Đây là một trong những dấu hiệu cho thấy sự thiếu đồng bộ, thiếu hiểu biết lẫn nhau giữa hai bên, dẫn đến khả năng khách hàng bất mãn là rất cao.

Để xác định chính xác đâu là nguyên nhân gây ra tình trạng khó khăn cho dự án, để có thể đề xuất các giải pháp “cứu chữa” hoặc kiểm soát hữu hiệu, người ta thường phân tích sâu vào bản thân từng tình huống khó khăn, thông qua các dấu hiệu của nó, với sự tương tác với các yếu tố có liên quan xung quanh. Dĩ nhiên, để kiểm soát tốt, trưởng dự án có kinh nghiệm không chờ khó khăn xảy ra rồi mới cứu chữa, mà phải “đón đầu” và nhận diện trước, kiểm soát chặt chẽ từ ban đầu các dấu hiệu của rủi ro có thể xảy ra trong dự án (xem thêm TBVTSG số 05/2010, phát hành ngày 25-3 về “Những rủi ro thường gặp trong quản lý dự án”).

Việc tham khảo các nguyên nhân phổ biến gây ra các khó khăn trong dự án được đúc kết từ nhiều dự án cũng là một trong những phương cách quan trọng giúp trưởng dự án nhanh chóng định vị được các vấn đề và nguyên nhân gốc gây ra vấn đề đó ở dự án của mình.

Có rất nhiều công trình tìm hiểu và phân tích các nguyên nhân phổ biến gây ra khó khăn và thất bại cho các dự án phần mềm do nhiều tổ chức khác nhau thực hiện. Hai trong số công trình khá nổi tiếng là chuỗi bài phân tích “10 nguyên nhân hàng đầu gây thất bại cho dự án”(1) của Frank Winter nhấn mạnh lý do chủ yếu thường là từ vấn đề quản lý, và một khảo sát khác được tiến hành bởi Standish Group(2) trên nhiều dự án cũng chỉ ra 10 nguyên nhân hàng đầu gây ra sự thất bại cho dự án (bảng 1). Mặc dù 10 nguyên nhân do Standish Group chỉ ra liên quan không chỉ đến lĩnh vực quản lý mà còn cả kỹ thuật, nhưng tựu chung vẫn do vấn đề quản lý mà ra, trong đó đứng đầu là các nguyên nhân liên quan đến yêu cầu về sản phẩm và sự tham gia của người sử dụng.

Trở lại ví dụ về sự thất bại của dự án đình đám Visual Case File(3) của FBI (xem TBVTSG số 5/2010), sau nhiều công việc phân tích đã được thực hiện, các nguyên nhân quan trọng nhất về mặt kỹ thuật làm cho dự án thất bại được đúc kết bao gồm:

• Thiết kế kiến trúc yếu kém ngay từ bước khởi đầu.

• Các yêu cầu và đặc tả hệ thống thay đổi quá nhiều, phạm vi dự án phình to liên tục, khối lượng mã nguồn (source code) phát triển đồ sộ.

• Thay đổi người lãnh đạo liên tục.

• Giám sát thực thi yếu kém.

• Quá nhiều người tham gia vào dự án, kể cả những người thiếu hiểu biết về CNTT.

• Thêm người khi dự án đang gặp rắc rối, vi phạm quy tắc Brooks(4), càng làm cho rắc rối phát triển thêm.Trong thực tế, nguyên nhân của các vấn đề ở các dự án khác nhau là khác nhau, hoặc tác hại của chúng khác nhau rõ rệt dù trong cùng điều kiện và hoàn cảnh. Do thời gian và nguồn lực dự án là có hạn, việc phân tích và phân loại nguồn gốc các nguyên nhân có ý nghĩa quan trọng giúp giám đốc dự án “khoanh vùng” ưu tiên để xác định những nguyên nhân nào là nguyên nhân “gốc”, cần “trị” trước theo nguyên tắc 20/80 để cứu chữa hoặc phòng ngừa tốt nhất cho dự án.

Phân tích các nguyên nhân đã nêu (bảng 1), xét thêm trong môi trường Việt Nam, ta thấy một số nguyên nhân gây ra các khó khăn thường gặp trong thực tế bao gồm:

Yêu cầu không rõ ràng, gây ra sự hiểu sai. Trong thực tế điều này rất hay xảy ra và là nguyên nhân của rất nhiều lỗi. Các lỗi này qua nhiều đợt xem xét (review) và kiểm định vẫn có thể không được phát hiện cho đến giai đoạn cuối chỉ đơn giản vì sự hiểu sai đã không được nhận ra. Việc yêu cầu không rõ ràng cũng thường xuất hiện ở những dự án nâng cấp, tài liệu về yêu cầu đôi khi không có, nhân viên dự án phải “chạy thử” hệ thống cũ để hiểu yêu cầu, do đó mang nặng tính “giả định”. Mặt khác, yêu cầu không rõ ràng cũng là nguyên nhân làm dự án mất khá nhiều thời gian để làm rõ, đính chính và xác nhận với khách hàng

Thay đổi quá nhiều và dày. Đây là nguyên nhân của rất nhiều rủi ro và khó khăn xảy ra trong các dự án. Thay đổi, bao gồm cả yêu cầu và nguồn lực dự án, dẫn đến phá vỡ các kế hoạch thực hiện dự án. Thành viên dự án không nắm bắt kịp các yêu cầu, khiến dự án bị mất kiểm soát, thiếu thời gian để điều chỉnh thiết kế và kiểm định dẫn đến nhiều sai sót xuất hiện, làm tăng số nhân lực và khả năng dự án không hoàn thành đúng hạn, thậm chí thất bại hoàn toàn.

Ước lượng thiếu chính xác là nguyên nhân của hầu hết các dự án có sai lệch giữa kích thước dự án thực và kích thước ước lượng từ đầu. Ngoài các nguyên nhân khách quan như yêu cầu thiếu, sai hoặc thay đổi, nguyên nhân chủ quan thường là khả năng hiểu biết về hệ thống yếu kém, năng lực của quy trình và kỹ thuật ước lượng yếu kém, làm cho khối lượng công việc thực tế của dự án lớn hơn nhiều so với dự kiến, buộc dự án phải tăng người hoặc thời gian hoàn thành.

Kiểm soát dự án yếu kém. Có nhiều vấn đề xảy ra trong dự án có nguyên nhân từ sự yếu kém và buông lỏng trong công tác hoạch định và kiểm soát dự án. Nhiều tác vụ được quy định trong quy trình đã không được hoạch định hoặc hoạch định nhưng không được giám sát để bảo đảm là chúng được thực hiện nghiêm túc (làm cho có). Trong thực tế, phần lớn các trưởng dự án được đề bạt từ chuyên gia kỹ thuật, một số thiếu kỹ năng quản trị, kỹ năng điều phối và giải quyết xung đột, sa đà vào giải quyết sự vụ kỹ thuật. Trong đa số trường hợp, kiểm soát kém dẫn đến tình trạng mất kiểm soát, làm cho dự án thất bại.

Năng lực kỹ thuật của nhân viên dự án còn yếu kém. Trong thực tế, luôn có khoảng cách giữa năng lực thực tế của nhân viên và yêu cầu vốn khá cao của các dự án, đặc biệt ở những vị trí cần chuyên gia then chốt. Nhiều nhân viên mới tuyển, dù đã qua huấn luyện vẫn chưa đủ kinh nghiệm và kỹ năng để đáp ứng yêu cầu của dự án. Tình trạng yếu kém về năng lực vẫn có thể xảy ra đối với kỹ sư cao cấp, đặc biệt với những hệ thống có kỹ thuật quá mới, hoặc hệ thống cũ nhưng thiếu tài liệu hoặc thời gian nghiên cứu, thực hành.

Truyền thông (communication) với khách hàng chưa tốt, xảy ra ở nhiều cấp độ, từ bán hàng (sales) đến quản lý cấp cao, đến trưởng dự án. Biểu hiện thường gặp là phạm vi (scope) của dự án đã thay đổi khá nhiều so với các cam kết ban đầu, hoặc các thay đổi và cam kết hoặc giả định đã được hiểu không chính xác giữa hai bên. Nhiều thay đổi không phù hợp với khả năng của dự án đã dẫn đến rất nhiều khó khăn phát sinh cho dự án.

Rào cản ngôn ngữ. Đây là một nguyên nhân phổ biến trong nhiều dự án được thực hiện tại Việt Nam cho đối tác nước ngoài, đặc biệt với khách hàng không sử dụng tiếng Anh. Rào cản này ảnh hưởng trực tiếp đến các khâu quan trọng nhất trong dự án là phát triển yêu cầu và truyền thông với khách hàng, do đó là nguyên nhân của rất nhiều khó khăn, sai sót xảy ra.

Rõ ràng, quản lý và kiểm soát một dự án hướng đến thành công, đạt được các mục tiêu đề ra là việc làm không đơn giản. Nó liên quan đến rất nhiều yếu tố kể cả định lượng lẫn bất định lượng, trong đó vai trò và kỹ năng của giám đốc dự án mang tính quyết định. Vậy một giám đốc dự án giỏi cần phải có những kỹ năng cơ bản nào? Đó là nội dung của bài viết kế tiếp.

_________________________________________________

(1) “The Top 10 Reasons Projects Fail”, Frank Winters, 2003, www.gantthead.com

(2) The Standish Group – CHAOS Report, www.standishgroup.com

(3) http://en.wikipedia.org/wiki/Virtual_Case_File

(4) Quy tắc Brooks (Brooks’ Law) khá nổi tiếng cho rằng trong việc phát triển phần mềm, thêm người vào dự án khi nó bị trễ hạn sẽ càng làm cho nó bị trễ hạn nhiều hơn. Một cách nói khác của quy tắc là “chín người đàn bà cũng không thể tạo ra một em bé trong vòng một tháng”

BÌNH LUẬN

Vui lòng nhập bình luận của bạn
Vui lòng nhập tên của bạn ở đây

Tin liên quan

Có thể bạn quan tâm

Tin mới