IT Governance

Hàng ngàn danh nghiệp đang "AI-First", áp dụng AI trong 100% công việc, tất cả vị trí, tất cả level.Nhưng đưa AI vào quy trình phát triển phần mềm không chỉ đơn giản là câu chuyện mua thêm license Claude/Codex cho team Dev/QC. Thật sự phải công nhận một điều rằng, tầm ảnh hưởng của AI trong phát triển phần mềm đang thay đổi hoàn toàn cách chúng ta định nghĩa thế nào về hiệu suất công việc, nhưng đồng thời cũng mở ra cho chúng ta một rủi ro vận hành ở quy mô chưa từng có.Khi một Developer sử dụng AI Assistant độc lập, hiệu suất có thể tăng gấp đôi, gấp ba,.... Quá trình giải quyết vấn đề nhanh gọn, code được gen ra một cách mượt mà. Tuy nhiên, bài toán sẽ lập tức đảo chiều khi quy mô tăng lên 50, 500 và rồi 5.000 Developers trong một hệ thống Enterprise. Lúc này, cuộc chơi chuyển từ "tối ưu cá nhân" sang một cơn ác mộng về kiến trúc và quản trị: Sự Bội Phát AI Skills (AI Skill Explosion).Ma Trận "Vô Chủ" Của Hàng Vạn AI SkillsTrong một tổ chức hoặc nhỏ hơn là một dự án thiếu bộ khung chuẩn hóa, hàng trăm developers sẽ sử dụng hàng nghìn AI Agents khác nhau. Mỗi developer lại tự "huấn luyện" hoặc định nghĩa cho Agent của mình hàng chục AI Skills chuyên biệt – từ những đoạn prompt custom tối ưu logic, các automation scripts tự chạy test, đến những plugin tự động đọc và phân tích database design, liên kết phân tích hàng trăm tài liệu design của màn hình.Và rất nhanh thôi, hệ quả tất yếu là một hệ sinh thái phân mảnh. Doanh nghiệp đột nhiên sở hữu 50.000 AI Skills trôi nổi. Mỗi người viết một kiểu, mỗi Agent thực thi một logic, không có một trung tâm nào kiểm duyệt, không có version control, hoặc nếu có cũng chỉ cho đúng process. Dự án dần biến thành một "ma trận hỗn loạn" nơi mà những đoạn code do AI tạo ra nằm rải rác, chồng chéo, dư thừa và không thể truy vết, có người clean source muốn xóa đi thì cũng chẳng biết tìm đến ai để xử lý.Sự thay đổi này định hình lại hoàn toàn vòng đời phát triển phần mềm (SDLC). Bài toán của các Tech Lead và Project Manager không còn nằm ở việc đánh giá xem AI có code được không, mà là giải quyết 5 trụ cột quản trị cốt lõi dưới đây.5 Trụ Cột Quản Trị (Governance) Định Hình SDLC 2.01. Quyền Hạn và Bảo Mật (Access Control & Security) Trước đây, việc cấp quyền cho một con người đã phức tạp, thì bây giờ cấp quyền cho hàng nghìn Autonomous Agents còn nguy hiểm hơn. Khi một Agent tự động sinh ra kịch bản tối ưu query, liệu nó có được cấp quyền IAM policies để truy cập trực tiếp vào cơ sở dữ liệu trên AWS RDS hay truy vấn đồ thị trên Neptune? Agent có được phép đọc log hệ thống lưu trữ tại S3 để debug không? Agent có lưu trữ sử dụng access token vào VM hay tự run những batch job? Việc thiếu kiểm soát ranh giới dữ liệu sẽ biến AI Assistant thành lỗ hổng bảo mật nghiêm trọng nhất của hệ thống.2. Trách Nhiệm Giải Trình (Accountability) Nếu lúc trước bạn viết code sai lệch so với requirement của khách hàng, người Leader và bạn có thể cùng chịu các phần trách nhiệm. Nhưng nếu một đoạn code do AI viết ra (thông qua một Skill tự tạo của dev) gây rò rỉ dữ liệu khách hàng hoặc làm sập server UAT/Prod, vậy ai sẽ là người chịu trách nhiệm cuối cùng? Rõ ràng, một doanh nghiệp không thể sa thải một công cụ. Do đó, ranh giới trách nhiệm giữa người đánh giá (Developer) và hệ thống tạo lập (AI Agent) cần được định nghĩa rõ ràng bằng các SLA (Service Level Agreement) nội bộ.3. Khủng Hoảng Chất Lượng & Audit Code AI rất giỏi, rất nhanh, rất tiện lợi là điều hiển nhiên, bất kì ai cũng nhận ra. Với khả năng gen code hàng loạt, AI đẩy tốc độ pull request lên mức tối đa, vượt qua tốc độ trung bình của dev. Những người làm vai trò Tester và QA đôi lúc sẽ bị quá tải trước hàng triệu dòng code được đẩy lên mỗi tuần. Việc đánh giá chất lượng lúc này không chỉ là kiểm tra syntax, kiểm tra business, mà phải dò tìm các "ảo giác" (hallucinations) ẩn sâu trong logic, vì biết đâu được rằng trong lúc AI gen code theo tài liệu, nó đã thêm mắm thêm muối thêm đường vào trong những logic, và tự đưa ra những xử lý mà khách hàng chưa bao giờ yêu cầu. Thực tế việc Audit hệ thống đòi hỏi một cơ chế kiểm duyệt code nhiều lớp, nơi AI phải được dùng để tự động test chính output của AI trước khi con người nhúng tay vào.4. Rủi Ro Deploy Lên Production Sự tự động hóa hứa hẹn CI/CD không chạm (zero-touch deployment) nghe thì rất là hay, mấy ông DevOps chả cần làm gì nhiều, tiết kiệm hàng giờ effort mỗi ngày, PM có thể rất hài lòng vì tối ưu được cost. Nhưng việc cho phép các Agent tự động merge code, tự chạy các runner pipeline và đẩy lên các môi trường sát với end-user là một canh bạc. Việc thiếu các chốt chặn (gatekeepers) an toàn giữa môi trường staging và production trong kỉ nguyên AI có thể dẫn đến những thảm họa downtime không thể vãn hồi. Nói thảm họa có vẻ nghe hơi nguy hiểm, nhưng thực tế rằng, việc sai lệch một chút có thể dẫn đến thiệt hại hàng triệu đô.5. Bài Toán Kinh Tế (Economics & ROI) Tất cả chúng ta đều biết rằng Token chưa bao giờ là miễn phí. Khi mọi developer đều để Agent chạy ngầm, liên tục gửi context windows khổng lồ để phân tích log hay refactor code, chi phí hạ tầng AI sẽ phình to không kiểm soát. Hằng tuần tôi nhận được hàng chục buổi AI Sharing về những solution, những bộ toolkit cho dự án, nhưng khi nói về giá trị cốt lõi đem lại thực tế cho team thì chưa biết là gì, hay chỉ đơn giản là mọi người đang cố chạy theo KPI, dùng hàng tỉ token để khoe với người rằng tôi có skill này, có tool kiaDo đó, mỗi doanh nghiệp cho dù là vừa, to hay là nhỏ cũng nên cần phải công cụ đo lường chính xác ROI của AI: liệu lượng token tiêu thụ có thực sự tỉ lệ thuận với hiệu suất công việc và giá trị mang lại, hay chỉ là sự lãng phí tài nguyên trong cuộc đua về AI?Scale AI cho doanh nghiệp chưa bao giờ là việc nhân bản Claude/ChatGPT lên 5.000 lần. Nó là một bài toán kĩ thuật hệ thống phức tạp, đòi hỏi sự giao thoa khắt khe giữa Engineering, Security, Governance và Economics. Để không bị nhấn chìm trong mớ bòng bong của hàng vạn AI Skills tự phát, các tổ chức cần ngay lập tức xây dựng một "Centralized Skill Registry" – nơi mọi prompt, mọi quyền hạn của Agent đều được chuẩn hóa, phân quyền và giám sát.Bạn nghĩ sao về viễn cảnh các Tester và Developer sẽ chuyển dịch sang vai trò "Người giám sát AI" nhiều hơn là người trực tiếp vận hành hệ thống? Hay đơn vị của bạn đã bắt đầu xây dựng framework quản trị cho AI Agent & AI Skill chưa? 

