Tại sao kỹ sư công nghệ cần 'Talk like a Suit'?
Việc thay đổi nội dung diễn đạt sẽ tạo ra sự khác biệt lớn. Các công ty đều đánh giá cao một kỹ sư có thể giao tiếp bằng ngôn ngữ kỹ thuật và ngôn ngữ kinh doanh. Hãy tập 'Talk like a Suit'.
This post is also available in English
Khi bàn luận về chuyển đổi số, SSD thường được nhắc đến như một cách tiếp cận phù hợp nhất: Simplify (Đơn giản hóa) - Standardize (Chuẩn hóa) - Digitize (Số hóa).
Thông thường, đội ngũ kỹ sư sẽ bắt đầu tham gia phát triển khi dự án đang ở công đoạn số hóa (Digitize). Nhưng giả sử các kỹ sư được tiếp cận sớm ngay từ quá trình đơn giản hóa (Simplify), đồng thời áp dụng tư duy thiết kế (design thinking) thì họ có thể hiểu tường tận lý do tại sao và điều gì dẫn đến nhu cầu số hóa hay không? Liệu công việc triển khai lúc này có còn nhàm chán với họ, hay trở thành một dự án đầy thách thức và thú vị?
Tôi tin câu trả lời là có! Bên cạnh đó, việc này còn giảm nguy cơ hiểu lầm, giảm ma sát trong các dự án nội bộ.
Nhưng tại sao CIO/CTO lại cảm thấy ngần ngại khi làm như vậy?
Hãy thử đặt câu hỏi:
Chúng ta cần bao nhiêu thời gian để tiếp cận một cách bình tĩnh và có được chiến tướng phù hợp để đảm bảo cuộc trò chuyện giữa business user và IT không nhảy ngay vào phần triển khai? (SSD, nếu chỉ có Digitize thì hoặc là một dự án nhàm chán hoặc chúng ta quá vội).
Đã bao nhiêu lần CIO/CTO nhấn mạnh cụm từ 'cải thiện giao tiếp' với đội ngũ nhân lực của mình?
Chắc chắn thông điệp 'cải thiện giao tiếp' này không dễ đạt được hiệu quả, vì đội ngũ họ có xuất thân là kỹ sư CNTT.
Bởi vì điều chính xác chúng ta cần nói với họ là 'Talk like a Suit'. (Có lẽ CIO hay CTO nên trích một phần ngân sách để mua khoản Netflix và yêu cầu họ xem bộ phim Suit!)
'Talk like a Suit' ám chỉ cách diễn đạt nội dung hết sức thuyết phục như các ví dụ điển hình như dưới đây. (Vâng, các kỹ sư học tốt hơn từ các ví dụ, đó cũng là điều mà các nhà quản lý nên hiểu!).
Thay vì nói "Source code hiện tại lởm quá nên tôi chả code nhanh được đâu", họ có thể nói "Khi một tính năng phát sinh việc thay đổi code sẽ cần gấp đôi thời gian để hoàn thành và có thể xảy ra vấn đề về chất lượng hơn”.
Thay vì nói "Mỗi khi tôi muốn làm gì, tôi phải làm việc với 2-3 bộ phận khác và có vẻ như không ai muốn làm", họ có thể nói "Ba phần tư tổng thời gian để hoàn thành một tính năng được dùng để chờ đồng thuận và phê duyệt. Nếu các quy trình này được sắp xếp hợp lý hơn, chúng ta có thể giảm đáng kể thời gian để xây dựng một tính năng, đáp ứng nhu cầu thay đổi".
Việc thay đổi nội dung diễn đạt sẽ tạo ra sự khác biệt lớn. Các nhà quản lý sẽ dễ dàng nhận thấy điều này vì họ có kinh nghiệm và đã dành phần lớn thời gian sự nghiệp để rèn luyện kỹ năng này. Riêng các kỹ sư thì lại khác, họ dành nhiều thời gian cho việc theo đuổi chuyên môn hơn.
Để thuyết phục các nhà quản lý công nghệ tin vào việc rèn luyện 'Talk like a Suit' cho đội ngũ, chúng ta hãy cùng chiêm nghiệm những nhận định sau:
- Các nhà quản lý thường có xu hướng đánh giá thấp sự phức tạp và thách thức của công đoạn Digitize vì họ cho rằng "CRUD thì dễ mà", "code chỉ chiếm 20% tổng công việc thôi", thậm chí có thể đi thuê vendor hoặc mua cho rẻ và nhanh! Trong trường hợp dù đã thực hiện tất cả các phần việc khó nhằn của đơn giản hóa (Simplify) và chuẩn hóa (Standardize), nhưng kết quả thực thi (delivery) lại chẳng ra gì thì chắc chắn chương trình nghị sự chuyển đổi số của bạn cũng đang thất bại.
- Có khá nhiều công việc của đội ngũ kỹ sư thường không được ưu tiên vì họ không thuyết phục được đội ngũ lãnh đạo và quản lý về ý tưởng của mình (nhất là các ý tưởng về non-functional, system). Điều này dẫn đến tech-debt (nợ kỹ thuật), rủi ro hệ thống và sự xuất hiện của các hệ thống legacy. Do đó, nếu đội ngũ kỹ thuật không thể giao tiếp, chúng ta sẽ ngồi trên bãi mìn hẹn giờ hoặc gặp tình huống mà cả hệ thống lệ thuộc vào một vài siêu nhân nào đó mà không ai biết đích đến là gì.
Kể cả khi họ giao tiếp nhưng nếu họ không thể diễn đạt rõ ràng thì chắc chắn dự án sẽ không thể nhận được nguồn lực hay căn cứ chính xác. Theo thời gian, động lực làm việc sẽ biến mất, trang trại zombie mọc lên, hoặc sẽ có khá nhiều ghế trống trong khoang IT.
Giải pháp là gì?
Tại thời điểm viết bài, tôi tin rằng năm 2022 vẫn còn tồn tại một sự thật: Đào tạo IT cho dân kinh tế vẫn rất khó. Chúng ta thường làm ngược lại và thực tế nhiều nhà quản lý và lãnh đạo ngày nay xuất thân là dân kỹ thuật. Vấn đề là cần đào tạo đội ngũ kỹ sư cách giao tiếp bằng ngôn ngữ mà dân kinh doanh hiểu được.
Qua các ví dụ ở trên, bạn có thể nhận ra các khuôn mẫu để cải thiện cách giao tiếp của đội ngũ kỹ sư. Trong số đó có lẽ khó làm nhất chính là chiến lược: Đừng chỉ nói chuyện, hãy kể chuyện!
- Các câu chuyện luôn thu hút dân kinh tế và giúp chúng ta đóng khung cuộc trò chuyện dưới góc độ khách quan. Trong mọi câu chuyện, business user là nhân vật chính hoặc thậm chí là anh hùng và đội ngũ kỹ thuật chính là cánh tay đắc lực của họ.
- Chuẩn bị một câu chuyện hấp dẫn (khá gần với thực tế đang diễn ra) bằng cách củng cố thông tin với số liệu và dữ liệu kinh doanh, chẳng hạn như thời gian hoàn thành, năng suất, chất lượng, hiệu suất, và đặc biệt là yêu cầu tuân thủ (compliance). Các yêu cầu tuân thủ sẽ dễ dàng thuyết phục business user đồng thuận và hầu hết là họ thậm chí không nhớ nó.
- Đừng chỉ nêu ra vấn đề. Tốt hơn hết là bạn nên chuẩn bị các giải pháp để họ cùng tham gia vào quá trình cân nhắc đánh đổi. Business user thực sự thích thương lượng, quá trình này làm họ cảm thấy họ là người chèo lái và ra quyết định thay vì bị ép buộc. Tất nhiên, họ nên chọn quyết định mà chúng ta đã có định hướng từ đầu.
Thật ra bài viết này muốn nhắn gửi tới các bạn kỹ sư rằng các công ty đều đánh giá cao một người có thể nói cả ngôn ngữ kỹ thuật và ngôn ngữ kinh doanh. Hãy tập 'Talk like a Suit'.
Còn với các nhà quản lý, đây phải là ý tưởng đầu tiên khi bạn huấn luyện đội ngũ kỹ sư, hãy cung cấp cho họ những ví dụ chi tiết hơn thay vì chỉ nói "em cần giao tiếp tốt hơn"!