Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ

Mục lục

Đánh giá post

Chia sẻ chuyên mục Đề Tài Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ hay nhất năm 2026 cho các bạn học viên ngành đang làm luận văn thạc sĩ tham khảo nhé. Với những bạn chuẩn bị làm bài luận văn tốt nghiệp thì rất khó để có thể tìm hiểu được một đề tài hay, đặc biệt là các bạn học viên đang chuẩn bị bước vào thời gian lựa chọn đề tài làm luận văn thì với đề tài Luận Văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ theo phương pháp Agile/DevOps dưới đây chắc chắn sẽ giúp cho các bạn học viên có cái nhìn tổng quan hơn về đề tài sắp đến.

3.1 Cơ sở đề ra giải pháp

Các giải pháp được xây dựng từ bốn hạn chế đã xác định tại Chương 2, thay vì xuất phát từ xu hướng công nghệ chung. Agile/DevOps đã tạo tác động tích cực đến khả năng phản hồi, tiến độ và hiệu quả quản trị dự án, thể hiện qua giá trị trung bình của nhóm hiệu quả đạt 3,91 và tỷ lệ đồng thuận 73,2%. Kết quả này cho thấy doanh nghiệp không cần thay thế toàn bộ phương thức hiện tại mà cần xử lý những điểm nghẽn làm hiệu quả chênh lệch giữa các dự án.

Hạn chế nổi bật nhất thuộc về tự động hóa và năng lực nền tảng, với giá trị trung bình 3,86 và tỷ lệ đồng thuận 70,9%. Các nhóm dự án còn tự xây dựng quy trình tích hợp và triển khai theo cách riêng, kiểm thử tự động chưa đủ rộng, một số công đoạn vẫn phụ thuộc vào thao tác thủ công. Đáng chú ý, 78,3% người trả lời cho rằng công việc phát triển nền tảng và tự động hóa thường bị ưu tiên thấp hơn tính năng nghiệp vụ. Vấn đề vì vậy không nằm ở việc thiếu công cụ riêng lẻ mà ở cách phân bổ nguồn lực và thiếu các thành phần kỹ thuật dùng chung.

Xung đột giữa tốc độ triển khai với bảo mật và tuân thủ đạt giá trị trung bình 3,86, với tỷ lệ đồng thuận 70,6%. Trong đó, 78,4% người trả lời ghi nhận khó khăn khi phải đồng thời triển khai nhanh và bảo đảm an toàn. Các bước kiểm soát thực hiện muộn làm tăng công việc sửa đổi và kéo dài thời gian phát hành. Giải pháp cần chuyển bảo mật từ khâu phê duyệt cuối chu kỳ thành một phần của yêu cầu, thiết kế, kiểm thử và quy trình triển khai.

Mức độ trưởng thành Agile/DevOps chưa đồng đều đạt giá trị trung bình 3,83 và tỷ lệ đồng thuận 69,6%. Hiệu quả vẫn phụ thuộc đáng kể vào năng lực của từng nhóm hoặc cá nhân chủ chốt, trong khi tiêu chí đánh giá và chỉ số quản trị chưa được chuẩn hóa. Hạn chế này khiến doanh nghiệp khó xác định dự án cần hỗ trợ, so sánh kết quả hoặc nhân rộng các cách làm hiệu quả.

Quan hệ phụ thuộc và phối hợp đa nhóm đạt giá trị trung bình 3,69, với tỷ lệ đồng thuận 63,5%. Tuy thấp hơn ba nhóm còn lại, đây vẫn là điểm nghẽn trực tiếp đối với tiến độ. Công việc thường phải chờ giao diện lập trình, dữ liệu, môi trường, kiểm thử hoặc phê duyệt từ nhóm khác. Việc tối ưu hiệu suất của từng nhóm không giải quyết được vấn đề nếu toàn bộ luồng công việc vẫn bị gián đoạn tại các điểm bàn giao.

Khả năng triển khai giải pháp được hỗ trợ bởi nền tảng văn hóa và chuyên môn hiện có. Nhóm điều kiện tổ chức đạt giá trị trung bình 3,86 và tỷ lệ đồng thuận 70,0%, hoạt động chia sẻ trong các cộng đồng chuyên môn nhận được mức đồng thuận 87,6%. Tuy nhiên, chỉ 56,4% đánh giá nhóm dự án được trao quyền phù hợp để cải tiến quy trình và công cụ. Vì vậy, giải pháp kỹ thuật sẽ khó tạo kết quả nếu không đi kèm quyền quyết định, thời gian cải tiến và trách nhiệm rõ ràng.

Dựa trên các hạn chế trên tác giả đã đề xuất các nhóm giải pháp tương ứng và đưa ra khảo sát đến các nhân viên trong công ty.

Bảng 3.1 Mức độ đồng thuận đối với các nhóm giải pháp đề xuất

Kết quả khảo sát về các phương án đề xuất cho thấy cả bốn nhóm giải pháp đều nhận được mức đồng thuận cao. Giải pháp quản trị quan hệ phụ thuộc và tổ chức theo định hướng sản phẩm đạt giá trị trung bình 4,29, mô hình trưởng thành Agile/DevOps đạt 4,26, DevSecOps đạt 4,22, chuẩn hóa quy trình tích hợp, triển khai và kỹ thuật nền tảng đạt 4,19. Những kết quả này phản ánh mức độ chấp nhận của người tham gia khảo sát, nhưng chưa chứng minh hiệu quả thực tế. Tác động của từng giải pháp phải được kiểm chứng bằng thí điểm và các chỉ số đo lường sau triển khai.

Bảng 3.2. Liên kết giữa hạn chế và giải pháp đề xuất

Việc triển khai phải tuân theo bốn nguyên tắc. Giải pháp phải xử lý trực tiếp nguyên nhân đã xác định, được điều chỉnh theo mức độ rủi ro của từng dự án, triển khai thí điểm trước khi mở rộng, và được đánh giá bằng dữ liệu thay vì nhận định chủ quan. Các chỉ số theo dõi gồm mức độ dự báo chính xác của chu kỳ phát triển, thời gian xử lý thay đổi, tần suất triển khai, tỷ lệ thay đổi gây lỗi, thời gian khôi phục, tỷ lệ bao phủ kiểm thử tự động, số điểm nghẽn do phụ thuộc và tỷ lệ vượt qua cổng kiểm soát bảo mật.

3.2 Giải pháp 1: Chuẩn hóa mô hình mức độ trưởng thành Agile/DevOps Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Giải pháp này xử lý trực tiếp tình trạng mức độ áp dụng Agile/DevOps khác nhau giữa các dự án. Nhóm hạn chế MAT đạt giá trị trung bình 3,83 và tỷ lệ đồng thuận 69,6%, trong khi giải pháp xây dựng mô hình đánh giá thống nhất đạt giá trị trung bình 4,26 và tỷ lệ đồng thuận 86,4%. Kết quả cho thấy nhu cầu chuẩn hóa không xuất phát từ thiếu công cụ, mà từ việc doanh nghiệp chưa có cùng một hệ quy chiếu để đánh giá, so sánh và cải tiến dự án.

Mô hình đề xuất không nhằm buộc mọi dự án vận hành giống nhau. Dự án tài chính có yêu cầu bảo mật cao không thể áp dụng cùng cơ chế với dự án thử nghiệm sản phẩm hoặc bảo trì hệ thống. Mục tiêu là thống nhất tiêu chí đánh giá, còn cách đạt tiêu chí được điều chỉnh theo quy mô, kiến trúc và mức độ rủi ro của từng dự án.

Nội dung mô hình đề xuất

Mô hình đánh giá gồm năm nhóm năng lực:

