thể làm cả kỹ thuật và marketing. Tôi chỉ hi vọng những vị thạc sỹ quản trị
kinh doanh có thể tạo nên điều gì đó tương xứng với những đoạn mã của
tôi”. Tuy nhiên, đừng lo lắng nhiều về lời nói dối này, vì nó sẽ tự điều chỉnh
khi kỹ sư bỏ lỡ hết hạn chót này tới hạn chót khác, và nhận ra rằng anh ta có
những vấn đề lớn hơn.
2. “Chúng tôi chuẩn bị kiểm tra bản beta”. Đây là một lời khẳng định
vô nghĩa vì khi nào bạn kiểm tra bản beta không phải là vấn đề, vấn đề là khi
nào bạn giới thiệu bản beta đã được kiểm tra đó. (Hạn chót không thể thay
đổi cho việc giới thiệu bản beta là “trước khi bạn hết tiền”.)
Ngày trước, alpha được dùng với nghĩa “Mọi đặc tính đều được thực thi
dù không nhất thiết phải hoạt động tốt cả”. Beta được dùng với nghĩa
“Không có thêm lỗi lặp đi lặp lại nào”. Ngày nay, beta có nghĩa là “Chỉ cần
có thể vượt qua được ngày giao hàng mà chúng ta đã hứa với nhà đầu tư là
chúng ta đã hoàn thành”.
3. “Tôi sẽ giảng giải về mã để người tiếp theo có thể hiểu điều tôi đã
làm”. Đây là lời nói dối về những ý định tốt. Người kỹ sư có ý định giảng
giải về đoạn mã, nhưng khi kế hoạch thất bại, các vấn đề ưu tiên sẽ thay đổi.
Câu hỏi đặt ra cho những người quản lý trở thành “Các ông muốn tôi giảng
giải về đoạn mã hay hoàn thành nó sớm hơn?” Hãy đoán xem câu trả lời là
gì. May mắn là việc thiếu những lời giảng giải thường không thành vấn đề,
vì đoạn mã tồi đến mức cần phải được viết lại trong vòng một năm.
4. “Kiến trúc của chúng tôi có thể mở rộng”. Đây là lời nói dối mà tôi
thích nghe nhất. Thông thường, một người kỹ sư chưa bao giờ tạo ra một sản
phẩm sẽ nói câu này sau khi tạo ra một kiểu mẫu trong Visual Basic. Toàn
bộ lời nói dối sẽ là thế này: “Kiến trúc của Google không thể so sánh với
kiến trúc của tôi được. Họ có thể hỗ trợ 25 triệu nghiên cứu cùng lúc nhưng
chúng tôi sẽ dễ dàng ứng phó với con số một tỷ”. May mắn là trong hầu hết
các trường hợp, sự tiếp nhận sản phẩm diễn ra chậm hơn nhiều so với dự
đoán “thận trọng” của các vị CEO, vì vậy mà sự so sánh này không bao giờ
trở thành một vấn đề.
