Demo 30 phút mỗi tuần để không bị bất ngờ ở tuần thứ tám

Thử hình dung tuần thứ tám của một dự án. Bạn chia sẻ màn hình để trình bày bản gần hoàn chỉnh, và trưởng nhóm vận hành phía khách hỏi một câu khiến cả phòng im lặng: “Sao nó không đọc được file đính kèm? Một nửa khiếu nại của bọn tôi nằm trong file PDF.”

Câu hỏi ấy hiếm khi cho thấy bạn code dở. Nó cho thấy suốt bảy tuần không ai phía khách được chạm vào phần mềm. Mỗi giả định sai trong khoảng đó lại được xây chồng lên giả định trước, và đến ngày bàn giao thì sửa lại rất tốn kém.

Với FDE, đây là rủi ro của nghề chứ không phải chuyện xui. Bạn ngồi sát bên khách, nơi yêu cầu có thể đổi từ tuần này sang tuần khác, nên cách rẻ nhất để chống bất ngờ là một nhịp cố định: mỗi tuần 30 phút, khách được tự tay dùng thứ bạn vừa làm ra.

Ý tưởng này có từ trước khi có nghề FDE

Agile Manifesto đặt lên hàng đầu việc làm khách hài lòng bằng cách giao phần mềm có giá trị sớm và liên tục. Bản tuyên ngôn khuyên giao phần mềm chạy được trong khoảng từ vài tuần đến vài tháng một lần, và ưu tiên khoảng ngắn hơn. Nó còn coi phần mềm chạy được, chứ không phải tài liệu, là thước đo tiến độ chính.

Scrum Guide nói thêm một ý mà nhiều đội bỏ qua. Mục đích của Sprint Review là xem xét kết quả và quyết định sẽ điều chỉnh gì tiếp theo. Bản hướng dẫn cũng dặn rằng đây là một buổi làm việc, và đội nên tránh biến nó thành một buổi thuyết trình.

Ghép hai ý lại, một buổi demo đúng nghĩa cần đủ ba thứ: phần mềm thật, khách cùng tham gia, và kết thúc bằng một thay đổi. Thiếu một trong ba thì bạn chỉ đang báo cáo.

Vì sao 30 phút, và vì sao mỗi tuần?

Scrum Guide giới hạn Sprint Review tối đa bốn tiếng cho một Sprint dài một tháng. Nếu chia theo tỷ lệ, một tuần làm việc chỉ cần khoảng một phần tư thời lượng đó. 30 phút còn nhẹ hơn nữa, vừa một ô trong lịch của người phía khách mà không ai phải xin phép sếp.

Agile Manifesto muốn người làm business và developer làm việc với nhau hằng ngày suốt dự án. Ở site khách, việc đó thường khó, vì người dùng thật còn bận việc chính. Buổi demo hằng tuần là mức gặp tối thiểu đã ghim sẵn trong lịch: dù cả tuần không gặp nhau, bạn vẫn chắc chắn có một lần nghe phản hồi.

Nhịp này vẫn hợp với đội chạy sprint dài hơn. Đội FDE của PostHog làm sprint hai tuần, từ thứ Hai tuần này đến thứ Sáu tuần sau. Nếu demo mỗi tuần, bạn có một lần kiểm tra giữa sprint, khi còn kịp đổi hướng, và một lần ở cuối sprint.

Một buổi demo mẫu, tính theo từng phút

Giả sử bạn đang deploy một agent phân loại email khiếu nại cho bộ phận chăm sóc khách hàng của một công ty bảo hiểm. Trước khi viết dòng code đầu tiên, hãy làm như đội FDE của PostHog: viết scope thành một bản brief ngắn và gửi khách xác nhận trước khi cam kết. Bản brief đó là thước đo của mọi buổi demo sau này.

Phút	Việc	Ai cầm chuột
0–3	Nhắc lại mục tiêu tuần trong brief và quyết định của tuần trước	FDE
3–18	Khách tự chạy 5 email thật lấy từ hộp thư của họ	Người dùng phía khách
18–25	Hỏi đáp, chỉ ra chỗ sai, cùng xếp ưu tiên	Cả hai bên
25–30	Đọc to các quyết định, chốt việc của tuần sau	FDE

Phần quan trọng nhất là đoạn từ phút thứ 3 đến 18. Bạn không trình diễn. Bạn nói: “Chị chọn giúp năm email khó nhất tuần này, rồi dán vào đây.” Khi agent phân loại sai, đừng giải thích ngay. Hãy hỏi: “Nếu là chị thì email này thuộc nhóm nào, và chị dựa vào đâu?”

Câu trả lời cho câu hỏi đó là dữ liệu quý nhất của cả tuần. Nếu chị ấy nói “nhìn file đính kèm là biết”, bạn vừa phát hiện ở tuần thứ hai vấn đề mà kịch bản ở đầu bài phải đợi tới tuần thứ tám.