Quản trị Agile: chất lượng danh sách công việc ưu tiên, lập kế hoạch chu kỳ phát triển, khả năng dự báo và cơ chế phản hồi.
Phối hợp và luồng công việc: quyền tự chủ của nhóm, số lần bàn giao và khả năng xử lý quan hệ phụ thuộc.
Tự động hóa kỹ thuật: tích hợp mã nguồn, kiểm thử tự động, triển khai và tính đồng nhất của môi trường.
Bảo mật và vận hành: kiểm soát bảo mật, giám sát, ghi nhật ký, truy vết và khả năng khôi phục sự cố.
Đo lường và cải tiến: sử dụng dữ liệu để nhận diện điểm nghẽn, ưu tiên đầu tư và đánh giá kết quả cải tiến.

Mỗi nhóm năng lực được đánh giá theo bốn cấp độ: Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Bảng 3.3. Mô hình mức độ trưởng thành Agile/DevOps tại Endava Việt Nam

Việc xếp cấp không nên dựa trên điểm trung bình đơn thuần. Một dự án có quy trình Agile tốt nhưng kiểm thử, bảo mật hoặc triển khai còn thủ công chưa thể được xem là đã đạt mức tích hợp. Dự án chỉ được công nhận ở một cấp độ khi đáp ứng điều kiện tối thiểu của cả năm nhóm năng lực. Cách đánh giá này ngăn kết quả tích cực ở một khía cạnh che khuất điểm yếu có thể gây rủi ro cho toàn bộ dự án.

Kết quả đánh giá cũng không được sử dụng để xếp hạng nhân sự hoặc quy trách nhiệm. Mô hình phải trả lời ba câu hỏi quản trị: dự án đang ở mức nào, điểm nghẽn nằm ở đâu, nguồn lực cải tiến cần được ưu tiên cho nội dung nào.

Kế hoạch thực hiện

Trong tháng đầu tiên, Endava Việt Nam cần thành lập nhóm xây dựng mô hình gồm đại diện quản lý dự án, chuyên gia Agile, trưởng nhóm kỹ thuật, DevOps, kiểm thử và bảo mật. Nhóm này thống nhất định nghĩa chỉ tiêu, nguồn dữ liệu, cách chấm điểm và bằng chứng cần sử dụng. Các tiêu chí phải đủ rõ để hai người đánh giá độc lập không đưa ra kết quả chênh lệch lớn.

Giai đoạn tháng thứ hai và thứ ba tập trung thí điểm tại một số dự án có đặc điểm khác nhau, gồm dự án phát triển mới, bảo trì hệ thống và dự án có yêu cầu tuân thủ cao. Việc lựa chọn mẫu đa dạng giúp kiểm tra liệu mô hình có phản ánh đúng khác biệt thực tế hay chỉ phù hợp với một loại dự án.

Dữ liệu đánh giá được lấy trực tiếp từ Jira, Azure DevOps, hệ thống quản lý mã nguồn, công cụ tích hợp và triển khai, kiểm thử và giám sát. Phỏng vấn hoặc tự đánh giá chỉ dùng để bổ sung những nội dung chưa thể đo tự động như quyền tự chủ, chất lượng phối hợp và cách xử lý sai sót. Cách kết hợp này giảm phụ thuộc vào nhận định chủ quan.

Trong tháng thứ tư, nhóm phụ trách đối chiếu kết quả giữa các dự án, điều chỉnh tiêu chí chưa phù hợp và xác định mức chuẩn ban đầu. Mỗi dự án phải có một kế hoạch cải tiến ngắn, tập trung vào tối đa hai hoặc ba điểm nghẽn quan trọng. Việc yêu cầu cải tiến quá nhiều nội dung cùng lúc sẽ phân tán nguồn lực và khó xác định tác động.

Tháng thứ năm và thứ sáu được sử dụng để hoàn thiện bảng điều khiển theo dõi, đào tạo người phụ trách và đưa đánh giá vào chu kỳ quản trị hằng quý. Dự án có mức độ trưởng thành thấp được ưu tiên hỗ trợ về chuyên gia, đào tạo hoặc nền tảng kỹ thuật. Dự án đạt cấp độ cao được lựa chọn làm mô hình tham chiếu, nhưng chỉ nhân rộng những thực hành đã chứng minh được hiệu quả bằng dữ liệu. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Đối tượng triển khai

Bộ phận quản trị dự án hoặc nhóm quản trị Agile chịu trách nhiệm xây dựng tiêu chí, điều phối đánh giá và tổng hợp kết quả ở cấp tổ chức. Quản lý hoạt động triển khai chịu trách nhiệm sử dụng kết quả để xác định ưu tiên cải tiến, phân bổ nguồn lực và kiểm soát rủi ro trong danh mục dự án.

Chuyên gia Agile, trưởng nhóm kỹ thuật, trưởng nhóm DevOps và kiểm thử tham gia đánh giá thực trạng và xác định nguyên nhân của từng điểm yếu. Nhóm dự án trực tiếp cung cấp dữ liệu, kiểm chứng kết quả và thực hiện kế hoạch cải tiến. Sự tham gia của nhóm thực thi giúp mô hình tránh trở thành một thủ tục kiểm tra từ cấp quản lý.

Ban đầu chỉ nên áp dụng tại các dự án đang sử dụng Agile/DevOps hoặc mô hình kết hợp. Sau khi tiêu chí ổn định, phạm vi mới được mở rộng sang các dự án khác. Cách triển khai từng bước giảm chi phí điều chỉnh và tránh tạo thêm gánh nặng báo cáo.

Nguồn lực thực hiện

Nguồn lực chính là dữ liệu sẵn có từ hệ thống quản trị công việc, mã nguồn, kiểm thử, triển khai và vận hành. Doanh nghiệp không nên xây dựng thêm báo cáo thủ công nếu dữ liệu có thể được trích xuất tự động.

Nhân sự thực hiện gồm chuyên gia quản trị dự án, Agile, DevOps, kiểm thử, bảo mật và phân tích dữ liệu. Nhóm phụ trách cần đủ năng lực đánh giá cả quy trình quản trị lẫn kết quả kỹ thuật, nếu chỉ tập trung vào nghi thức Agile hoặc số lượng công cụ, mô hình sẽ không phản ánh hiệu quả thực chất.

Doanh nghiệp cần dành ngân sách cho việc xây dựng bảng điều khiển, đào tạo nhóm có mức độ trưởng thành thấp và tài liệu hóa thực hành tốt. Nguồn lực cải tiến phải được đưa vào kế hoạch dự án. Nếu chỉ yêu cầu nâng cấp nhưng không dành thời gian và nhân sự, mô hình sẽ dừng ở hoạt động chấm điểm. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Chỉ tiêu theo dõi và kết quả kỳ vọng

Trong sáu tháng đầu, mục tiêu đề xuất gồm:

Toàn bộ dự án thí điểm có hồ sơ đánh giá và kế hoạch cải tiến được phê duyệt.
Phần lớn chỉ tiêu cốt lõi được thu thập tự động thay vì lập báo cáo thủ công.
Mỗi dự án cấp thấp xử lý ít nhất một điểm nghẽn có tác động trực tiếp đến tiến độ hoặc chất lượng.
Kết quả đánh giá được sử dụng trong quyết định đào tạo, hỗ trợ chuyên gia và ưu tiên đầu tư.

Hiệu quả của giải pháp được theo dõi qua mức độ dự báo chính xác của chu kỳ phát triển, thời gian xử lý thay đổi, tần suất triển khai, tỷ lệ thay đổi gây lỗi và thời gian khôi phục sau sự cố. Mức độ trưởng thành tăng chỉ có ý nghĩa khi các chỉ tiêu vận hành được cải thiện, việc hoàn thành thêm nghi thức hoặc sử dụng thêm công cụ không được xem là kết quả cuối cùng.

Kỳ vọng chính của giải pháp là giảm chênh lệch năng lực giữa các dự án, hạn chế phụ thuộc vào cá nhân chủ chốt và tạo căn cứ minh bạch cho phân bổ nguồn lực. Mô hình cũng cung cấp dữ liệu nền để triển khai ba giải pháp tiếp theo về DevSecOps, quản trị quan hệ phụ thuộc và kỹ thuật nền tảng.

Bảng 3.4. Tóm tắt triển khai giải pháp chuẩn hóa mức độ trưởng thành Agile/DevOps