Most meetings fail before they even start.Not because of bad ideas. Not because of the wrong people in the room. Because the person running it didn't do the work beforehand.Ever had a hard time getting a decision out of a meeting? Ever watched stakeholders glaze over somewhere around slide 14 — knowing full well your actual idea is on slide 25?That's not an attention problem. That's a preparation problem. Here's the uncomfortable truth:If you walk into a meeting trying to convince people of something — you've already lost and end in an  discussion about what the actual problem is rather then talking about the solution. Convincing is not a meeting activity. Convincing is homework.The meeting is where you collect the signature on work that was already done in the hallway, the Slack thread, the quick call on Tuesday, and the coffee you had with the one stakeholder you knew was going to push back.Align before the meeting. Use the meeting to decide.That's the whole playbook.And when you do it right, something almost magical happens:👉 The meeting ends early 👉 Decisions happen fast 👉 Nobody fights you in the roomBecause the resistance didn't disappear. You just dealt with it before anyone opened a calendar invite.For decision meetings, my rule is simple:3–5 slides. No more.Structure:Outcome → "We are going to do this."How → The approach, the solution, the planDecision → What needs approval, right now, in this roomThree lines per slide. Visuals over text walls.If your slide needs more than three lines to explain — you haven't finished thinking yet.And if you're on slide 25 before you get to the point — you haven't respected the room.But the real work happened before slide one.You talked to the key stakeholders earlyYou understood their concerns before they became objectionsYou incorporated their input so they already see themselves in the solutionYou gave them time to digest — so they're not processing and deciding at the same timeThat last part matters more than people realize.Nobody makes good decisions cold. When someone hears an idea for the first time in a meeting, their first instinct is protection, not progress. They poke holes. They ask for more time. They "want to take it offline."But when they've already had the conversation? When they've already raised their concern and seen it addressed?They walk in ready. The meeting becomes a formality — in the best possible way.This is also how you respect everyone in that room.Your developers, your consultants, your strategy leads, your junior team members — they're not there to watch a 45-minute presentation. They're there because their judgment matters.Pre-alignment means when they arrive, the context is already shared. Their energy goes toward the decision — not catching up, not sitting politely through slides that don't concern them.Great presenters inform. Great leaders close.The debate, the brainstorming, the messy back-and-forth — that belongs in the channels you already have.Do the work before the meeting. Keep it to 5 slides. Walk out with a decision.That's the difference between people who run meetings and people who actually get things done.The slide 25 line is the funniest and most relatable moment in this version — everyone has lived that meeting. Want me to now write the short series intro lines for all three posts so they feel like a cohesive LinkedIn series?

