Tại sao tôi không tin AI sẽ giúp quy trình của bạn nhanh hơn

Tôi có cảm giác rằng mọi tổ chức hiện nay đều đang, ít nhất một phần, tập trung vào tối ưu hóa quy trình, một việc thường xảy ra khi thị trường đi xuống. Những ngày nay, còn có thêm yếu tố AI trong câu chuyện này, cùng với những kỳ vọng phi thực tế đi kèm.

Để chuẩn bị tốt nhất cho điều này, tôi đã quyết định đọc lại hai cuốn sách kinh điển trong lĩnh vực này: The Toyota Way và The Goal. Tôi đã đọc cả hai cuốn sách này thời đại học, nhưng việc đọc lại khiến tôi nhận ra rằng nhiều bài tập tối ưu hóa quy trình quá đơn giản hóa về bản chất, và thường hiểu sai trọng tâm cần chú ý.

Nút thắt cổ chai trong quy trình

Nút thắt cổ chai trực quan

Hãy để tôi minh họa ý tôi bằng một biểu đồ Gantt. Nếu bạn nhìn vào biểu đồ này, bạn sẽ ngay lập tức thấy khâu mất nhiều thời gian nhất: phát triển phần mềm. Nếu nhiệm vụ của bạn là cải thiện thông lượng dự án, đó sẽ là điểm dừng chân đầu tiên của bạn. Và điều đó là chính xác.

Tuy nhiên, vấn đề nằm ở cách mọi người thường giải quyết nó: đổ người vào vấn đề hoặc đơn giản là giả định AI sẽ làm mọi thứ nhanh hơn rất nhiều.

Những gì mọi người thường không làm là tìm hiểu xem tại sao việc này lại mất nhiều thời gian, và quan trọng hơn: thời gian kéo dài không tự động đồng nghĩa với việc gốc rễ vấn đề nằm ở đó.

Giải quyết vấn đề ở khâu đầu vào

Chúng ta đang nói về phát triển phần mềm, nhưng điều này áp dụng cho tất cả các quy trình mất nhiều thời gian hơn mong muốn.

Mọi lập trình viên đều biết rằng bạn không thể làm dự án nhanh hơn chỉ bằng cách gõ phím nhanh hơn. Nếu đúng như vậy, chúng ta đều sẽ đi học đánh máy.

Phát triển phần mềm là việc chuyển đổi một vấn đề thành giải pháp mà máy tính có thể hiểu và giải quyết tự động. Tốt nhất là theo cách bảo mật và có khả năng mở rộng.

Để làm được điều đó, bạn cần cái nhìn tổng quan đầy đủ về vấn đề. Thông qua các tài liệu tính năng hoặc phạm vi (nếu bạn theo hướng Waterfall), hoặc thông qua sự lặp lại liên tục với các chuyên gia trong lĩnh vực (hướng Agile hơn).

Đây thường là phần làm chậm phát triển phần mềm. Đó là việc cố gắng tìm hiểu một yêu cầu tính năng mơ hồ, chỉ có tiêu đề, thực sự có ý nghĩa gì.

"Gửi email cho người dùng khi bán hàng hoàn tất" có nghĩa là gì? Ok, chúng ta có thể gửi email, nhưng nội dung email nên là gì? Nếu có vấn đề trong quá trình bán hàng, chúng ta có gửi email báo lỗi không? Khi nào thì bán hàng được coi là hoàn tất?

Chỉ cần ném AI vào vấn đề

Một lập luận mà tôi thường nghe về việc tự động hóa phát triển phần mềm (tạo code bằng AI) là bạn có thể bỏ qua phần phát triển và lập trình viên sẽ trở thành quản lý dự án. Các cuộc thảo luận xung quanh AI trong phát triển phần mềm thực sự minh họa hoàn hảo cho vấn đề này.

Nhiều người kỳ vọng kết quả của phát triển AI sẽ trông như thế này: giai đoạn Phát triển chỉ mất 3 ngày thay vì 70 ngày.

Nhưng đó không phải là cách nó hoạt động. Ở đây, chúng ta gặp phải vấn đề tương tự ở khâu đầu vào như trước đây.

Đúng là AI có thể tạo mã rất nhanh (dù điều đó có tốt hay không còn gây tranh cãi), nhưng điều đó không có nghĩa là nó đang tạo ra mã chính xác.

Trong các so sánh giữa phát triển của con người và AI, họ luôn bỏ qua việc hỗ trợ chi tiết (handholding) cần thiết để AI thực hiện công việc của mình. Nó trông giống như thế này: thời gian cho Tài liệu hóa và Phát triển AI tăng lên đáng kể vì cần sự tham gia sâu rộng hơn.

Có lẽ cách thiết lập này nhanh hơn so với cách làm việc cũ. Nhưng tôi cũng nghĩ đó là một sự so sánh không công bằng. Làm việc như vậy đòi hỏi sự tham gia sâu sắc hơn nhiều của các chuyên gia về lĩnh vực và sản phẩm. Sự tham gia này sẽ có nghĩa là phải viết ra mọi tính năng và bản sửa lỗi chi tiết đến từng chi tiết nhỏ nhất.

Điều chính xác này là những gì các lập trình viên đã mong mỏi từ đầu nghề nghiệp: Nhận được một phác thảo chi tiết về vấn đề và kết quả cuối cùng nên trông như thế nào.

Nếu bạn cung cấp cho các lập trình viên con người cùng một lượng tài liệu tính năng/phạm vi đó, bạn cũng sẽ thấy năng suất của họ tăng vọt.

Thực sự tăng tốc quy trình

Nếu bạn muốn tăng tốc quy trình, bạn cần đảm bảo rằng những người cần thực hiện công việc có đủ phương tiện để thực hiện công việc đó.

Điều này có nghĩa là nếu quy trình phê duyệt pháp lý của bạn đang chậm, bạn hãy xem xét những gì cần thiết để bắt đầu quy trình phê duyệt pháp lý. Nếu họ phải đuổi theo năm người khác nhau để lấy các tài liệu chưa hoàn chỉnh, bạn sẽ không thể tăng tốc quy trình đó bằng cách thêm nhiều luật sư vào bộ phận.

Một trong những bài học lớn của The Goal là: "Các nút thắt cổ chai nên nhận được các đầu vào có thể dự đoán và chất lượng cao".

Tôi nghĩ đó nên là điểm dừng chân đầu tiên trong tự động hóa quy trình.

Nợ kiến trúc không chỉ là nợ kỹ thuật