Rất nhiều câu hỏi đặt ra cho ngành phần mềm trong nước? Trong khi vấn đề như vậy ở các dự án outsourcing ít gặp hơn, nhưng không có nghĩa là không có.

Xem thêm: 

Nỗi lo sợ của đơn vị vận hành:

• Phần mềm tiềm ẩn lỗi. 
• Sợ thậm chí một lỗi dù là nhỏ, dẫn đến một module có chứa lỗi đó chưa thể nghiệm thu, từ đó dẫn đến cả dự án cũng chưa thể nghiệm thu, tạo ra hiệu ứng domino "nỗi sợ". Xem thêm: Lý thuyết con gián của tổng giám đốc Google.
• Dữ liệu có thể bị "lộ" do phần mềm có lỗ hổng.
• Sợ bị báo chí chụp lại được Website bị hack, hoặc dữ liệu bị bôi nhọ.
• Không đủ năng lực vận hành nên không tự tin.
• Nỗi sợ "trách nhiệm" nếu chẳng may phần mềm có sự cố, trong khi phần lớn nhân lực vận hành không rành về kỹ thuật (trừ các doanh nghiệp lớn có duy trì phòng IT riêng).
• Nỗi sợ "chất lượng vận hành". Các lãnh đạo chưa tự tin về năng lực vận hành của nhân viên sau khi tham gia đào tạo.

Nỗi lo sợ của đơn vị sản xuất:

• Đầu vào (scope, requirement) và đầu ra (năng lực vận hành, kỹ năng CNTT) không cân khi đơn vị vận hành chuẩn bị "launching" phần mềm. Điều này đồng nghĩa với thách thức là nhà thầu sẽ liên tục support trong 12 tháng bảo hành, bao gồm thời gian và chi phí chỉ để hỗ trợ tìm hiểu các vấn đề vượt khung trách nhiệm phải hỗ trợ. Nguyên nhân chủ yếu đến từ quá trình triển khai từ đầu đã không có kịch bản hoàn chỉnh và tập trung (còn gọi là brief hoặc overview design).
• Chi phí dự án vượt khung.
• Bị lãnh đạo chỉ trích vì không hoàn thành mục tiêu nghiệm thu, ảnh hưởng đến công tác nhân sự của các dự án khác.

Phần mềm là sản phẩm "vô hình" (không sờ được, không nắm được...) và đặc biệt lĩnh vực phần mềm là sản phẩm của trí tuệ, của sự sáng tạo không ngừng, sự thay đổi công nghệ chóng mặt. Do đó khách hàng sẽ không đánh giá hết được khối lượng công việc như đánh giá một công trình xây dựng. Mâu thuẫn liên quan đến sở hữu trí tuệ cũng bắt đầu phát sinh từ đây.

Nếu nói phần mềm không có khấu hao như sản phẩm hữu hình thì cũng không chính xác. Phần mềm có thể bị lạc hậu, không tương thích với dòng máy tính mới nhất, hoặc có khả năng xử lý một lượng dữ liệu lớn theo thời gian. Do không hiểu rõ điều này nên tồn tại thêm mâu thuẫn giữa các bên về kế hoạch bảo hành, bảo trì.

Những gì đơn vị vận hành sẽ nghĩ:

• Phần mềm sẽ "automatic" công việc của chúng ta.
• Phần mềm sẽ cung cấp các công cụ để lọc dữ liệu xấu, đây là trách nhiệm của nhà thầu sẽ phải xây dựng các công cụ.
   

Những gì đơn vị sản xuất sẽ nghĩ:

• Thay đổi yêu cầu quá lớn và thường xuyên (hiện tượng quả cầu tuyết).
• Các kỹ sư phần mềm đã "làm thêm miễn phí" quá nhiều, khiến dự án kéo dài không thể nghiệm thu.
• Một doanh nghiệp vận hành sẽ không cho phép dự án kéo dài, gây lãng phí thời gian và nguồn lực, ảnh hưởng đến tình hình tài chính doanh nghiệp.
• Cân đối thời gian và công sức: Nhà thầu có thể bỏ thời gian support trong một thời gian dài (thí dụ 12 tháng bảo hành), nhưng sẽ không bỏ công sức vì yếu tố này ảnh hưởng đến tình hình tài chính doanh nghiệp.

Các mâu thuẫn khác:

