Demo hỏng trước mặt khách: nói thật một lần rồi đi tiếp

Bạn bấm “Chạy”. Thanh tiến trình đứng yên, rồi một dòng lỗi đỏ hiện lên màn hình chiếu, trước mặt tất cả những người bên khách hàng.

Blog của Reprise mô tả rất đúng phản xạ lúc đó: hoảng lên và xin lỗi rối rít. Nhưng cũng theo Reprise, khi người trình bày toát ra vẻ hoảng loạn, khách thấy khó chịu và không còn tập trung vào điều bạn đang nói. Lỗi kỹ thuật chỉ làm mất một luồng demo. Sự hoảng loạn có thể làm mất cả buổi họp.

Nếu bạn làm FDE, hãy coi một buổi demo hỏng như bản diễn tập cho những sự cố có thể gặp khi hệ thống chạy thật. Việc cần làm ở hai nơi giống nhau: nói thật, quyết định nhanh và giữ lời hứa.

Phút đầu tiên chỉ có ba việc

Việc đầu tiên là nói ra. MangoApps khuyên thừa nhận sự cố một lần rồi đi tiếp, trước khi khoảng lặng biến thành nghi ngờ. Chữ quan trọng ở đây là “một lần”: lời xin lỗi thứ ba không cung cấp thêm thông tin nào, chỉ khiến mọi người tiếp tục nghĩ về lỗi.

Việc thứ hai là không sửa ngay trên sân khấu. Một bài trên blog của Atomic Object viết thẳng rằng demo không phải lúc để đẩy code hay thay đổi rủi ro trên môi trường chỉ để giữ thể diện. Bản vá viết vội trong lúc cả phòng đang chờ có thể biến một lỗi thành hai.

Việc thứ ba là phân loại mức hỏng rồi chọn đường đi, vì mỗi mức cần một phản ứng khác nhau. Khi đã biết mình đang ở mức nào, bạn không phải nghĩ ra giải pháp giữa lúc đầu óc đang căng nhất.

Mức hỏng	Dấu hiệu	Phản ứng	Cần có sẵn
Cục bộ	Một bước lỗi, phần còn lại vẫn chạy	Ghi nhận rồi đi đường khác	Luồng thay thế đã thử
Mất luồng chính	Bước trọng tâm không chạy được	Chuyển sang video hoặc ảnh chụp, nói rõ đó là bản quay	Video, ảnh chụp, text output
Toàn bộ	Môi trường không dùng được	Dùng bản click-through, nếu cần thì đóng gọn	Bản click-through, đề xuất bước tiếp

Một buổi họp 45 phút, lỗi ở phút 18

Thử hình dung bạn demo một agent đối soát hóa đơn cho công ty logistics. Luồng gồm ba bước: tải lô hóa đơn, agent đối chiếu với đơn hàng, rồi xuất báo cáo ngoại lệ. Đến phút 18, bước đối chiếu trả về lỗi 500. Đây là luồng chính, nên bạn đang ở mức thứ hai.

Bạn nói một lần, không đổ thừa wifi hay hạ tầng của khách khi chưa biết nguyên nhân:

“Bước đối chiếu vừa báo lỗi, em chưa biết nguyên nhân. Đồng nghiệp của em sẽ kiểm tra riêng, còn em đi tiếp để anh chị vẫn thấy được kết quả cuối cùng.”

Atomic Object gọi người đồng nghiệp này là wing person: người sẵn sàng điều tra hoặc chuẩn bị dữ liệu trong khi người trình bày tiếp tục. Ý của họ rất rõ: đừng trông chờ sẽ có ai đó đỡ cho mình, hãy sắp xếp người từ trước. Trong phòng họp, người này mở log còn bạn mở video đã quay.

“Đây là video em quay trước buổi họp, cùng luồng này với dữ liệu mẫu. Anh chị chú ý phần báo cáo ngoại lệ, em sẽ dừng lại ở đó.”

Hãy nói rõ đó là bản quay. Nếu khách tưởng đang xem hệ thống chạy trực tiếp rồi phát hiện ra sau, thứ bị mất sẽ là niềm tin chứ không còn là một luồng demo.

Rồi trưởng phòng kế toán hỏi: “Lỗi này xảy ra lúc chạy thật thì sao?” Reprise khuyên khi bí thì bình tĩnh nhận rằng bạn sẽ phản hồi sau, và câu trả lời trung thực ở đây là một mốc thời gian, không phải một lời cam đoan:

“Em chưa trả lời chắc được vì chưa biết nguyên nhân. Chiều nay em sẽ gửi email cho anh chị, nêu rõ nguyên nhân và cách xử lý.”

Lỗi nhỏ có khi lộ ra yêu cầu thật

Vài phút sau, wing person nhắn riêng: file demo thiếu cột mã nhà cung cấp, một yêu cầu mà người trình bày đã quên. Atomic Object cũng kể một tình huống cùng kiểu, khi lỗi tưởng là bug hóa ra do người dùng quên một yêu cầu; vấn đề được ghi lại, nhóm có thêm thông tin hữu ích và demo đi tiếp.

Đừng dừng ở việc đính chính. Hãy nhận phần lỗi về mình, rồi biến nó thành một câu customer discovery:

“Em biết nguyên nhân rồi: file vừa nãy thiếu mã nhà cung cấp, do em chuẩn bị sót. Nhưng em muốn hỏi thêm: hóa đơn thật của anh chị có lúc nào thiếu trường này không?”

