Đây không phải lỗi, mà là tính năng — bản chất, nguồn gốc và sự khác biệt

“Đây không phải lỗi, mà là tính năng” có nghĩa là gì

“Đây không phải lỗi, mà là tính năng” — câu nói mà nhà phát triển hoặc quản lý dùng để chỉ ra rằng hành vi bất ngờ của chương trình là có chủ đích, không phải lỗi. Trong trường hợp cổ điển, đó là một trò đùa: mọi người đều hiểu hành vi đó là sai, nhưng gọi nó là “tính năng” để giảm căng thẳng. Tuy nhiên, trong các dự án thực tế, câu nói cũng được sử dụng một cách nghiêm túc — khi hành vi thực sự khớp với đặc tả nhưng không đáp ứng kỳ vọng của người dùng.

Sự khác biệt giữa lỗi và tính năng thường mang tính chủ quan. Đối với nhà phát triển đã viết mã, một hành vi nhất định có vẻ hợp lý. Đối với người dùng, nó có vẻ bất ngờ và sai sót. Tính chủ quan của nhận thức là lý do chính khiến câu nói tồn tại lâu đến vậy. Nó chuyển cuộc trò chuyện từ “ai có lỗi” sang “đã được thiết kế như vậy”. Theo UX Collective, 40% lỗi do người dùng báo cáo thực ra là vấn đề về UX, không phải lỗi mã.

Trong các nhóm agile, câu nói thường được sử dụng như một cơ chế phòng vệ trong các buổi demo. Nhà phát triển trình bày hành vi bất ngờ, chủ sở hữu sản phẩm cau mày, và câu nói định mệnh “đây không phải lỗi, mà là tính năng” được thốt ra. Niềm tin trong nhóm quyết định liệu câu nói sẽ được coi là trò đùa hay là nỗ lực che giấu vấn đề. Trong một nhóm lành mạnh, trò đùa như vậy làm dịu bầu không khí; trong một nhóm độc hại, nó gây ra xung đột.

Lịch sử ra đời của câu nói biểu tượng

Lần sử dụng đầu tiên được biết đến của câu nói được ghi lại vào năm 1976 trong một bản tin của DECUS (Digital Equipment Corporation User Society). Một người dùng phàn nàn rằng trình xử lý văn bản RUNOFF xử lý các dòng trống không đúng. Câu trả lời của nhà phát triển: “Đây không phải lỗi, mà là tính năng — đó là cách các đoạn văn được xử lý.” Kể từ đó, câu nói đã trở thành biểu tượng của việc bảo vệ mã được viết “nguyên trạng”, bất kể chất lượng thực tế của nó.

Sự phổ biến của câu nói được thúc đẩy bởi Jargon File — một từ điển tiếng lóng của hacker, vào những năm 1990 đã trở thành nền tảng cho cuốn sách “The New Hacker’s Dictionary”. Trong Jargon File, mục từ “feature” đề cập trực tiếp đến những lỗi đã trở thành tính năng vì không thể hoặc không muốn sửa chữa. Ví dụ: phím Caps Lock trên các thiết bị đầu cuối ban đầu không có đèn báo — đây là một lỗi đã trở thành tính năng “cho việc gõ mù”.

Trong những năm 2000, câu nói đã chuyển sang văn hóa đại chúng qua các meme internet. Một bức ảnh mèo với chú thích “It’s not a bug, it’s a feature” lan truyền trên các diễn đàn và mạng xã hội. Trong ngành công nghiệp game, câu nói được sử dụng đặc biệt thường xuyên: những lỗi đồ họa không ảnh hưởng đến lối chơi được tuyên bố là “tính năng” cho bầu không khí. Hiện tượng văn hóa đã lan xa ra ngoài phạm vi IT — câu nói có thể được nghe thấy trong bất kỳ bối cảnh nào mà một lỗi đang được biện minh.

Tâm lý của lời biện hộ: tại sao lại nói vậy

Cơ sở tâm lý của câu nói là sự bất hòa nhận thức. Một nhà phát triển đã dành hàng giờ để viết mã, và thừa nhận kết quả là sai có nghĩa là phủ nhận giá trị công việc của mình. Câu nói “đây không phải lỗi, mà là tính năng” làm giảm sự bất hòa: lỗi trở thành một quyết định có chủ đích, và nhà phát triển từ người có lỗi trở thành tác giả của ý tưởng. Đó là một cơ chế phòng vệ tâm lý giúp bảo vệ lòng tự trọng.

Lý do thứ hai là nỗi sợ làm lại. Thừa nhận lỗi có nghĩa là phải trải qua quá trình đánh giá mã, kiểm thử và triển khai lại. “Tính năng” không yêu cầu sửa chữa — nhiệm vụ được đóng, khối lượng công việc giảm. Theo Microsoft Research, các nhà phát triển cố tình đánh giá thấp mức độ nghiêm trọng của lỗi để tránh làm lại trong 23% trường hợp. Câu nói là một dạng nhẹ của việc đánh giá thấp đó.

Lý do thứ ba là văn hóa doanh nghiệp. Ở một số công ty, lỗi ảnh hưởng đến KPI của nhà phát triển, và việc tìm thấy lỗi trong đánh giá mã được coi là sai sót của tác giả. Trong môi trường như vậy, câu nói “đây không phải lỗi, mà là tính năng” là cách để tránh hậu quả tiêu cực cho sự nghiệp. Một văn hóa lỗi lành mạnh (văn hóa không đổ lỗi) loại bỏ lý do này: nếu lỗi không bị trừng phạt, chúng dễ được thừa nhận hơn.