• Nhà thầu chỉ giới hạn đào tạo cơ bản cho từng vai trò (vận hành, lãnh đạo...), nhưng đơn vị vận hành cho rằng nhà thầu phải đào tạo chuyên sâu, cầm tay chỉ việc từ những thao tác cơ bản nhất.
• Nhà thầu chỉ là công ty dịch vụ phần mềm (Software House), không phải công ty sản xuất phần mềm (Software Company). Chủ đầu tư lầm tưởng rằng nhà thầu có thể hỗ trợ đa năng, bao gồm cả hạ tầng (phần cứng) và cả viết code mở rộng tính năng.
• Hai bên không thống nhất được thế nào gọi là bảo hành, thế nào gọi là bảo trì. Xem thêm: Bảo hành, bảo trì là gì? Gồm những công việc và lưu ý gì?
• Xuất hiện "gap" khi đơn vị vận hành mong muốn nhà thầu "đồng hành" cùng họ, thậm chí khi hết 12 tháng bảo hành. Trong khi nhà thầu cho rằng đơn vị vận hành vô tình biến dự án thành sản phẩm "in-house".
• Các mâu thuẫn hợp đồng giữa thầu chính và thầu phụ cũng dẫn đến kết quả chung của dự án, khiến quá trình nghiệm thu kéo dài.
   

Theo kinh nghiệm của các chuyên gia phần mềm, cả 2 đơn vị vận hành và đơn vị phát triển đều có những vấn đề từ nhỏ cho đến nghiêm trọng, tạm gọi là vấn đề cốt lõi (vấn đề "key"). Ngay cả chủ đầu tư là đơn vị giải ngân tài chính dự án cũng có những vấn đề nếu chỉ đánh giá chất lượng dự án chỉ dựa vào ý kiến một bên. Nếu không phá băng được các vấn đề "key" này, dự án sẽ lâm vào bế tắc. Thậm chí có dự án sau khi đã được đồng ý nghiệm thu, sau 12 tháng bảo hành không đạt được sự đồng thuận giữa các bên do bất đồng quan điểm, tồn tại "gap" lớn hơn sau nghiệm thu, cuối cùng dẫn đến tình trạng tồi tệ hơn là "sản phẩm đắp chiếu" vì thiếu sự hỗ trợ lâu dài, thiếu niềm tin giữa các bên, thiếu các chất xúc tác để hài hòa lợi ích giữa các bên.

Các vấn đề "key" của đơn vị vận hành:

• Phần mềm phải hoàn hảo, phải "sạch" lỗi thì mới có thể nghiệm thu.
• Tất cả các kịch bản kiểm thử (Test Case) phải được "pass" qua, mặc dù đơn vị vận hành không kiểm tra được phần mềm đó có khoảng bao nhiêu Test Cases là đảm bảo an toàn.
• Tham mưu bởi đơn vị tư vấn chất lượng thấp, hoặc nhiệm vụ tư vấn có nhiều bất cập vì không bám sát yêu cầu và phạm vi dự án (tình trạng xảy ra thường xuyên ở các dự án trong nước).

Chính vì suy nghĩ "mọi thứ đã có nhà thầu lo", "phần mềm phải "automatic" công việc quản trị"... đã khiến dự án vượt phạm vi, kéo dài thời gian thực hiện tối đa được quy định trong Hợp đồng cũng như gia hạn Hợp đồng...

Những vấn đề thuộc về nhà thầu

Vấn đề chất lượng luôn xảy ra ở mọi nơi. Tuy nhiên Việt Nam không phải là Nhật Bản hay EU nên tiêu chuẩn chất lượng cũng không thể sánh với các quốc gia phát triển. Tuy nhiên chúng ta cần nhờ rằng "quality" (chất lượng) khác với "grade" (đẳng cấp). Một sản phẩm có nhiều tính năng "khủng" (đẳng cấp) chưa chắc đã chất lượng hơn sản phẩm ít tính năng.

Do phần mềm là loại sản phẩm "mềm" nên chất lượng cũng rất "biến động" theo từng hoàn cảnh. Một phần mềm hoàn toàn "base" trên nguồn đóng (thí dụ Sharepoint) hay mã nguồn mở (thí dụ Website CMS trên nền tảng DotNetNuke, Liferay,...) đương nhiên sẽ luôn chất lượng hơn phần mềm do nhà thầu tự viết ra. 

Trong bất cứ mô hình nào thì chất lượng phần mềm phụ thuộc rất lớn vào năng lực của nhà thầu. Thông thường theo công thức tỷ lệ 1 Kiểm thử viên (tester) trên 2 lập trình viên. Có nghĩa là nếu có 10 lập trình viên, thì nhất định phải có 5 testers mới đảm bảo yêu cầu chất lượng. Do muốn đạt mục tiêu giảm chi phí nên nhiều nhà thầu tìm cách giảm bớt số lượng testers, chấp nhận rủi ro kéo dài thời gian nghiệm thu.

