Đập tan văn hóa “làm cho xong” — Tuyên ngôn KHÔNG khoan nhượng
Có những câu nói đang giết chết chất lượng phần mềm, giết chết sự chuyên nghiệp, và đang được thốt ra TỪNG NGÀY trong các tổ chức:
- “Cái này khách không cần đâu.”
- “Miễn chạy được là được.”
- “Xưa nay vẫn vậy, có sao đâu.”
- “Review gì mà làm khó nhau thế.”
Xin nói thẳng: Đó là BAO BIỆN, không phải lý do.
Và điều tệ nhất? Khi lãnh đạo gọi đây là “vùng xám” để dĩ hòa vi quý, họ không đang “linh hoạt”. Họ đang HỢP THỨC HÓA SỰ CẨU THẢ.
Mỗi lần chúng ta “châm chước” cho qua, chúng ta đang tự ký vào giấy nhận nợ: Nợ kỹ thuật, nợ uy tín, và nợ tương lai.
Sự thật mất lòng
Chúng ta đang ở trong một vòng luẩn quẩn độc hại:
- Developer chạy KPI “làm cho xong để còn đi chơi“
- Lãnh đạo chạy KPI “làm cho xong để lấy tiền khách“
- Workshop mở ra nhưng không ai thật sự tham gia; kiến thức không tích lũy; lỗi cũ lặp lại
Không ai thật sự quan tâm chất lượng. Không ai thật sự quan tâm knowledge.
Và rồi chúng ta blame “không có passion”.
Xin lỗi — “Passion” là thứ CỘNG THÊM. CHUẨN MỰC NGHỀ NGHIỆP là BẮT BUỘC.
Nghề này trả lương cho bạn để giải quyết vấn đề một cách BỀN VỮNG, không phải để tạo ra một đống rác chạy được.
Nguyên tắc thép: 0 thương lượng
Phải có một lằn ranh không thể đàm phán. Nguyên tắc cốt lõi của tôi là:
Scope có thể cắt — Standards TUYỆT ĐỐI KHÔNG CẮT. Sản phẩm “chạy” nhưng không an toàn, không bảo trì được = NỢ, không phải GIÁ TRỊ.
Từ hôm nay, mọi tranh luận phải đứng sau các điểm này. Đây là HÀNG RÀO CHẤT LƯỢNG (Quality Gate). Thiếu một, KHÔNG SHIP.
- CI (Integration) phải XANH 100%: Lint, Unit Test, Security Checks. CI đỏ = Build thất bại. Không bàn cãi.
- PR Checklist BẮT BUỘC: Tích hợp thẳng vào CI, thiếu một mục → CI tự động FAIL.
- Mô tả rõ What / Why / How-to-run (5-8 dòng)
- Có ảnh/clip xác nhận luồng chính
- Đã tuân thủ Style Guide & Kiến trúc
- Code Review PHI CÁ NHÂN:
- Sử dụng nhãn: Blocking (vi phạm chuẩn, phải sửa), Major (nợ kỹ thuật, cần ticket + hạn sửa), Nit/Question(góp ý, không chặn)
- Không “dĩ hòa vi quý”. Tập trung vào code, không phải người viết code
- RCA (Root Cause Analysis) bắt buộc: Áp dụng cho MỌI sự cố nghiêm trọng. Không tìm người đổ lỗi. Tìm LỖ HỔNG HỆ THỐNG và vá nó vĩnh viễn.
“Nhưng tôi cần đi gấp!”
Tuyệt vời. Chúng ta không có “vùng xám”, nhưng chúng ta có quy trình cho việc gấp.
Đừng van nài. Đừng họp hành. Hãy nộp “WAIVER” (Giấy Miễn trừ Chuẩn mực).
Đây không phải là giấy cho qua. Đây là một bản GHI NỢ CÔNG KHAI. Nó buộc người ra quyết định phải CHỊU TRÁCH NHIỆM với sự vội vàng của mình.
Mẫu Waiver (nộp công khai):
- Chuẩn mực xin miễn: …
- Lý do kinh doanh BẮT BUỘC: …
- Rủi ro & Tác động (Bảo mật/Bảo trì): …
- Owner chịu trách nhiệm (Tên): …
- Kế hoạch + Hạn sửa (Deadline ≤ 14 ngày): …
- Ký duyệt (PM / Tech Lead): …
Không có Waiver hợp lệ → KHÔNG MERGE. Chấm hết.
Quy trình này khóa “vùng xám” bằng cách biến nó thành “vùng SÁNG TỎ”. Nó buộc chúng ta phải ra quyết định dựa trên dữ liệu, chứ không phải cảm tính “làm cho xong”.
Lời kêu gọi thẳng thắn và cuối cùng
Gửi Developer: Bạn có quyền không đam mê; bạn KHÔNG CÓ QUYỀN LÀM ẨU. Đòi hỏi chuẩn mực không phải là “làm khó”, đó là TÔN TRỌNG NGHỀ NGHIỆP của chính bạn và của đồng đội bạn.
Gửi Lãnh đạo: Đừng hợp thức hóa sự cẩu thả. Đổi uy tín dài hạn lấy doanh thu ngắn hạn là THUA LỖ CHIẾN LƯỢC. Bạn không phải “người giữ hòa khí”, bạn là NGƯỜI GÁC CỔNG CHO CHUẨN MỰC. Thất bại trong việc này là thất bại của lãnh đạo.
Hoặc chọn làm ít hơn nhưng ĐÚNG CHUẨN — hoặc chấp nhận “cháy nhà” vào một ngày đẹp trời.
Tôi chọn vế đầu. 0 khoan nhượng.
