Phát triển phần mềm có nhiều vấn đề rất khó dự đoán và khó lập kế hoạch một cách rõ ràng. Về bản chất, phát triển phần mềm có nhiều điều mơ hồ và có nhiều bên liên quan. Sự kết hợp của các yếu tố này có thể tạo ra một số rủi ro cần được xem xét và quản lý ngay khi bắt đầu dự án.
Mặc dù chúng ta có thể ước lượng các mối đe dọa có thể ảnh hưởng dự án phần mềm, nhưng khả năng xảy ra và tác động của chúng sẽ khác nhau tùy thuộc vào phương pháp mà bạn đang sử dụng. Dưới đây là những rủi ro lớn nhất có thể xảy ra với bất cứ dự án phần mềm nào mà bạn cần phải xem xét với tư cách là một quản lý dự án hoặc là một developer đóng vai trò cần thiết trong dự án.
1. Ước lượng không chính xác
Ước lượng là một phần thường không thể tránh khỏi trong quá trình phát triển phần mềm nhưng việc này cũng có thể tạo ra rủi ro nếu ước tính tạo ra những kỳ vọng không thể đáp ứng được.
Ước lượng không chính xác xảy ra khi độ dài của một dự án, các cột mốc cần thiết và nhiều yếu tố khác bị nhóm dự án đánh giá thấp. Ước lượng phần mềm có thể gây ra vấn đề giữa nhà phát triển và khách hàng vì chúng dẫn đến nhiều hệ lụy như thời gian của dự án dẫn đến việc tăng chi phí của dự án. Rủi ro này rất có thể xảy ra và gây ảnh hưởng nghiêm trọng đến việc thực hiện dự án nếu có.
Làm thế nào để ước lượng chính xác khi xây dựng phần mềm? Có một số chiến lược bạn có thể xem xét để giảm thiểu rủi ro:
- Chỉ xây dựng công việc cần ưu tiên trước mắt;
- Tính đến Tech Spikes trong ước lượng của bạn (tức là phân bổ thời gian để tập trung vào một số vấn đề kỹ thuật hoặc vấn đề thiết kế trong dự án cần được giải quyết trước và loại bỏ rủi ro đối với một phần đặc biệt phức tạp hoặc không quen thuộc của dự án);
- Thêm hệ số phân bổ vào ước lượng (nghĩa là hệ số thời gian được tính toán mà nhóm phát triển dành trong tuần công tác cho nhiệm vụ bên ngoài dự án); và
- Xem xét Mô hình nón của sự bất định ( Cone of Uncertainly)khi ước lượng phần mềm.
2. Các thay đổi về phạm vi
Các thay đổi về phạm vi (scope) xảy ra khi phạm vi của tác vụ thay đổi sau một khung thời gian đã được thống nhất. Sự phản hồi thường xuyên của khách hàng, của các bên liên quan hoặc chủ sở hữu sản phẩm thường sẽ thường dẫn đến việc thay đổi phạm vi của một dự án.
Tuy nhiên, sự khác biệt về phạm vi tạo ra rủi ro nghiêm trọng cho các dự án. Khi phạm vi thay đổi, nó ảnh hưởng đáng kể đến khả năng của các nhà phát triển trong việc bám sát dòng thời gian ban đầu của một dự án.
Vậy làm thế nào để bạn quản lý các biến thể của dự án? Quản lý kỳ vọng của khách hàng xung quanh việc thay đổi scope có thể ảnh hưởng đến các ước lượng ban đầu của một dự án là một chiến lược giảm thiểu rủi ro này cần thiết.
Việc sử dụng số liệu biến thể (variation metric) để đo lường các thay đổi về scope, cho phép khách hàng dễ thấy hơn về cách các yêu cầu đã tác động đến dự án.
Sau đây là một số chiến lược khác để đối phó với các thay đổi về scope:
- Các lần lặp (iteration)ngắn, có thể quản lý được (hoặc sử dụng phương pháp Agile) cho phép có nhiều cơ hội thường xuyên hơn để phản ánh và thay đổi phạm vi dự án; và
- Xây dựng công việc ưu tiên duy nhất.
3. Tương tác của người dùng cuối
Rủi ro này là khi một sản phẩm được tung ra thị trường nhưng người dùng không chấp nhận các thay đổi hoặc xảy ra xung đột giữa những người dùng.
Tại sao sự tham gia của người dùng lại cần thiết trong quá trình xây dựng phần mềm? Việc đảm bảo rằng người dùng sẽ thực sự sử dụng phần mềm sẽ chứng minh được sự thành công của nó. Trong trường hợp một công ty xây dựng phần mềm cho một khách hàng bên ngoài, nó sẽ tương quan với lợi nhuận. Trong trường hợp một doanh nghiệp xây dựng phần mềm để sử dụng nội bộ, nó có thể xác định liệu phần mềm đó có thực sự cải thiện năng suất trong công ty được không.
Làm cách nào để bạn cải thiện mức độ tương tác của người dùng? Bạn có thể ngạc nhiên khi câu trả lời đơn giản thế nào: hãy lắng nghe người dùng của bạn. Một số chiến lược giảm thiểu rủi ro có thể xảy ra bao gồm:
- Thử nghiệm và khảo sát người dùng;
- Làm việc với các nhóm tập trung (focus groups);
- Phát hành thường xuyên; và
- Thử nghiệm beta.
Các chiến lược giảm thiểu này dễ áp dụng hơn nhiều bằng cách sử dụng phát triển linh hoạt
4. Kỳ vọng của các bên liên quan
Mặc dù chúng ta đang nói về việc quản lý kỳ vọng của các bên liên quan (stakeholders) như một chiến lược giảm thiểu rủi ro, nhưng việc áp dụng chiến lược này tự nó có thể trở thành một rủi ro của dự án.
Vậy bên liên quan trong phát triển phần mềm là gì? Các bên liên quan là bất kỳ cá nhân hoặc nhóm nào có thể tác động hoặc sẽ bị ảnh hưởng bởi kết quả của dự án phần mềm. Các bên liên quan này có thể bao gồm từ chủ doanh nghiệp, đến nhóm phát triển, hoặc thậm chí là các nhà đầu tư vào dự án. Chính mối quan hệ chặt chẽ này với kết quả dự án khiến việc quản lý kỳ vọng của từng bên liên quan trở thành một thách thức.
Vậy bạn đặt kỳ vọng với các bên liên quan thế nào? Sau đây là một số cân nhắc:
- Giao tiếp hiệu quả;
- Đạt được sự chấp thuận và nhận sự hồi đáp thường xuyên về dự án từ các bên liên quan;
- Tuân theo các phương pháp phát triển đã được chứng minh (chẳng hạn như phương thức Phối hợp công việc (Agile Way of Working);
- Cho các bên liên quan tham gia vào các cuộc họp cần thiết; và
- Đảm bảo các bên liên quan duy trì các kênh phản hồi hợp lý với các nhóm phát triển.
5. Code chất lượng kém
Khi chất lượng của một dự án không phù hợp với kỳ vọng của các bên liên quan, sẽ có nguy cơ đáng kể là dự án sẽ không thành công. Code chất lượng kém có thể xảy ra vì một số lý do, chẳng hạn như khi các dự án bị đánh giá thấp và các nhà phát triển gấp rút hoàn thành các tác vụ.
Code xấu là gì? Code chất lượng kém có thể có có nhiều nghĩa. Code có thể khó đọc, tức là các developers khác khó có thể xem xét hoặc thực hiện thay đổi. Nó có thể đã được phát hành vội vã và không được kiểm thử, do đó còn nhiều các lỗi có thể ngăn chặn được. Nói cách khác, code chất lượng kém sẽ tạo ra nguy cơ nợ kỹ thuật (technical debt).
Làm thế nào để bạn xác định nợ kỹ thuật? Nợ kỹ thuật về cơ bản là bất kỳ những code nào làm giảm tính linh hoạt của một dự án phần mềm trong dài hạn. Thông thường, nó được tạo ra bằng cách sử dụng các phương pháp tắt khi viết code để đạt được mục tiêu nhanh hơn. Tuy nhiên, chất lượng code giảm sẽ làm giảm nỗ lực phát triển dài hạn của một dự án bằng khiến cho dự án khó hiểu, khó bảo trì và mở rộng hơn.
Có thể cải thiện chất lượng code thế nào, điều cần thiết là các developers phải duy trì một tiêu chuẩn cao cho code của họ. Một số các các chiến lược sau có thể :
- Xây dựng các Tiêu chí chấp nhận của người dùng (User LVN Groupeptance Criteria) để các bên liên quan xác nhận dự án đạt tiêu chuẩn;
- Đánh giá code;
- Các tiêu chuẩn và hướng dẫn lập trình rõ ràng;
- Kiểm tra tất cả các code;
- Chỉ định một Giám đốc sản xuất chuyên trách để giám sát chất lượng của dự án và nắm quyền sở hữu đối với tất cả các bên liên quan về sự thành công và thất bại; và
- Chú ý Way of Working (đã đề cập bên trên).
6. Năng suất kém
Khi một nhóm dự án bị tụt lại so với kế hoạch về thời gian, bạn có thể cần phải kiểm tra năng suất của nhóm phát triển. Mặc dù không chắc, nhưng năng suất kém có thể là nguyên nhân.
Làm cách nào để bạn đo lường năng suất của nhà phát triển? Để xác định mức năng suất của nhóm phát triển, bạn có thể sử dụng các công cụ như biểu đồ ghi lại hoặc báo cáo lặp lại.
Nếu công ty của bạn đã trải qua một quy trình tuyển dụng tử tế, ít có khả năng bạn sẽ phải đối mặt với rủi ro này. Tuy nhiên nếu điều này xảy ra có thể gây bất lợi cho việc thực hiện thành công dự án.
Do đó, rất có giá trị khi xem xét các chiến lược sau:
- Văn hóa con người của công ty bạn;
- Lên kế hoạch thời gian có thể đạt được trong dài hạn để tránh tình trạng kiệt sức của chuyên viên; và
- Tìm một Giám đốc sản phẩm tham gia trực tiếp và cộng tác với nhóm.
Điều cần thiết cần nhớ là con người không phải là máy móc và do đó, việc kỳ vọng họ công tác hiệu quả mỗi giờ tại nơi công tác là không thực tiễn.
7. Quản lý rủi ro không trọn vẹn
Quản lý rủi ro không trọn vẹn có thể xảy ra khi bất kỳ rủi ro cụ thể nào của dự án phần mềm không được các bên liên quan nhận biết và giảm thiểu (mitigate) một cách thích hợp.
Quản lý rủi ro trọn vẹn cho một dự án phát triển phần mềm là gì? Con đường để quản lý rủi ro thích hợp bắt đầu với việc dành thời gian đầu tiên để thừa nhận rằng rủi ro tồn tại. Chiến lược đà điểu vùi đầu vào cát và giả vờ rằng bạn có thể gửi tới phần mềm mà không phải đối mặt với bất kỳ vấn đề nào trong số này sẽ chỉ gây ra căng thẳng lâu dài.
Một giải pháp tốt hơn là xem xét các chiến lược giảm thiểu ngay từ đầu và liên tục đánh giá trong suốt dự án phần mềm. Có rất nhiều rủi ro khi xây dựng phần mềm, và nếu rủi ro được xác định một cách hiệu quả thì nó có thể được giảm thiểu.
Một số chiến lược giúp giảm thiểu các rủi ro dự án phần mềm bao gồm:
- Đưa các rủi ro vào trong ước lượng; và
- Sử dụng Sổ đăng ký rủi ro (Risk Register) để quản lý các rủi ro của dự án.
Điều cần thiết là bạn phải xác định những rủi ro cụ thể cho dự án và đặt ra các phương pháp để giảm thiểu chúng ngay từ đầu dự án của bạn. Để giúp xác định tác động của một rủi ro cụ thể có thể có đối với dự án phần mềm, bạn có thể sử dụng ma trận rủi ro (risk matrix). Để xác định những rủi ro lớn nhất trong dự án của bạn, bạn sẽ cần phải xác định tác động ( impact) và khả năng rủi ro (likelihood) sẽ xảy ra.
8. Ít có sự tham gia của các bên liên quan
Mức độ tham gia của các bên liên quan thấp nghĩa là gì? Là khi khách hàng hoặc bên liên quan mà bạn đang cộng tác không tham gia với nhóm của bạn ở tần suất cần thiết. Việc ít tham gia của các bên liên quan là một rủi ro đáng kể đối với các dự án vì phản hồi chậm từ khách hàng có thể ảnh hưởng đến kế hoạch ra mắt sản phẩm.
Rủi ro do việc ít tham gia của các bên liên quan càng tăng lên khi triển khai các phương pháp agile. Lý do là các lần lặp lại (iterations) được phân phối thường xuyên hơn và vì vậy cần có phản hồi thường xuyên hơn từ các bên liên quan cho nhóm phát triển.
Làm thế nào để cải thiện sự tham gia của các bên liên quan? Một số chiến lược giảm thiểu có thể được xem xét bao gồm:
- Thỏa thuận rõ ràng với khách hàng hoặc các bên liên quan về thời gian phản hồi, đặc biệt đối với bất kỳ Thử nghiệm chấp nhận người dùng (User LVN Groupeptance Testing) nào; và
- Lựa chọn hiệu quả việc hoàn thành và các mục tiêu của dự án.
9. Nguồn nhân lực không đủ
Mặc dù không chắc chắn, nhưng đôi khi một bên liên quan hoặc thành viên nhóm phát triển phải rời khỏi dự án một cách đột xuất. Điều này có thể tạo ra rủi ro cho dự án, đặc biệt nếu kiến thức về dự án không được ghi chép trọn vẹn.
Làm thế nào để bạn giảm rủi ro này? Một có chiến lược bạn có thể xem xét:
- Duy trì cập nhật tài liệu;
- Cung cấp các tài liệu hướng dẫn trọn vẹn cho người mới tham gia; và
- Theo dõi lịch trình công tác của nhóm một cách thường xuyên.
10. Thiếu quyền sở hữu
Tại sao ý thức sở hữu lại cần thiết đối với việc phát triển phần mềm? Quyền sở hữu phần mềm là cần thiết để đảm bảo luôn có người trong nhóm chịu trách nhiệm về phần mềm được chuyển giao và chịu trách nhiệm về những thành công và thất bại.
Thật không may, rủi ro này thường chỉ trở nên rõ ràng khi có sự cố xảy ra trong một dự án. Do đó, ngay từ đầu phải xác định rõ ai là người chịu trách nhiệm về những khía cạnh nào của dự án và khi nào thì dự án sẽ được chuyển giao.
Làm thế nào để bạn tránh được rủi ro này? Một số chiến lược có thể bao gồm:
- Đặt ra trách nhiệm cho các bên liên quan;
- Thiết lập các kênh liên lạc rõ ràng giữa các bên liên quan với sự minh bạch và trung thực;
- Ghi lại các cuộc họp và các mục hành động có thể phát sinh; và
- Đảm bảo Tiêu chí chấp nhận của người dùng (User LVN Groupeptance Criteria) được hoàn thành và được phê duyệt bởi Người quản lý sản phẩm.
Mặc dù những lí do nêu trên không bao hàm tất cả các rủi ro có thể xảy ra đối với dự án phần mềm, nhưng nó bao gồm một số rủi ro có thể ảnh hưởng lớn đến dự án mà bạn cần phải chú ý để quản lý ngay từ ban đầu. Xác định và quản lý rủi ro là những phần cần thiết đối với sự thành công của bất kỳ dự án phần mềm nào.