Trong thực tế, để nghiệm thu một phần mềm đã thực sự hoàn tất kiểm thử UAT hay chưa có thể căn cứ vào một danh sách các Key Test Cases (nếu dự án 1000 man-days thì sẽ có khoảng 200 key Test Cases) hoặc dựa trên kết quả báo cáo của nhà thầu về số lượng các lỗi trên luồng chính.

Sạch lỗi trên luồng chính, liệu phần mềm đã đủ để nghiệm thu?
 

Những vấn đề thuộc về "tư vấn" dự án

Không quá khó hiểu khi mọi dự án cần phải có tư vấn, từ tư vấn giải pháp cho đến tư vấn giám sát, tư vấn vận hành. Tùy từng dự án có nguồn kinh phí cho dịch vụ thuê tư vấn, chất lượng dự án phụ thuộc khá nhiều vào năng lực tư vấn.

Không giống như tư vấn trong các lĩnh vực khác, tư vấn phần mềm có đặc thù riêng và chỉ những người sinh ra sau thập kỷ 70 mới đủ khả năng tư vấn vì đây là độ tuổi "chín" để đáp ứng nhu cầu của ngành công nghệ non trẻ nhưng rất "hại não" như ngành CNTT. Thành ngữ có câu "Đi hỏi già, về nhà hỏi trẻ" cho thấy vai trò của tư vấn là rất quan trọng.

Cân đối các yếu tố là chìa khóa thành công

Bạn đã bao giờ nghe "stakeholder"? Đó là những người có lợi ích trong dự án. Thí dụ ông A không phải là người sử dụng phần mềm, nhưng ông A có tiếng nói. Ông B không có ảnh hưởng đến dự án, nhưng ông B là người có nhiều kinh nghiệm vận hành. Bà C không phải người sử dụng cuối (end-user), nhưng bà C là người có thể ra được đầu bài phù hợp với lộ trình phát triển của doanh nghiệp. v.v.

Để dự án nghiệm thu sẽ cần sự tham gia của tất cả các stakeholder trên, mặc dù không phải 100% đều có ảnh hưởng đến quyết định cuối cùng. Chỉ cần 1/10 phòng ban chưa thể đồng ý nghiệm thu, dự án sẽ rất khó được nghiệm thu sớm.

Ngoài việc cân đối "stakeholder", các bên cũng phải cân đối giữa phạm vi và kinh phí, giữa chất lượng (quality) và điểm tối đa (grade), giữa lợi ích lâu dài và lợi ích ngắn hạn.

Cân bằng các yếu tố là chìa khóa thành công trong nghiệm thu dự án

TÌM HIỂU HÊM VỀ CÔNG THỨC NGHIỆM THU DỰ ÁN TẠI ĐÂY: 

Kinh nghiệm tư vấn TIGO Solutions

Tại TIGO, chúng tôi cung cấp dịch vụ tư vấn miễn phí cho đầu vào dự án CNTT. Chúng tôi có kinh nghiệm tư vấn chuyên sâu về các ứng dụng phần mềm điều hành Doanh Nghiệp, các hệ thống Web, các hệ thống chuyển đổi số, tích hợp trí tuệ nhân tạo (AI)... Nhân sự của TIGO bao gồm các thành viên với nhiều kỹ năng đa dạng, đạt chứng chỉ quốc tế Business Analyst, PMP, Scrum, ISTQB - foundation level (kiểm thử quốc tế).
 

Dịch vụ tư vấn giải pháp phần mềm miễn phí: 

Kết Luận:

Đầu vào và đầu ra không "cân" là nguyên nhân cốt lõi của mọi vấn đề, và vấn đề nghiệm thu chỉ là một phần nổi của tảng băng.

Dự án phần mềm không giống các công trình xây dựng. Các công trình khi đã triển khai thì không thể "rút lại", trong khi các module phần mềm có thể bị gỡ vì phạm vi ngoài hợp đồng do 2 bên không tìm được tiếng nói chung trong khâu nghiệm thu. Những vấn đề như vậy cần xử lý thấu tình đạt lý. Các bên phải ưu tiên sự hợp tác và đồng thuận, cân bằng lợi ích và chi phí.

Để hai bên cùng đạt được "win-win" là một quá trình kéo dài và cân não. Đối với các dự án size > 2000 man-days thì thời gian nghiệm thu và thanh lý hợp đồng có thể kéo dài đến 1 năm. Do đó nếu dự án của bạn chỉ tầm 1000 man-days thì nên cân nhắc rủi ro nếu thời gian nghiệm thu kéo dài hơn 6 tháng.

Chuyên gia TIGO Solutions

Tiếp tục theo dõi...