Không ai chủ đích gây khó, không có kẻ thù rõ ràng, nhưng mọi nỗ lực đều bị đẩy từ chỗ này sang chỗ khác mà không bao giờ đến đích. Đó là Kafkaesque — và nó không chỉ nằm trong trang sách.
Franz Kafka là ai
Franz Kafka (1883–1924) là nhà văn người Séc gốc Do Thái, viết bằng tiếng Đức. Ông nổi tiếng vì viết về cảm giác của con người bị mắc kẹt trong hệ thống mà chính họ cũng không hiểu nó vận hành theo logic gì. Nhân vật của Kafka không bao giờ gặp kẻ thù rõ ràng, không ai chủ đích hại họ, nhưng họ bị đẩy từ chỗ này sang chỗ khác, bị yêu cầu làm hết thứ này đến thứ khác, mà không bao giờ đến được đích.
Thuật ngữ “Kafkaesque” được đặt ra sau khi ông mất để mô tả đúng cái cảm giác đó — và nó trở thành một khái niệm được dùng rộng rãi trong cả văn học, triết học, quản trị, và kinh doanh.
Ba tác phẩm chính
“Vụ án” — Josef K. bị bắt và đưa ra tòa mà không ai nói cho anh ta biết tội gì. Anh ta cố hỏi, cố tìm hiểu, gặp luật sư, gặp quan tòa, nhưng mỗi người chỉ biết một mảnh nhỏ, không ai nắm toàn cảnh. Hệ thống vận hành trơn tru nhưng hoàn toàn mù mờ về mục đích. Cuối cùng anh ta bị xử tử mà vẫn không hiểu mình phạm tội gì.
“Lâu đài” — Nhân vật K. được thuê làm việc cho một lâu đài nhưng không bao giờ vào được. Mỗi lần cố liên lạc, anh ta bị đẩy qua các tầng trung gian. Không ai từ chối thẳng, nhưng cũng không ai giúp. Hệ thống không nói “không” — nó chỉ không bao giờ nói “có.”
“Hóa thân” — Gregor Samsa tỉnh dậy thành con bọ khổng lồ. Điều đáng chú ý không phải việc biến hình, mà là phản ứng của gia đình: họ dần coi anh ta là gánh nặng, là vấn đề cần xử lý, chứ không phải con người cần cứu. Con người bị chính hệ thống xung quanh mình coi như đồ vật.
Kafkaesque là gì — nói đơn giản
Kafkaesque không đơn giản là “rườm rà” hay “phức tạp.” Nó có những đặc điểm rất cụ thể:
Mỗi phần thì hợp lý, nhưng ghép lại thì vô lý — Người A duyệt vì đúng quy trình. Người B yêu cầu thêm giấy tờ vì đúng quy định. Nhưng tổng lại thì kết quả phi lý. Không ai sai cả, nhưng mọi thứ vẫn sai.
Không có ai chịu trách nhiệm — Không có “ông sếp xấu” hay kẻ thù rõ ràng. Vấn đề nằm trong chính cách tổ chức vận hành. Không ai cố ý gây khó, nhưng hệ thống tự nó tạo ra rào cản. Muốn sửa cũng không biết sửa chỗ nào vì không có người cụ thể để chỉ ra.
Con người bị coi như mã số — Hoàn cảnh riêng, sự cấp bách, nỗ lực cá nhân — tất cả bị bỏ qua. Hệ thống đối xử với mọi trường hợp như nhau, kể cả khi điều đó hoàn toàn không phù hợp.
Luôn cho hy vọng nhưng không bao giờ đến đích — Hệ thống không nói thẳng “không được.” Nó luôn để ngỏ: “chờ thêm”, “đang xem”, “cần thêm thông tin.” Người bên trong cứ hy vọng, cứ cố gắng, nhưng không bao giờ được giải quyết dứt điểm.
Người bị kẹt bắt đầu tự trách mình — “Có phải mình sai không? Mình thiếu gì? Mình chưa làm đúng bước nào?” Hệ thống đẩy trách nhiệm từ chính nó sang cá nhân.
Hệ thống Kafkaesque tự bảo vệ chính nó
Người có lợi từ quy trình (người có quyền duyệt, người quản lý trung gian) sẽ bảo vệ quy trình đó, vì nó là nguồn gốc vai trò của họ. Bỏ quy trình đi thì vai trò của họ không còn ý nghĩa.
Mỗi lần cố cải cách thường bị hệ thống “nuốt” — thêm một ban cải tiến, thêm một nhóm đánh giá — bản thân việc cải cách lại trở thành thêm một lớp rườm rà mới.
Phân biệt với những thứ tương tự
- Rườm rà thông thường: Biết mình cần gì, chỉ là mất thời gian. Kafkaesque thì không chắc mình cần gì, hệ thống cũng không nói rõ.
- Thủ tục hành chính: Rào cản cụ thể, có thể bỏ từng cái. Kafkaesque là khi việc tìm ra rào cản ở đâu cũng bị cản trở.
- Nghịch lý vòng tròn: Mâu thuẫn logic cụ thể (cần kinh nghiệm để xin việc, nhưng cần đi làm để có kinh nghiệm). Kafkaesque rộng hơn — toàn bộ hệ thống phi lý chứ không chỉ một điểm.
Kafkaesque trong doanh nghiệp — 4 tầng
Tầng 1: Quy trình
Quy trình phê duyệt ban đầu 2 bước, qua vài năm mỗi lần có sự cố thì thêm một bước kiểm soát. Không ai bao giờ bỏ bước cũ vì “nhỡ lại xảy ra sự cố.” Hệ thống chỉ siết chặt chứ không bao giờ nới lỏng — vì thêm bước thì không ai bị chê trách, nhưng bỏ bước mà xảy ra sự cố thì bị quy trách nhiệm.
Tầng 2: Công nghệ
Công cụ chồng công cụ. Dùng phần mềm A để quản lý công việc, nhưng quản lý lại muốn báo cáo trên bảng tính riêng, sếp lại muốn xem trên bảng điều khiển khác. Nhân viên phải cập nhật cùng một thông tin ở 3 nơi. Mỗi công cụ được chọn vì nó “tốt nhất” cho việc riêng của nó, nhưng tổng thể thì tạo ra mê cung.
Tầng 3: Tổ chức
Cấu trúc phòng ban tạo ra ranh giới giả tạo. Một việc cần 3 nhóm phối hợp, mỗi nhóm có mục tiêu riêng, ưu tiên riêng, lịch làm việc riêng. Không ai cản trở ai, nhưng cũng không ai cùng hướng với ai.
Tầng 4: Văn hóa
Tầng sâu nhất và khó sửa nhất. Nhân viên không còn hỏi “tại sao” nữa. Họ chấp nhận “đây là cách mọi thứ hoạt động.” Người mới vào hỏi thì bị coi là chưa hiểu. Sự phi lý trở thành bình thường đến mức không ai nhận ra nó nữa.
Các vấn đề cụ thể đang tồn tại
Vấn đề 1: Phạm vi công việc bị thu hẹp không lý do
Hệ thống quản lý khách hàng được thiết kế ban đầu với đầy đủ chức năng: quản lý khách hàng, quản lý giấy phép phần mềm, tích hợp thanh toán, phân quyền theo phòng ban, xử lý yêu cầu hỗ trợ, quản lý bán hàng. Một lập trình viên đã một mình hoàn thành khoảng 70-80% khối lượng — hơn 213.000 dòng mã nguồn.
Sau đó phạm vi bị cắt dần. Mỗi lần cắt đều có lý do nghe hợp lý — thiếu người, cần tập trung. Nhưng cắt đến mức hệ thống quản lý khách hàng không còn quản lý khách hàng thì nó không còn đúng tên gọi nữa. Phần đã làm xong bị bỏ mà không ai giải thích sai ở đâu.
Công sức bị phủ nhận ngược — không phải người làm thất bại, mà phạm vi bị rút đi sau khi đã hoàn thành.
Vấn đề 2: Công nghệ được chọn theo cảm hứng
Thay vì quy trình “xác định vấn đề → đánh giá lựa chọn → chọn giải pháp phù hợp”, quyết định đang đi ngược: thấy giải pháp hay → tìm cách nhét vào → không quan tâm vấn đề thực tế là gì.
- Better Auth: Công cụ xác thực dành cho người dùng cuối bị đem dùng để xác thực giữa các máy chủ nội bộ — sai hoàn toàn mục đích thiết kế.
- Keycloak: Đúng công cụ cho việc quản lý quyền tập trung, nhưng triển khai mà không kiểm tra các phần khác đã sẵn sàng chưa. Vấn đề tài khoản đại lý không thuộc công ty chưa có cách xử lý — nhưng vẫn đòi áp dụng ngay.
- Phần mềm mã nguồn mở: Dùng để xây sản phẩm bán ra mà không xem xét điều khoản bản quyền. Nhiều phần mềm mã nguồn mở có ràng buộc — nếu dùng nó để làm sản phẩm thương mại, toàn bộ sản phẩm đó cũng phải công khai. Đây là rủi ro pháp lý thực sự.
Người quyết định đang chọn công nghệ vì nó nghe hay, vì người khác dùng — không phải vì nó giải quyết vấn đề cụ thể nào.
Vấn đề 3: Xây đi xây lại không có điểm dừng
Hệ thống cũ được viết từ hơn 1 năm trước với nhiều vấn đề chất lượng:
- Hệ thống kiểm tra lỗi tự động bị tắt hoàn toàn — tức là bỏ đi lớp bảo vệ quan trọng nhất
- Mã nguồn cồng kềnh, thiếu tổ chức
- Phần xử lý lỗi bị vô hiệu hóa — khi hệ thống gặp sự cố, nó không báo cho ai biết, cứ chạy tiếp với dữ liệu có thể đã sai
Lập trình viên được giao chuyển sang hệ thống mới, hoàn thành, rồi một ngày được thông báo sẽ xây lại hoàn toàn. Không ai nói lỗi ở đâu. Không ai chỉ ra cần sửa gì.
Chất lượng mã nguồn cũ phản ánh vấn đề văn hóa: tắt kiểm tra lỗi vì nó “cản trở tốc độ”, vô hiệu hóa xử lý sự cố vì không biết sửa. Đây là văn hóa “chạy được là xong.” Khi văn hóa đó vẫn còn, xây lại bao nhiêu lần thì hệ thống mới cuối cùng cũng sẽ giống hệ thống cũ.
Vấn đề 4: Không ai chịu trách nhiệm mô tả yêu cầu
Bộ phận bán hàng yêu cầu chức năng mới nhưng mô tả không ai hiểu rõ. Lập trình viên cố viết tài liệu xác nhận lại — không ai trả lời. Bộ phận bán hàng cần tính năng vòng quay may mắn cho “khách hàng” nhưng không ai nói rõ “khách hàng” ở đây là ai — là người đã mua hàng? Hay chỉ cần đăng ký tài khoản là đủ?
Thiếu hoàn toàn người chịu trách nhiệm về sản phẩm — người mô tả rõ yêu cầu, quyết định làm gì và không làm gì, và chịu trách nhiệm cho quyết định đó.
Lập trình viên bị buộc phải vừa viết mã, vừa đoán yêu cầu, vừa tự quyết định sản phẩm — nhưng không được trao quyền. Phải đoán, làm theo phỏng đoán, rồi chịu hậu quả khi phỏng đoán sai.
Vấn đề 5: Hệ thống im lặng
Bảng khảo sát cho sản phẩm nội dung AI được chuẩn bị, nhờ cấp trên gửi nội bộ. Không ai từ chối. Nhưng cũng không ai gửi. Không có phản hồi nào.
Giống hệt nhân vật K. trong Lâu đài — không bao giờ bị từ chối thẳng, chỉ là không bao giờ được chấp nhận.
Bộ phận hỗ trợ yêu cầu chức năng quản lý yêu cầu hỗ trợ, nhưng khi hỏi kỹ thì chỉ cần lưu lại thông tin — không cần theo dõi lịch sử, không cần phân công tự động. Tại sao phải xây phần mềm cho việc mà bảng tính Excel làm tốt hơn?
Vấn đề 6: Quyết định kỹ thuật thay thế quyết định kinh doanh
Một lập trình viên — không phải người phụ trách sản phẩm — đang ra quyết định vận hành mà không hiểu nghiệp vụ kinh doanh và không hỏi ý kiến các phòng ban.
Lập trình viên giỏi đến mấy thì chuyên môn vẫn là kỹ thuật. Khi ra quyết định kinh doanh mà không hiểu kinh doanh, quyết định sẽ dựa trên thứ duy nhất họ hiểu: công nghệ. Thấy công cụ nào hay thì dùng, không phải vì nó giải quyết vấn đề cụ thể nào.
Khi người đó không hỏi các phòng ban: lập trình viên tự quyết → phòng ban thấy không được hỏi thì không góp ý → lập trình viên càng tự quyết → sản phẩm càng xa nhu cầu thực tế.
Quyết định kinh doanh thuộc về người hiểu thị trường, hiểu khách hàng, hiểu nhu cầu nội bộ. Lập trình viên biến quyết định đó thành sản phẩm. Hai vai trò bổ sung, không thay thế nhau.
Vấn đề 7: Hai hệ thống liên quan mật thiết bị xây tách rời
Hệ thống quản lý khách hàng và hệ thống quản lý nhân sự phụ thuộc lẫn nhau:
- Nhân viên bán hàng trong hệ thống khách hàng cũng là nhân viên trong hệ thống nhân sự
- Phân công khách hàng cần biết nhân viên thuộc nhóm nào, ai là quản lý, còn làm hay đã nghỉ
- Tính hiệu quả bán hàng: dữ liệu giao dịch phải khớp với thông tin nhân viên
- Phân quyền theo phòng ban: cấu trúc tổ chức nằm ở hệ thống nhân sự
Thực tế: hệ thống nhân sự được xây mà không hỏi ý kiến người đang quản lý toàn bộ hệ thống phía sau. Hai hệ thống phụ thuộc nhau ở tầng sâu nhất nhưng được xây bởi hai bên không trao đổi.
Hậu quả: phải làm lại một trong hai, hoặc xây thêm lớp kết nối — tốn công gấp nhiều lần so với thống nhất từ đầu.
Vấn đề 8: Tài liệu và hoạt động hình thức
Tài liệu tồn tại để đảm bảo mọi người hiểu giống nhau. Nhưng thực tế:
- Tài liệu xác nhận nghiệp vụ được viết — người nhận đọc không hiểu nhưng không hỏi lại, gật rồi để đó
- Tài liệu nhờ AI viết hộ rồi gửi đi mà không đọc lại, không biết viết cho ai, nội dung có đúng không
- Hoạt động đọc sách nội bộ: thay vì chia sẻ góc nhìn cá nhân sau khi đọc xong (cuốn này thay đổi cách mình nghĩ thế nào, đồng ý chỗ nào, không đồng ý chỗ nào), thì lấy một đoạn ra phân tích tách rời — trong khi còn chẳng biết tác giả viết đoạn đó trong bối cảnh nào
Tất cả là biểu hiện của cùng một vấn đề: mọi thứ được làm theo mảnh, không ai nhìn tổng thể, không ai hỏi “cái này phục vụ mục đích gì.”
Nghịch lý tổng thể
Hệ thống đang đồng thời:
- Cắt bỏ những thứ có giá trị đã làm xong
- Nhét vào những thứ không cần thiết mà không ai đánh giá
- Yêu cầu xây lại mà không nói lý do
- Không mô tả yêu cầu nhưng vẫn kỳ vọng có sản phẩm
- Im lặng trước mọi nỗ lực trao đổi
Mỗi quyết định riêng lẻ đều có vẻ hợp lý. Tổng thể thì hoàn toàn phi lý. Đây là Kafkaesque.
Bối cảnh bên ngoài — AI đang thay đổi mọi thứ
Nghiên cứu của Anthropic
Anthropic — công ty phát triển trí tuệ nhân tạo Claude — đã công bố nghiên cứu phân tích mức độ AI đang thay thế công việc trong từng ngành. Ngành tiếp thị tự động, công cụ hỗ trợ bán hàng, và phần mềm kinh doanh trực tuyến nằm trong nhóm bị ảnh hưởng nặng nhất.
Bị đe dọa từ hai phía
Phía thứ nhất — Các công cụ AI mới: Claude, ChatGPT, Gemini có thể tạo nội dung, lên kế hoạch tiếp thị, phân tích khách hàng — những việc trước đây phải dùng phần mềm chuyên dụng.
Phía thứ hai — Các nền tảng lớn tự tích hợp AI: Facebook có công cụ quảng cáo AI, TikTok có bộ sáng tạo nội dung AI, các sàn thương mại điện tử có trợ lý AI. Khi chính nền tảng cung cấp miễn phí những gì công ty đang bán, giá trị sản phẩm giảm rất nhanh.
Khoảng trễ đang rút ngắn
Các ngành này chưa bị thay thế ngay vì người dùng cần thời gian thử, so sánh, đánh giá hiệu quả. Nhưng khoảng thời gian đó đang ngắn lại rất nhanh.
Ngành phần mềm là ví dụ: cách đây 2 năm lập trình viên viết mã từ đầu đến cuối, bây giờ công cụ AI đã thay đổi hoàn toàn cách làm việc. Quá trình chuyển đổi mất khoảng 18-24 tháng.
Ngành tiếp thị đang ở đúng giai đoạn đó. Và rào cản chuyển đổi còn thấp hơn: chủ shop chỉ cần mở ChatGPT, dán mô tả sản phẩm, nhờ viết 10 bài đăng — xong. Không cần cài phần mềm, không cần mua giấy phép.
Khách hàng chưa bỏ đi không phải vì sản phẩm tốt hơn AI, mà vì họ chưa thử xong. Khi kết luận rằng AI đủ tốt — và kết luận đó đến gần hơn sau mỗi bản cập nhật — thì sự chuyển dịch rất nhanh vì không có gì giữ chân.
Cách vận hành năm 2005 trong thế giới 2026
AI thay đổi sau mỗi bản cập nhật — có khi mỗi tháng. Cách vận hành bên trong giống hai mươi năm trước: yêu cầu không ai mô tả rõ, công nghệ chọn theo cảm hứng, phạm vi thay đổi liên tục, phòng ban không kết nối.
Hai mươi năm trước thì chấp nhận được vì thị trường chậm. Năm 2026, khi một nhóm hai người dùng AI xây sản phẩm cạnh tranh trong vài tuần, thì cách vận hành này là tự đào thải.
Nếu thuê bên ngoài làm thì sao?
Đơn vị làm phần mềm thuê ngoài sẽ nhận ra ngay: hỏi “khách hàng là gì?” — không ai trả lời. Gửi tài liệu xác nhận — không ai phản hồi. Làm xong — bị bảo làm lại.
Khác biệt: lập trình viên nội bộ chịu đựng, bên ngoài tính tiền. Mỗi buổi họp kéo dài, họ tính. Mỗi lần thay đổi, họ tính thêm. Chi phí gấp 3-5 lần.
Vấn đề không phải “tự làm hay thuê” — vấn đề là “biết mình muốn gì không.” Tự làm mà không biết thì lãng phí công sức. Thuê mà không biết thì lãng phí tiền.
So sánh với Apache Kafka — hệ thống truyền thông điệp
Apache Kafka (phần mềm) và Franz Kafka (nhà văn) chỉ trùng tên — người tạo ra đặt tên vì thích nhà văn. Nhưng sự tương đồng rất thú vị.
Apache Kafka giải quyết đúng bài toán: nhiều phần trong hệ thống, mỗi phần có nhu cầu riêng, mỗi nhu cầu đều hợp lý, nhưng khi tất cả nói chuyện trực tiếp thì thành hỗn loạn. Mỗi kết nối riêng lẻ có lý do, tổng thể thì phi lý. Đúng tinh thần Kafkaesque.
Apache Kafka giải quyết bằng trạm trung chuyển. Thay vì mọi người nói trực tiếp tạo hỗn loạn, mọi thông điệp đi qua một chỗ, có thứ tự, có ghi lại.
Kéo về tổ chức: công ty đang thiếu trạm trung chuyển. Bán hàng gửi yêu cầu, kỹ thuật nhận và thực hiện, người phụ trách sản phẩm là trạm trung chuyển — đảm bảo yêu cầu rõ ràng, đúng thứ tự, không bị mất. Hiện tại thì bán hàng nói một kiểu, hỗ trợ hiểu một kiểu, lập trình viên tự đoán, thông điệp bị mất, bị hiểu sai.
Điều trớ trêu: công ty hoạt động trong ngành công nghệ, có thể hiểu tại sao hệ thống phần mềm cần trạm trung chuyển — nhưng không áp dụng được tư duy đó vào cách vận hành của chính mình.
Vấn đề 9: Hệ thống chỉ nhúc nhích khi có xung đột
Sau nhiều lần trình bày hợp lý, viết tài liệu, hỏi xác nhận — không ai phản hồi — cuối cùng lập trình viên phải phản ứng gay gắt thì mới được tự viết lại CRM theo cách đúng. Tức là tổ chức không có cơ chế tiếp nhận ý kiến bình thường. Lý lẽ không hiệu quả, chỉ có xung đột mới tạo ra thay đổi.
Nhưng đây chỉ là thuốc giảm đau, không phải thuốc chữa bệnh. Vấn đề gốc vẫn nguyên.
Vấn đề 10: Cùng người, cùng cách làm cũ, chỉ khác dự án
Người đã quyết định dùng phần mềm mã nguồn mở có vấn đề bản quyền để xây CRM, giờ được giao làm HRM. Cùng một người, cùng cách tiếp cận, chỉ khác dự án. Và cách làm lặp lại y hệt: ném một file mô tả vào rồi bảo triển khai Keycloak, không cần biết cơ sở dữ liệu chồng chéo thế nào, không cần biết đại lý có hàng đống vấn đề chưa giải quyết, không có bức tranh tổng thể, không có quy trình nghiệp vụ.
Cái file mô tả đó không phải tài liệu phân tích nghiệp vụ, không phải tài liệu thiết kế hệ thống — chỉ là mô tả ở mức bề mặt. Không có câu trả lời cho những câu hỏi cơ bản: khi nhân viên nghỉ việc trong hệ thống nhân sự thì tài khoản trong hệ thống khách hàng xử lý thế nào? Đại lý có mặt trong hệ thống nhân sự không hay chỉ trong hệ thống khách hàng? Quyền truy cập đồng bộ giữa hai hệ thống ra sao?
Đây là cùng một vòng lặp từ đầu đến giờ: ai đó ra quyết định mà không hiểu vấn đề → triển khai gặp trục trặc → không ai chịu trách nhiệm → lập trình viên phải gánh hậu quả → phản ứng gay gắt → được quyền làm lại → xong rồi lại tiếp tục vòng mới.
Vấn đề 11: Họ có thật sự hiểu nghiệp vụ không?
Câu hỏi cốt lõi cần đặt ra: người ra quyết định có thật sự hiểu hệ thống vận hành thế nào không? Và họ có muốn người khác hiểu không?
Có hai khả năng, và cả hai đều là vấn đề nghiêm trọng.
Khả năng thứ nhất: họ không hiểu. Họ biết tên gọi — CRM, HRM, Keycloak — nhưng không hiểu bên trong vận hành thế nào, dữ liệu chảy từ đâu đến đâu, phòng ban nào cần gì, quy trình xử lý một đơn hàng từ lúc khách liên hệ đến lúc hoàn tất trải qua bao nhiêu bước. Họ nhìn hệ thống như một cái hộp: bỏ yêu cầu vào, ra sản phẩm. Bên trong hộp hoạt động thế nào thì không quan tâm. Vì không hiểu, nên mới có chuyện ném file mô tả rồi bảo triển khai mà không cần biết gì thêm.
Khả năng thứ hai: họ hiểu, nhưng không muốn người khác hiểu. Nếu một người giữ toàn bộ hiểu biết trong đầu mà không chia sẻ, không viết tài liệu đàng hoàng, không giải thích cho người khác — thì hoặc họ không có khả năng truyền đạt, hoặc họ cố ý giữ thông tin vì khi chỉ mình họ hiểu thì chỉ mình họ có quyền quyết định. Thông tin trở thành quyền lực. Đây là cơ chế tự bảo vệ kinh điển trong hệ thống Kafkaesque.
Cả hai khả năng đều dẫn đến cùng hệ quả: người thực sự phải triển khai không có đủ thông tin để làm đúng. Nhận được mô tả bề mặt, không có quy trình nghiệp vụ, không có bức tranh tổng thể. Rồi khi kết quả không như kỳ vọng, trách nhiệm rơi về phía người triển khai.
Và câu hỏi sâu hơn: nếu họ không hiểu nghiệp vụ, thì ai trong tổ chức hiểu? Nếu không ai hiểu toàn bộ cách hệ thống vận hành từ đầu đến cuối — từ lúc khách hàng tiếp cận, qua bán hàng, thanh toán, cấp giấy phép, hỗ trợ sau bán hàng, quản lý đại lý — thì sản phẩm đang được xây dựng dựa trên cái gì? Dựa trên phỏng đoán của từng người, mỗi người một mảnh, không ai ghép lại.
Cách tiếp cận: làm việc như đơn vị bên ngoài ngay trong nội bộ
Khi tổ chức đối xử với lập trình viên như người nhận yêu cầu rồi thực thi — không hỏi ý kiến, không chia sẻ bức tranh tổng thể, không quan tâm góp ý — thì cách bảo vệ mình là đặt mình vào đúng vai trò đó: người nhận yêu cầu và thực thi, không hơn không kém.
Khi nhận được file mô tả và bảo triển khai, xử lý đúng như một đơn vị bên ngoài: nhận yêu cầu, đọc, liệt kê những gì thiếu, những gì mâu thuẫn, những gì không thể thực hiện với thông tin hiện có — rồi gửi lại. Không đoán hộ, không tự bổ sung, không lấp chỗ trống bằng phỏng đoán. Thiếu thông tin thì hỏi lại bằng văn bản. Có vấn đề thì ghi lại bằng văn bản. Không ai trả lời thì ghi nhận rằng không ai trả lời — cũng bằng văn bản.
Cách này bảo vệ ở nhiều tầng:
Về trách nhiệm: khi đã ghi lại rằng yêu cầu thiếu mô tả nghiệp vụ, cơ sở dữ liệu chưa thống nhất, vấn đề đại lý chưa có giải pháp — thì khi có trục trặc, có bằng chứng đã cảnh báo. Không ai có thể nói “sao không nói sớm.”
Về công sức: ngừng lấp chỗ trống cho người khác. Trước đây vừa viết mã, vừa tự tìm hiểu nghiệp vụ, vừa tự thiết kế giải pháp, vừa viết tài liệu xác nhận mà không ai đọc. Bây giờ trả lại đúng phần trách nhiệm: mô tả yêu cầu rõ ràng là việc của người yêu cầu, không phải việc của người thực hiện.
Về tinh thần: không còn bị kẹt giữa “muốn làm đúng nhưng không được cho phép.” Làm đúng những gì được yêu cầu, trong phạm vi thông tin được cung cấp. Phần còn thiếu là trách nhiệm của người cung cấp thông tin.
Và cái hay nhất: khi ngừng đoán hộ, ngừng lấp chỗ trống, ngừng tự chạy đi hỏi khắp nơi — thì những lỗ hổng về nghiệp vụ, về quy trình, về liên kết giữa các phòng ban sẽ tự hiện ra. Không cần chỉ ra nữa — chính kết quả công việc sẽ chỉ ra.
Khi muốn trao đổi thẳng thắn
Nên nói, nhưng không nói tất cả cùng lúc
Nếu đổ hết mọi vấn đề ra một lần, dù đúng đến mấy, người nghe sẽ quá tải và phản ứng phòng thủ. Họ sẽ nghe thấy “phàn nàn” thay vì “phân tích.”
Chọn đúng một vấn đề cụ thể nhất, thiết thực nhất, dễ hiểu nhất để bắt đầu. Ví dụ: chuyện CRM và HRM — hai hệ thống phụ thuộc nhau mà đang được xây tách rời, không có tài liệu nghiệp vụ, không thống nhất cơ sở dữ liệu. Chỉ cần nói: “Hai hệ thống này cần nói chuyện với nhau ở tầng dữ liệu. Hiện tại chưa có ai ngồi lại thống nhất. Nếu không làm bây giờ thì sau sửa lại tốn gấp nhiều lần. Cần một buổi ngồi lại với người làm HRM để thống nhất trước khi triển khai tiếp.”
Đây là yêu cầu cụ thể, hợp lý, không ai coi là phàn nàn. Và phản ứng của cấp trên với yêu cầu đơn giản này sẽ cho biết rất nhiều: nếu đồng ý ngồi lại — tốt, có cơ hội trao đổi sâu hơn sau. Nếu gạt đi hoặc im lặng — thì biết rằng ngay cả yêu cầu đơn giản nhất cũng không được tiếp nhận.
Giọng nói quan trọng
Giữ giọng của người đang bảo vệ sản phẩm chung, không phải người đang bảo vệ bản thân. “Muốn hệ thống chạy đúng” khác rất nhiều với “mệt mỏi vì mọi thứ.” Cả hai đều đúng, nhưng câu đầu mở ra cuộc trao đổi, câu sau khiến người nghe phòng thủ.
Nói với ai quan trọng hơn nói cái gì
Cần tìm người có quyền ra quyết định VÀ sẵn sàng lắng nghe. Hai điều kiện phải đi cùng. Người có quyền mà không nghe thì đang nói với bức tường. Người nghe mà không có quyền thì chỉ thêm đồng minh bất lực. Nếu không tìm được ai có cả hai, điều đó tự nó là câu trả lời.
Cách đặt vấn đề
Nói như người đang tìm cách giải quyết, không phải người đang chỉ ra lỗi:
- “Chức năng xử lý yêu cầu hỗ trợ cần kết nối với dữ liệu khách hàng không? Nếu có thì cần mô tả rõ hơn, nếu không thì làm đơn giản nhất.”
- “Sản phẩm nội dung AI nhắm đến ai, đã có phản hồi từ người dùng chưa? Bảng khảo sát đã sẵn sàng, cần hỗ trợ gửi.”
Chuẩn bị cho hai kết quả
Kết quả tốt: ai đó lắng nghe, phản hồi, bắt đầu có trao đổi thực sự.
Kết quả còn lại: im lặng tiếp tục. Nếu xảy ra thì không mất gì — nhưng có được sự rõ ràng. Biết chắc tổ chức không có chỗ cho tiếng nói này, và quyết định tiếp theo sẽ dễ hơn.
Kết luận
Toàn bộ những vấn đề trên không phải chuyện riêng lẻ. Chúng là biểu hiện của cùng một gốc rễ: tổ chức không có khả năng trao đổi có ý nghĩa, không có người chịu trách nhiệm ra quyết định, và chuỗi quyết định ngẫu nhiên đang được ngụy trang thành kế hoạch.
Kafka viết cách đây hơn 100 năm và tác phẩm vẫn được đọc vì hệ thống ông mô tả vẫn tồn tại khắp nơi. Nhưng Kafka không đưa ra giải pháp — nhân vật của ông luôn thua. Ngoài đời thực, sự khác biệt là có thể nhận ra hệ thống Kafkaesque và quyết định thay đổi.
Câu hỏi không phải là có muốn thay đổi hay không. Câu hỏi là có sẵn sàng thay đổi trước khi thị trường buộc phải thay đổi — nhưng lúc đó đã quá muộn.
Những gì đã tích lũy được — khả năng thiết kế hệ thống, xây dựng sản phẩm phục vụ hàng nghìn người dùng, tích hợp thanh toán, ứng dụng AI, và quan trọng nhất là khả năng nhìn thấy vấn đề và đặt đúng câu hỏi — tất cả là của mình. Không phạm vi nào bị cắt, không hệ thống nào bị xây lại, không tổ chức nào lấy đi được những thứ đó.
chưa đóng
Con dấu đọc
Đọc tới cuối rồi ngồi lại một nhịp — con dấu sẽ tự đóng. Không điểm, không streak; chỉ một vết mực cho riêng bạn.