3.3 Giải pháp 2: Tích hợp bảo mật và tuân thủ theo DevSecOps

Giải pháp này xử lý tình trạng các yêu cầu bảo mật thường được kiểm tra muộn, làm tăng thời gian sửa lỗi và kéo dài phê duyệt trước khi phát hành. Nhóm hạn chế về bảo mật và tuân thủ đạt giá trị trung bình 3,86, với 70,6% người khảo sát đồng thuận. Trong đó, khó khăn khi cân bằng giữa tốc độ triển khai và an toàn hệ thống đạt mức đánh giá cao nhất. Điều này cho thấy điểm nghẽn không nằm ở yêu cầu kiểm soát, mà ở cách bảo mật đang được tách khỏi quá trình phát triển.

DevSecOps cần được áp dụng theo nguyên tắc đưa bảo mật vào toàn bộ vòng đời sản phẩm, từ xác định yêu cầu, thiết kế, lập trình, kiểm thử đến triển khai và vận hành. Mục tiêu không phải bổ sung thêm một lớp kiểm tra, mà phát hiện rủi ro sớm và tự động hóa những kiểm soát có thể lặp lại. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Nội dung giải pháp

Trước hết, yêu cầu bảo mật và tuân thủ phải được chuyển thành điều kiện cụ thể trong danh sách công việc ưu tiên. Mỗi tính năng liên quan đến dữ liệu, phân quyền, giao dịch hoặc kết nối hệ thống phải xác định rõ tiêu chí bảo mật ngay khi lập kế hoạch. Cách làm này hạn chế tình trạng chức năng đã hoàn thiện nhưng không vượt qua bước kiểm tra cuối chu kỳ.

Tiêu chuẩn hoàn thành cần bổ sung các điều kiện về an toàn mã nguồn, thư viện sử dụng, quyền truy cập, bảo vệ dữ liệu và khả năng truy vết. Một tính năng chỉ được xem là hoàn tất khi đáp ứng đồng thời yêu cầu nghiệp vụ, kỹ thuật và bảo mật. Điều này làm rõ trách nhiệm của nhóm phát triển thay vì chuyển toàn bộ rủi ro sang bộ phận bảo mật.

Các kiểm tra có tính lặp lại cần được tích hợp vào quy trình tự động, gồm:

Phân tích mã nguồn để phát hiện điểm yếu bảo mật.
Kiểm tra thư viện và thành phần phụ thuộc.
Quét thông tin bí mật bị đưa nhầm vào mã nguồn.
Kiểm tra cấu hình hạ tầng và môi trường.
Kiểm thử bảo mật ứng dụng trong môi trường thử nghiệm.
Kiểm tra điều kiện tuân thủ trước khi triển

Mỗi mức rủi ro cần có cơ chế xử lý khác nhau. Lỗi nghiêm trọng phải chặn triển khai, lỗi trung bình cần được xử lý trong thời hạn xác định, lỗi thấp có thể đưa vào danh sách cải tiến nếu không ảnh hưởng trực tiếp đến hệ thống. Việc chặn mọi phát hiện mà không phân loại sẽ làm quy trình chậm và khiến nhóm tìm cách bỏ qua công cụ.

Các dự án có yêu cầu tuân thủ cao cần duy trì bằng chứng tự động về quá trình kiểm tra, kết quả phê duyệt và lịch sử thay đổi. Dữ liệu này phục vụ kiểm toán mà không buộc nhóm lập lại báo cáo thủ công sau mỗi đợt phát hành.

Kế hoạch thực hiện

Trong tháng đầu, doanh nghiệp cần xây dựng bộ yêu cầu bảo mật tối thiểu theo từng loại dự án. Dự án xử lý dữ liệu tài chính, thông tin cá nhân hoặc giao dịch phải áp dụng mức kiểm soát cao hơn dự án thử nghiệm nội bộ. Cách phân loại theo rủi ro giúp tránh áp dụng cùng một quy trình nặng cho mọi trường hợp. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Tháng thứ hai tập trung lựa chọn công cụ và xác định vị trí kiểm tra trong quy trình phát triển. Các bước kiểm tra nhanh được thực hiện khi lập trình viên gửi thay đổi mã nguồn. Kiểm tra chuyên sâu được thực hiện tại môi trường tích hợp hoặc trước khi phát hành. Việc bố trí đúng thời điểm giúp phát hiện lỗi sớm mà không làm chậm mọi lần cập nhật.

Trong tháng thứ ba và thứ tư, giải pháp được thí điểm tại một dự án có yêu cầu bảo mật cao và một dự án có quy trình triển khai tương đối ổn định. Nhóm phụ trách đo thời gian kiểm tra, số lỗi phát hiện, tỷ lệ cảnh báo sai và số lần triển khai bị chặn. Kết quả thí điểm dùng để điều chỉnh ngưỡng kiểm soát trước khi mở rộng.

Tháng thứ năm tập trung chuẩn hóa mẫu quy trình, tiêu chí bảo mật và hướng dẫn xử lý lỗi. Các cấu hình đã kiểm chứng cần được đưa vào kho dùng chung để dự án mới có thể sử dụng ngay, thay vì tự thiết lập lại.

Từ tháng thứ sáu, DevSecOps được mở rộng theo mức độ rủi ro và khả năng sẵn sàng của từng dự án. Việc mở rộng phải gắn với kết quả đánh giá mức độ trưởng thành tại Giải pháp 1, tránh triển khai công cụ bảo mật tự động trên quy trình kỹ thuật chưa ổn định.

Đối tượng triển khai

Nhóm bảo mật chịu trách nhiệm xây dựng tiêu chuẩn, phân loại rủi ro và xác định điều kiện bắt buộc. Vai trò của nhóm này chuyển từ kiểm tra cuối chu kỳ sang tư vấn, thiết kế kiểm soát và xử lý các trường hợp phức tạp.

Lập trình viên chịu trách nhiệm khắc phục lỗi trong mã nguồn và thư viện sử dụng. Nhóm kiểm thử bổ sung các tình huống kiểm tra liên quan đến xác thực, phân quyền và bảo vệ dữ liệu. Kỹ sư DevOps tích hợp công cụ bảo mật vào quy trình tự động, quản lý cấu hình và bảo vệ thông tin bí mật.

Quản lý dự án hoặc quản lý hoạt động triển khai chịu trách nhiệm đưa công việc bảo mật vào kế hoạch, thay vì xem đây là phần phát sinh ngoài phạm vi. Chủ sở hữu sản phẩm phải cân đối giữa tính năng nghiệp vụ và yêu cầu an toàn, đặc biệt khi rủi ro có thể ảnh hưởng đến khách hàng hoặc nghĩa vụ pháp lý.

Mỗi dự án nên có một thành viên kỹ thuật làm đầu mối bảo mật. Người này không thay thế chuyên gia bảo mật mà hỗ trợ giải thích yêu cầu, theo dõi lỗi và duy trì thực hành an toàn trong nhóm.

Nguồn lực thực hiện Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Nguồn lực kỹ thuật gồm công cụ phân tích mã nguồn, kiểm tra thư viện phụ thuộc, quét cấu hình, quản lý thông tin bí mật và kiểm thử bảo mật ứng dụng. Doanh nghiệp nên ưu tiên tích hợp công cụ vào nền tảng hiện có thay vì tạo thêm hệ thống báo cáo tách biệt.

Nguồn lực con người gồm chuyên gia bảo mật, DevOps, kiến trúc sư, lập trình viên và kiểm thử. Các nhóm cần được đào tạo theo vai trò. Lập trình viên cần biết cách phòng tránh và sửa lỗi phổ biến, DevOps cần bảo vệ quy trình triển khai, quản lý dự án cần hiểu tác động của rủi ro bảo mật đến phạm vi và tiến độ.

Ngân sách không chỉ dành cho giấy phép công cụ mà còn phải bao gồm thời gian xử lý lỗi, điều chỉnh quy trình và đào tạo. Nếu dự án chỉ đầu tư công cụ nhưng không phân bổ thời gian khắc phục, số lượng cảnh báo tăng sẽ tạo thêm điểm nghẽn thay vì giảm rủi ro.

