FDE PulseViệc làm FDE đang mở 314Mới đăng 7 ngày qua 10Chủ đề nổi bật: Đào tạo kỹ năng FDE tại Đông Nam Á

Tờ báo của nghề Forward Deployed Engineer

Bách khoa

10 phút với lãnh đạo khách hàng: biến kết quả pilot thành một quyết định được ký

Pilot của bạn có thể chạy rất tốt, nhưng nếu phút đầu tiên của buổi họp chỉ dùng để kể kiến trúc, nhiều khả năng bạn sẽ không có buổi thứ hai.

Đồ hoạKịch bản 10 phút trước lãnh đạo khách hàng
  1. 1Phút 0–1: Đề xuấtNói việc cần duyệt, người chịu trách nhiệm và cách bạn sẽ dùng 10 phút
  2. 2Phút 1–3: SCQATình huống, vướng mắc, câu hỏi cần trả lời và câu trả lời bạn đề xuất
  3. 3Phút 3–6: Ba bằng chứngMỗi bằng chứng một câu, chi tiết kỹ thuật để ở phụ lục
  4. 4Phút 6–7: Phương ánSo sánh làm ngay với chờ thêm, nói rõ bạn khuyến nghị phương án nào
  5. 5Phút 7–10: Hỏi đáp, chốtTrả lời câu hỏi, nhắc lại đề xuất và xin quyết định

Đề xuất đi trước, bằng chứng theo sau, và câu cuối cùng là lời xin một quyết định cụ thể.

Đồ hoạ: FDE Times

Tóm tắt nhanh

  • Câu đầu tiên phải là đề xuất và quyết định bạn cần, không phải bối cảnh hay kiến trúc.
  • Lãnh đạo thường chốt ngay trong buổi họp, nên việc thống nhất với từng bên phải xong từ trước.
  • Deck chỉ cần một trang tóm tắt, phần còn lại để làm phụ lục cho phần hỏi đáp.
Chia sẻLinkedInFacebookX

Thử hình dung bạn vừa xong sáu tuần pilot ở một công ty logistics. Agent đọc chứng từ chạy ổn, bộ eval xanh, đội vận hành đã quen dùng. Rồi lịch họp gửi tới: giám đốc vận hành dành cho bạn 10 phút vào chiều thứ Năm.

Kết cục của sáu tuần làm việc nằm trong 10 phút đó. Pilot có thể lên production, cũng có thể nằm mãi trong một thư mục chia sẻ. Will Larson, người viết blog Irrational Exuberance, nhận xét rằng lãnh đạo thường chốt luôn trong buổi họp, và bạn hiếm khi có thêm một lần để bàn lại trước khi quyết định được đưa ra.

Vì vậy, đây không phải kỹ năng mềm có cũng được, không có cũng chẳng sao. Code của bạn chỉ tạo ra giá trị khi có người phía khách hàng ký cho nó chạy thật. Bài này hướng dẫn cách dựng 10 phút đó, từng phút một.

Lãnh đạo không duyệt kết quả, họ duyệt đề xuất

Kỹ sư quen kể chuyện theo thứ tự thời gian: bài toán là gì, đã thử những gì, gặp lỗi gì, cuối cùng ra con số nào. Đến phút thứ tám mới hỏi xin quyết định. Lúc đó người nghe đã đọc điện thoại từ lâu.

Larson khuyên làm ngược lại. Theo ông, cách sắp xếp rõ ràng nhất luôn là nói ý tổng quát trước, rồi mới đến từng ý chi tiết bên dưới. Đây là Pyramid Principle của Barbara Minto, còn đoạn mở đầu thì dựng theo SCQA: Situation, Complication, Question, Answer.

Nancy Duarte, chuyên gia về thuyết trình, cũng khuyên tương tự: mở đầu bằng phát hiện và khuyến nghị, và nói ngay từ đầu bạn sẽ dùng thời gian cuộc họp ra sao.

