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

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

Sách & khoá học

The Pyramid Principle: cuốn sách giúp FDE viết sao cho lãnh đạo khách hàng đọc câu đầu là hiểu

Ở công ty tư vấn, một bản nháp bị trả về kèm lời dặn "make it Minto". FDE, người phải viết cho lãnh đạo khách hàng, rất nên học thói quen đó.

Bìa sách The Pyramid Principle: Logic in Writing and Thinking
The Pyramid Principle: Logic in Writing and Thinking · Barbara Minto · Ảnh bìa: Open Library

Tóm tắt nhanh

  • Barbara Minto là chuyên gia về giao tiếp điều hành, có MBA Harvard, đã dạy phương pháp kim tự tháp hơn 30 năm
  • Ba ý nên giữ: đưa kết luận lên đầu, chỉ gom những ý so sánh được về logic, và bắt đầu từ câu hỏi người đọc đang có
  • Với FDE, đây là cuốn sách dạy cách nghĩ trước khi viết email, báo cáo pilot và đề xuất cho lãnh đạo khách hàng
Chia sẻLinkedInFacebookX
Đồ hoạKim tự tháp Minto trong một email gửi khách
  1. Câu hỏi của người đọcĐiều lãnh đạo khách đang hỏi, ví dụ: pilot có kịp go-live không?
  2. Ý chính ở đỉnhCâu trả lời đặt ở dòng đầu, tóm tắt toàn bộ các ý bên dưới
  3. Nhóm ý hỗ trợCác ý cùng loại, so sánh được về logic, tóm được bằng một câu
  4. Bằng chứng chi tiếtSố liệu, lỗi kỹ thuật, kết quả chạy thử, đặt dưới cùng

Kết luận đứng ở đỉnh, mỗi tầng bên dưới chỉ để chứng minh cho tầng phía trên.

Đồ hoạ: FDE Times

Câu này phổ biến đến mức phương pháp của Barbara Minto đã thành ngôn ngữ chung của giới làm nghề.

FDE không phải consultant, nhưng thử hình dung những văn bản một FDE có thể phải viết: email cập nhật cho VP bên khách, báo cáo sau pilot, đề xuất mở rộng deployment. Cách an toàn là cứ giả định người nhận chỉ đọc kỹ vài dòng đầu rồi mới quyết định có đọc tiếp hay không.

Vì vậy, code chạy đúng nhưng email viết rối thì dự án vẫn có thể bị dừng. Đó là lý do The Pyramid Principle đáng nằm trên bàn của bất kỳ kỹ sư nào làm việc trực tiếp với khách hàng.

Một cuốn sách về tư duy, không chỉ về hành văn

Barbara Minto là tác giả kiêm nhà tư vấn người Mỹ chuyên về giao tiếp điều hành, có bằng MBA của Harvard Business School. Khóa học của bà đúc kết từ hơn 30 năm giảng dạy ở nhiều nước.

Sách ra lần đầu năm 1985. Bản 1996 do chính tác giả phát hành, tên The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving, gồm 4 phần, 12 chương, 3 phụ lục, bán trực tiếp qua barbaraminto.com. Bản dễ tìm hơn là ấn bản thứ 3 của Pearson Education, The Pyramid Principle: Logic in Writing and Thinking.

Người mới nên bắt đầu từ bản Pearson, còn bản của tác giả hợp với lúc bạn muốn đi sâu vào phần giải quyết vấn đề.

Sách giúp bạn sắp xếp suy nghĩ về bất kỳ chủ đề nào để trình bày rõ cho người khác, và dạy dùng chính cấu trúc kim tự tháp để phát triển ý tưởng. Thứ tự ấy đáng chú ý: ý phải được xếp xong trong đầu trước khi chữ đầu tiên được gõ ra.

Vì sao câu trả lời phải nằm ở đầu?

Nguyên tắc đầu tiên rất đơn giản: nêu ý tổng quát trước, sau đó mới đi xuống các ý hỗ trợ. Đây là cách giao tiếp từ trên xuống, trong đó ý chính là bản tóm tắt cấp cao của những ý bên dưới.

Thử hình dung bạn đang ở tuần thứ hai của một pilot dùng agent xử lý hóa đơn cho một công ty logistics.

