Việc triển khai AI không chỉ là câu chuyện công nghệ. Thành công hay thất bại phụ thuộc rất lớn vào cách tổ chức học hỏi, thích nghi và thay đổi phương thức làm việc.

Khi công ty tôi bắt đầu khuyến khích nhân viên sử dụng Microsoft Copilot, hầu hết mọi người xem đó là cơ hội để khám phá và thử nghiệm công nghệ mới. Còn tôi xem đó là một cánh cửa cơ hội để chủ động tạo ra những thay đổi tích cực trong cách làm việc.

Tôi không đợi phòng đào tạo tổ chức khóa học chính thức. Tôi tự xây dựng và tổ chức một buổi chia sẻ về "Prompt Engineering 101" (Hướng dẫn đội ngũ cách sử dụng AI hiệu quả).

Lý do không phải vì đó là trách nhiệm trong mô tả công việc của tôi, mà vì tôi hiểu rằng cách mọi người tiếp cận và giao tiếp với AI ngay từ đầu sẽ ảnh hưởng trực tiếp đến giá trị mà doanh nghiệp nhận được sau này, cũng như chi phí vận hành mà tổ chức phải bỏ ra khi mở rộng việc ứng dụng công nghệ này trên quy mô lớn.

Chi phí ẩn của việc viết Prompt kém chất lượng

Viết prompt không tốt không chỉ làm giảm chất lượng kết quả mà còn làm tăng đáng kể chi phí khi triển khai AI trên toàn doanh nghiệp.

Mỗi lần AI xử lý dữ liệu đều tiêu tốn token. Khi hàng trăm hoặc hàng nghìn người cùng sử dụng, lượng token tiêu hao từ các prompt kém chất lượng sẽ tăng lên rất nhanh. Đáng tiếc là nhiều chương trình triển khai AI chỉ nhận ra điều này khi hóa đơn dịch vụ xuất hiện.

Trong buổi đào tạo của mình, tôi đã bắt đầu bằng một ví dụ đơn giản.

Prompt ban đầu tôi nhập vào là: 

“Hãy tạo một tài liệu yêu cầu nghiệp vụ (BRD)”

Với câu lệnh này, AI đã tạo ra nhiều trang nội dung mang tính khái quát, dài dòng, thiếu cấu trúc rõ ràng và gần như không thể sử dụng ngay nếu không chỉnh sửa đáng kể.

Sau đó tôi thử lại bằng một prompt có cấu trúc theo mô hình RTF (Role – Task – Format), nhằm làm rõ vai trò, nhiệm vụ và định dạng mong muốn:

“Bạn là một business analyst trong một công ty dịch vụ tài chính. Hãy xây dựng một tài liệu yêu cầu nghiệp vụ (BRD) cho quy trình xử lý khoản vay nội bộ. Tài liệu cần được cấu trúc theo các phần: Mục tiêu, Phạm vi, Yêu cầu chức năng và Các ràng buộc. Không bao gồm tên khách hàng, số tài khoản hoặc bất kỳ dữ liệu độc quyền nào. Giới hạn nội dung trong 500 từ.”

Sự khác biệt xuất hiện ngay lập tức. Với prompt ban đầu, AI gần như phải tự suy diễn toàn bộ phần ngữ cảnh còn thiếu: ai là người sử dụng, mục tiêu là gì, phạm vi đến đâu và kết quả cần được trình bày theo định dạng nào. Kết quả là đầu ra thường dài dòng, mang tính khái quát và tiêu tốn nhiều token cho những nội dung không thực sự được yêu cầu.

Ngược lại, một prompt được xây dựng có cấu trúc sẽ giúp AI hiểu rõ bối cảnh, mục tiêu và các ràng buộc ngay từ đầu. Nhờ đó, kết quả tạo ra không chỉ sát nhu cầu hơn mà còn có thể sử dụng như một bản nháp khả thi ngay trong lần đầu tiên, đồng thời giảm thiểu rủi ro lộ thông tin nhạy cảm vào nội dung do AI tạo ra.

Xây dựng rào chắn kiểm soát ngay từ những bước đầu

Buổi chia sẻ không chỉ hướng đến việc tạo ra những kết quả tốt hơn từ AI. Một phần quan trọng buổi chia sẻ là trao đổi về những rào chắn kiểm soát (guardrails) - những nguyên tắc và giới hạn giúp đảm bảo AI được sử dụng đúng mục đích, an toàn và phù hợp với các yêu cầu tuân thủ của tổ chức.