Disclaimer: This is a high-level PM management experience on the view of agile projects in a strategic portfolio management situation. I'm a full agile believer------------------------------------------------------------------------------------------------------------------------------------There are few things more ironic than watching Agile turn back into Waterfall.After managing ~90 projects and programs per year in an IT portfolio, I've seen almost every "Agile transformation" playbook.Same pattern every time:New frameworksNew rolesMore ceremoniesMore alignment layersAnd yet… delivery slows down.Why?Because somewhere above your beautiful two-week sprints, a CFO is sitting at a spreadsheet doing a very Waterfall thing: approving an annual budget.Your team ships in quarters. Finance plans in fiscal years. And somewhere in a risk register nobody reads, a contingency budget is quietly held back "just in case", which means the money only flows when the year (or the deadline) is almost over.But it's not just the money.It's the deadlines too.In portfolio planning, every project gets a delivery window, because projects don't exist in a vacuum and resources have to be aligned on a multi year project roadmap. They exist to support something. A product launch. A market entry. A regulatory deadline.The new product goes live in October? Then the cybersecurity project must be done by September. Not "done enough." Done.Suddenly your "Agile" cybersecurity team isn't prioritizing based on risk or value anymore. They're prioritizing based on a date that was set in a portfolio spreadsheet eight months ago — before anyone wrote a single user story.The budget flows down like a waterfall. The deadline flows down like a waterfall. The scope follows quietly behind.Congrats. Your Agile project just became a Waterfall project in a hoodie.Real agility isn't a framework. It's what happens when funding, decisions, and delivery all move at the same speed.Everything else is just stand-ups with extra steps.