Mở đầu — vì sao bài này quan trọng
Khi một tổ chức kỹ thuật còn nhỏ, chất lượng thường được đảm bảo bằng… văn hóa ngầm. Vài kỹ sư giỏi ngồi cạnh nhau, họ tự review code cho nhau, tự viết test vì "thấy cần", tự sửa bug trước khi khách hàng phàn nàn. Không ai gọi đó là "chương trình" cả — nó chỉ là cách những người tử tế làm việc.
Nhưng khi bạn scale từ 15 kỹ sư lên 80, rồi 150, cái "văn hóa ngầm" đó tan biến rất nhanh. Người mới không biết chuẩn nằm ở đâu. Kỹ sư giỏi bị phân tán mỏng ra khắp các team. Áp lực deadline khiến người ta cắt góc, và vì không có cơ chế nào bắt buộc, việc cắt góc trở thành bình thường mới. Sáu tháng sau, bạn nhìn lại và không hiểu tại sao chất lượng sản phẩm lại tụt dốc dù mình tuyển toàn người giỏi.
Engineering Excellence Programs — tạm dịch là "các chương trình chuẩn hóa và nâng cao chất lượng kỹ thuật" — chính là câu trả lời cho vấn đề này. Đó là cách bạn biến những thói quen tốt vốn tồn tại trong đầu vài người giỏi thành hệ thống có thể lặp lại, đo được, và dạy được cho hàng trăm người. Bài này không nói về từng kỹ thuật lẻ (code review làm thế nào, test viết ra sao — những nội dung đó thuộc các bài khác), mà nói về cách thiết kế, vận hành và duy trì cả một chương trình để chất lượng không phụ thuộc vào may rủi con người.
Khái niệm cốt lõi
Engineering Excellence Program là gì?
Hãy phân biệt rõ. Một thực hành tốt (good practice) là hành vi của cá nhân — ví dụ một kỹ sư luôn viết test. Một chương trình (program) là một cấu trúc có chủ đích bao gồm bốn thành phần:
- Chuẩn (Standards) — định nghĩa "tốt" trông như thế nào, được viết ra rõ ràng.
- Cơ chế thực thi (Enforcement) — cách đảm bảo chuẩn được tuân thủ, ưu tiên tự động hóa.
- Đo lường (Measurement) — chỉ số cho biết ta đang ở đâu so với chuẩn.
- Chủ sở hữu (Ownership) — người/nhóm chịu trách nhiệm duy trì và tiến hóa chương trình.
Từ dàn ý gốc: hai trụ cột kinh điển
Ý định gốc của bài nhấn mạnh hai chương trình phổ biến nhất, đáng để mổ xẻ vì chúng minh họa rõ tư duy "chương trình hóa":
Trụ cột 1 — Chuẩn hóa Code Review. Không phải là dạy cách review (bài khác lo), mà là biến review thành một chương trình: có checklist chuẩn để mọi reviewer nhìn cùng một danh sách; có automated lint để máy bắt lỗi định dạng, style, security cơ bản trước khi con người phải nhìn; có SLA về thời gian review (ví dụ: mọi PR phải có phản hồi đầu tiên trong vòng 4 giờ làm việc); và có định nghĩa "approved" thống nhất trên toàn tổ chức thay vì mỗi team hiểu một kiểu.
Trụ cột 2 — Ngưỡng Test Coverage tối thiểu. Con số kinh điển là 70% coverage cho code mới (lưu ý: cho code mới — new code coverage — chứ không phải ép toàn bộ codebase cũ lên 70% một lúc, đó là cạm bẫy sẽ nói sau). Đây là ví dụ hoàn hảo cho việc biến một mong muốn mơ hồ ("chúng ta nên test nhiều hơn") thành một chuẩn đo được, được gate tự động trong CI, và hiển thị trên mọi PR.
Nguyên tắc thiết kế: Paved Road, không phải Police
Cách tiếp cận sai lầm phổ biến nhất là biến Engineering Excellence thành một đội "cảnh sát chất lượng" đi bắt lỗi và trách phạt. Cách này tạo ra sự chống đối và văn hóa che giấu.
Cách đúng, được Netflix và Spotify phổ biến, là Paved Road (con đường trải nhựa): làm cho việc làm đúng trở thành con đường dễ đi nhất. Nếu muốn kỹ sư viết test, đừng chỉ ra lệnh — hãy cung cấp template test, generator, CI chạy sẵn, và feedback ngay trên PR. Khi con đường đúng cũng là con đường ít ma sát nhất, người ta tự nhiên đi vào đó. Cưỡng chế (enforcement) chỉ là hàng rào cuối cùng cho những trường hợp cố tình đi lệch.
Excellence là leading indicator, không phải lagging
Một tư duy quan trọng: chất lượng kỹ thuật là chỉ số dẫn dắt (leading indicator) của kết quả kinh doanh. Một codebase có coverage tốt, review kỷ luật, tech debt được kiểm soát sẽ cho phép team ship nhanh và ổn định trong 6-12 tháng tới. Ngược lại, khi bạn thấy velocity tụt, incident tăng, thì gốc rễ thường đã hình thành từ nhiều tháng trước khi các chuẩn excellence bị buông lỏng. Đầu tư vào chương trình excellence là đầu tư vào tương lai, nên nó luôn bị cám dỗ trì hoãn — và đó chính là lý do nó cần được chương trình hóa thay vì phó mặc thiện chí.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán coverage áp đặt sai cách
Giả định một bối cảnh rất điển hình ở một công ty thương mại điện tử lớn tại Việt Nam như Tiki. Đội kỹ thuật khoảng 120 người, VP Engineering ra chỉ đạo: "Từ quý sau, toàn bộ codebase phải đạt 80% test coverage." Nghe rất quyết liệt.
Chuyện gì xảy ra? Codebase có hàng trăm nghìn dòng code legacy được viết trong nhiều năm, coverage hiện tại khoảng 30%. Để nhảy lên 80%, kỹ sư bắt đầu viết những test vô nghĩa — test gọi hàm rồi assert true, test chỉ để chạy qua dòng code cho tăng con số. Coverage lên đúng 80% sau hai tháng, nhưng số bug production không giảm, thậm chí tăng vì thời gian lẽ ra để làm việc có ích bị đổ vào việc "cày" coverage giả.
Diễn giải: Sai lầm nằm ở chỗ áp chuẩn lên toàn bộ thay vì lên code mới. Con số 70% cho new code là hợp lý vì nó chỉ yêu cầu bạn test tử tế những gì bạn đang viết hôm nay — điều hoàn toàn khả thi và có giá trị thật. Ép legacy code lên chuẩn cao tạo ra hành vi gian lận chỉ số (gaming the metric).
Bài học: Chương trình excellence phải phân biệt "ratchet" (bánh cóc chỉ tiến không lùi) cho code mới với chiến lược "boy scout rule" cho code cũ (cải thiện dần mỗi khi chạm vào). Và luôn nhớ: coverage là proxy cho chất lượng test, không phải chất lượng test. Đo cả mutation testing hoặc số bug lọt production để không bị con số đơn lẻ đánh lừa.
Ví dụ 2 — Grab và "Engineering Excellence Week"
Grab, với đội kỹ thuật hàng nghìn người trải khắp Đông Nam Á, đối mặt vấn đề: làm sao duy trì chuẩn chung khi team quá phân tán? Một cơ chế được nhiều công ty quy mô này áp dụng (và Grab là ví dụ hợp lý) là các chương trình tập trung định kỳ — chẳng hạn "Fix-it Week" hoặc "Engineering Excellence Sprint" mỗi quý.
Trong tuần đó, tất cả team tạm dừng làm feature mới và tập trung vào: dọn tech debt được xếp hạng ưu tiên, nâng coverage cho các service quan trọng dưới ngưỡng, cập nhật runbook, và vá các lỗ hổng lint/security tồn đọng. Kết quả được đo bằng dashboard chung: bao nhiêu service vượt qua "Production Readiness Checklist", coverage trung bình di chuyển thế nào, số alert giả (noisy alerts) giảm bao nhiêu.
Diễn giải: Điều thông minh ở đây là biến excellence thành sự kiện có nhịp điệu (cadence) thay vì kỳ vọng nó xảy ra "tranh thủ" giữa các sprint feature — điều gần như không bao giờ xảy ra vì áp lực deliver. Khi lãnh đạo chính thức cho phép dừng feature để đầu tư chất lượng, kỹ sư mới thực sự làm.
Bài học: Nếu bạn không lên lịch cho excellence, nó sẽ luôn thua feature trong cuộc đua ưu tiên. Dành ra một ngân sách thời gian cố định (ví dụ 20% mỗi sprint, hoặc một tuần mỗi quý) và bảo vệ nó như bảo vệ một cam kết với khách hàng.
Ví dụ 3 — Một startup fintech 40 người và "Production Readiness Review"
Một startup fintech tại TP.HCM, khoảng 40 kỹ sư, gặp sự cố: một service thanh toán mới ra mắt gây downtime 3 giờ vì thiếu monitoring và không có runbook — kỹ sư trực đêm không biết phải làm gì. Sau sự cố, CTO thiết lập một chương trình nhẹ nhưng bắt buộc: Production Readiness Review (PRR) — mọi service trước khi lên production phải qua một checklist gồm ~20 mục: có health check chưa, có alert chưa, có runbook chưa, có test coverage tối thiểu chưa, có rollback plan chưa, đã load test chưa.
Ban đầu team càu nhàu vì "thêm thủ tục". Nhưng chỉ sau một quý, số incident nghiêm trọng (P1) giảm từ 6 xuống còn 1. Quan trọng hơn, PRR trở thành công cụ dạy học: kỹ sư junior nhìn checklist là hiểu ngay "một service production tử tế cần những gì" — kiến thức mà trước đây chỉ nằm trong đầu vài senior.
Bài học: Ở quy mô nhỏ, bạn không cần một đội excellence riêng. Một checklist bắt buộc gắn vào một gate rõ ràng (ở đây là "trước khi lên prod") đã là một chương trình excellence hoàn chỉnh: có chuẩn (checklist), có thực thi (gate), có đo (số mục pass, số incident), có chủ sở hữu (CTO ký duyệt ban đầu, sau giao cho tech lead). Chương trình không cần to, cần có đủ bốn thành phần.
Hướng dẫn từng bước
Nếu bạn được giao xây dựng một Engineering Excellence Program, đây là lộ trình thực dụng:
Bước 1 — Đo baseline trước khi đặt mục tiêu. Đừng đặt chuẩn khi chưa biết mình đang ở đâu. Thu thập các con số hiện tại: coverage của code mới trung bình, thời gian review PR trung bình, số incident/tháng, tỷ lệ PR bị revert. Không có baseline thì mọi mục tiêu đều là võ đoán và bạn không thể chứng minh tiến bộ.
Bước 2 — Chọn 2-3 chuẩn, không nhiều hơn. Cám dỗ lớn nhất là muốn chuẩn hóa mọi thứ cùng lúc. Đừng. Chọn hai đến ba thứ có đòn bẩy cao nhất cho đúng nỗi đau hiện tại của bạn. Ví dụ điển hình để khởi động: (a) 70% coverage cho code mới, (b) checklist code review + lint tự động, (c) SLA thời gian review. Ba cái này đủ tạo chuyển biến rõ mà không gây quá tải.
Bước 3 — Tự động hóa việc thực thi ngay từ đầu. Chuẩn nào con người phải nhớ để kiểm thì chuẩn đó sẽ chết. Cài coverage gate vào CI (dùng công cụ như SonarQube, Codecov để check new code coverage). Cài lint/formatter chạy tự động (pre-commit hook + CI). Cấu hình để PR không thể merge nếu chưa pass. Máy làm việc bắt lỗi, con người dành sức cho việc phán đoán thiết kế.
Bước 4 — Làm dashboard hiển thị công khai. Tạo một dashboard cho thấy từng team đứng đâu so với chuẩn. Công khai (transparent) chứ không phải để xếp hạng bêu tên — mục tiêu là tạo tự giác và cho phép team tự so sánh, học hỏi. Con số hiển thị tạo áp lực xã hội lành mạnh mạnh hơn nhiều so với email nhắc nhở.
Bước 5 — Giao chủ sở hữu rõ ràng. Ai đó phải "own" chương trình: có thể là một Staff/Principal Engineer, một guild chất lượng, hoặc một Platform team (liên hệ tới vai trò của Platform/Enabling team đã học ở các bài trước). Chủ sở hữu chịu trách nhiệm cập nhật chuẩn, review dashboard hằng tháng, và gỡ vướng khi chuẩn xung đột thực tế.
Bước 6 — Tạo nhịp review và tiến hóa. Mỗi quý, ngồi lại xem: chuẩn nào đang giúp ích, chuẩn nào chỉ tạo ma sát? Nâng ngưỡng khi team đã quen (ratchet), hoặc bỏ chuẩn nào không còn giá trị. Excellence program là sản phẩm sống, không phải bộ luật khắc đá.
Lỗi thường gặp & mẹo
Lỗi 1: Biến chỉ số thành mục tiêu (Goodhart's Law). "Khi một thước đo trở thành mục tiêu, nó thôi làm thước đo tốt." Ép coverage lên cao, người ta viết test rác. Mẹo: luôn ghép chỉ số proxy (coverage) với chỉ số kết quả (bug production, mutation score) để phát hiện gian lận.
Lỗi 2: Áp chuẩn lên legacy code cùng lúc. Như ví dụ Tiki. Mẹo: dùng "ratchet cho code mới, boy scout cho code cũ". Chỉ gate code mới, cải thiện code cũ dần khi chạm vào.
Lỗi 3: Excellence trở thành cảnh sát. Đội chất lượng đi bắt lỗi tạo văn hóa đối phó. Mẹo: theo triết lý Paved Road — làm việc đúng thành việc dễ nhất. Cung cấp công cụ, template, tự động hóa thay vì trách phạt.
Lỗi 4: Không có ngân sách thời gian. Kỳ vọng excellence xảy ra "khi rảnh" — nhưng không bao giờ rảnh. Mẹo: lên lịch cụ thể (Fix-it Week hằng quý, hoặc % thời gian mỗi sprint) và để lãnh đạo bảo vệ nó.
Lỗi 5: Đặt quá nhiều chuẩn một lúc. Team choáng ngợp, không chuẩn nào được tuân thủ thật. Mẹo: bắt đầu với 2-3 chuẩn, chứng minh giá trị, rồi mới mở rộng.
Lỗi 6: Quên yếu tố con người. Chuẩn tốt nhưng áp đặt từ trên xuống không giải thích "vì sao" sẽ gặp kháng cự. Mẹo: đưa kỹ sư senior vào việc thiết kế chuẩn để tạo cảm giác sở hữu, và luôn giải thích lý do đằng sau mỗi chuẩn.
Mẹo vàng: Bắt đầu chương trình từ một sự cố có thật. Ngay sau một incident đau đớn là lúc tổ chức sẵn sàng chấp nhận chuẩn mới nhất — như startup fintech đã làm với PRR. "Đừng lãng phí một cuộc khủng hoảng."
Bài tập thực hành
- Chẩn đoán baseline: Với team hiện tại của bạn (hoặc team giả định 50 kỹ sư), liệt kê 5 chỉ số bạn sẽ đo để hiểu tình trạng chất lượng kỹ thuật. Với mỗi chỉ số, ghi rõ nguồn lấy dữ liệu và con số nào là "đủ tốt".
- Thiết kế chương trình tối thiểu: Chọn một nỗi đau (ví dụ: review PR quá chậm, hoặc bug production nhiều). Thiết kế một chương trình excellence nhỏ cho nó với đủ 4 thành phần: chuẩn (viết cụ thể con số), thực thi (tự động hóa thế nào), đo lường (dashboard gì), chủ sở hữu (ai).
- Phản biện coverage: Một quản lý đề xuất "ép toàn bộ codebase lên 90% coverage trong quý này". Viết một đoạn 150 từ phản biện, đề xuất cách tiếp cận thay thế đúng đắn, dùng lập luận từ bài.
- Xây Production Readiness Checklist: Soạn một checklist 10-15 mục cho việc đưa một service mới lên production trong bối cảnh của bạn. Đánh dấu mục nào có thể tự động kiểm, mục nào cần con người duyệt.
Tóm tắt
Engineering Excellence Program là cách bạn biến những thói quen tốt vốn nằm rải rác trong đầu vài kỹ sư giỏi thành một hệ thống có thể lặp lại, đo được và dạy được ở quy mô lớn. Một chương trình đúng nghĩa luôn có bốn thành phần: chuẩn rõ ràng, thực thi tự động, đo lường minh bạch, và chủ sở hữu chịu trách nhiệm.
Hai trụ cột kinh điển để khởi động là chuẩn hóa code review (checklist + automated lint + SLA) và ngưỡng test coverage tối thiểu 70% cho code mới — nhấn mạnh "code mới" để tránh cạm bẫy ép legacy gây gian lận chỉ số. Triết lý dẫn đường là Paved Road — làm việc đúng thành việc dễ nhất — chứ không phải làm cảnh sát bắt lỗi.
Ba nguyên tắc cần khắc cốt: (1) chọn ít chuẩn, có đòn bẩy cao, chứng minh giá trị rồi mới mở rộng; (2) tự động hóa thực thi để không phụ thuộc trí nhớ con người; (3) lên lịch và bảo vệ ngân sách thời gian cho excellence, vì nó luôn thua feature nếu để tự do cạnh tranh. Cuối cùng, hãy nhớ chất lượng kỹ thuật là chỉ số dẫn dắt của sức khỏe tổ chức — đầu tư hôm nay là tốc độ và sự ổn định của bạn sáu tháng tới.