Tất cả bài viết
Tất cả bài viết
Đôi khi phải té một cú thật đau thì mới biết mình đang đi lạc ở đâu. Nhật ký một lần thử sức làm AI app, ngã ê ẩm nhưng nhìn lại cũng được ít bài học đắt giá.
Có một nghịch lý buồn cười: bạn có thể dựng lên một ứng dụng chạy mượt mà chỉ trong vài đêm, nhưng lại có thể trượt chân ngã đau điếng chỉ vì… một định nghĩa chưa thông.
Cú vấp gần đây nhất của mình là tại một cuộc thi phát triển sản phẩm. Ý tưởng nghe rất kêu: “Use Agile to build Agile” — một AI Agent đồng hành hỗ trợ Product Owner (PO) và Project Manager (PM) ra quyết định. Mình bước vào cuộc chơi với toàn bộ sự tự tin của một người có kỹ năng kỹ thuật, làm prototype nhanh và hiểu quy trình làm việc.
Thế nhưng, khi đứng trước ban giám khảo, toàn bộ sự tự tin đó bị bẻ gãy chỉ sau hai câu hỏi phản biện.
Khi trình bày về cơ chế ra quyết định, mình đưa ra mô hình tam giác ràng buộc nhưng lại ghi là: Scope - Capacity - Cost.
Ban giám khảo bắt lỗi ngay lập tức: “Tam giác quản lý dự án kinh điển (Iron Triangle) là Scope - Time - Cost, tại sao lại là Capacity?”
Khoảnh khắc đó mình giật mình nhận ra: vì xuất phát điểm quen nhìn vào năng lực đội ngũ và tải công việc, mình đã vô thức đem góc nhìn nội bộ của team đánh tráo vào một nguyên lý chuẩn tắc. Khi nền móng khái niệm bị lệch, mọi logic suy luận phía sau lập tức mất đi độ tin cậy.
Đây mới là câu hỏi khiến mình đứng hình nhất.
Một PO thực thụ sinh ra không phải để làm thợ cân đo đong đếm task hay điều phối nguồn lực xem sprint này ai rảnh ai bận. Sứ mệnh cốt lõi của PO là tối đa hóa giá trị sản phẩm (Maximize Value).
Bằng việc chỉ tập trung vào Scope, Capacity và Cost, con AI Agent của mình vô tình mới dừng lại ở tầng tối ưu vận hành thay vì giải quyết tầng bài toán chiến lược. Nó trả lời trơn tru câu hỏi "Làm sao để team chạy kịp với nguồn lực này?", nhưng lại bỏ ngỏ câu hỏi tối thượng của một người làm chủ sản phẩm:
“Quyết định này mang lại giá trị kinh doanh gì? Tại sao chọn đầu tư vào tính năng này thay vì tính năng khác dựa trên impact, ROI hay trải nghiệm cốt lõi, chứ không phải chỉ vì team đang còn chỗ trống?”
Mình nhận ra mình không hề thiếu giải pháp công nghệ, mà là đã định vị giải pháp ở tầng quá thấp so với kỳ vọng thực sự của vai trò PO.
Cảm giác trượt một cuộc thi vì bị bắt lỗi khái niệm nền tảng lúc đầu rất cay cú. Nhưng khi ngồi xuống nhìn lại, mình thấy biết ơn vì cú ngã này đến sớm.
Reflection không phải là ngồi tiếc nuối hay tự dằn vặt, mà là sự dũng cảm đối diện với sự thật:
Sau bài học này, mình thấm thía sâu sắc cách phân bổ kỹ năng qua hai giai đoạn:
Khả năng code nhanh, dựng prototype trong thời gian ngắn là một lợi thế cực lớn để biến ý tưởng thành hình. Nhưng nếu chỉ có kỹ năng thực thi, bạn rất dễ bị "ru ngủ" trong cảm giác thỏa mãn ảo rằng dự án đang tiến triển tốt chỉ vì sản phẩm đã chạy được.
Đây mới là lúc kỹ năng cứu bạn một bàn thua trông thấy. Nó buộc bạn phải:
Làm sản phẩm thực chất là hành trình liên tục va đập để gọt bớt sự ngộ nhận của bản thân. Một cú ngã giúp mình nhận ra mình đang đứng ở tầng tư duy nào luôn có giá trị hơn một sản phẩm hoàn thiện nhưng chỉ lướt trên bề mặt.
Điểm dừng này không phải là dấu chấm hết cho ý tưởng, mà là bước lùi cần thiết để lần tới quay lại, con AI Agent đó sẽ thực sự đứng ở vị thế của một người đồng hành tạo ra Giá trị.
Mục lục
Bạn thấy hành trình này thế nào?
Cùng chủ đề