Chúng tôi cùng thảo luận các vấn đề thiết thực như chính sách sử dụng AI của công ty thực sự có ý nghĩa gì trong công việc hằng ngày của mọi người, đâu là giới hạn khi đưa dữ liệu nghiệp vụ vào AI, những loại thông tin nào không được phép nhập vào hệ thống,... Tôi muốn mọi người hình thành thói quen đúng ngay từ đầu thay vì chỉ học được bài học sau khi xảy ra sự cố.

Buổi thảo luận diễn ra sôi nổi và đầy tương tác - điều hiếm khi có được khi mọi người chỉ tiếp cận thông tin thông qua các tài liệu chính sách hoặc quy định nội bộ. Mọi người bắt đầu cởi mở chia sẻ và đặt ra những câu hỏi mà họ đã trăn trở suốt nhiều tuần nhưng chưa có cơ hội trao đổi hoặc tìm lời giải đáp.

Đó là bài học đầu tiên tôi rút ra khi dẫn dắt những thay đổi liên quan đến AI: 

Cơ hội để định hình cách tổ chức sử dụng AI chỉ xuất hiện trong một khoảng thời gian ngắn. Sớm muộn sẽ có người quyết định cách doanh nghiệp học và áp dụng công nghệ này. Tốt hơn hết đó nên là người hiểu rõ các hệ quả của nó.

Vòng phản hồi không chỉ dành cho khách hàng bên ngoài

Vài tháng sau, nhóm của tôi đã phát triển một AI Agent (Tác nhân Trí tuệ Nhân tạo) có khả năng tự động tạo User Story. Ngay khi công cụ này được đưa vào sử dụng, các cuộc thảo luận nhanh chóng chuyển sang những cải tiến tiếp theo: bổ sung tính năng mới, nâng cao chất lượng đầu ra và mở rộng khả năng tích hợp với các hệ thống khác.

Giữa lúc mọi người đang hào hứng bàn về những cải tiến tiếp theo, tôi đặt ra một câu hỏi khiến cả phòng họp lặng đi trong giây lát: “Chúng ta có thực sự biết mọi người đang sử dụng công cụ này như thế nào không?”

Không ai có câu trả lời rõ ràng. Chúng tôi có dữ liệu triển khai hệ thống, nhưng lại thiếu dữ liệu về mức độ sử dụng thực tế. Chúng tôi không biết đội nhóm nào đang sử dụng công cụ thường xuyên, đội nhóm nào chỉ dùng thử một lần rồi bỏ, những khó khăn hay rào cản nào đang khiến người dùng không tiếp tục sử dụng công cụ này.

Điều đáng nói là chúng tôi đang chuẩn bị đầu tư thêm nguồn lực để nâng cấp sản phẩm, trong khi vẫn chưa thực sự hiểu rõ người dùng đang tiếp nhận và sử dụng phiên bản hiện tại như thế nào. Nếu đây là một sản phẩm dành cho khách hàng bên ngoài, chắc chắn chúng tôi sẽ không làm như vậy. Thế nhưng với một sản phẩm phục vụ nội bộ, chúng tôi lại gần như mặc nhiên bỏ qua bước này.

Ưu tiên mức độ chấp nhận sử dụng hơn việc bổ sung tính năng

Thay vì tiếp tục phát triển các tính năng mới, chúng tôi quyết định tạm dừng việc cải tiến và thực hiện một khảo sát về mức độ sử dụng thực tế của người dùng.

Kết quả thu được đã làm thay đổi hoàn toàn hướng đi của dự án. Vấn đề không nằm ở chức năng của công cụ. Rào cản thực sự là niềm tin và thói quen sử dụng. Nhiều người dùng chưa thực sự tin tưởng vào chất lượng đầu ra của AI Agent. Họ vẫn cảm thấy cần phải rà soát và chỉnh sửa rất nhiều trước khi có thể sử dụng.

Nói cách khác, đây là bài toán về tính minh bạch, truyền thông và hướng dẫn người dùng, chứ không phải vấn đề về tính năng. Nếu người dùng chưa hiểu công cụ hoạt động như thế nào và chưa đủ tin tưởng vào kết quả mà nó tạo ra, thì dù chúng tôi có bổ sung thêm bao nhiêu khả năng mới đi nữa, điều đó cũng không giải quyết được nguyên nhân gốc rễ.

