Đó là một buổi sáng thứ Ba. VP Engineering của bạn đang đứng trước một slide deck, hào hứng đến mức thường chỉ thấy ở những người vừa phát hiện ra tiền điện tử năm 2017. Họ vừa đi hội nghị về. Hoặc có thể là một bữa tối với vendor. Ba ly pinot noir và một màn demo, và giờ họ có tin lớn.
"Chúng ta sẽ triển khai AI coding assistant cho toàn bộ team. Số liệu ban đầu cho thấy tăng 40% sản lượng code. Điều này sẽ thay đổi tốc độ phát triển của chúng ta."
Căn phòng phản ứng theo kiểu quen thuộc: một nửa gật đầu, nửa còn lại bỗng thấy laptop của mình thú vị hơn. Staff engineer của bạn đang làm cái biểu cảm đó. Bạn biết cái biểu cảm đó — kiểu đang tính xem nên nói gì hay chỉ cập nhật LinkedIn luôn.
Không ai hỏi câu quan trọng nhất: tốc độ hướng tới cái gì?
Bởi vì đây là điều vừa xảy ra. VP của bạn nhìn vào toàn bộ tổ chức phát triển phần mềm, xác định thứ vốn đã khá nhanh, rồi quyết định làm nó nhanh hơn nữa. Họ tìm thấy một công đoạn không phải bottleneck và đổ tiền vào đó.
Nếu bạn hiểu cách hệ thống hoạt động, bạn biết điều này không chỉ không giúp ích. Nó còn khiến mọi thứ tệ hơn.
Goldratt muốn nói chuyện với bạn
Năm 1984, Eli Goldratt viết The Goal, một cuốn tiểu thuyết về sản xuất nhưng lại cực kỳ phù hợp với phần mềm. Đây cũng là cuốn sách kinh doanh hữu ích nhất mà lại là fiction — gần như trái ngược hoàn toàn với hầu hết các framework KPI.
Ý tưởng cốt lõi là Theory of Constraints:
-
Mỗi hệ thống chỉ có một điểm nghẽn (bottleneck)
-
Throughput của toàn hệ thống phụ thuộc vào bottleneck đó
-
Mọi thứ khác không quan trọng cho đến khi bạn giải quyết bottleneck
Phần này thì nhiều người hiểu. Nhưng phần tiếp theo mới đáng sợ:
Khi bạn tối ưu một bước không phải bottleneck, bạn không làm hệ thống nhanh hơn — bạn làm nó tệ hơn.
Hãy hình dung cơ học:
-
Station A sản xuất nhanh hơn
-
Station B (bottleneck) vẫn xử lý cùng tốc độ
Kết quả:
-
Hàng tồn đọng giữa A và B tăng
-
Lead time tăng
-
Team ở B bị quá tải
-
Quyết định trở nên hỗn loạn
-
Chất lượng giảm
Bạn không tăng tốc. Bạn tạo ra tắc nghẽn rồi gọi đó là năng suất.
Cơn ác mộng: điều gì xảy ra khi bạn “tăng 3x output code”
Có thể bạn đang sống trong tình huống này rồi.
Developer tạo PR nhanh hơn bao giờ hết. Tuyệt vời. Nhưng:
-
Reviewer không tăng gấp 3
-
Không ai nghĩ đến reviewer
-
Vì slide của vendor không nhắc tới reviewer
Kết quả:
-
PR nằm chờ 1 ngày, 2 ngày, 1 tuần
-
Tác giả đã chuyển context sang task khác
-
Khi review quay lại: họ không nhớ code mình viết
"Bạn giải thích function này giúp?"
— hỏi một người đang nhìn code 8 ngày trước (tức là… thời kỳ Jurassic với developer)
Review bắt đầu làm qua loa. PR được approve mà không đọc kỹ. Merge.
CI chạy 45 phút:
-
Fail vì flaky test
-
Rerun
-
Pass (cho đến khi không pass nữa lúc production 2h sáng thứ Bảy)
Deploy pipeline cần approve thủ công từ người đang họp.
Feature nằm ở staging 3 ngày vì không ai chịu trách nhiệm push lên production.
Trong lúc đó:
-
Dev đã tạo thêm 2 PR nữa
-
Queue phình to
-
WIP tăng vọt
-
Ai cũng làm 6 thứ cùng lúc
-
Không có gì hoàn thành
Cycle time (thứ thực sự đo giá trị) → tệ hơn.
Bạn đang:
-
Viết nhiều code hơn
-
Ship ít phần mềm hơn
Dashboard báo: +40% productivity
Chúc mừng. Bạn vừa xây một nhà máy sản xuất tồn kho để… mục rữa.
Tôi đã thấy kịch bản này ở 3 công ty khác nhau:
-
Dashboard tăng
-
Shipping giảm
-
Không ai liên kết hai thứ đó
Vì dashboard được báo cáo lên board.
Và board thì không biết cycle time là gì.
Điều đáng lo nhất:
-
Code AI tạo → không ai thực sự hiểu
-
Người “viết” chỉ prompt + skim
-
On-call không viết code đó
-
Người prompt không giải thích được
Bạn vừa:
-
Tăng bề mặt lỗi
-
Giảm số người hiểu hệ thống
Nhiều code hơn, ít hiểu biết hơn = bom hẹn giờ.
Vậy bottleneck thực sự ở đâu?
Nếu không phải viết code (và gần như luôn là vậy), hãy nhìn vào value stream:
Từ: “có ý tưởng”
→ đến: “user nhận được giá trị”
Bottleneck sẽ lộ diện ngay.
1. Bạn không biết phải build cái gì
Đây là vấn đề không ai muốn nói.
-
PM không nói chuyện với user 2 tháng
-
Requirement = 3 dòng Jira + link Figma
-
Người duyệt design chưa từng dùng sản phẩm
Engineer phải tự quyết định:
-
behavior
-
edge cases
-
error handling
=> Họ đang đoán.
Tôi từng thấy team:
-
build feature 6 tuần
-
từ một Slack message của sales
-
dựa trên lời kể lại của khách hàng
Kết quả:
-
khách không mua
-
feature có 11 user
-
9 người là QA nội bộ
Đây không phải delivery problem.
Đây là: “chúng ta đang làm cái quái gì vậy?”
Viết code nhanh hơn chỉ giúp bạn:
→ đến “chúng ta đang làm gì vậy?” nhanh hơn.
2. Mọi thứ sau khi code “xong”
Code chỉ ~20% hành trình.
80% còn lại:
-
nằm chờ
-
trong queue
-
già đi
Tôi đã thấy:
-
code viết trong 1 buổi chiều
-
mất 2 tháng lên production
Các bước:
-
PR review
-
CI
-
staging
-
QA
-
security
-
product sign-off
-
deploy window
-
rollout
Hầu hết thời gian: code đứng yên
Nếu bạn từng thấy:
-
PR approve lúc 4:55 chiều thứ Sáu
→ “thôi để thứ Hai ship”
Bạn hiểu.
Bottleneck = waiting time
3. Vòng xoáy sợ deploy
-
test flaky
-
observability tệ
-
canary không đáng tin
-
deploy thứ Năm → phá cuối tuần
Giải pháp của team:
→ batch lớn hơn
→ risk cao hơn
→ càng sợ hơn
→ lại batch lớn hơn
Fear spiral.
Thêm AI:
-
nhiều code hơn
-
cùng mức sợ
→ batch to hơn
→ release ít hơn
Bạn vừa khiến team sợ ship hơn.
4. Ship rồi… có hiệu quả không?
-
không analytics
-
không interview user
-
không kiểm tra outcome
→ lại đoán cho feature tiếp theo
Toàn bộ roadmap = chuỗi đoán có học thức.
AI giúp bạn:
→ đoán nhanh hơn
→ sai nhanh hơn
5. Calendar là bottleneck
-
chờ meeting để quyết định
-
3 team không nói chuyện
-
1 architect duyệt tất cả
-
planning 6 tuần
Tôi từng thấy:
Feature không ship vì:
→ “đợi meeting với người đang nghỉ phép”
Không phải technical problem.
Không phải code problem.
→ calendar problem
Bottleneck = org structure
AI không sửa được org chart.
Làm gì thay thế (phần không sexy)
Map value stream
Theo dõi từ idea → production
-
mỗi bước
-
mỗi thời gian
-
mỗi khoảng chờ
Bạn sẽ thấy cycle time thật.
Đo cycle time, không đo output
Đừng đo:
-
lines of code
-
PR count
-
story points
Hãy đo:
→ commit → production → user dùng
Giết wait time
-
PR chờ → tối ưu review
-
deploy chờ → automate
-
decision chờ → giảm meeting
Stop starting, start finishing
-
ít WIP hơn
-
nhiều thứ hoàn thành hơn
Nói chuyện với người làm việc
Dev đã biết bottleneck từ lâu.
Họ chỉ nghĩ không ai nghe.
Điểm mấu chốt
Quay lại buổi sáng thứ Ba.
Thay vì nói:
“+40% code output”
VP nên nói:
“Feature đang chờ trung bình 9 ngày giữa các bước. Chúng ta sẽ giảm một nửa.”
Không sexy.
Không bán được.
Không keynote.
Nhưng:
→ đó mới là cách ship nhanh hơn.
Tốc độ viết code chưa bao giờ là vấn đề.
Nếu bạn nghĩ nó là vấn đề,
thì khoảng cách giữa niềm tin đó và thực tế
chính là nơi mọi vấn đề thật sự của bạn nằm.
Lợi thế cạnh tranh không thuộc về team viết code nhanh nhất.
Mà là team:
-
biết build gì
-
build xong
-
đưa vào tay user
trong khi phần còn lại vẫn đang chìm trong queue review đầy PR do AI tạo mà không ai có thời gian đọc.