Chỉ tiêu theo dõi và kết quả kỳ vọng

Hiệu quả giải pháp được đánh giá bằng tỷ lệ vượt qua cổng kiểm soát bảo mật ngay từ lần đầu, số lỗi phát hiện trước khi phát hành, thời gian xử lý lỗi và số sự cố bảo mật sau triển khai. Cần theo dõi thêm tỷ lệ kiểm tra được tự động hóa và thời gian trung bình dành cho bước phê duyệt.

Trong giai đoạn đầu, mục tiêu không nên là loại bỏ hoàn toàn lỗi bảo mật. Mục tiêu thực tế là chuyển phần lớn lỗi sang giai đoạn phát triển, giảm số trường hợp phát hiện sát thời điểm phát hành và rút ngắn thời gian phê duyệt.

Kết quả kỳ vọng gồm giảm công việc sửa lại cuối chu kỳ, tăng khả năng truy vết, hạn chế triển khai thay đổi có rủi ro cao và giảm xung đột giữa nhóm phát triển với nhóm bảo mật. Khi kiểm soát được tích hợp và tự động hóa, tốc độ triển khai có thể được duy trì mà không phải hạ thấp yêu cầu an toàn.

Bảng 3.5. Tóm tắt triển khai giải pháp DevSecOps

Giải pháp này chỉ tạo hiệu quả khi trách nhiệm bảo mật được phân bổ trong toàn nhóm. Nếu doanh nghiệp chỉ bổ sung công cụ nhưng vẫn giao toàn bộ việc kiểm soát cho một bộ phận ở cuối quy trình, điểm nghẽn cũ sẽ tiếp tục tồn tại.

3.4 Giải pháp 3: Tăng cường quản trị quan hệ phụ thuộc và tổ chức nhóm theo định hướng sản phẩm Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Giải pháp này xử lý tình trạng tiến độ toàn dự án bị chi phối bởi thời gian chờ giữa các nhóm. Nhóm hạn chế về quan hệ phụ thuộc đạt giá trị trung bình 3,69, với 63,5% người khảo sát đồng thuận. Giải pháp quản trị phụ thuộc và tổ chức theo định hướng sản phẩm đạt giá trị trung bình 4,29, cao nhất trong bốn nhóm giải pháp đề xuất. Kết quả cho thấy nhân sự không chỉ nhận diện vấn đề phối hợp mà còn đánh giá cao nhu cầu thay đổi cách tổ chức công việc.

Điểm nghẽn hiện tại không nằm hoàn toàn ở năng lực của từng nhóm. Một nhóm có thể hoàn thành nhiệm vụ đúng hạn nhưng tính năng vẫn chưa thể đưa vào sử dụng do phải chờ giao diện lập trình, dữ liệu, môi trường, kiểm thử hoặc phê duyệt từ đơn vị khác. Vì vậy, doanh nghiệp cần chuyển trọng tâm từ tối ưu hiệu suất từng bộ phận sang quản trị toàn bộ luồng công việc tạo ra giá trị cho khách hàng.

Nội dung giải pháp

Trước hết, các dự án cần xác định những quan hệ phụ thuộc có khả năng ảnh hưởng trực tiếp đến đợt phát hành. Mỗi phụ thuộc phải được ghi nhận trong hệ thống quản trị công việc, gồm nội dung cần bàn giao, nhóm cung cấp, nhóm tiếp nhận, thời hạn và người chịu trách nhiệm xử lý. Việc chỉ thảo luận phụ thuộc trong cuộc họp nhưng không theo dõi đến khi hoàn tất sẽ khiến điểm nghẽn lặp lại qua nhiều chu kỳ.

Các phụ thuộc quan trọng phải được nhận diện ngay khi lập kế hoạch, không chờ đến giai đoạn phát triển hoặc tích hợp. Nhóm dự án cần đánh giá liệu một tính năng có thể hoàn thành độc lập hay còn phụ thuộc vào hệ thống, môi trường và quyết định bên ngoài. Kết quả đánh giá được sử dụng để điều chỉnh thứ tự ưu tiên, chia nhỏ phạm vi hoặc bố trí nguồn lực xử lý sớm.

Danh sách công việc nên được xây dựng theo tính năng hoặc giá trị nghiệp vụ có thể hoàn thành trọn vẹn, thay vì chia tách hoàn toàn theo thành phần kỹ thuật. Một tính năng chỉ tạo ra giá trị khi các phần giao diện, xử lý phía máy chủ, dữ liệu, kiểm thử và triển khai được hoàn thành đồng bộ. Cách tổ chức này giảm số lần bàn giao và hạn chế tình trạng từng nhóm hoàn thành chỉ tiêu riêng nhưng kết quả chung vẫn chậm. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Các dự án có mức phụ thuộc cao cần tổ chức nhóm theo định hướng sản phẩm. Nhóm liên chức năng nên có đủ năng lực để thực hiện phần lớn công việc từ phân tích, phát triển, kiểm thử đến triển khai. Các chuyên gia bảo mật, dữ liệu hoặc điện toán đám mây có thể hỗ trợ nhiều nhóm, nhưng trách nhiệm tích hợp và đưa tính năng vào sử dụng phải thuộc về nhóm sản phẩm.

Tổ chức theo định hướng sản phẩm không đồng nghĩa với xóa bỏ các nhóm chuyên môn. Các cộng đồng chuyên môn tiếp tục duy trì tiêu chuẩn, đào tạo và chia sẻ kinh nghiệm. Khác biệt nằm ở chỗ nhân sự chuyên môn tham gia trực tiếp vào mục tiêu sản phẩm, thay vì chỉ tiếp nhận yêu cầu và bàn giao kết quả giữa các bộ phận.

Đối với phụ thuộc không thể loại bỏ, doanh nghiệp cần thiết lập cơ chế xử lý vượt cấp. Các vấn đề liên quan đến nhiều dự án, quyền truy cập, môi trường hoặc quyết định của khách hàng phải có người đủ thẩm quyền giải quyết trong thời hạn xác định. Nếu không có cơ chế này, nhóm dự án chỉ có thể ghi nhận trở ngại nhưng không thể loại bỏ nguyên nhân.

Kế hoạch thực hiện

Trong tháng đầu, Endava Việt Nam lựa chọn một số dự án có nhiều nhóm cùng tham gia để lập bản đồ luồng công việc. Hoạt động này xác định các bước từ khi yêu cầu được tiếp nhận đến khi tính năng được triển khai, đồng thời đo thời gian thực hiện và thời gian chờ tại từng điểm bàn giao.

Tháng thứ hai tập trung phân loại quan hệ phụ thuộc. Phụ thuộc phát sinh từ cách phân chia công việc cần được loại bỏ bằng cách tổ chức lại nhóm hoặc phạm vi trách nhiệm. Phụ thuộc kỹ thuật cần được giảm thông qua chuẩn hóa giao diện, môi trường và dữ liệu. Phụ thuộc từ khách hàng phải được quản trị bằng cam kết thời hạn, đầu mối quyết định và cơ chế báo cáo vượt cấp.

Trong tháng thứ ba và thứ tư, doanh nghiệp thí điểm nhóm liên chức năng theo định hướng sản phẩm tại một dự án phù hợp. Nhóm được giao trách nhiệm đối với một luồng giá trị hoặc nhóm tính năng hoàn chỉnh, đồng thời có quyền chủ động về cách tổ chức công việc và cải tiến quy trình trong phạm vi đã thống nhất.

Trong giai đoạn thí điểm, các phụ thuộc được theo dõi trên một bảng điều khiển chung. Cuộc họp phối hợp chỉ tập trung vào những vấn đề có nguy cơ ảnh hưởng đến mục tiêu chu kỳ hoặc đợt phát hành. Những phụ thuộc đã có người phụ trách và thời hạn rõ ràng không cần tiếp tục thảo luận kéo dài. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Tháng thứ năm tiến hành so sánh kết quả trước và sau thí điểm thông qua thời gian chờ, số nhiệm vụ bị chặn, tỷ lệ hoàn thành tính năng và mức độ dự báo tiến độ. Các thay đổi không tạo ra cải thiện phải được điều chỉnh trước khi mở rộng.