Ranh giới giữa lỗi và tính năng ở đâu

Ranh giới rõ ràng chỉ tồn tại khi có Tiêu chí Chấp nhận. Nếu hành vi không khớp với bất kỳ mục tiêu chí chấp nhận nào — đó là lỗi. Nếu hành vi khớp với tiêu chí chấp nhận nhưng người dùng không thích — đó là vấn đề UX, không phải lỗi. Nếu không có tiêu chí chấp nhận — bất kỳ hành vi nào cũng có thể được tuyên bố là tính năng, và đây là lý do chính khiến câu nói tồn tại lâu dài.

Một quy tắc thực tế: lỗi là khi chương trình làm điều không nên làm, hoặc không làm điều nên làm, theo đặc tả. Tính năng là khi chương trình làm điều đã được dự định, ngay cả khi kết quả làm người dùng ngạc nhiên. Các trường hợp ranh giới: hành vi không xác định (ngôn ngữ không định nghĩa kết quả), điều kiện cạnh tranh (xuất hiện không ổn định), các giá trị biên (hoạt động với 99% dữ liệu).

Để rõ ràng, hãy sử dụng ma trận quyết định:

• Hành vi được mô tả trong đặc tả và triển khai đúng — tính năng, ngay cả khi bạn không thích
• Hành vi được mô tả nhưng triển khai sai — lỗi, cần sửa chữa
• Hành vi không được mô tả nhưng suy ra một cách logic từ yêu cầu — tính năng không được ghi nhận, cần thêm vào đặc tả
• Hành vi không được mô tả và phi logic — lỗi, cần làm rõ yêu cầu

Trường hợp nguy hiểm nhất là khi không có đặc tả và nhà phát triển tự quyết định điều gì là tính năng. Trong những dự án như vậy, bất kỳ lỗi nào cũng có thể được tuyên bố là “tính năng”, khiến mã trở nên không thể dự đoán cho toàn bộ nhóm. Tiêu chí Chấp nhận rõ ràng cho mỗi nhiệm vụ — cách duy nhất để vạch ranh giới một cách khách quan.

Tại sao đánh tráo khái niệm lại nguy hiểm trong nhóm

Mối nguy hiểm đầu tiên là suy giảm chất lượng. Nếu mọi lỗi đều có thể được tuyên bố là tính năng, nhóm không có động lực để viết mã chất lượng. Các lỗi ngừng được sửa, nợ kỹ thuật tăng lên, và người dùng quen với “hành vi kỳ lạ”. Không sớm thì muộn, đối thủ cạnh tranh tung ra sản phẩm hoạt động có thể dự đoán được, và người dùng bỏ đi.

Mối nguy hiểm thứ hai là xung đột trong nhóm. Kỹ sư QA tìm thấy lỗi, nhà phát triển nói “đó là tính năng”. Nếu không có tiêu chí khách quan (Tiêu chí Chấp nhận), cuộc tranh luận trở nên cá nhân: “anh kiểm thử kém” vs “anh lập trình kém”. Theo PractiTest State of Testing 2023, tranh chấp “lỗi vs tính năng” là một trong ba nguyên nhân chính gây xích mích giữa QA và nhà phát triển.

Mối nguy hiểm thứ ba là rủi ro pháp lý. Trong các ngành được quản lý (y tế, tài chính, hàng không), khái niệm “lỗi” và “tính năng” có trọng lượng pháp lý. Nếu trong phần mềm y tế, một hành vi được tuyên bố là tính năng nhưng dẫn đến tính toán liều lượng sai — đó không phải trò đùa, mà là vi phạm yêu cầu quy định. Các hệ thống an toàn quan trọng không dung thứ cho việc đánh tráo khái niệm, do đó chúng luôn sử dụng xác minh hình thức.

Cách ngăn ngừa nhầm lẫn giữa lỗi và tính năng

Công cụ chính — Tiêu chí Chấp nhận rõ ràng trong mỗi nhiệm vụ. Tiêu chí Chấp nhận được viết trước khi bắt đầu phát triển: “Khi nhập X, hệ thống phải xuất Y”. Nếu hành vi không được mô tả — đó là lỗi theo mặc định, ngay cả khi nhà phát triển nghĩ khác. Tiêu chí Chấp nhận phải đo lường được và có thể kiểm chứng: “nút màu xanh lá” là tệ, “HEX #00FF00” là tốt.

Công cụ thứ hai — Định nghĩa Hoàn thành trong nhóm. Mô tả rõ ràng về “nhiệm vụ hoàn thành” có nghĩa là gì: mã đã viết, kiểm thử đã viết, kiểm thử đạt, đánh giá mã hoàn tất, đã triển khai lên môi trường staging, đã được QA kiểm tra. Nếu tất cả các điểm của Định nghĩa Hoàn thành được đáp ứng và người dùng vẫn phàn nàn — đó không phải lỗi, mà là yêu cầu bị thiếu sẽ được đưa vào hàng đợi công việc như một tính năng mới.

Công cụ thứ ba — văn hóa phân tích sau sự cố không đổ lỗi. Nếu một lỗi được tuyên bố là tính năng và được đưa lên môi trường sản xuất — chúng ta phân tích nguyên nhân, không tìm người chịu trách nhiệm. Tại sao nhà phát triển nghĩ đó là tính năng? Tại sao QA bỏ sót? Tại sao Tiêu chí Chấp nhận không đầy đủ? Câu trả lời cho những câu hỏi này cải thiện quy trình, không trừng phạt con người. Những cải tiến hệ thống hiệu quả hơn việc cấm câu nói “đây không phải lỗi, mà là tính năng”.