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ò quan trọng 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 quan trọng 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 làm việ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 Uncertainty) 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 quan trọng.
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 quan trọng 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 hay 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 như 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 nlinh hoạt (agile development).
Việc tương tác của người dùng cuối kém có khả năng xảy ra cao hơn trong các dự án theo phương pháp thác nước. Điều này là do các loại dự án này không thể thích ứng với phản hồi của người dùng cuối trong quá trình phát triển. Bản chất của phát triển thác nước không chấp nhận sự thay đổi về phạm vi.
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 ra, 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 như 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 quan trọng;
- Đả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.
Bạn có thể cải thiện chất lượng code như thế nào? Điều quan trọng 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 Acceptance 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 phẩm 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 nhâ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 quan trọng cần nhớ là con người không phải là máy móc và do đó, việc kỳ vọng họ làm việc hiệu quả mỗi giờ tại nơi làm việc là không thực tế.
7. Quản lý rủi ro không đầy đủ
Quản lý rủi ro không đầy đủ 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 đầy đủ 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ể cung cấp 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 quan trọng 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 Acceptance 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 đầy đủ.
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 đầy đủ cho người mới tham gia; và
- Theo dõi lịch trình làm việ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 quan trọng đối với việc phát triển phần mềm? Quyền sở hữu phần mềm là quan trọng để đả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 Acceptance Criteria) được hoàn thành và được phê duyệt bởi người quản lý sản phẩm.
Kết luận
Mặc dù danh sách này không bao hàm tất cả các rủi ro có thể xảy ra đối với dự án phầm 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 quan trọng đối với sự thành công của bất kỳ dự án phần mềm nào.
Bài của tác giả Mikaela Robertson đăng trên codebots.com
