Hỏi về risk của các dự án phần mềm làm lâu năm?

[Do_Tung_Lam (Đỗ Tùng Lâm)]

Em chào mọi người, hiện em đang làm trong dự án phần mềm quản lý cảng biển với công việc ngày qua ngày là maintain và implement các yêu cầu từ khách hàng, dự án này đã được 3 năm? Thì với những dự án lâu như vậy, khối lượng bussiness càng tăng lên, các anh chị có kinh nhiệm chinh chiến các dự án lớn lâu năm cho em hỏi là các risk của những dự án lớn lâu năm là gì? Em cám ơn

[thaipt (Thai Pham)]

Đây là một số khó khăn trong các dự án mà tôi đã làm việc qua:

• Cân bằng giữa phát triển và bảo trì: đây là một trong những vấn đề tranh cãi thường xuyên giữa đội ngũ kỹ thuật và đội ngũ kinh doanh. Đội ngũ kỹ thuật luôn muốn dành nhiều thời gian để hoàn thiện các chức năng của phần mềm, sửa lỗi, vv… Trong khi đội ngũ kinh doanh lại muốn dùng thời gian này để phát triển các tính năng mới để hấp dẫn khách hàng. Nếu các nhà quản lý không am hiểu kỹ thuật, họ sẽ ủng hộ phe kinh doanh, lâu ngày sẽ dẫn đến các mâu thuẫn trong nội bộ và ảnh hưởng đến chất lượng sản phẩm.
• Lỗ hổng về kiến thức: Vấn đề này thường xảy ra do một số nhân viên quan trọng rời nhóm phát triển, dự án hoặc công ty. Điều này thường kéo theo việc một số hiểu biết quan trọng về hệ thống bị mất và không bao giờ được chuyển giao cho những nhân viên còn lại. Vì vậy, nếu có các vấn đề phát sinh liên quan đến các kiến thức này, bạn sẽ gặp rắc rối vì không thể đưa ra các dự đoán chính xác về thời gian cũng như nhân sự cần có để khắc phục dựa trên các số liệu trong quá khứ.
• Các vấn đề kỹ thuật còn tồn đọng trong dự án (Technical debt): Thường thì trong các dự án lớn, thế nào cũng có một số vấn đề cần được sữa chữa và khắc phục. Các vấn đề này phát sinh vì khi dự án còn trong quá trình phát triển, đội ngũ phát triển không có đủ thời gian để tạo ra thiết kế hoặc mã nguồn hoàn chỉnh và chấp nhận các thiết kế cũng như mã nguồn “tạm được” với hy vọng sẽ trở lại và sửa sau khi dự án hoàn thành. Nhưng thực tế là hầu như việc này không xảy ra. Vì vậy, các vấn đề này cứ còn lại trong hệ thống cho đến khi nó phát sinh ra các lỗi trong một số trường hợp. Và nếu là trường hợp nghiêm trọng, có khi bạn sẽ là người “lãnh đạn” với vai trò là quản lý dự án.
• Mã nguồn cũ (legacy code): Thường các dự án lớn sẽ phải làm việc với một số thành phần (component) từ các dự án trước đó được biết đến như là các thành phần hay mã cũ (legacy). Các thành phần này có thể ảnh hưởng hoặc gây hạn chế rất nhiều cho việc mở rộng dự án, thêm các chức năng mới và đôi khi gây khó khăn rất lớn vì bạn không thể thay đổi hoặc thuyết phục các cá nhân hoặc công ty chịu trách nhiệm và phát triển chúng thay đổi theo nhu cầu của dự án của bạn.
• Mã nguồn tồi và không có tài liệu kèm theo: Thường thì vấn đề này liên quan đến nhóm lập trình viên và các trưởng nhóm lập trình nhiều hơn. Nhưng nó sẽ gây khó khăn cho bạn khi phải làm việc với họ để có các số liệu chính xác trong việc lên kế hoạch cũng như tạo ra các bản báo cáo đầy đủ.
• Thiết kế thiếu khả năng mở rộng (Scalable): Vấn đề này cũng không liên quan trực tiếp với bạn, nó liên quan với bên kỹ thuật, đặc biệt là nhóm thiết kế hay kiến trúc phần mềm (architecture). Tuy nhiên, bạn cũng phải nắm được vấn đề để làm việc với bộ phận kỹ thuật và các stakeholders trong trường hợp sản phẩm không đáp ứng được nhu cầu khi số người sử dụng hoặc độ phức tạp của phần mềm gia tăng.
• Các vấn đề bảo mật: Đây cũng là phần liên quan đến kỹ thuật nhiều hơn là chức năng của bạn. Tuy nhiên nó sẽ ảnh hưởng đến tiến độ dự án cũng như tiếng tăm của công ty nếu phần mềm được phát triển có tính năng bảo mật yếu hoặc không có. Bạn sẽ phải cân nhắc để xem cần bao nhiêu thời gian để xử lý các vấn đề bảo mật.
• Tiến độ (Progress) cũng như lộ trình phát hành (Road map): các stakeholders thường chỉ muốn sản phẩm được cập nhật càng nhanh càng tốt. Họ không hiểu và cũng không quan tâm đến tầm quan trọng của việc thiết kế và thi công. Thường các công đoạn này đòi hỏi sự cẩn trọng và chiếm một lượng lớn trong thời gian phát triển nhưng lại không kết thúc với một sản phẩm cụ thể mà họ có thể nhìn thấy. Vì vậy, bạn phải thuyết phục được họ hoặc đưa ra tiến trình hợp lý để đảm bảo đội ngũ kỹ thuật có đủ thời gian thiết kế và thi công, còn stakeholder cũng không phiền lòng.
• Yêu cầu thay đổi trong thời gian thực hiện dự án (scope creep): các stakeholders hoặc chính đội ngũ phát triển hay có khuynh hướng thay đổi các yêu cầu và thiết kế trong quá trình thực hiện dự án. Điều này có thể chấp nhận được với các dự án nhỏ, nhưng với các dự án lớn thì không thể. Do đó, bạn phải lên kế hoạch chi tiết và cho các bên liên quan xác nhận (sign off) tầm vực (scope) trước khi dự án được triển khai để họ không thể thay đổi tùy tiện.

Thật ra tổng kết lại thì các vấn đề về quản lý dự án dù lớn hay nhỏ cũng chỉ gói gọn trong việc cân bằng giữa thời gian (time), chi phí (cost) và chất lượng (quality) thôi.