Từ tháng thứ sáu, mô hình được áp dụng cho các dự án có mức phụ thuộc cao. Doanh nghiệp không nên tổ chức lại đồng loạt toàn bộ dự án vì chi phí thay đổi lớn và không phải dự án nào cũng cần cùng một cấu trúc..

Đối tượng triển khai

Quản lý hoạt động triển khai chịu trách nhiệm xác định các phụ thuộc liên dự án, điều phối nguồn lực và xử lý vấn đề vượt khỏi thẩm quyền của từng nhóm. Quản lý dự án theo dõi phụ thuộc trong kế hoạch, đánh giá tác động và cập nhật rủi ro đối với tiến độ phát hành.

Chủ sở hữu sản phẩm chịu trách nhiệm sắp xếp công việc theo giá trị và hạn chế việc ưu tiên các nhiệm vụ kỹ thuật rời rạc không tạo ra kết quả hoàn chỉnh. Chuyên gia hướng dẫn Agile hỗ trợ xây dựng bản đồ luồng công việc, đo thời gian chờ và điều chỉnh cách lập kế hoạch.

Kiến trúc sư và trưởng nhóm kỹ thuật chịu trách nhiệm giảm phụ thuộc do kiến trúc, giao diện và dữ liệu. Các nhóm phát triển, kiểm thử và DevOps cùng chịu trách nhiệm đối với kết quả cuối cùng, thay vì chỉ hoàn thành phần việc chuyên môn của mình.

Đối với phụ thuộc từ khách hàng, cần xác định rõ đầu mối có quyền ra quyết định. Việc gửi yêu cầu đến nhiều bên nhưng không có người chịu trách nhiệm cuối cùng sẽ tiếp tục kéo dài thời gian chờ.

Nguồn lực thực hiện

Giải pháp chủ yếu sử dụng các công cụ quản trị công việc hiện có như Jira hoặc Azure DevOps. Doanh nghiệp cần bổ sung trường dữ liệu để theo dõi nhóm phụ thuộc, thời hạn, trạng thái và mức độ ảnh hưởng. Không cần xây dựng một hệ thống riêng nếu dữ liệu có thể được quản lý trong công cụ hiện hành.

Nguồn lực con người gồm quản lý dự án, quản lý hoạt động triển khai, chủ sở hữu sản phẩm, chuyên gia Agile, kiến trúc sư và đại diện các nhóm kỹ thuật. Việc tổ chức theo sản phẩm có thể yêu cầu điều chỉnh phân bổ nhân sự, nhưng không nhất thiết làm tăng tổng số người nếu trách nhiệm được bố trí lại hợp lý. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Doanh nghiệp cần dành thời gian cho việc lập bản đồ luồng công việc, chuẩn hóa giao diện và xử lý các phụ thuộc tồn đọng. Nếu chỉ thay đổi tên nhóm nhưng không điều chỉnh quyền hạn, phạm vi trách nhiệm và kiến trúc kỹ thuật, mô hình mới sẽ không làm giảm thời gian chờ.

Chỉ tiêu theo dõi và kết quả kỳ vọng

Hiệu quả giải pháp được đánh giá thông qua số nhiệm vụ bị chặn, thời gian chờ trung bình, số phụ thuộc chưa được xử lý trước đợt phát hành và thời gian hoàn thành một tính năng từ đầu đến cuối. Cần theo dõi thêm tỷ lệ tính năng hoàn tất trong cùng nhóm và mức độ dự báo chính xác của chu kỳ phát triển.

Trong sáu tháng đầu, mục tiêu là giảm số phụ thuộc được phát hiện muộn, rút ngắn thời gian chờ và tăng tỷ lệ công việc được hoàn thành trọn vẹn trong một nhóm. Các mục tiêu định lượng cụ thể cần được xác lập sau khi đo đường cơ sở tại từng dự án, tránh đặt tỷ lệ chung thiếu căn cứ.

Kết quả kỳ vọng là giảm bàn giao, tăng quyền tự chủ và làm rõ trách nhiệm đối với sản phẩm. Khi phụ thuộc được nhận diện sớm và có người chịu trách nhiệm, nhóm dự án có thể dự báo tiến độ chính xác hơn, hạn chế dồn công việc vào cuối chu kỳ và phản hồi nhanh hơn trước thay đổi.

Bảng 3.6. Tóm tắt triển khai giải pháp quản trị quan hệ phụ thuộc

3.5 Giải pháp 4: Chuẩn hóa quy trình tích hợp, triển khai và phát triển kỹ thuật nền tảng

Giải pháp này xử lý tình trạng quy trình tích hợp và triển khai được xây dựng riêng theo từng dự án, còn nhiều thao tác thủ công và khó tái sử dụng. Nhóm hạn chế về tự động hóa và năng lực nền tảng đạt giá trị trung bình 3,86, với 70,9% người khảo sát đồng thuận. Giải pháp chuẩn hóa quy trình và phát triển kỹ thuật nền tảng đạt giá trị trung bình 4,19, cho thấy nhu cầu cải tiến được đánh giá cao.

Vấn đề cốt lõi không phải thiếu công cụ. Các dự án đã sử dụng nhiều nền tảng quản lý mã nguồn, kiểm thử, triển khai và giám sát, nhưng cách cấu hình phân tán làm tăng công việc lặp lại, chi phí bảo trì và mức độ phụ thuộc vào kỹ sư chuyên trách. Endava Việt Nam cần chuyển từ tự động hóa riêng lẻ sang cung cấp các năng lực kỹ thuật dùng chung cho nhiều dự án.

Nội dung giải pháp Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Trước hết, doanh nghiệp cần xây dựng bộ mẫu chuẩn cho quy trình tích hợp và triển khai tự động. Bộ mẫu gồm các bước cơ bản như biên dịch mã nguồn, kiểm tra chất lượng, kiểm thử tự động, kiểm tra bảo mật, đóng gói, triển khai và xác nhận sau triển khai. Dự án được phép điều chỉnh theo công nghệ và yêu cầu khách hàng nhưng không nên xây dựng lại toàn bộ quy trình từ đầu.

Các cấu hình môi trường cần được quản lý dưới dạng mã nguồn. Cách làm này giúp môi trường phát triển, kiểm thử và vận hành được tạo lập theo cùng một cấu hình, hạn chế sai lệch do thao tác thủ công. Mọi thay đổi hạ tầng phải được kiểm soát phiên bản, rà soát và có khả năng khôi phục.

Kiểm thử tự động phải được mở rộng theo mức độ rủi ro. Các chức năng quan trọng cần ưu tiên kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hồi quy. Không nên tự động hóa mọi trường hợp nếu chi phí duy trì lớn hơn giá trị mang lại. Phạm vi kiểm thử cần tập trung vào các luồng nghiệp vụ quan trọng, khu vực thường phát sinh lỗi và chức năng được thay đổi thường xuyên.

Quy trình triển khai cần bổ sung cơ chế xác nhận tự động sau mỗi lần phát hành. Hệ thống phải kiểm tra trạng thái dịch vụ, khả năng kết nối, chức năng cốt lõi và các chỉ số vận hành trước khi hoàn tất triển khai. Khi xuất hiện dấu hiệu bất thường, quy trình cần hỗ trợ dừng hoặc khôi phục phiên bản trước, thay vì chờ xử lý thủ công sau khi sự cố đã ảnh hưởng đến người dùng.

Hoạt động giám sát, ghi nhật ký và truy vết hệ thống cần được tích hợp vào tiêu chuẩn kỹ thuật. Mỗi dịch vụ phải cung cấp đủ dữ liệu để nhóm vận hành xác định vị trí và nguyên nhân lỗi. Nếu hệ thống chỉ phát cảnh báo chung mà không hỗ trợ truy vết, thời gian khôi phục vẫn kéo dài dù quá trình triển khai đã được tự động hóa.

