Đã khá lâu rồi tôi mới ngồi xuống để viết blog. Một phần vì vai trò mới mang đến nhiều thách thức: vừa phải theo đuổi mục tiêu doanh số, vừa ổn định đội ngũ, lại vừa học hỏi những kỹ năng quản trị mới. Giữa tất cả những bận rộn đó, tôi nhận ra mình đã tích lũy không ít trải nghiệm đáng để ghi lại – không chỉ về công nghệ, mà còn về cách tư duy và ra quyết định.
Và đây chính là lúc để nhìn lại: hành trình mà tôi cùng đồng nghiệp tham gia trong một chương trình chuyển đổi số quy mô lớn trong lĩnh vực tài chính – dịch chuyển hệ thống IT lên AWS Cloud. Chúng tôi đồng hành cùng khách hàng từ khâu khảo sát, tư vấn, thiết kế, cho đến triển khai và vận hành.
📌 Disclaimer: Nội dung trong bài viết này đến từ trải nghiệm cá nhân trong nhiều dự án, có xen kẽ thêm một số tình huống giả định để minh họa cho các mental models. Và phải thú thật rằng nếu không có sự hỗ trợ của ChatGPT – “người bạn đồng hành” giúp tôi sắp xếp dòng suy nghĩ, có lẽ bài viết này khó mà ra đời.
Bắt đầu: từ Cloud Advisory Board đến Landing Zone
Điểm khởi đầu là việc tư vấn thành lập Cloud Advisory Board – một diễn đàn chung giữa chúng tôi và khách hàng. Đây là nơi tất cả các bên có thể cùng nhau bàn thảo, đảm bảo kế hoạch bám sát AWS best practices và các quy định khắt khe của ngành tài chính.
Tiếp đó, chúng tôi thiết kế và triển khai Landing Zone – bộ khung hạ tầng bảo mật, kết nối an toàn với trung tâm dữ liệu hiện hữu, và sẵn sàng cho hàng loạt dịch vụ trọng yếu.
Khi migration bắt đầu, chúng tôi áp dụng linh hoạt nhiều pattern: lift & shift, replatform, rearchitect. Song song, một nền tảng DevSecOps tập trung được xây dựng để quản lý CI/CD và bảo mật. Cuối cùng, một operation team được thành lập, giám sát hệ thống theo SLA, đảm bảo vận hành ổn định.
Những tình huống & mental models đi kèm
Trong dự án cloud migration này, mỗi quyết định hay khó khăn đều gợi tôi liên tưởng đến một mental model cụ thể. Việc kết nối trải nghiệm thực tế với mô hình tư duy giúp tôi không chỉ xử lý vấn đề trước mắt, mà còn học được cách nhìn xa và hệ thống hơn.
1. Margin of Safety (Biên an toàn)
- Tình huống: Kế hoạch timeline migration ban đầu rất chặt chẽ, gần như không có buffer. Khi một số ứng dụng core banking cần thêm thời gian test bảo mật, toàn bộ tiến độ có nguy cơ trễ.
- Áp dụng mental model: Giống như khi đầu tư tài chính, luôn cần một “biên an toàn” để chống lại biến động. Trong quản lý dự án cũng vậy – cần dự phòng về thời gian, ngân sách, và tài nguyên.
- Bài học: Lên kế hoạch thực tế hơn, giữ lại khoảng 10–15% buffer để hấp thụ những bất ngờ.
2. Inversion (Nghĩ ngược)
- Tình huống: Ban đầu, team tập trung vào “làm thế nào để thành công”. Nhưng khi sự cố security gap xuất hiện, chúng tôi nhận ra cần nghĩ theo hướng ngược lại: “Điều gì có thể khiến dự án thất bại?”.
- Áp dụng mental model: Việc liệt kê rõ ràng những rủi ro lớn nhất (thiếu security baseline, dependency giữa các nhóm, acceptance criteria chưa rõ) giúp cả team chủ động phòng tránh.
- Bài học: Đặt câu hỏi “làm sao để thất bại?” ngay từ đầu có thể tiết kiệm hàng tháng xử lý khủng hoảng về sau.
3. Opportunity Cost (Chi phí cơ hội)
- Tình huống: Có lúc khách hàng phân vân giữa dùng bản miễn phí của công cụ giám sát hoặc mua gói enterprise có support.
- Áp dụng mental model: Lợi ích trước mắt là tiết kiệm chi phí license, nhưng cái giá ẩn là downtime lâu hơn nếu sự cố, làm mất uy tín và ảnh hưởng SLA.
- Bài học: Cần tính đến chi phí cơ hội – cái “rẻ” ngắn hạn đôi khi dẫn đến cái “đắt” dài hạn.
4. Principal–Agent Problem
- Tình huống: Khách hàng ký hợp đồng với tập đoàn, kỳ vọng năng lực toàn cầu, nhưng khi triển khai lại do một đơn vị thành viên đảm nhiệm. Năng lực không đồng đều gây chênh lệch kỳ vọng.
- Áp dụng mental model: Đây chính là “vấn đề người ủy thác – đại diện”. Người bán (agent) có động lực khác với người mua (principal).
- Bài học: Ngay từ đầu, cần minh bạch vai trò, phạm vi và nguồn lực của đơn vị triển khai, tránh “quảng cáo” quá so với thực tế.
5. Feedback Loops
- Tình huống: Một số module cloud ban đầu thiết kế chưa sát nhu cầu. Nếu chỉ chờ đến UAT cuối cùng, việc sửa sai sẽ tốn kém.
- Áp dụng mental model: Thiết lập vòng phản hồi ngắn qua Cloud Advisory Board, nhận feedback mỗi 2 tuần. Điều này giúp tinh chỉnh sớm.
- Bài học: Vòng phản hồi càng ngắn, chi phí sửa sai càng rẻ.
6. Trust as a Currency
- Tình huống: Trong những tuần đầu, khi ứng dụng đầu tiên gặp sự cố kết nối, khách hàng hoài nghi.
- Áp dụng mental model: Ở dự án đầu tiên, niềm tin là “đồng tiền chung”. Sự minh bạch – ví dụ báo cáo sự cố ngay trong ngày thay vì giấu nhẹm – giúp tăng uy tín.
- Bài học: Một khi niềm tin được xây dựng, các quyết định sau này (ví dụ approve thêm ngân sách) diễn ra dễ dàng hơn nhiều.
7. Law of Diminishing Returns
- Tình huống: Khi một ứng dụng legacy không chạy ổn định trên môi trường mới, khách hàng đề nghị bổ sung thêm người vào team.
- Áp dụng mental model: Thực tế, thêm người vào lúc đó chỉ khiến chi phí tăng mà hiệu quả không tăng tương ứng – vì vấn đề nằm ở độ phức tạp kỹ thuật.
- Bài học: Tốt hơn nên tập trung cho team cốt lõi thêm thời gian, đồng thời dùng nhân sự bổ sung cho luồng công việc khác để không trì trệ toàn dự án.
8. Working Backwards
- Tình huống: Lúc đầu team chỉ chăm chăm tạo đủ số lượng servers, VPC, subnet theo thiết kế. Nhưng khách hàng quan tâm hơn outcome: liệu ứng dụng có đáp ứng SLA không.
- Áp dụng mental model: Bắt đầu từ outcome (ứng dụng chạy ổn định với latency < 200ms), rồi “làm ngược” ra thiết kế hạ tầng.
- Bài học: Outcome > Output.
9. Second-order Thinking
- Tình huống: Một hệ thống cũ sắp end-of-life được tạm thời giữ lại để tiết kiệm chi phí migration.
- Áp dụng mental model: Quyết định này tưởng như tiết kiệm ngắn hạn, nhưng kéo theo hậu quả: security risk, chi phí duy trì tăng, và migration về sau khó hơn.
- Bài học: Luôn suy nghĩ đến hệ quả bậc hai, bậc ba.
10. Bayes’ Theorem (Cập nhật niềm tin)
- Tình huống: Một pilot replatform thành công với ứng dụng CRM.
- Áp dụng mental model: Dựa trên đó, chúng tôi điều chỉnh niềm tin (prior → posterior): xác suất thành công của các ứng dụng tương tự cao hơn, do đó ưu tiên migration nhóm này trước.
- Bài học: Cập nhật liên tục niềm tin theo dữ liệu mới giúp ra quyết định nhanh và linh hoạt hơn.
11. Tragedy of the Commons (Bi kịch cái chung)
- Tình huống: Các nhóm dev khác nhau đều muốn dùng tài nguyên cloud nhiều nhất có thể, dẫn đến chi phí phình to và hạ tầng quá tải.
- Áp dụng mental model: Đây chính là bi kịch tài nguyên chung. Giải pháp là đặt quota, tagging và chargeback để ai dùng thì phải chịu trách nhiệm.
- Bài học: Governance là chìa khóa.
12. Complex Adaptive Systems (Hệ thống thích nghi phức tạp)
- Tình huống: Mỗi quyết định kỹ thuật đều phải cân bằng giữa luật ngành, nhu cầu kinh doanh, và giới hạn công nghệ. Không thể vẽ một plan cố định 12 tháng.
- Áp dụng mental model: Xem dự án như một hệ thống phức tạp, cần nguyên tắc thích ứng thay vì chi li kiểm soát. Ví dụ: quy định “mọi service mới đều phải có IaC + CI/CD” thay vì mô tả từng bước chi tiết.
- Bài học: Đặt nguyên tắc, không đặt checklist bất biến.
13. Sunk Cost Fallacy (Ngụy biện chi phí chìm)
- Tình huống: Một ứng dụng kế toán cũ đã tiêu tốn nhiều tháng effort nhưng vẫn kém hiệu quả khi chạy trên cloud.
- Áp dụng mental model: Thay vì “đã làm nhiều thì phải làm tiếp”, chúng tôi dừng lại và cân nhắc giải pháp SaaS thay thế.
- Bài học: Quyết định dựa trên giá trị tương lai, không dựa trên chi phí đã bỏ.
14. Network Effects (Hiệu ứng mạng lưới)
- Tình huống: Ban đầu chỉ có phòng IT core tham gia Cloud Advisory Board. Sau khi họ có kết quả tốt, các phòng ban khác (compliance, risk, HR) cũng muốn tham gia.
- Áp dụng mental model: Càng nhiều bên tham gia, giá trị hội đồng tăng theo cấp số nhân – từ chia sẻ kinh nghiệm đến đồng thuận trong quyết định.
- Bài học: Tạo hiệu ứng kéo theo thay vì ép buộc.
15. Comparative Advantage (Lợi thế so sánh)
- Tình huống: Khách hàng muốn tự vận hành toàn bộ hạ tầng cloud.
- Áp dụng mental model: Thực tế, năng lực lõi của họ là tài chính – không phải cloud infra. Việc để vendor đảm nhiệm phần hạ tầng giúp họ tập trung vào giá trị kinh doanh.
- Bài học: Chọn đúng chỗ để tập trung.
16. Critical Mass (Khối lượng tới hạn)
- Tình huống: Ban đầu nhiều người nghi ngờ. Nhưng khi 5 ứng dụng trọng yếu đã migration thành công, toàn bộ dự án đạt “đà tự thân” – những ứng dụng còn lại được kéo theo.
- Áp dụng mental model: Một khi vượt qua ngưỡng khối lượng tới hạn, quán tính thay đổi sẽ làm phần còn lại dễ dàng hơn nhiều.
- Bài học: Đầu tư cho “first wins” để tạo đà.
17. Pareto Principle (80/20)
- Tình huống: Trong hàng chục ứng dụng, chỉ vài ứng dụng tài chính lõi tạo ra 80% giá trị kinh doanh.
- Áp dụng mental model: Ưu tiên migration nhóm này trước để ROI hiển hiện, từ đó thuyết phục các bên còn nghi ngờ.
- Bài học: Không phải việc nào cũng quan trọng như nhau.
18. Resistance to Change (Kháng cự thay đổi)
- Tình huống: Một số bộ phận e ngại cloud vì sợ rủi ro.
- Áp dụng mental model: Chúng tôi tạo quick win: migrate một ứng dụng nhỏ, cho họ thấy hệ thống chạy ổn định và an toàn. Từ đó, họ giảm kháng cự.
- Bài học: Niềm tin xây bằng minh chứng, không phải thuyết phục suông.
19. Loss Aversion (Ác cảm mất mát)
- Tình huống: Khi nói về lợi ích cloud (scalability, agility), khách hàng không mấy hứng thú. Nhưng khi nói “nếu không chuyển đổi, rủi ro downtime sẽ tăng gấp đôi”, họ quan tâm ngay.
- Áp dụng mental model: Con người sợ mất mát hơn là mong lợi ích.
- Bài học: Khung thông điệp quan trọng không kém nội dung kỹ thuật.
20. Endowment Effect (Hiệu ứng sở hữu)
- Tình huống: Bộ phận IT gắn bó với on-premise nhiều năm, có xu hướng đánh giá nó cao hơn thực tế.
- Áp dụng mental model: Khi cho họ tham gia trực tiếp thiết kế cloud, họ cảm thấy “cloud cũng là của mình” → giảm kháng cự, tăng cam kết.
- Bài học: Trao quyền để giảm kháng cự.
Kết lại
Nhìn lại, dự án này không chỉ là một câu chuyện về cloud migration, mà còn là hành trình trưởng thành trong cách tư duy. Các mental models trở thành công cụ giúp tôi diễn giải và rút ra bài học từ trải nghiệm.
Mỗi quyết định, mỗi thách thức là một cơ hội học hỏi: đôi khi là về sự cần thiết của biên an toàn, đôi khi là về sức mạnh của niềm tin, và có khi chỉ đơn giản là tập trung vào 20% quan trọng nhất.
Chuyển đổi số là một cuộc chơi dài hơi, nhưng với cách tư duy đúng đắn, chúng ta có thể tiến xa hơn – không chỉ về công nghệ, mà cả trong sự trưởng thành cá nhân và tổ chức.
Transforming Leadership 