Thực tế, đây không phải là một ý tưởng mới. Thực chất, đây chính là tinh thần kiểm tra và thích ứng (inspect and adapt) của Agile. Nguyên tắc thứ 12 của Agile Manifesto nhấn mạnh rằng các nhóm cần thường xuyên nhìn lại cách làm việc của mình để tìm ra hướng cải thiện hiệu quả hơn. Tương tự, việc phát hành sản phẩm theo từng bước nhỏ cũng nhằm mục đích thu thập phản hồi thực tế trước khi tiếp tục đầu tư vào những giả định chưa được kiểm chứng. Chúng ta áp dụng nguyên tắc này rất nghiêm túc đối với các sản phẩm dành cho khách hàng bên ngoài. Thế nhưng, khi nói đến các công cụ nội bộ hoặc AI agent do chính mình xây dựng, nguyên tắc này lại thường bị bỏ quên.

Cách khắc phục lỗi này thực ra rất đơn giản: Các AI agent nội bộ cũng cần được lắng nghe và cải tiến dựa trên phản hồi thực tế, giống như bất kỳ sản phẩm nào khác. Chúng cũng có người sử dụng, và những người đó luôn có nhu cầu riêng, những điểm chưa hài lòng, cũng như những cách “lách” để hoàn thành công việc khi công cụ chưa đáp ứng được kỳ vọng.

Vì vậy, trước khi tiếp tục đầu tư phát triển thêm tính năng hay mở rộng phạm vi giải pháp, điều quan trọng trước tiên là phải hiểu rõ người dùng đang thực sự trải nghiệm công cụ như thế nào.

Thay đổi văn hóa diễn ra trong những cuộc họp hàng ngày, không phải trong các thông báo

Một trong những điều bất ngờ nhất mà tôi quan sát được khi đưa AI Agent vào buổi Backlog Refinement (tinh chỉnh danh sách công việc tồn đọng) không phải là hiệu quả công việc. Mà là sự thay đổi trong mức độ tham gia của các thành viên.

Ban đầu, tôi kỳ vọng AI sẽ giúp nhóm tiết kiệm thời gian và cải thiện chất lượng thảo luận. Nhưng điều thực sự nổi bật lại là cách mọi người tương tác với nhau.

Trước đây, trong các buổi Backlog Refinement, một số thành viên thường tham gia khá thụ động. Họ lắng nghe nhiều hơn phát biểu và để những người có tiếng nói mạnh hơn dẫn dắt cuộc thảo luận. 

Khi AI Agent bắt đầu đưa ra các đề xuất và góc nhìn mới, mọi thứ thay đổi. Họ đặt câu hỏi, phản biện, bổ sung và chỉnh sửa các đề xuất của AI, thay vì tiếp nhận chúng một cách mặc nhiên.

Thay vì trở thành câu trả lời cuối cùng, kết quả từ AI trở thành điểm khởi đầu cho những cuộc trao đổi sâu sắc hơn. AI không thay thế khả năng phán đoán của nhóm. Nó chỉ tạo điều kiện để nhiều người cảm thấy tự tin hơn khi lên tiếng, chia sẻ góc nhìn và đóng góp ý kiến của mình.

Khi tư duy của nhóm được "hiển thị" rõ ràng hơn

Có một tình huống khiến tôi nhớ mãi.

Một thành viên vốn rất ít phát biểu trong các buổi Refinement bất ngờ đưa ra một góc nhìn mà cả nhóm chưa từng nghĩ tới. Nguyên nhân bắt đầu từ cách AI Agent diễn giải User Story theo một hướng hoàn toàn khác so với cuộc trao đổi trước đó. Sự diễn giải này đã giúp anh ấy có một điểm tựa cụ thể để phản hồi. Thay vì phải tự nghĩ ra ý tưởng từ một "tờ giấy trắng", anh ấy có thể phản biện trực tiếp vào đề xuất của AI.

Anh ấy chỉ ra những điểm chưa hợp lý, đề xuất điều chỉnh và mở ra một hướng thảo luận mới. Ngay sau đó, những thành viên khác cũng bắt đầu tham gia nhiều hơn. Điều thú vị là cuộc trao đổi không chỉ trở nên cởi mở hơn mà còn chất lượng hơn. Nhóm bắt đầu đặt ra những câu hỏi làm rõ yêu cầu mà trước đây chưa từng được nhắc đến. Những giả định vốn âm thầm tồn tại trong backlog suốt nhiều tuần bỗng được đưa ra ánh sáng chỉ trong một buổi họp.