Để duy trì các năng lực dùng chung, Endava Việt Nam cần thành lập Nhóm kỹ thuật nền tảng. Nhóm này không thay thế kỹ sư DevOps tại dự án mà chịu trách nhiệm phát triển, vận hành và cải tiến các thành phần kỹ thuật dùng chung. Sản phẩm của nhóm gồm mẫu quy trình tích hợp và triển khai, cấu hình hạ tầng, công cụ quan sát hệ thống, cơ chế quản lý quyền truy cập và tài liệu hướng dẫn. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Nhóm kỹ thuật nền tảng phải vận hành theo tư duy sản phẩm. Các nhóm dự án được xem là người sử dụng nội bộ, nhu cầu của họ được ghi nhận, sắp xếp ưu tiên và đánh giá thông qua mức độ sử dụng thực tế. Nếu nền tảng khó dùng hoặc không đáp ứng yêu cầu dự án, các nhóm sẽ tiếp tục xây dựng giải pháp riêng và mục tiêu chuẩn hóa không đạt được.

Kế hoạch thực hiện

Trong tháng đầu, doanh nghiệp cần khảo sát các quy trình hiện có để xác định công cụ, bước triển khai và thành phần được sử dụng phổ biến. Kết quả khảo sát phải chỉ ra nội dung nào có thể chuẩn hóa, nội dung nào phụ thuộc vào khách hàng và những công việc đang bị lặp lại giữa nhiều dự án.

Tháng thứ hai tập trung xây dựng phiên bản tối thiểu của nền tảng dùng chung. Phạm vi ban đầu chỉ nên gồm quản lý mã nguồn, kiểm tra chất lượng, kiểm thử cơ bản, đóng gói và triển khai đến môi trường thử nghiệm. Việc xây dựng quá nhiều chức năng ngay từ đầu sẽ kéo dài thời gian và làm tăng nguy cơ nền tảng không phù hợp với nhu cầu thực tế.

Trong tháng thứ ba và thứ tư, nền tảng được thí điểm tại hai hoặc ba dự án có công nghệ và mức độ trưởng thành khác nhau. Các dự án thí điểm cần đo thời gian thiết lập, số bước thủ công, tỷ lệ triển khai thành công và mức độ hài lòng của nhóm sử dụng. Phản hồi được dùng để điều chỉnh mẫu quy trình và tài liệu hướng dẫn.

Tháng thứ năm mở rộng các thành phần kiểm thử, bảo mật, quản lý cấu hình và giám sát. Những nội dung này phải liên kết với giải pháp DevSecOps, tránh xây dựng hai quy trình kiểm tra tách biệt.

Từ tháng thứ sáu, nền tảng được cung cấp cho các dự án mới và dự án có nhu cầu cải tiến. Doanh nghiệp không nên buộc toàn bộ dự án chuyển đổi đồng thời, đặc biệt với hệ thống kế thừa hoặc hạ tầng do khách hàng kiểm soát. Mức độ áp dụng cần căn cứ vào lợi ích, rủi ro và chi phí chuyển đổi.

Sau giai đoạn thí điểm, nhóm kỹ thuật nền tảng phải công bố lộ trình phát triển theo quý. Mỗi hạng mục cần có mục tiêu, nhóm sử dụng và chỉ số đánh giá rõ ràng. Cách tổ chức này ngăn nền tảng trở thành một dự án kỹ thuật tách rời nhu cầu triển khai.

Đối tượng triển khai Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Nhóm kỹ thuật nền tảng là đơn vị chịu trách nhiệm chính về kiến trúc, phát triển và vận hành các thành phần dùng chung. Thành phần nhóm gồm kỹ sư DevOps, điện toán đám mây, tự động hóa kiểm thử, bảo mật và giám sát hệ thống.

Kiến trúc sư kỹ thuật xác định nguyên tắc tích hợp và giới hạn tùy chỉnh. Kỹ sư DevOps tại dự án phối hợp đưa quy trình hiện tại lên nền tảng chung, đồng thời phản hồi các yêu cầu chưa được đáp ứng. Nhóm kiểm thử chịu trách nhiệm xác định phạm vi và duy trì các bộ kiểm thử tự động.

Nhóm bảo mật tham gia xây dựng các cổng kiểm soát và tiêu chuẩn cấu hình. Quản lý dự án bố trí thời gian chuyển đổi, kiểm soát rủi ro và theo dõi tác động đến tiến độ. Các nhóm phát triển sử dụng nền tảng theo cơ chế tự phục vụ, thay vì phải gửi yêu cầu cho nhóm kỹ thuật nền tảng ở mỗi lần triển khai.

Ban quản lý chịu trách nhiệm bảo đảm nguồn lực và ngăn công việc nền tảng liên tục bị thay thế bởi yêu cầu nghiệp vụ ngắn hạn. Nếu nhóm nền tảng thường xuyên bị điều chuyển sang xử lý sự cố riêng của từng dự án, năng lực dùng chung sẽ không được hình thành.

Nguồn lực thực hiện

Nguồn lực kỹ thuật gồm hệ thống quản lý mã nguồn, máy chủ thực hiện quy trình tự động, kho lưu trữ sản phẩm phần mềm, nền tảng kiểm thử, quản lý cấu hình và giám sát. Doanh nghiệp nên tận dụng các công cụ hiện có, chỉ đầu tư mới khi công cụ cũ không đáp ứng khả năng tích hợp, bảo mật hoặc mở rộng.

Nguồn lực nhân sự cần được bố trí ổn định. Nhóm kỹ thuật nền tảng không nên chỉ gồm nhân sự làm kiêm nhiệm vì công việc phát triển nền tảng đòi hỏi trách nhiệm lâu dài về chất lượng, hỗ trợ và cải tiến. Giai đoạn đầu có thể lựa chọn nhân sự giàu kinh nghiệm từ các nhóm DevOps, điện toán đám mây và kiểm thử tự động.

Ngân sách cần bao gồm chi phí hạ tầng, giấy phép công cụ, đào tạo và thời gian chuyển đổi của các dự án thí điểm. Chi phí này phải được so sánh với phần công việc lặp lại, thời gian thiết lập và chi phí xử lý lỗi được cắt giảm, thay vì chỉ đánh giá dựa trên số tiền đầu tư ban đầu. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Chỉ tiêu theo dõi và kết quả kỳ vọng

Hiệu quả giải pháp được đánh giá qua các chỉ tiêu:

Thời gian thiết lập quy trình cho dự án mới.
Tỷ lệ dự án sử dụng thành phần nền tảng dùng
Tỷ lệ các bước xây dựng, kiểm thử và triển khai được tự động hóa.
Tỷ lệ bao phủ kiểm thử tự động đối với chức năng quan trọng.
Tỷ lệ triển khai thành công ngay từ lần đầu.
Tần suất triển khai và thời gian xử lý thay đổi.
Tỷ lệ thay đổi gây lỗi và thời gian khôi phục.
Số sự cố xuất phát từ sai lệch cấu hình môi trường.

Các chỉ tiêu cần được đo trước khi thí điểm để tạo đường cơ sở. Mục tiêu cải thiện được xác định riêng cho từng nhóm dự án, không nên áp dụng một tỷ lệ chung cho mọi hệ thống vì kiến trúc, công nghệ và yêu cầu kiểm soát khác nhau.

Kết quả kỳ vọng là giảm công việc lặp lại, rút ngắn thời gian thiết lập dự án và tăng tính nhất quán của quy trình triển khai. Nền tảng dùng chung còn giúp giảm phụ thuộc vào một số cá nhân, tăng khả năng chuyển giao và cho phép kỹ sư DevOps tập trung vào vấn đề có giá trị cao hơn thay vì duy trì các cấu hình tương tự ở nhiều dự án.