Larson còn chỉ ra một điểm dễ bị bỏ qua. Bạn không thể tạo đồng thuận trong phòng nếu không có một đề xuất để mọi người cùng đứng sau. Nếu bạn chỉ mang tới một vấn đề, cả phòng sẽ tranh luận. Nếu bạn mang tới một đề xuất, họ sẽ chỉnh sửa nó rồi ký.

Kịch bản 10 phút, viết ra từng câu

Quay lại ví dụ giả định ở trên. Pilot xử lý 2.000 chứng từ hải quan. Agent tự hoàn tất 1.640 chứng từ, tức 82%, còn 360 chứng từ được chuyển cho người kiểm.

Thời gian xử lý trung bình mỗi chứng từ giảm từ 9 phút xuống 2 phút. Quyết định bạn cần là cho agent quyền ghi vào ERP production ở một kho, kèm một người phía khách làm chủ quy trình kiểm duyệt.

Phút 0–1, đề xuất và luật chơi. “Em đề nghị anh duyệt hôm nay hai việc: cho agent ghi vào ERP ở kho Bình Dương, và giao trưởng nhóm chứng từ làm chủ quy trình kiểm duyệt trong 8 tuần. Em trình bày 6 phút, 4 phút còn lại dành cho câu hỏi của anh.” Duarte cho rằng khi người nghe biết trước sẽ có phần hỏi đáp, họ dễ để bạn trình bày hết các ý chính mà không ngắt lời.

Phút 1–3, SCQA. Situation: đội chứng từ đang nhập tay toàn bộ. Complication: mùa cao điểm sắp tới mà không tuyển thêm người kịp. Question: có nên đưa agent vào vận hành thật trước cao điểm không? Answer: nên, với hai điều kiện vừa nêu.

Phút 3–6, ba bằng chứng, mỗi bằng chứng một câu. Agent tự xử lý 82% chứng từ. Chứng từ nào chưa vượt ngưỡng tin cậy thì không được ghi vào ERP khi chưa qua người kiểm. Những lỗi đã gặp trong pilot đều đã có cách chặn, chi tiết nằm ở phụ lục.

Phút 6–7, các phương án và cái giá của việc chờ. Phương án A là triển khai ngay ở một kho. Phương án B là chạy pilot thêm 4 tuần, nghĩa là bước vào cao điểm vẫn với quy trình nhập tay. Bạn nói rõ mình khuyến nghị phương án nào và vì sao.

Phút 7–10, hỏi đáp và chốt. Câu cuối cùng nhắc lại đúng đề xuất ở phút đầu, rồi bạn dừng lại chờ câu trả lời.

Phần khó nhất là chuyển ngôn ngữ kỹ thuật thành ngôn ngữ ra quyết định:

Câu kỹ sư hay nói Câu lãnh đạo cần nghe
F1 của bước trích xuất đạt mức cao 82% chứng từ không cần người chạm vào
Có fallback human-in-the-loop Chứng từ chưa chắc chắn luôn có người duyệt trước khi vào ERP
Cần thêm quyền truy cập hệ thống Cần anh duyệt quyền ghi ở một kho trong 8 tuần
Anh thấy kết quả thế nào ạ? Anh có duyệt phương án A hôm nay không?

Việc thật sự diễn ra trước buổi họp

Vì không có lần thứ hai, phần lớn công việc phải xong trước khi bước vào phòng. Larson gọi việc thống nhất với các bên liên quan trước buổi trình bày là nemawashi.

Trong ví dụ trên, bạn cần gặp riêng đội bảo mật IT về quyền ghi vào ERP, và gặp trưởng nhóm chứng từ để chắc rằng người này đồng ý nhận vai chủ quy trình.

Nếu một người trong phòng nghe đề xuất lần đầu ở buổi họp chính, rủi ro rất lớn là câu trả lời sẽ thành “để tuần sau bàn tiếp”.