AI không khiến đội ngũ trở nên thông minh hơn. Điều AI làm là giúp quá trình tư duy của cả nhóm được bộc lộ rõ ràng hơn. Và khi tư duy trở nên hữu hình, mọi người đều có cơ sở để tham gia vào cuộc trao đổi, không chỉ những người thường xuyên phát biểu hay có sức ảnh hưởng lớn nhất trong phòng họp.

Một trong những bài học quan trọng nhất tôi rút ra là:

Việc ứng dụng AI thành công không đến từ các thông báo của lãnh đạo hay những khóa đào tạo bắt buộc. Nó đến từ việc mọi người có những trải nghiệm khác đi trong chính công việc hằng ngày của họ. Một cuộc họp quen thuộc. Một buổi Refinement diễn ra như thường lệ. Nhưng cách mọi người suy nghĩ, trao đổi và ra quyết định lại thay đổi. Đó mới là lúc văn hóa bắt đầu dịch chuyển.

Với Scrum Master, các sự kiện Scrum chính là một trong những đòn bẩy mạnh mẽ nhưng thường bị bỏ qua trong quá trình chuyển đổi này. Không nhất thiết phải khởi động một chương trình AI quy mô lớn ngay từ đầu. Đôi khi, điều hiệu quả hơn là đưa AI vào những hoạt động đang diễn ra hằng ngày và để đội ngũ trực tiếp trải nghiệm, tương tác và tự đánh giá giá trị mà công cụ đó thực sự mang lại.

Trải nghiệm là điều kiện để dẫn dắt

Tôi đã tham gia một chương trình mang tên AgentHack - một cuộc thi hackathon tập trung vào việc xây dựng AI Agent. Vì tôi nhận ra rằng bản thân đang thiếu trải nghiệm thực tế để củng cố độ tin cậy và tính thuyết phục trong vai trò của mình. 

Tôi thường xuyên hỗ trợ các nhóm thảo luận về AI Agent, hướng dẫn họ đánh giá cách xây dựng và triển khai các giải pháp AI. Tuy nhiên, chính tôi lại chưa từng tự tay xây dựng một AI Agent hoàn chỉnh. Khoảng cách ấy gần như vô hình trong hầu hết các cuộc trao đổi. Người khác có thể không nhận thấy, nhưng tôi cảm nhận rất rõ. Mỗi khi một lập trình viên chia sẻ về những khó khăn trong quá trình thử nghiệm và điều chỉnh prompt, tôi hiểu về mặt khái niệm. Nhưng tôi chưa thực sự trải qua những khó khăn đó. Và điều đó khiến khả năng dẫn dắt của tôi có những giới hạn nhất định. Tôi nhận ra một sự thật đơn giản: Bạn không thể hướng dẫn người khác vượt qua những thách thức mà chính mình chưa từng trải nghiệm.

Muốn dẫn dắt quá trình ứng dụng AI trong tổ chức, trước hết người lãnh đạo cần trực tiếp sử dụng, thử nghiệm và học hỏi từ chính những trải nghiệm thực tế của mình.

Trải nghiệm thực tế định hình lại cách dẫn dắt

Việc trực tiếp xây dựng AI Agent đã thay đổi góc nhìn của tôi. Tôi bắt đầu nhận ra khoảng cách giữa những gì mình kỳ vọng AI có thể làm và những gì công nghệ này thực sự làm được trong thực tế. Chính trải nghiệm đó giúp tôi hiểu rõ hơn một bài học quan trọng mà trước đây tôi chỉ nhìn thấy ở bề mặt: vấn đề trong việc triển khai AI Agent không nằm ở số lượng tính năng, mà nằm ở mức độ tin tưởng của người dùng. Sau khi tự mình trải qua quá trình xây dựng và thử nghiệm, tôi quay lại làm việc với các nhóm theo một cách khác. Tôi đặt những câu hỏi sắc bén hơn. Tôi cảm thấy thoải mái hơn khi đối diện với những điều chưa chắc chắn. Và khi trao đổi về các thách thức trong quá trình ứng dụng AI, tôi không còn lặp lại những điều đọc được từ sách báo hay hội thảo. Tôi nói từ những trải nghiệm mà bản thân đã thực sự trải qua. Những cuộc trao đổi vì thế cũng trở nên chân thực và có chiều sâu hơn, bởi chúng được xây dựng từ trải nghiệm đã được kiểm chứng thay vì những hiểu biết gián tiếp.