3.6 Lộ trình triển khai tổng thể Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Bốn giải pháp có quan hệ phụ thuộc nên không thể triển khai đồng loạt. Mô hình trưởng thành phải được xây dựng trước để xác định điểm xuất phát, DevSecOps, quản trị quan hệ phụ thuộc và kỹ thuật nền tảng được thí điểm trên cùng nhóm dự án để kiểm chứng tác động, chỉ mở rộng khi dữ liệu cho thấy hiệu quả. Cách tiếp cận này giảm đầu tư dàn trải và tránh áp dụng một khuôn mẫu cho các dự án có điều kiện khác nhau.

Lộ trình đề xuất kéo dài 12 tháng, gồm ba giai đoạn: chuẩn bị và đánh giá, thí điểm và điều chỉnh, chuẩn hóa và mở rộng.

Bảng 3.7. Lộ trình triển khai các giải pháp Agile/DevOps tại Endava Việt Nam

Giai đoạn 1: Chuẩn bị và đánh giá

Ba tháng đầu tập trung xây dựng cơ sở quản trị, không triển khai công cụ trên diện rộng. Endava Việt Nam cần thành lập nhóm điều phối gồm đại diện quản lý hoạt động triển khai, Agile, DevOps, kiểm thử, bảo mật, kiến trúc và các nhóm dự án.

Nhóm điều phối xác định bộ chỉ tiêu, phương pháp thu thập dữ liệu và nguyên tắc đánh giá. Các chỉ tiêu tối thiểu gồm thời gian xử lý thay đổi, tần suất triển khai, tỷ lệ thay đổi gây lỗi, thời gian khôi phục, tỷ lệ kiểm thử tự động, số công việc bị chặn và thời gian phê duyệt bảo mật.

Dữ liệu ban đầu phải được ghi nhận trước khi triển khai giải pháp. Nếu không có đường cơ sở, doanh nghiệp không thể phân biệt cải thiện thực tế với biến động thông thường của dự án.

Các dự án thí điểm nên đại diện cho ba bối cảnh: phát triển sản phẩm mới, bảo trì hệ thống và dự án có yêu cầu tuân thủ cao. Dự án quá ổn định sẽ không phản ánh đầy đủ điểm nghẽn, dự án đang khủng hoảng lại làm sai lệch kết quả do chịu tác động của nhiều yếu tố ngoài Agile/DevOps.

Giai đoạn 2: Thí điểm và điều chỉnh

Giai đoạn thí điểm không tách bốn giải pháp thành các chương trình độc lập. Một dự án có thể đồng thời áp dụng tiêu chí trưởng thành, kiểm tra bảo mật tự động, quản trị quan hệ phụ thuộc và mẫu quy trình triển khai dùng chung. Cách triển khai tích hợp giúp xác định tác động qua lại giữa tổ chức, quy trình và công nghệ.

Phạm vi thí điểm cần đủ hẹp để kiểm soát. Doanh nghiệp nên ưu tiên một số luồng nghiệp vụ quan trọng thay vì chuyển đổi toàn bộ hệ thống. Các thay đổi được theo dõi theo chu kỳ ngắn để phát hiện sớm công cụ không phù hợp, quy trình quá phức tạp hoặc trách nhiệm chưa rõ.

Kết quả không chỉ được đánh giá qua mức độ hoàn thành kế hoạch. Một giải pháp chỉ được giữ lại khi giảm thời gian chờ, giảm lỗi, tăng khả năng dự báo hoặc giảm công việc thủ công. Các hoạt động làm tăng báo cáo và họp nhưng không cải thiện chỉ tiêu cần được loại bỏ. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Giai đoạn 3: Chuẩn hóa và mở rộng

Việc mở rộng dựa trên kết quả thí điểm, không dựa trên yêu cầu áp dụng đồng loạt. Những thành phần tạo hiệu quả rõ ràng được chuẩn hóa thành mẫu quy trình, cấu hình, hướng dẫn và tiêu chí kiểm soát. Nội dung chỉ phù hợp với một khách hàng hoặc kiến trúc cụ thể không nên biến thành quy định chung.

Các dự án được phân nhóm theo mức độ trưởng thành và rủi ro. Dự án ở cấp thấp được ưu tiên hỗ trợ về đào tạo, chuyên gia và nền tảng. Dự án có yêu cầu tuân thủ cao áp dụng cổng kiểm soát chặt hơn. Dự án đã ổn định được trao quyền tự chủ lớn hơn nhưng vẫn phải đáp ứng các chỉ tiêu tối thiểu.

Kết quả đánh giá cần được xem xét theo quý. Nhóm điều phối sử dụng dữ liệu để quyết định nội dung tiếp tục đầu tư, điều chỉnh hoặc dừng triển khai. Cách làm này ngăn doanh nghiệp duy trì các công cụ và quy trình chỉ vì đã đầu tư trước đó.

Cơ chế điều phối và trách nhiệm:

Ban quản lý phê duyệt phạm vi, nguồn lực và xử lý các vấn đề vượt thẩm quyền dự án. Nhóm điều phối Agile/DevOps xây dựng tiêu chuẩn, tổng hợp dữ liệu và giám sát lộ trình. Nhóm kỹ thuật nền tảng chịu trách nhiệm đối với các thành phần kỹ thuật dùng chung. Bộ phận bảo mật xác định mức kiểm soát theo rủi ro. Quản lý dự án và các nhóm thực thi chịu trách nhiệm triển khai cải tiến trong phạm vi dự án.

Mỗi hoạt động phải có một đơn vị chịu trách nhiệm chính. Trách nhiệm chia đều cho nhiều bộ phận thường dẫn đến không có đơn vị nào chịu trách nhiệm cuối cùng. Các nhóm hỗ trợ có thể tham gia, nhưng quyền quyết định và thời hạn xử lý phải được xác định rõ.

Nguyên tắc đánh giá kết quả:

Hiệu quả của lộ trình được xác định bằng sự thay đổi của các chỉ tiêu vận hành, không dựa trên số khóa đào tạo, số công cụ được cài đặt hoặc số quy trình được ban hành. Mục tiêu định lượng cụ thể chỉ nên thiết lập sau khi có dữ liệu đường cơ sở của từng dự án.

Sau 12 tháng, doanh nghiệp cần đánh giá ba kết quả cốt lõi: mức chênh lệch năng lực giữa các dự án có giảm hay không, các điểm nghẽn về bảo mật, phụ thuộc và thao tác thủ công có được xử lý hay không, hiệu quả đạt được có duy trì khi thay đổi nhân sự hoặc mở rộng phạm vi hay không. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

TÓM TẮT CHƯƠNG 3

Chương 3 đã chuyển bốn hạn chế được xác định tại Chương 2 thành bốn nhóm giải pháp tương ứng. Giải pháp thứ nhất xây dựng mô hình mức độ trưởng thành Agile/DevOps để thống nhất tiêu chí đánh giá, xác định khoảng cách năng lực và ưu tiên cải tiến theo từng dự án. Giải pháp thứ hai tích hợp bảo mật và tuân thủ theo DevSecOps, đưa yêu cầu an toàn vào danh sách công việc, tiêu chí hoàn thành và quy trình kiểm tra tự động. Giải pháp thứ ba tăng cường quản trị quan hệ phụ thuộc, đồng thời tổ chức nhóm theo định hướng sản phẩm nhằm giảm bàn giao và thời gian chờ. Giải pháp thứ tư chuẩn hóa quy trình tích hợp, kiểm thử và triển khai, kết hợp phát triển nhóm kỹ thuật nền tảng để cung cấp các thành phần dùng chung cho nhiều dự án.

Bốn giải pháp không vận hành độc lập. Mô hình trưởng thành xác định điểm xuất phát và nội dung cần ưu tiên, kỹ thuật nền tảng cung cấp năng lực tự động hóa, DevSecOps kiểm soát rủi ro trong quá trình triển khai, tổ chức theo định hướng sản phẩm giảm các điểm nghẽn giữa nhóm. Nếu chỉ đầu tư công cụ mà không thay đổi cơ chế phối hợp, hiệu quả sẽ dừng ở từng dự án. Ngược lại, thay đổi cơ cấu tổ chức nhưng thiếu nền tảng kỹ thuật cũng không thể rút ngắn toàn bộ luồng công việc.

