- Công cụ lập trình AI được cho là giúp tăng tốc độ phát triển, nhưng nút thắt thực sự không nằm ở việc viết code mà ở quy trình tổ chức kém hiệu quả
- Khi tăng sản lượng code, tình trạng ùn ứ ở các bước ngoài phát triển như chờ review, chậm triển khai, yêu cầu không rõ ràng càng nghiêm trọng hơn, và cycle time thực tế thậm chí còn tăng
- Theo Lý thuyết ràng buộc (Theory of Constraints) của Eli Goldratt, tối ưu một công đoạn không phải nút thắt sẽ không làm hệ thống nhanh hơn mà còn khiến nó tệ đi
- Trong tình huống ngay cả người “viết” ra code do AI sinh cũng không thật sự hiểu hết, sẽ xuất hiện rủi ro mang tính cấu trúc: bề mặt ứng phó sự cố rộng hơn nhưng số người có thể suy luận về hệ thống lại ít đi
- Lợi thế cạnh tranh không thuộc về đội viết code nhanh nhất, mà thuộc về đội biết phải xây cái gì và đưa nó đến tay người dùng
Khởi đầu của một sự tối ưu sai hướng
- Đã xuất hiện những công bố cho rằng sau khi áp dụng AI coding assistant, lượng code đầu ra tăng 40%
- Nhưng lại thiếu câu hỏi “tăng tốc để hướng tới điều gì?”
- Nếu dồn nguồn lực vào một công đoạn vốn đã nhanh (viết code), toàn bộ hệ thống sẽ chậm đi
- Tăng tốc phần không phải nút thắt sẽ làm tồn kho code chưa hoàn tất chất đống, gây suy giảm chất lượng và hỗn loạn
Tối ưu sai chỗ sẽ làm hệ thống tệ hơn
- Cốt lõi của Lý thuyết ràng buộc (Theory of Constraints) được Eli Goldratt nêu trong tiểu thuyết The Goal năm 1984: mọi hệ thống đều có đúng một nút thắt, và thông lượng tổng thể được quyết định bởi thông lượng của nút thắt đó
- Nếu tối ưu một công đoạn không phải nút thắt, hệ thống không nhanh hơn mà chỉ tích thêm tồn kho công việc chưa hoàn thành, kéo theo lead time tăng, hỗn loạn và chất lượng đi xuống
- Ví dụ dễ hiểu: dù trạm A làm widget nhanh hơn, nếu tốc độ xử lý của trạm B là nút thắt vẫn giữ nguyên, thì cũng chỉ giống như đống widget chưa xử lý chất chồng giữa A và B
"Sản lượng code gấp 3" thực tế dẫn đến điều gì
- Developer tạo PR nhanh hơn bao giờ hết, nhưng số reviewer vẫn như cũ, nên PR phải nằm trong hàng chờ review một ngày, hai ngày, thậm chí một tuần
- Tác giả lúc đó đã chuyển ngữ cảnh sang tính năng tiếp theo có AI hỗ trợ, nên khi phải phản hồi comment review cho đoạn code viết từ 8 ngày trước, họ gần như không còn nhớ rõ đoạn đó
- Review quá nhiều dẫn tới kiểu rubber-stamp review phê duyệt cho có mà không đọc kỹ
- CI mất 45 phút và lại fail vì flaky test rồi phải chạy lại; pipeline triển khai thì chờ phê duyệt thủ công từ người đang họp, khiến tính năng bị bỏ ở staging suốt 3 ngày
- Developer đã mở thêm 2 PR nữa, khiến WIP (Work In Progress) tăng vọt, ai cũng làm đồng thời 6 việc nhưng chẳng cái nào hoàn tất
- Code được tạo ra nhiều hơn nhưng phần mềm phát hành ít đi hơn; cycle time xấu đi nhưng dashboard vẫn hiển thị năng suất tăng 40%
- Rủi ro bổ sung của code do AI sinh: người “viết” thực ra không tự viết mà chỉ tạo bằng prompt rồi lướt qua, nên khi production gặp sự cố lúc 2 giờ sáng, cả người trực on-call lẫn người viết prompt đều không giải thích nổi đoạn code đó
- Code tăng lên còn mức độ hiểu biết lại giảm xuống không phải là tăng năng suất, mà là một quả bom hẹn giờ với dashboard đẹp hơn
Nút thắt thực sự 1: Không biết phải xây cái gì
- PM đã không nói chuyện với người dùng thật suốt 2 tháng, nhưng yêu cầu lại được gửi xuống dưới dạng 3 dòng Jira ticket và một link Figma
- Kỹ sư mỗi ngày phải đưa ra 50 quyết định vi mô (hành vi, edge case, xử lý lỗi) chỉ bằng suy đoán, vì không có đặc tả nào rõ ràng
- Có đội đã xây một tính năng trong 6 tuần dựa trên điều nhân viên sales chuyển qua Slack về những gì một khách hàng tiềm năng có lẽ đã nói trong cuộc gọi; cuối cùng khách đó không mua, và tính năng chỉ có 11 người dùng (trong đó 9 người là QA nội bộ)
- Viết code nhanh hơn chỉ làm tăng tốc độ tạo ra thứ sai, về bản chất là tự động hóa sự phỏng đoán
- Nút thắt nằm ở mức độ hiểu bài toán, thứ không thể giải quyết bằng cách gõ nhanh hơn
Nút thắt thực sự 2: Mọi thứ xảy ra sau khi code “xong”
- Ở đa số tổ chức, viết code chỉ chiếm khoảng 20% toàn bộ hành trình; 80% còn lại là thời gian code nằm chờ trong nhiều hàng đợi khác nhau
- Có trường hợp một tính năng chỉ mất một buổi chiều để viết code nhưng lại cần 2 tháng để lên production
- PR review, CI, staging, QA, security review, phê duyệt sản phẩm, deployment window, canary rollout... tạo thành chuỗi handoff, chờ đợi và hàng đợi kéo dài
- Phần lớn thời gian, code không hề di chuyển mà chỉ nằm đó chờ ai đó xem, chờ pipeline chạy, chờ được cho phép tồn tại
- Muốn phát hành nhanh hơn, phải tìm ra điểm công việc bị kẹt lại, và đo tỷ lệ giữa thời gian chờ trong hàng đợi so với thời gian thực sự làm việc
Nút thắt thực sự 3: Vòng luẩn quẩn của niềm tin triển khai
- Khi test còn flaky, khả năng observability thì tệ, và không ai tin vào quy trình canary, các team sẽ sợ triển khai
- Vì sợ, họ gom thay đổi thành các bản phát hành lớn hơn; điều này làm rủi ro tăng lên, khiến việc triển khai càng đáng sợ hơn, rồi lại tiếp tục gom lớn hơn nữa — một vòng luẩn quẩn của nỗi sợ
- Nếu lại cộng thêm việc tăng tốc sản lượng code: code nhiều hơn nhưng văn hóa triển khai vẫn đầy sợ hãi, nên batch ngày càng lớn và tần suất phát hành ngày càng thấp
Nút thắt thực sự 4: Thiếu phản hồi sau khi phát hành
- Sau khi làm xong và phát hành tính năng, không có phân tích tử tế, không có phỏng vấn người dùng sau phát hành, và cũng không có ai kiểm tra xem tính năng đó có thật sự giải quyết được vấn đề hay không
- Tính năng tiếp theo cũng là phỏng đoán, rồi cái sau nữa cũng là phỏng đoán; toàn bộ product roadmap trở thành chuỗi suy đoán không có phản hồi
- Tăng tốc sản lượng code chỉ đơn giản là làm vòng lặp “xây xong, phát hành, nhún vai” quay nhanh hơn
Nút thắt thực sự 5: Lịch họp là bức tường chịu lực
- Đôi khi nút thắt không nằm ở kỹ thuật mà là các cuộc họp để ra quyết định, việc thống nhất API contract giữa 3 team đã không nói chuyện với nhau cả tháng, hoặc backlog tồn 2 tuần của một architect là điểm phê duyệt duy nhất cho mọi thiết kế quan trọng
- Vì quy trình lập kế hoạch theo quý mất tới 6 tuần, nên ngay cả việc khẩn cấp cũng phải chờ 5 tuần mới có thể bắt đầu
- Cũng có trường hợp tính năng chưa thể phát hành chỉ vì “đang chờ họp với một người đang nghỉ phép”
- Đây là vấn đề phối hợp, vấn đề con người, vấn đề chính trị, hoàn toàn không liên quan đến tốc độ viết code
Thay vào đó nên làm gì
- Lập bản đồ value stream: theo dõi một tính năng từ ý tưởng đến production, ghi lại thời gian ở từng giai đoạn và thời gian chờ giữa các giai đoạn
- Đo cycle time: đừng đo số dòng code, số PR được merge hay story point; hãy đo thời gian từ commit đến khi lên production và người dùng thật sự dùng được
- Loại bỏ trạng thái chờ: nếu PR review mất 2 ngày, hãy xử lý bằng pair programming, PR nhỏ, khung giờ review chuyên biệt, quy ước review bất đồng bộ. Nếu triển khai đang chờ phê duyệt thủ công, hãy tự động hóa hoặc ít nhất chuyển sang nút bấm trên Slack
- Ngừng bắt đầu, tập trung hoàn thành: WIP limit tồn tại có lý do; 3 việc hoàn thành tốt hơn 10 việc đang làm dở. Mọi thứ đang dở dang đều tạo thêm chi phí chuyển ngữ cảnh
- Nói chuyện với người trực tiếp làm việc: developer vốn đã biết nút thắt ở đâu; họ nói điều đó trong standup và đã biến nó thành meme trên Slack suốt nhiều tháng. Chỉ là họ nghĩ chẳng ai lắng nghe
Kết luận cốt lõi
- Thay vì VP công bố “sản lượng code tăng 40%”, lẽ ra phải nói rằng “phân tích value stream cho thấy một tính năng trung bình phải chờ 9 ngày giữa các giai đoạn, và chúng tôi sẽ cắt con số đó xuống một nửa”
- Lợi thế cạnh tranh không thuộc về đội viết code nhanh nhất, mà thuộc về đội hiểu cần phải xây gì, xây xong và đưa được đến tay người dùng
- Nút thắt không nằm ở bàn phím
3 bình luận
> Khách hàng tiềm năng đó đã không mua, và tính năng đó chỉ có 11 người dùng (trong đó 9 người là QA nội bộ)
lol
Pipeline vẫn y nguyên
chỉ là có vẻ như các lập trình viên đã trở nên thiếu trách nhiệm hơn thôi
Muốn trở thành một nghệ nhân phần mềm quá.