Nếu bạn đang dẫn dắt các cuộc thảo luận về ứng dụng AI trong tổ chức nhưng chưa từng tự tay xây dựng bất kỳ giải pháp AI nào, tôi khuyến khích bạn thử thu hẹp khoảng cách đó. Không phải vì trải nghiệm ấy sẽ biến bạn thành chuyên gia kỹ thuật, mà vì nó giúp bạn dẫn dắt bằng những điều mình đã thực sự trải qua thay vì chỉ dựa trên kiến thức lý thuyết.

Người dẫn dắt thay đổi không phải là người biết nhiều nhất

Tôi muốn làm rõ một điều. Tôi không phải là người hiểu AI sâu sắc nhất trong các nhóm mà tôi làm việc cùng. Tôi cũng không sở hữu kiến thức kỹ thuật vượt trội nhất trong phòng họp. Và thực tế thì tôi cũng không cần điều đó.

Điều tôi có là hơn 15 năm quan sát các tổ chức đối mặt với những thách thức trong quá trình thay đổi. Tôi đã chứng kiến:

• Những khoảng trống về niềm tin khiến các sáng kiến chuyển đổi thất bại.
• Những chương trình triển khai dần mất động lực sau giai đoạn khởi đầu.
• Những công nghệ rất tốt nhưng không được sử dụng hiệu quả vì người dùng không được hỗ trợ đúng cách.

Đó mới là kinh nghiệm mà thời điểm hiện tại thực sự cần. Không phải vì AI chỉ đơn thuần là một bài toán quản lý thay đổi. Thực tế, AI có quy mô tác động lớn hơn và tốc độ thay đổi nhanh hơn nhiều so với hầu hết các chương trình chuyển đổi trước đây. Tuy nhiên, những nguyên tắc nền tảng vẫn không thay đổi:

• Con người cần cảm thấy an toàn để thử nghiệm và học hỏi.
• Các vòng lặp phản hồi vẫn là yếu tố cốt lõi để cải tiến.
• Cơ chế quản trị được xây dựng từ sớm luôn hiệu quả và ít tốn kém hơn việc bổ sung sau này.

Những Scrum Master có khả năng tạo ra ảnh hưởng trong giai đoạn chuyển đổi này không nhất thiết là những người hiểu biết nhiều nhất về AI. Họ là những người sẵn sàng bước đi đầu tiên, chủ động thử nghiệm, trung thực nhìn nhận những gì mình học được và chủ động mang những bài học đó quay trở lại với đội ngũ mà không cần chờ ai yêu cầu.

Đó chính là tinh thần của lãnh đạo phục vụ. Và suy cho cùng, tinh thần ấy chưa bao giờ thay đổi.

Suy ngẫm cuối cùng về chuyển đổi

Chuyển đổi chưa bao giờ là công việc dễ dàng. Tôi đã chứng kiến nhiều chương trình chuyển đổi bị đình trệ. Có những sáng kiến dần mất động lực. Có những chương trình âm thầm bị gác lại khi tổ chức phải ưu tiên những vấn đề cấp bách hơn. Tôi hiểu cảm giác phải cố gắng thuyết phục mọi người tiến về phía trước trong khi họ vẫn chưa nhìn thấy giá trị của sự thay đổi. 

Nhưng có một điều tôi luôn tin tưởng: Nếu muốn dẫn dắt chuyển đổi, bạn phải trở thành một phần của quá trình chuyển đổi đó. Không chỉ đứng bên ngoài quan sát. Không chỉ điều phối từ một khoảng cách an toàn. Mà thực sự tham gia vào hành trình đó. Tự học hỏi. Tự trải nghiệm. Tự vấp ngã. Và liên tục điều chỉnh.

Người tiên phong luôn là người bắt đầu trước.

Nếu có một điều tôi muốn gửi gắm, đó là: Hãy chọn một hành động nhỏ ngay trong tuần này.

Bạn có thể tổ chức một buổi chia sẻ ngắn về Prompt Engineering cho đội nhóm, thử đưa một AI Agent vào buổi Backlog Refinement tiếp theo, khảo sát mức độ sử dụng các công cụ AI nội bộ đang có sẵn trong tổ chức, hoặc tham gia một hackathon và tự mình xây dựng một giải pháp mới.

Bạn không cần phải bắt đầu bằng một dự án lớn. Điều quan trọng là sẵn sàng bước đi đầu tiên. Sau đó, hãy mang những gì bạn học được quay trở lại đội nhóm của mình. Đó là cách để người dẫn dắt luôn đi trước một bước. Và cũng là cách để những chương trình chuyển đổi thực sự tạo ra thay đổi trong tổ chức.

Nguồn: PMI | Tác giả: Rathan Ramachandra