Lộ trình 12 tháng được chia thành ba giai đoạn: chuẩn bị và đánh giá, thí điểm và điều chỉnh, chuẩn hóa và mở rộng. Các giải pháp được triển khai trước tại một số dự án có đặc điểm khác nhau, sau đó mới nhân rộng dựa trên kết quả đo lường. Cách thực hiện này hạn chế đầu tư dàn trải và tránh áp dụng một quy trình cứng nhắc cho mọi dự án.

Hiệu quả triển khai được đánh giá bằng sự thay đổi của các chỉ tiêu vận hành như mức độ dự báo chính xác của chu kỳ phát triển, thời gian xử lý thay đổi, tần suất triển khai, tỷ lệ thay đổi gây lỗi, thời gian khôi phục, tỷ lệ bao phủ kiểm thử tự động, số điểm nghẽn do quan hệ phụ thuộc và tỷ lệ vượt qua cổng kiểm soát bảo mật. Số lượng công cụ, khóa đào tạo hoặc quy trình được ban hành không được xem là kết quả cuối cùng nếu các chỉ tiêu dự án không cải thiện.

KẾT LUẬN Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

Đề án đánh giá việc ứng dụng Agile/DevOps trong quản trị dự án công nghệ tại Công ty TNHH Endava Việt Nam, tập trung vào kết quả đạt được, hạn chế, nguyên nhân và giải pháp cải tiến. Nghiên cứu sử dụng dữ liệu thứ cấp, số liệu tổng hợp từ một số dự án giai đoạn 2022–2024 và khảo sát 305 nhân sự tham gia quản trị, phát triển, kiểm thử, vận hành và bảo mật.

Kết quả cho thấy Agile/DevOps đã tạo tác động tích cực đến hoạt động quản trị dự án. Nhóm chỉ tiêu hiệu quả đạt giá trị trung bình 3,91 và tỷ lệ đồng thuận 73,2%. Khả năng phản hồi thay đổi, hoàn thành các hạng mục đúng tiến độ và hiệu quả quản trị tổng thể được đánh giá cao. Dữ liệu dự án cũng ghi nhận xu hướng tăng tần suất triển khai, rút ngắn thời gian xử lý thay đổi, giảm tỷ lệ thay đổi gây lỗi và giảm thời gian khôi phục sau sự cố. Kết quả này cho thấy lợi ích của Agile/DevOps không chỉ nằm ở tốc độ phát triển phần mềm mà còn thể hiện ở khả năng kiểm soát tiến độ, chất lượng và độ ổn định của hệ thống.

Hiệu quả đạt được chưa đồng đều giữa các dự án. Nhóm hạn chế về tự động hóa và năng lực nền tảng có giá trị trung bình 3,86, tỷ lệ đồng thuận 70,9%, bảo mật và tuân thủ đạt 3,86 và 70,6%, mức độ trưởng thành Agile/DevOps đạt 3,83 và 69,6%, quan hệ phụ thuộc giữa các nhóm đạt 3,69 và 63,5%. Các kết quả này chỉ ra rằng vấn đề của Endava Việt Nam không còn nằm ở việc có áp dụng Agile/DevOps hay không, mà ở khả năng chuẩn hóa, đo lường và mở rộng phương pháp giữa các dự án.

Bốn nguyên nhân cốt lõi được xác định. Thứ nhất, doanh nghiệp chưa có khung đánh giá thống nhất để xác định mức độ trưởng thành và khoảng cách năng lực của từng dự án. Thứ hai, yêu cầu bảo mật và tuân thủ còn được xử lý muộn, làm tăng công việc sửa lại và thời gian phê duyệt. Thứ ba, cách phân chia công việc theo chức năng hoặc thành phần kỹ thuật tạo ra nhiều điểm bàn giao và thời gian chờ. Thứ tư, mỗi dự án còn có xu hướng tự xây dựng quy trình tích hợp và triển khai, trong khi công việc nền tảng và kiểm thử tự động thường bị ưu tiên thấp hơn các tính năng nghiệp vụ.

Trên cơ sở đó, đề án đề xuất bốn nhóm giải pháp. Giải pháp thứ nhất xây dựng mô hình mức độ trưởng thành Agile/DevOps để thống nhất tiêu chí đánh giá và xác định ưu tiên cải tiến. Giải pháp thứ hai tích hợp bảo mật và tuân thủ theo DevSecOps, đưa các yêu cầu kiểm soát vào danh sách công việc, tiêu chí hoàn thành và quy trình kiểm tra tự động. Giải pháp thứ ba tăng cường quản trị quan hệ phụ thuộc và tổ chức nhóm theo định hướng sản phẩm nhằm giảm bàn giao, tăng quyền tự chủ và rút ngắn thời gian chờ. Giải pháp thứ tư chuẩn hóa quy trình tích hợp, kiểm thử và triển khai, đồng thời phát triển nhóm kỹ thuật nền tảng để cung cấp các thành phần dùng chung.

Các giải pháp cần được triển khai theo lộ trình 12 tháng gồm ba giai đoạn: chuẩn bị và đánh giá, thí điểm và điều chỉnh, chuẩn hóa và mở rộng. Việc mở rộng chỉ nên thực hiện khi kết quả thí điểm cho thấy sự cải thiện về thời gian xử lý thay đổi, tần suất triển khai, tỷ lệ thay đổi gây lỗi, thời gian khôi phục, tỷ lệ kiểm thử tự động, số công việc bị chặn và hiệu quả kiểm soát bảo mật. Số lượng công cụ, quy trình hoặc khóa đào tạo không thể thay thế các chỉ tiêu phản ánh kết quả thực tế.

Đóng góp chính của đề án là xây dựng sự liên kết giữa cơ sở đánh giá, bằng chứng thực trạng và giải pháp quản trị. Mô hình đề xuất không xem Agile/DevOps là tập hợp nghi thức hoặc công cụ kỹ thuật riêng lẻ, mà là năng lực tổ chức được hình thành từ con người, quy trình, công nghệ, dữ liệu và cơ chế phối hợp. Cách tiếp cận này giúp Endava Việt Nam xác định đúng điểm nghẽn và phân bổ nguồn lực cải tiến dựa trên dữ liệu thay vì nhận định chủ quan.

Nghiên cứu vẫn có một số giới hạn. Dữ liệu dự án được trình bày dưới dạng tổng hợp do yêu cầu bảo mật và chỉ phản ánh một số dự án tiêu biểu. Khảo sát sử dụng thống kê mô tả nên phản ánh nhận thức của người trả lời, chưa chứng minh quan hệ nhân quả giữa Agile/DevOps và hiệu quả quản trị. Phạm vi nghiên cứu tại một doanh nghiệp cũng hạn chế khả năng khái quát kết quả cho toàn ngành. Các nghiên cứu tiếp theo có thể kết hợp phỏng vấn chuyên sâu, so sánh giữa các nhóm dự án và dữ liệu trước – sau triển khai để kiểm chứng tác động của từng giải pháp. Luận văn: Giải pháp hoàn thiện mô hình quản trị dự án công nghệ.

XEM THÊM NỘI DUNG TIẾP THEO TẠI ĐÂY:

===>>> Luận văn: Ứng dụng phương pháp Agile/DevOps trong quản trị

Dịch Vụ Viết Luận Văn 24/7 Chuyên cung cấp dịch vụ làm luận văn thạc sĩ, báo cáo tốt nghiệp, khóa luận tốt nghiệp, chuyên đề tốt nghiệp và Làm Tiểu Luận Môn luôn luôn uy tín hàng đầu. Dịch Vụ Viết Luận Văn 24/7 luôn đặt lợi ích của các bạn học viên là ưu tiên hàng đầu. Rất mong được hỗ trợ các bạn học viên khi làm bài tốt nghiệp. Hãy liên hệ ngay Dịch Vụ Viết Luận Văn qua Website: https://hotrovietluanvan.com/ – Hoặc Gmail: hotrovietluanvan24@gmail.com