Một FDE được Insight Partners trích lời nói rằng một bản demo đáng giá hơn rất nhiều so với những cuộc trò chuyện. Đoạn 15 phút này cho thấy vì sao.

Năm phút cuối dành để đọc to: “Tuần sau: thêm bước đọc PDF, bỏ nhóm ‘khác’ vì không ai dùng, tạm hoãn tích hợp CRM.” Ai không đồng ý thì nói ngay trong phòng, không đợi tới email.

Phản hồi chỉ có giá trị khi nó đi tiếp

Trong vòng một giờ sau buổi demo, hãy gửi recap gồm ba phần: khách đã thấy gì, hai bên đã quyết gì, tuần sau có gì. Nếu một quyết định làm lệch bản brief ban đầu, ghi rõ điều đó và xin khách xác nhận lại bằng văn bản. Một thay đổi nhỏ không được ghi lại hôm nay rất dễ thành bất ngờ ở ngày bàn giao.

Phản hồi còn phải đi về đội product của chính bạn. Đội FDE của PostHog tự coi mình là vòng phản hồi nhanh nhất giữa cách khách dùng sản phẩm thật và roadmap.

Insight Partners cũng nhấn mạnh rằng vòng phản hồi về product phải được làm có chủ đích. Một dòng “khách bảo hiểm cần đọc PDF đính kèm” gửi kèm recap mỗi tuần chính là việc có chủ đích đó.

Năm lỗi biến demo thành nghi thức

Lỗi phổ biến nhất là chiếu slide thay cho phần mềm. Slide chỉ cho thấy điều bạn định làm, còn phần mềm chạy được mới là bằng chứng tiến độ. Lỗi thứ hai là demo trên dữ liệu mẫu do chính bạn soạn: nó được viết để trơn tru, nên che mất đúng những ca khó mà khách quan tâm.

Lỗi thứ ba là chỉ mời người tài trợ dự án mà không mời người sẽ dùng hệ thống hằng ngày. Người tài trợ duyệt hướng đi, còn người dùng mới là người phát hiện lỗi.

Lỗi thứ tư là giấu phần còn hỏng. Cho khách xem một tính năng làm dở vẫn tốt hơn hủy buổi vì “tuần này chưa có gì để xem”, bởi một lần hủy dễ thành thói quen.

Lỗi cuối cùng tinh vi hơn cả: buổi demo diễn ra suôn sẻ nhưng không có quyết định nào. Nếu ba tuần liền recap không có dòng nào ở mục “đã quyết”, bạn đang trình bày chứ không làm việc cùng khách.

Bài tập: viết recap cho buổi demo mẫu

Quay lại buổi demo với công ty bảo hiểm. Thử hình dung kết quả: trưởng nhóm chạy 5 email, agent phân loại đúng 3, sai 2 email có khiếu nại nằm trong PDF đính kèm, không ai chọn nhóm “khác”, và chị ấy nói tích hợp CRM chưa gấp. Hãy đặt đồng hồ 10 phút và viết recap ba phần trước khi đọc tiếp.

Một bản đạt yêu cầu sẽ trông thế này. Đã thấy: 3/5 email đúng nhóm, 2 ca sai đều do khiếu nại nằm trong PDF. Đã quyết: thêm bước đọc PDF, bỏ nhóm “khác”, hoãn CRM sang sau. Tuần sau: chạy lại đúng 5 email này cộng 5 email mới có đính kèm.

Sau đó tự chấm bản của bạn bằng ba câu hỏi. Quyết định nào làm lệch brief và đã có dòng xin khách xác nhận lại chưa? Dòng nào cần gửi về đội product? Người đọc không dự buổi demo có hiểu được tuần sau sẽ xem gì không?

Biến nhịp demo thành lợi thế khi đi tìm việc

Nếu muốn chứng minh mình biết lặp nhanh với khách chứ không chỉ biết code, đừng viết “giao tiếp tốt với khách hàng” trong CV.

Thay vào đó, hãy viết một dòng nói rõ bạn đã làm gì và việc đó dẫn tới đâu, chẳng hạn: “Tổ chức demo 30 phút hằng tuần với người dùng cuối; phát hiện thay đổi scope ở tuần thứ hai và xác nhận lại brief bằng văn bản.”

Trước buổi phỏng vấn, hãy chuẩn bị sẵn một câu chuyện cụ thể về lần phản hồi trong buổi demo khiến bạn đổi hướng. Khi đọc job description, để ý những đoạn mô tả việc làm trực tiếp với khách: đó là chỗ câu chuyện này đáng được đem ra kể.

Bạn không cần xin phép ai để bắt đầu. Hãy đặt một lịch lặp lại 30 phút, mời người sẽ dùng hệ thống, và để họ cầm chuột. Câu hỏi về file PDF kiểu gì cũng sẽ đến, và tốt nhất là bạn nghe nó ngay từ tuần thứ hai.