“Business không cho phép…” – và những câu bào chữa quen thuộc của dev 

  • “Business không cho làm telemetry cho tử tế.”

  • “Không có thời gian viết test.”

  • “Sếp không approve refactor.”

  • “Không có budget cho CI/CD.”

  • “Deadline không cho phép viết tài liệu API.”

Nghe quen chứ? Mấy câu này xuất hiện đều đặn như daily standup và… cà phê sáng. Mình từng nghe, mà cũng từng nói y như vậy.

Nhưng nói thật lòng, đằng sau những câu “biện hộ” đó là một sự nhầm lẫn khá cơ bản: đâu là quyết định thuộc về kinh doanh, đâu là phạm vi kỹ thuật – và ai mới là người có quyền (và trách nhiệm) đưa ra quyết định đó.

Ai mới là người có quyền quyết định kỹ thuật?

Nói nhanh cho vuông: người kỹ thuật thì nên quyết định chuyện kỹ thuật.
Nghe đơn giản, nhưng thực tế thì… tụi mình hay tự thoái thác quyền đó.

Bạn đâu có xin phép manager để tạo file mới, đặt tên biến, hay debug đúng không?
Vậy tại sao lại cần hỏi “Business có cho viết test không?”, hay “Mình có nên setup CI không?”, hoặc “Được phép refactor không vậy?”

Viết code chỉ là một phần của việc "deliver feature".
Còn phần còn lại – test, đo lường, monitoring, deploy an toàn, rồi quan sát hành vi sau khi release – cũng là việc của dev, là một phần của phát triển phần mềm, chứ không phải “việc dư” hay “optional”.

Yêu cầu kinh doanh ≠ Chỉ thị kỹ thuật

Business có quyền nói cái gì cần làm, khi nào cần có.
Nhưng làm thế nào để làm được việc đó – là phạm vi chuyên môn của dev, tech lead, QA, architect, v.v.

Ví dụ: khi PO nói

“Tính năng này cần có trước cuối tháng.”

Người ta không có ý bảo bạn:

“Làm ẩu cũng được, khỏi cần test, khỏi cần handle error, miễn xong.”

Ý của họ đơn giản là: đây là ràng buộc thời gian, còn việc đánh đổi như thế nào – đó là phần bạn cần đánh giá và phản hồi.

Và nếu thực sự không thể làm tốt trong khung thời gian đó, thì hãy quay lại với business để trao đổi theo ngôn ngữ của họ:

  • ❌ “Chắc phải thêm 2 ngày để viết test.” → quá kỹ thuật.

  • ✅ “Nếu mình làm theo hướng hiện tại, khả năng cao sau 2–3 tháng sẽ có outage do không có error tracking.”

  • ✅ “Không có telemetry thì nếu có lỗi, mình sẽ không phát hiện kịp và downtime sẽ kéo dài → ảnh hưởng đến SLA.”

Họ không cần biết bạn xài tool gì, dùng pattern nào. Họ cần hiểu rủi ro, tác động, và chi phí của lựa chọn đó.

Khi kỹ thuật trốn tránh trách nhiệm

Mình từng thấy tình huống như sau rất nhiều:

  1. Dev hỏi: “Tính năng này có cần test không ạ?”

  2. PM: “Thôi skip đi cho kịp deadline.”

  3. Dev: “Dạ.”

  4. Lặp lại 5 lần → Business tưởng họ có quyền quyết định chuyện kỹ thuật.

  5. Dev quen luôn việc “hỏi ý kiến” thay vì chịu trách nhiệm.

Cuối cùng, team cứ build ra hệ thống mà ai cũng biết có vấn đề – nhưng… “do business chỉ đạo mà”.

Vấn đề thật ra không phải do business quá tay, mà do dev tự buông quyền, rồi bắt business làm hộ phần việc của mình.

“Business không cho” – tấm khiên hoàn hảo

Câu “business không cho…” nghe rất hợp lý, vì:

  • Không ai kiểm chứng được ngay lúc đó

  • Trách nhiệm bay lên đầu người khác

  • Mình vẫn giữ hình ảnh “dev có tâm” nhưng bị ép làm ẩu

Thậm chí nó còn giúp mình tránh khỏi việc đối mặt với thực tế:

“Mình biết cần làm gì cho tốt, nhưng mình ngại đứng lên bảo vệ lựa chọn đó.”

Nhưng sự thật là:
👉 Nếu bạn build một hệ thống mà bạn biết có vấn đề – thì bạn vẫn là người chịu trách nhiệm.
Bạn là người kỹ thuật. Việc của bạn không chỉ là code theo yêu cầu, mà là tìm cách thực thi tốt nhất trong bối cảnh đã cho.

Đừng nhầm yêu cầu với giải pháp

Một ví dụ kinh điển:

Business: “Chúng ta cần web app để ghi nhận thời gian làm việc.”

Có thể vấn đề thật là:

“Phòng nhân sự cần dữ liệu thời gian để tính lương chính xác.”

Tương tự, khi họ nói:

“Không có thời gian cho telemetry đâu!”

Sự thật không phải là họ phản đối telemetry, mà là:

“Tụi tôi lo lắng không kịp deadline.”

Vậy nên, thay vì mặc định “không được làm telemetry”, hãy giải mã nỗi lo, rồi đưa ra giải pháp phù hợp:

  • Giảm scope tính năng thay vì cắt giảm chất lượng

  • Làm theo phase, ưu tiên phần cốt lõi trước

  • Streamline quy trình để tiết kiệm thời gian

Kết luận: Trade-off có trách nhiệm ≠ Làm ẩu có lý do

Khi bị giới hạn về thời gian, ngân sách hay nguồn lực, bạn có 2 lựa chọn:

  • Trốn trách: “Business không cho nên tôi làm ẩu.”

  • Chịu trách nhiệm: “Tôi đánh giá rủi ro, cân nhắc trade-off và chọn hướng đi tối ưu nhất có thể.”

Hãy nhớ:

  • Test cơ bản, xử lý lỗi, validation, security → không phải “nice to have”. Đó là phần thiết yếu.

  • Một số tính năng có thể làm đơn giản trước, mở rộng sau.

  • Có thể delay một số việc, miễn là không ảnh hưởng đến chất lượng hệ thống.

Nếu bạn là dev senior hay architect...

Hãy nhìn lại xem bạn có đang:

  • Đẩy quyết định kỹ thuật lên đầu business?

  • Dùng “business không cho” như lá chắn để tránh phải nói chuyện khó?

Leadership kỹ thuật không chỉ là biết dùng công nghệ gì, mà là có bản lĩnh đứng lên bảo vệ điều đúng, và trình bày nó theo cách business có thể hiểu và cân nhắc.

Hãy nói chuyện về tác động kinh doanh, rủi ro, chi phí cơ hội – chứ không phải ngôn ngữ thuần kỹ thuật.

Grace Hopper từng nói:

“Xin lỗi bao giờ cũng dễ hơn xin phép.”

Nhưng mình nghĩ:

“Hiểu rõ vai trò của mình, dám chịu trách nhiệm, và nói chuyện có căn cứ – thì khỏi cần xin gì hết.”

Bạn là chuyên gia kỹ thuật.
Hãy hành xử như một người có chuyên môn.
Và lần sau, đừng đổ cho 'business không cho' nữa nhé. 😉

Cheers,
Một cô BrSE/BA vừa phải service client, vừa phải nhắc dev viết test code.