Sau đó mới đến deck. Duarte khuyên đặt một trang tóm tắt ngắn các ý chính lên đầu, phần còn lại chỉ để làm phụ lục. Sơ đồ kiến trúc, bảng eval, danh sách lỗi đều chuyển ra phụ lục và chỉ mở khi có người hỏi.

Để biết trang tóm tắt đã đủ gọn chưa, hãy dùng mẹo của Duarte: tưởng tượng cả slot của bạn bị cắt còn 5 phút. Thứ còn lại sau khi cắt chính là bài trình bày.

Kiger viết trên LeadDev rằng việc chắt lọc suy nghĩ như vậy còn buộc bạn hiểu rõ bài toán hơn. Nếu bạn chưa viết được câu đề xuất trong một dòng, rất có thể bạn chưa hiểu dự án đủ sâu.

Buổi họp chưa xong khi bạn rời phòng

Kiger nhấn mạnh rằng những điểm quan trọng phải được nhắc lại, và việc gì cũng cần dọn nền từ trước rồi bám tiếp sau buổi họp. Ngay trong ngày, hãy gửi một email ngắn chốt lại quyết định, người chịu trách nhiệm, phạm vi và mốc kiểm tra tiếp theo.

Email này biến một cái gật đầu trong phòng họp thành một cam kết có văn bản mà cả đội khách hàng có thể dựa vào.

Còn nếu câu trả lời là “chưa” hoặc “để tuần sau”, đừng rời phòng khi chưa hỏi rõ họ cần thêm điều gì để duyệt và cần gặp thêm ai. Khi đó, email chốt lại ghi đúng những điều kiện ấy cùng ngày bạn quay lại với câu trả lời.

Những lỗi khiến 10 phút trôi qua vô ích

Lỗi phổ biến nhất là mở đầu bằng kiến trúc. Lãnh đạo cần đúng thông tin họ dùng để quyết định, vì như Kiger viết, thời gian và sự chú ý của họ có hạn. Lỗi thứ hai là đem vấn đề vào phòng mà không có đề xuất, khiến buổi họp thành một cuộc brainstorm không có kết quả.

Lỗi tiếp theo khó nhận ra hơn: dồn quá nhiều con số. Ba bằng chứng có sức nặng hơn mười hai chỉ số, vì người nghe còn nhớ được chúng. Cuối cùng là xin quyết định một cách mơ hồ. “Anh thấy sao” không phải một quyết định. “Anh có duyệt phương án A không” mới là một quyết định.

Bài tập trong tuần

Lấy một việc kỹ thuật bạn đã làm xong trong quý này, chẳng hạn một lần migration hay một tính năng mới, rồi viết lại thành kịch bản 10 phút theo đúng khung trên. Câu đầu tiên phải trả lời được câu hỏi: ai cần duyệt việc gì, và trước ngày nào.

Kịch bản đó cũng là thứ bạn nên mang vào phỏng vấn nếu đang nhắm tới vai FDE. Khi được hỏi về một dự án đã làm, hãy mở bằng quyết định mà kết quả của bạn đã giúp ai đó đưa ra, rồi mới đến kỹ thuật. Trong CV, thay dòng “kỹ năng giao tiếp tốt” bằng đúng một câu như vậy.

Kết quả sáu tuần pilot vẫn giữ nguyên dù bạn trình bày ra sao. Thứ quyết định nó có lên production hay không là câu đầu tiên bạn nói trong phòng họp.

3 nguồn
Đọc tiếp trên lộ trình · Chặng 4: Khách hàngKhi người bảo trợ dự án nghỉ việc giữa chừng: FDE giữ deployment sống bằng cách nàoNgười kéo dự án vào công ty khách hàng vừa nghỉ việc. Code vẫn chạy, nhưng không còn ai duyệt, ký nghiệm thu hay bảo vệ dự án, và FDE thường là người nhận ra điều đó sớm nhất.