Trong kịch bản này, giả sử kế toán trả lời rằng hóa đơn từ các nhà cung cấp nhỏ thường thiếu. Bạn vừa tìm được một yêu cầu xử lý dữ liệu mà có thể sẽ không lộ ra nếu demo chạy trơn tru.

Giờ hãy làm phép tính thời gian. Lỗi ở phút 18 thì còn 27 phút. Một phút thừa nhận và chuyển hướng, ba phút xem video, bạn vẫn còn 23 phút để bàn về bài toán của khách. Nếu đứng debug 12 phút trước màn hình chiếu, bạn chỉ còn 15 phút, sau khi khách đã ngồi chờ suốt 12 phút đó.

Sau buổi họp, hãy giữ đúng mốc đã hứa. Reprise đề xuất quay một video ngắn, cụ thể về đúng tính năng hoặc câu hỏi chưa trình diễn được, và bạn gửi kèm nguyên nhân cùng cách xử lý. Video năm phút về đúng phần khách chưa được thấy sẽ có ích hơn một email xin lỗi dài.

Đường lui phải có từ hôm trước

Không ai nghĩ ra phương án dự phòng tốt trong lúc đang hoảng, nên sự bình tĩnh trong phòng họp phần lớn được chuẩn bị từ trước. Blog ORACLE-BASE khuyên có sẵn text output, ảnh chụp màn hình hoặc tốt hơn là video của các bản demo. Reprise bổ sung một bản click-through cho trường hợp hiếm là hỏng toàn bộ.

Trước mỗi buổi demo, bạn có thể đi theo thứ tự sau. Chạy lại toàn bộ luồng trên đúng môi trường sẽ dùng, rồi quay video ngay lần chạy đó. Ghi một danh sách ngắn các yêu cầu đầu vào, như cột dữ liệu bắt buộc hay tài khoản cần đăng nhập, để lỗi kiểu quên một trường bị bắt trước giờ họp.

Tiếp theo, chọn sẵn một luồng thay thế đã thử và chuẩn bị bộ dữ liệu sạch. Phân vai wing person, thống nhất kênh nhắn riêng và câu hiệu để người đó báo tin. Cuối cùng, tự đặt cho mình một giới hạn, ví dụ 60 giây: quá mốc đó mà chưa có tin thì chuyển đường lui, không chờ thêm.

Nếu mọi đường lui đều không dùng được, đừng cố. MangoApps khuyên đóng lại gọn gàng và đề xuất bước tốt nhất tiếp theo thay vì ép chạy một luồng đã hỏng. Câu nói có thể rất đơn giản: “Phần chưa chạy được em xin demo trong một buổi ngắn khác. Hôm nay, em muốn dành thời gian còn lại để nghe thêm về bài toán của anh chị.”

Năm cách tự làm lỗi nhỏ thành to

Cú trượt đầu tiên là xin lỗi liên tục, vì mỗi lần xin lỗi lại kéo sự chú ý về chỗ hỏng. Gần với nó là đoán bừa nguyên nhân: đổ cho mạng, rồi lát sau phát hiện lỗi do chính bạn, và lần đính chính ấy còn tốn uy tín hơn lỗi ban đầu.

Cú trượt thứ ba là chém gió khi bị hỏi khó. Một câu trả lời chắc nịch nhưng sai có thể bám theo bạn đến tận lúc ký hợp đồng, trong khi “chiều nay em sẽ gửi câu trả lời” chỉ tốn một email.

Cú trượt thứ tư là hứa rồi quên: toàn bộ công sức giữ bình tĩnh sẽ đổ sông đổ biển nếu mốc đã hứa trôi qua trong im lặng.

Cú trượt cuối cùng tinh vi hơn, đó là để người trình bày tự debug. Khi một người vừa nói vừa đọc log, cả hai việc đều giảm chất lượng, và khách nhìn thấy điều đó trên màn hình.

Biến lần hỏng thành bằng chứng năng lực

Kỹ năng này rất khó thể hiện bằng một dòng công nghệ trong CV, nên hãy kể nó bằng hành động. Thay vì “kỹ năng giao tiếp tốt”, hãy viết rằng bạn xây quy trình demo có đường lui và phân vai hỗ trợ, rồi nêu một yêu cầu cụ thể đã phát hiện được từ một sự cố.

Khi đi phỏng vấn FDE, hãy chuẩn bị sẵn một câu chuyện demo hỏng có thật: bạn đã nói gì trong phút đầu, chọn đường nào, sau buổi họp gửi gì. Nếu chưa từng demo cho khách, buổi trình bày nội bộ cũng là chỗ tốt để bắt đầu.

Bài tập: diễn tập một lần hỏng có chủ đích

Tuần này, chọn một bản demo bạn đang có và nhờ đồng nghiệp ngồi xem. Dặn người đó làm hỏng một thứ vào thời điểm bạn không biết trước, chẳng hạn tắt một service hoặc đổi tên một cột trong file đầu vào, rồi đóng vai khách và hỏi một câu khó ngay sau lỗi.

Bấm giờ từ lúc lỗi xuất hiện đến lúc bạn nói được câu đầu tiên và đến lúc chuyển sang đường lui. Rồi đếm số lần bạn xin lỗi. Lần đầu con số có thể làm bạn giật mình, nhưng chính con số đó cho bạn biết cần tập gì trước buổi demo thật, nơi lỗi sẽ không báo trước.