Kỹ sư hay Lập trình viên?
Khoảng cách tư duy quyết định dự án của bạn sẽ mở rộng quy mô — hay lặng lẽ sụp đổ trong môi trường production
TL;DR:
Hầu hết các nhóm đều nói họ muốn có “kỹ sư”, nhưng nhiều nơi lại khen thưởng “lập trình viên”. Không phải ở chức danh — mà ở tư duy. Chế độ lập trình viên tối ưu hóa tốc độ hoàn thành (throughput). Chế độ kỹ sư tối ưu hóa tính toàn vẹn lâu dài của sản phẩm. Bạn cần cả hai, nhưng bạn phải trung thực về những gì hệ thống của bạn thực sự khuyến khích.
Đây là câu hỏi khiến các nhà lãnh đạo thức trắng đêm (thường là ngay sau sự cố “tại sao cái này vẫn hỏng?” lần thứ ba trong quý):
Bạn đang xây dựng một đội ngũ lập trình viên (developers)… hay kỹ sư (engineers)?
Trước khi điều này bị gạt bỏ như một sự chẻ hoe câu chữ: sự khác biệt này đã định hình số phận của các dự án rủi ro cao, toàn bộ các ngành công nghiệp và sức khỏe lâu dài của các sản phẩm mà mọi người phụ thuộc vào.
Và bật mí trước: nó hầu như không liên quan gì đến bằng cấp.
Đầu tiên, hãy xóa bỏ huyền thoại về bằng cấp
Một số chuyên gia công nghệ giỏi nhất trên Trái đất là những người tự học. Một số có bằng Tiến sĩ. Hầu hết nằm đâu đó ở giữa.
Bằng cấp quan trọng trong một số lĩnh vực được quy định nghiêm ngặt, quan trọng đối với an toàn (thiết bị y tế, hàng không, cơ sở hạ tầng). Nhưng đối với hầu hết các nhóm sản phẩm, ranh giới phân chia không phải là học thuật.
Nó là thế này:
Lập trình viên tối ưu hóa cho “outputs” (đầu ra/sản lượng). Kỹ sư tối ưu hóa cho “outcomes” (kết quả/tác động).
Hãy nhớ kỹ điều đó. Đó là toàn bộ nội dung bài viết này.
Chế độ lập trình viên: hoàn thành nhiệm vụ (ship the task)
Chế độ lập trình viên về cơ bản là hướng nhiệm vụ.
Có một ticket.
Nó có tiêu chí chấp nhận (acceptance criteria).
Nó được hoàn thành.
Ticket tiếp theo.
Đây không phải là một sự xúc phạm — đó là một năng lực sống còn. Chế độ lập trình viên phát triển mạnh khi:
- các yêu cầu tương đối rõ ràng,
- ưu tiên là động lực (momentum),
- việc thực thi cần ổn định và đo lường được.
Nó cũng phù hợp gọn gàng vào các bảng điều khiển và báo cáo trạng thái (vì đầu ra rất dễ đếm).
Phương thức thất bại: chế độ lập trình viên có thể tiếp tục di chuyển mãi mãi trong một backlog không bao giờ kết thúc… mà không bao giờ hỏi liệu nhóm có đang di chuyển về đúng đích hay không.
Bạn có thể “ship” liên tục và vẫn:
- xây dựng sai thứ, hoặc
- xây dựng đúng thứ trên một nền tảng không vững chắc.
Chế độ kỹ sư: chất vấn thực tế
Chế độ kỹ sư bắt đầu với một bản năng khác:
“Điều này có hợp lý không?”
Các kỹ sư đặt câu hỏi về các yêu cầu. Họ thách thức các giả định. Họ quan tâm đến việc hệ thống sẽ trở thành gì sau thay đổi này — không chỉ là liệu ticket có thể được đóng trước thứ Sáu hay không.
Nơi một lập trình viên nhìn thấy một ticket, một kỹ sư nhìn thấy:
- một hệ thống,
- với các sự phụ thuộc,
- với các sự đánh đổi,
- với các hậu quả lâu dài.
Chế độ kỹ sư đặt ra những câu hỏi cảm thấy bất tiện bây giờ và vô giá sau này:
- Chúng ta đang giải quyết vấn đề thực sự — hay chỉ là triệu chứng ồn ào nhất?
- Tại sao điều này lại xảy ra một lần nữa?
- Giải pháp này đang trở nên đơn giản hơn… hay chỉ to ra?
- Chúng ta đang tạo ra nợ kỹ thuật gì, và nó sẽ tốn kém bao nhiêu sau này?
Thực tế cuối cùng sẽ kiểm toán tất cả mọi người.
Tại sao nhiều quản lý thích chế độ lập trình viên (và tại sao điều này nguy hiểm)
Đây là phần không thoải mái:
Nhiều tổ chức được cấu trúc để khen thưởng chế độ lập trình viên, bởi vì nó tạo ra các chỉ số rõ ràng, dễ báo cáo:
- số ticket đã đóng
- tính năng đã ship
- story points đã đốt
- “chúng ta đang đúng tiến độ”
Đó là món ăn tinh thần thoải mái cho quản lý. Nó trấn an các bên liên quan. Nó vừa vặn trong các slide thuyết trình.
Chế độ kỹ sư tạo ra một loại câu khác — thường là sự thật, thường cần thiết, và thường đáng sợ:
“Chúng tôi đã tìm thấy một cái gì đó sai cơ bản. Chúng ta nên dừng lại và sửa nó cho đúng.”
Câu đó không phù hợp trong một bản cập nhật trạng thái hàng tuần.
Nó đe dọa các mốc thời gian. Nó buộc các sự đánh đổi phải được phơi bày. Nó làm cho sự không chắc chắn trở nên hữu hình.
Nhưng đó cũng là câu nói ngăn chặn những thảm họa tốn kém.
Ba lăng kính thực tế
Đây không phải là những cú lừa. Chúng là các mô hình — cách các ưu đãi định hình hành vi ở quy mô lớn.
1) Khi “xong” không có nghĩa là “hoạt động” (Healthcare.gov)
Việc triển khai ban đầu của Healthcare.gov được trích dẫn rộng rãi như một trường hợp mà nhiều nhóm đã cung cấp các thành phần và cột mốc — nhưng hệ thống đầy đủ đã chật vật dưới nhu cầu thực tế.
Bài học không phải là “mọi người không biết code”.
Mà là thế này:
Khi các nhóm được khen thưởng vì hoàn thành nhiệm vụ trong các silo (khoang chứa riêng biệt), hệ thống có thể trông hoàn chỉnh trên giấy… trong khi thất bại về tổng thể.
2) Quyền dừng dây chuyền (Toyota)
Toyota đã thể chế hóa một nguyên tắc kỹ thuật mà nhiều tổ chức phần mềm chỉ giả vờ có:
Nếu có gì đó sai, bất cứ ai cũng có thể dừng dây chuyền.
Văn hóa không tôn vinh sự chuyển động. Nó tôn vinh sự phòng ngừa:
- tìm ra lỗi sớm,
- sửa chữa nguyên nhân gốc rễ,
- tránh lặp lại các vấn đề tương tự.
Đó là tư duy kỹ thuật biến thành cơ bắp của tổ chức.
3) Xây dựng nền tảng một lần (Estonia)
Câu chuyện chính phủ số của Estonia thường được trích dẫn vì nó không bắt đầu bằng “số hóa mọi biểu mẫu”.
Nó tập trung vào kiến trúc: xây dựng một nền tảng an toàn, có khả năng tương tác để các dịch vụ có thể được xây dựng một cách đáng tin cậy trên đó trong nhiều năm.
Đó là một câu hỏi của kỹ sư:
“Nền tảng nào làm cho 1.000 tính năng tiếp theo trở nên khả thi?”
Lưu ý: Sự khác biệt thực sự (Outputs vs Outcomes)
Đây là chẩn đoán đơn giản nhất.
Outputs (tối ưu hóa kiểu lập trình viên): ticket đã đóng, tính năng đã ship, story points, bug đã vá.
Outcomes - Kết quả (tối ưu hóa kiểu kỹ sư): sự cố lặp lại được loại bỏ, độ phức tạp giảm, nỗi đau của khách hàng được xóa bỏ, khả năng phục hồi của hệ thống được cải thiện.Outputs cảm giác như sự tiến bộ. Outcomes là sự tiến bộ — nhưng chúng khó đếm hơn.
Vậy… bạn cần cái nào ngay bây giờ?
Câu trả lời không phải là “kỹ sư tốt, lập trình viên xấu”. Đó là suy nghĩ lười biếng.
Bạn cần cả hai. Câu hỏi thực sự là:
Tổ chức của bạn khen thưởng điều gì?
Một quy tắc ngón tay cái thực tế:
- Giai đoạn đầu / phạm vi rõ ràng / lặp lại nhanh → chế độ lập trình viên có thể thắng.
- Độ phức tạp ngày càng tăng / sự cố lặp lại / quy mô người dùng lớn → chế độ kỹ sư trở thành vấn đề sống còn.
Các đội ngũ tốt nhất không thuê một loại người mãi mãi. Họ phát triển những người có thể đổi mũ:
- ship khi tốc độ là cần thiết,
- chậm lại khi tính toàn vẹn là cần thiết,
- và giải thích sự đánh đổi bằng ngôn ngữ dễ hiểu.
Lưu ý: Cách các nhà lãnh đạo có được tư duy kỹ sư nhiều hơn (mà không mất tốc độ)
Nếu bạn muốn hành vi chế độ kỹ sư, hãy khen thưởng hành vi hướng kết quả. Một cách rõ ràng.
- Tuyên dương bản sửa lỗi ngăn chặn năm sự cố tiếp theo — không chỉ bản vá đóng ticket ngày hôm nay.
- Theo dõi các vấn đề lặp lại và giảm bớt chúng (“tại sao chuyện này lại xảy ra nữa?”).
- Làm cho công việc đơn giản hóa trở nên hữu hình (loại bỏ sự phức tạp là tiến bộ).
- Bảo vệ thời gian cho sức khỏe hệ thống giống như cách bạn bảo vệ việc giao tính năng.
- Tạo sự an toàn để ai đó có thể nói “yêu cầu này không hợp lý” mà không bị gắn mác “khó tính”.
Suy nghĩ cuối cùng
Nếu backlog của bạn đang thu nhỏ lại nhưng sản phẩm của bạn đang trở nên:
- khó thay đổi hơn,
- khó kiểm thử hơn,
- và dễ vỡ hơn…
bạn không gặp vấn đề về năng suất.
Bạn có một vấn đề về động lực khuyến khích (incentives problem).
Các lập trình viên giữ cho cỗ máy chuyển động.
Các kỹ sư giữ cho cỗ máy không trở thành một thiết bị mong manh, quá phức tạp được gắn kết với nhau bằng hy vọng.
Vậy — đội của bạn khen thưởng điều gì hôm nay: outputs, hay outcomes?
TIC Insights | Quan điểm dành cho các nhà lãnh đạo cấp cao điều hướng công nghệ, đổi mới và thay đổi.