Trong bài viết trước, tôi đã đề cập đến tình trạng hiện tại của việc định nghĩa yêu cầu AI—cách quy trình đang chuyển từ 'sắp xếp' sang 'quyết định,' và mối lo ngại của tôi rằng nhiều nơi làm việc đang mù quáng giao phó khả năng tư duy của mình mà không nhận ra sự thay đổi này.
Lần này, tôi muốn gióng thêm một hồi chuông cảnh báo về một vấn đề liên quan khác.
Vấn đề là các CTO và SE nội bộ, vì giờ đây có thể code cực nhanh nhờ phát triển dựa trên AI, đang trở thành những người chỉ đơn thuần nhận lệnh từ các phòng ban nghiệp vụ—về cơ bản là 'internal SIer.'
Động Lực Mới do Phát Triển Dựa Trên AI Tạo Ra
Không thể phủ nhận rằng sự lan rộng của phát triển dựa trên AI đã hạ thấp rào cản đối với việc lập trình một cách đáng kể.
Kết quả là, các yêu cầu từ phòng ban nghiệp vụ như 'Tôi muốn cái này' hoặc 'Tôi muốn hệ thống hóa cái kia' đang đến với tốc độ không thể so sánh với trước đây. Không hiếm trường hợp nhân viên nghiệp vụ tự mình liệt kê các yêu cầu bằng AI, hoặc thậm chí tạo ra các bản mẫu.
Thoạt nhìn, điều này có vẻ tốt. Nó trông giống như một kịch bản lý tưởng nơi các phòng ban nghiệp vụ dẫn đầu trong DX và hợp tác với IT để triển khai hệ thống một cách nhanh chóng.
Tuy nhiên, có một cái bẫy ở đây.
Tôi cảm thấy ngày càng nhiều CTO và SE nội bộ đang trở thành 'những người chỉ đơn giản là hiện thực hóa các yêu cầu từ phòng ban nghiệp vụ.' Họ nhận yêu cầu, nhận ra nó về mặt kỹ thuật, và giao hàng. Đây chính xác là những gì một internal SIer làm.
Điều Gì Chờ Đợi Ở Cuối Con Đường Nhận Lệnh
Đáp ứng các yêu cầu nghiệp vụ tự nó không sai. Vấn đề là điều gì xảy ra khi bạn tiếp tục thực hiện mọi yêu cầu riêng lẻ của từng phòng ban một cách nguyên trạng.
Tôi gọi đó là sự gia tăng của 'hệ thống lạc' và 'cơ sở dữ liệu lạc.'
Phòng Sales tạo CRM riêng, Marketing thiết lập nền tảng phân tích dữ liệu riêng, và Customer Support xây dựng hệ thống quản lý ticket riêng. Mỗi phòng ban đều hài lòng vì có được một hệ thống tối ưu cho công việc của họ với tốc độ cao.
Nhưng toàn bộ công ty thì sao?
Dữ liệu bị phân tán ở nhiều nơi khác nhau, và định dạng không được thống nhất. Cùng một thông tin khách hàng tồn tại dưới nhiều dạng khác nhau trên nhiều cơ sở dữ liệu. Mỗi khi bạn cố gắng liên kết dữ liệu giữa các phòng ban, bạn cần làm thủ công hoặc phát triển tùy chỉnh.
Đây là một silo công nghệ.
Bởi vì phát triển dựa trên AI giúp xây dựng hệ thống quá dễ dàng, sự silo hóa này tiến triển với tốc độ chưa từng thấy. Trước đây, chi phí phát triển cao đóng vai trò như một chiếc phanh tự nhiên. Đã có một động lực là 'rất khó để xây dựng, vì vậy hãy chọn lọc nghiêm ngặt chỉ những gì thực sự cần thiết.'
Giờ đây, chiếc phanh đó đã biến mất. Bởi vì nó có thể được xây dựng, nên nó được xây dựng. Kết quả là, các hệ thống và cơ sở dữ liệu lạc nhân lên, và số lượng ứng dụng cũng như cơ sở hạ tầng cần quản lý không ngừng tăng lên.
Tại Sao Điều Này Lại Nghiêm Trọng Trong Kỷ Nguyên AI
Bạn có thể nghĩ, 'Dù hệ thống có hơi phân tán một chút, miễn là chúng hoạt động được thì cũng ổn.' Tuy nhiên, trong kỷ nguyên AI, sự silo hóa này gây ra những vấn đề nghiêm trọng hơn bao giờ hết.
Lý do rất đơn giản: Giá trị của AI tỷ lệ thuận với mức độ tích hợp dữ liệu.
AI thực sự phát huy sức mạnh khi dữ liệu được tích hợp trên toàn bộ công ty, cho phép có những hiểu biết vượt qua các phòng ban. Chỉ khi dữ liệu bán hàng, lịch sử khách hàng, hiệu quả tiếp thị và dữ liệu tài chính được tích hợp, AI mới có thể cung cấp những hiểu biết hỗ trợ các quyết định quản lý.
Trong một môi trường đầy rẫy các hệ thống lạc, dữ liệu ngay từ đầu đã không được kết nối. Bạn có thể đạt được những tối ưu hóa AI nhỏ trong phạm vi phòng ban, nhưng sẽ không bao giờ đạt được việc sử dụng AI trên toàn công ty—loại thực sự có tác động kinh doanh.
Bằng cách tích lũy các tối ưu hóa theo phòng ban, bạn vĩnh viễn đánh mất tối ưu hóa tổng thể. Đây là rủi ro mà các CTO và SE nội bộ theo kiểu nhận lệnh vô tình tạo ra.
Vai Trò Thực Sự Các CTO và SE Nội Bộ Nên Đảm Nhận
Vậy, các CTO và SE nội bộ nên đảm nhận vai trò như thế nào?
Câu trả lời rất rõ ràng: Hãy trở thành 'nhà thiết kế và người quyết định' chứ không chỉ là 'người xây dựng.'
'Thiết kế' ở đây không có nghĩa là thiết kế từng hệ thống riêng lẻ. Nó có nghĩa là thiết kế kiến trúc dữ liệu và hệ thống cho toàn bộ công ty.
Khi có yêu cầu từ một phòng ban nghiệp vụ, thay vì chỉ xây dựng nó, bạn hãy đánh giá 'yêu cầu này nên được định vị như thế nào trong kiến trúc toàn công ty.' Trong một số trường hợp, bạn phải nói, 'Điều này không nên được xây dựng riêng lẻ.' Nếu nó có thể được xử lý bằng cách mở rộng các nền tảng hiện có, hãy hướng dẫn họ đến đó.
Điều này có thể gây bất tiện cho các phòng ban nghiệp vụ. Họ có thể hỏi, 'Tại sao anh lại nói về toàn bộ công ty khi tôi chỉ muốn cái này được xây dựng ngay bây giờ?'
Nhưng chỉ có CTO và SE nội bộ mới có thể đưa ra đánh giá đó. Các phòng ban nghiệp vụ có động cơ để tối ưu hóa lĩnh vực của riêng họ, nhưng không có động cơ để bảo vệ kiến trúc toàn công ty. Đó là lý do tại sao các chuyên gia kỹ thuật phải đóng vai trò người bảo vệ của tối ưu hóa tổng thể.
'Quyết Định Không Xây Dựng' Là Kỹ Năng Kỹ Thuật Cao Nhất
Trớ trêu thay, khả năng quan trọng nhất được yêu cầu ở các CTO và SE nội bộ trong kỷ nguyên AI có thể là 'quyết định không xây dựng.' Đây là lý do tại sao tôi gọi họ là 'người quyết định.'
Một yêu cầu đến từ phòng ban nghiệp vụ. Về mặt kỹ thuật là khả thi. Với AI, nó có thể được định hình trong vài ngày. Nhưng bạn phải có sức mạnh để đặt câu hỏi liệu việc xây dựng nó có thực sự đúng đắn cho toàn bộ công ty hay không.
Yêu cầu này có thể được xử lý bởi các nền tảng hiện có không? Cấu trúc dữ liệu có phù hợp với quy tắc của công ty không? Một hệ thống tương tự đã được chạy ở phòng ban khác chưa? Việc thêm một hệ thống được tối ưu hóa riêng lẻ sẽ gây khó khăn cho việc tích hợp dữ liệu trong tương lai không?
Có thể đặt ra những câu hỏi này mới là sức mạnh kỹ thuật thực sự trong kỷ nguyên AI.
AI sẽ xử lý việc viết code. Tuy nhiên, đánh giá xây dựng cái gì và không xây dựng cái gì là điều AI không thể làm được. Như tôi đã đề cập trong bài viết trước rằng 'định nghĩa yêu cầu sẽ trở thành một quá trình ra quyết định,' vai trò của CTO và SE nội bộ tuân theo cùng một cấu trúc chính xác.
Thay vì trở thành người nhận lệnh, vai trò của bạn với tư cách là nhà thiết kế kiến trúc toàn công ty ngày càng trở nên quan trọng hơn nhờ kỷ nguyên AI.
Tạo Ra 'Trạng Thái Sẵn Sàng' Vì Tương Lai Không Thể Đoán Trước
Mặc dù tôi đã nhấn mạnh tầm quan trọng của 'quyết định không xây dựng,' vẫn còn một góc nhìn nữa mà các CTO và SE nội bộ nên có.
Bởi vì tương lai không thể đoán trước trong kỷ nguyên AI, bạn phải giữ cho công ty ở trong trạng thái có thể di chuyển bất cứ lúc nào.
Hiện tại, luận điệu rằng 'SaaS đã chết' đang lan rộng. Kể từ khi CEO của Microsoft, Satya Nadella, thốt ra những lời này vào cuối năm 2024, nhiều người đã dự đoán về sự kết thúc của SaaS. Quả thực, định giá của SaaS đang bị nén lại, và sự quan tâm của nhà đầu tư đang nhanh chóng chuyển sang các nền tảng AI-native.
Nhưng liệu SaaS có thực sự chết không?
Tôi không nghĩ nó đơn giản như vậy. Các công ty SaaS đang đầu tư mạnh vào R&D để tìm ra hình thức phần mềm tối ưu cho kỷ nguyên AI. Tích hợp AI đại lý, thanh toán dựa trên kết quả, nền tảng AI chuyên ngành... rất có thể các sản phẩm sẽ xuất hiện dưới những hình thức mà chúng ta hiện tại không thể tưởng tượng được.
Nói cách khác, cả việc kết luận 'SaaS đã chết' và lao vào phát triển nội bộ, cũng như ngừng suy nghĩ bằng cách nghĩ 'SaaS là đủ,' đều là những rủi ro.
Lập trường mà một CTO/SE nội bộ nên thực hiện không phải là đặt cược vào một trong hai. Đó là thiết kế một kiến trúc có thể đáp ứng bất kể mọi thứ đi theo hướng nào.
Cụ thể, hãy chuẩn hóa cách dữ liệu được lưu trữ và tạo ra một cấu trúc không bị khóa vào một SaaS hoặc công cụ cụ thể nào. Giữ cho các kết nối hệ thống được kết nối lỏng lẻo qua API. Đừng để các hệ thống lạc phát triển tràn lan; hãy thống nhất nền tảng dữ liệu của công ty.
Với triết lý thiết kế này, nếu SaaS phát triển và các sản phẩm tốt hơn ra đời, bạn có thể chuyển đổi. Ngược lại, nếu rõ ràng rằng việc xây dựng nội bộ tốt hơn cho một lĩnh vực nào đó, bạn có thể di chuyển sang đó.
Bạn không thể dự đoán tương lai. Nhưng bạn có thể tạo ra một cấu trúc có thể đáp ứng được nó. Đó chính là bản chất của thiết kế kiến trúc được yêu cầu ở các CTO và SE nội bộ trong kỷ nguyên AI. Ngược lại, chỉ có các chuyên gia kỹ thuật mới làm được điều này. Tôi không muốn bạn dành những nguồn lực quý giá đó để làm một internal SIer.
Tăng Tốc Các Quy Trình Thượng Nguồn Với AI
Như một công cụ hỗ trợ việc chuyển đổi các quy trình thượng nguồn, chúng tôi đã phát hành 'GEAR-UI,' một công cụ AI tạo định nghĩa màn hình và mock, dưới dạng OSS (Phần mềm nguồn mở).
Bằng cách biến nó thành OSS, chúng tôi hy vọng giải phóng người dùng khỏi các rào cản triển khai và giúp họ đối mặt với những điều cốt lõi. Hãy sử dụng nó, đặc biệt là cho những 'đánh giá trước khi xây dựng' mà tôi đã thảo luận.
Việc tùy chỉnh là miễn phí. Hãy tận dụng nó.