Bản nháp theo thói quen của developer thường kể theo thứ tự thời gian: đã tích hợp API ERP, gặp lỗi timeout, đã sửa xong, chạy thử 500 hóa đơn, phát hiện nhóm hóa đơn nước ngoài sai định dạng. Mãi đến câu cuối mới có đề xuất lùi go-live một tuần.

Nếu VP bên khách chỉ kịp đọc hai dòng đầu, họ chỉ biết rằng team đang bận. Viết theo Minto, dòng đầu tiên sẽ là: “Đề xuất lùi go-live một tuần để xử lý hóa đơn nước ngoài; phần còn lại đã sẵn sàng.” Các chi tiết kỹ thuật vẫn có trong email, nhưng chỉ làm bằng chứng cho đề xuất đó.

Những ý nào được đứng chung một nhóm?

Quy tắc thứ hai là các ý được gom chung phải so sánh được với nhau về logic, và mỗi tầng phải tóm tắt được các ý ngay bên dưới nó.

Trong ví dụ trên, ba ý hỗ trợ tốt sẽ là: tích hợp ERP đã xong, hóa đơn nội địa đạt độ chính xác yêu cầu, hóa đơn nước ngoài còn lỗi. Cả ba đều trả lời cùng một câu hỏi: hệ thống đã sẵn sàng đến đâu.

Ngược lại, một nhóm gồm “đang dùng model X”, “khách chưa cấp quyền truy cập” và “nên thêm dashboard” là ba loại thông tin khác nhau, và người đọc sẽ không biết rút ra điều gì. Phép thử nhanh: nếu không viết được một câu tóm tắt cả nhóm thì nhóm đó đang sai.

Người đọc đang hỏi gì?

Đây là nền tảng của khung Situation–Complication–Question.

Áp vào pilot ở trên, Situation là agent đã chạy được hai tuần. Complication là một nhóm hóa đơn bị lỗi. Câu hỏi tự nhiên của VP là “có kịp go-live không?”, và câu trả lời cho câu hỏi đó chính là đỉnh kim tự tháp.

Quy tắc này nối trực tiếp với customer discovery. Nếu bạn không biết lãnh đạo bên khách đang lo điều gì, kim tự tháp có chặt chẽ đến đâu cũng chỉ trả lời nhầm câu hỏi.

Học bằng cách sửa chính email của mình

Thứ tự hợp lý là đọc bài tóm tắt “Lessons from Barbara Minto” của Antoine Buteau trước để nắm các quy tắc, rồi mới đọc sách. Trong lúc đọc, mỗi ngày hãy viết lại một email thật theo phương pháp này thay vì chỉ gạch chân.

Với developer Việt Nam muốn chuyển sang FDE, đây là kỹ năng có thể đem ra cho người khác thấy. Lời khuyên là chuẩn bị sẵn một design doc hoặc báo cáo dự án đã viết theo cấu trúc kim tự tháp, kết luận ở dòng đầu, để mang theo khi phỏng vấn cho các vị trí làm việc trực tiếp với khách hàng.

Bài tập đầu tiên dành cho bạn: lấy lại nhóm ý lộn xộn ở phần trước, gồm “đang dùng model X”, “khách chưa cấp quyền truy cập” và “nên thêm dashboard”. Hãy tự viết lại trước khi đọc tiếp.

Ba câu hỏi gợi ý cho bạn tự kiểm tra. VP đang muốn biết điều gì về pilot lúc này? Trong ba ý, ý nào thật sự trả lời câu hỏi đó và xứng đáng lên đỉnh? Ý nào chỉ là bằng chứng, và ý nào thuộc về một email hoàn toàn khác?

Nhà tuyển dụng có thể kiểm tra kỹ năng code của bạn bằng một bài test. Còn khả năng làm lãnh đạo khách hàng gật đầu ngay sau câu đầu tiên thì bạn phải tự cho họ thấy.

5 nguồn
Đọc tiếp trên lộ trình · Chặng 4: Khách hàngFlawless Consulting của Peter Block: cuốn sách cho FDE có giải pháp đúng nhưng khách không dùngPhần khó nhất ở site khách thường không nằm ở pipeline mà ở căn phòng im lặng sau buổi demo, và Peter Block viết cuốn sách này để dạy bạn cách xử lý căn phòng ấy.