Bài thuyết trình bắt đầu từ slide thứ hai
(tidyfirst.substack.com)- Các bài thuyết trình kỹ thuật cần phần giải thích bối cảnh, nhưng rất dễ mất khán giả ở đoạn đầu, nên cấu trúc cho thấy vấn đề trước rồi mới bổ sung ngữ cảnh sẽ hiệu quả hơn
- Kỹ thuật này giống như lời khuyên viết lách của Lawrence Block: đổi chỗ phần đầu và phần thứ hai được viết một cách tự nhiên để đưa cảnh giàu căng thẳng lên trước
- Một bài thuyết trình giải thích bối cảnh trước sẽ là lặp lại với người đã biết, còn với người chưa biết thì họ vẫn chưa có đủ lý do để lắng nghe nên mức độ tập trung có thể giảm
- Trong ví dụ tối ưu hóa máy ảo dựa trên JIT, trước tiên trình bày hồ sơ hiệu năng, thay đổi mã có vẻ như sẽ cải thiện, rồi dữ liệu cho thấy thực tế lại chậm hơn, sau đó mới giải thích về JIT, tối ưu hóa và kiến trúc
- Khi nêu ra vấn đề cần giải ngay từ đầu, lập trình viên sẽ tự nhiên tìm cách giải quyết và có động lực để theo dõi phần giải thích phía sau
Cấu trúc thuyết trình cho thấy vấn đề trước
- Một bài thuyết trình kỹ thuật thường cần cả thiết lập ngữ cảnh lẫn việc nêu ra vấn đề cần giải quyết
- Tuy nhiên, nếu bắt đầu từ phần giải thích bối cảnh thì sức hút ở phần đầu sẽ yếu đi
- Với khán giả đã biết bối cảnh, đó sẽ là thông tin lặp lại
- Với khán giả chưa biết bối cảnh, họ vẫn chưa có động lực để cố hiểu
- Cách của Kent Beck là soạn tài liệu thuyết trình theo thứ tự mong muốn trước, rồi đổi chỗ hai slide đầu tiên, hoặc hai đoạn, hai chương đầu
- Đây là kỹ thuật lấy từ Telling Lies for Fun and Profit của Lawrence Block
- Khi viết câu chuyện một cách tự nhiên, chương đầu là giới thiệu nhân vật chính, chương hai là diễn biến sự việc
- Nếu đổi chỗ hai chương, câu chuyện sẽ bắt đầu bằng cảnh nhân vật chính đang gặp nguy hiểm
- Sau khi tạo ra căng thẳng, phần giới thiệu nhân vật mới xuất hiện, nên người đọc có lý do để muốn biết về nhân vật đó
Ví dụ về bài nói tối ưu hóa JIT và phản ứng của khán giả
- Nếu là một bài nói về tối ưu hóa máy ảo dựa trên biên dịch JIT, thông thường người nói sẽ giới thiệu trước về JITing, Pareto là nền tảng của tinh chỉnh hiệu năng, và kiến trúc máy hiện tại
- Nhưng một tối ưu hóa thông thường nhằm giảm hotspot có thể lại làm toàn bộ hiệu năng chậm hơn, và một thay đổi trông có vẻ không có vấn đề gì cũng có thể tạo ra cải thiện lớn
- Cách bắt đầu từ slide thứ hai là đặt ngay các dữ kiện để phán đoán vào slide đầu tiên
- Hồ sơ hiệu năng cho thấy hotspot
- Một thay đổi mã trông như sẽ cải thiện
- Dữ liệu cho thấy việc tối ưu hóa không chỉ thất bại mà còn khiến hệ thống chậm hơn
- Sau đó mới đưa vào phần giải thích về JIT, tối ưu hóa và kiến trúc thì cả khán giả đã biết bối cảnh lẫn khán giả chưa biết đều có lý do để theo dõi: người biết bối cảnh sẽ chờ lời giải cho bí ẩn, còn người chưa biết cũng có lý do để tập trung
- Lập trình viên thường có phản ứng kỹ thuật là muốn giải quyết khi một vấn đề được đưa ra, nên cách ném ra bài toán để cùng giải ngay ở phần đầu bài thuyết trình là rất hiệu quả
1 bình luận
Ý kiến trên Hacker News
Khi thuyết trình ở PyCon vài tuần trước, tôi đã chật vật để nhồi hết nội dung vào đúng thời lượng, và cuối cùng đã cắt bỏ phần mở đầu dài vài phút
Tôi bỏ phần dẫn dắt chậm vào chủ đề và phần giải thích bối cảnh vì sao tôi có tư cách để nói về chuyện này, rồi đi thẳng vào ý chính đầu tiên; ở đó có một câu đùa khá ổn nên hiệu quả rất tốt
Tôi học được rằng nếu chủ đề đủ thú vị thì có thể bỏ qua phần mở đầu và đi thẳng vào nội dung chính, và nếu thêm chút hài hước thì vẫn có thể thu hút đủ sự chú ý của khán giả
Tôi thực sự ghét những bài chào hàng bán hàng mở đầu bằng lịch sử công ty, và kỳ lạ là các tập đoàn lớn của Nhật thường đặc biệt tệ ở điểm này
Cần nghĩ rằng ở mỗi slide, “nếu bạn không cho khán giả một lý do để đọc slide tiếp theo thì họ sẽ đứng dậy bỏ đi”
Nếu họ còn chưa biết tôi cung cấp điều gì thì không cần phải biện minh cho sự hiện diện của người thuyết trình, và rốt cuộc trọng tâm không phải là người nói mà là người nghe
Những phần đó khó mà vấp quá nặng, và trong lúc đó cơ thể cũng kịp làm nóng để bước vào phần chính
Tất nhiên càng ngắn càng tốt, nên tôi thường học thuộc từng từ cho vài câu đầu
Ngay cả lúc lo nhất thì tôi vẫn có thể xử lý chắc chắn phần mở đầu, rồi sau đó nói tự do hơn
Khoảng 30 giây thì ổn, nhưng vài phút là quá dài, dù là bài thuyết trình hay video YouTube cũng vậy
Tôi hiểu vì sao người ta làm thế
Chắc là để giảm rủi ro kiểu “người này có đủ tư cách không?” hay “tôi không hiểu bối cảnh”, nhưng giá mà mọi người can đảm hơn một chút để đi thẳng vào trọng tâm
Tôi đã chọn đến nghe bài đó rồi, nên việc giải thích vì sao nó thú vị giống như giảng đạo cho người đã tin sẵn
Trong văn hóa hacker, người ta thường đánh giá bằng năng lực hơn là giấy chứng nhận, nên bạn có thể chen vào kiểu “nhân tiện thì tôi là người đã làm ra cái này”, nhưng đừng đọc CV; hãy thuyết phục bằng insight
Không phải bối cảnh nào cũng vậy, và có những nhóm khán giả xem trọng tư cách rất nhiều
Nếu mọi người không trực tiếp chọn bài nói đó thì cũng cần đủ bối cảnh
Dù vậy, nhìn chung vẫn tốt hơn nếu thu hút được sự chú ý trước, rồi sau khi đã có sự chú ý thì quay lại phần dẫn nhập
Hồi học cao học tôi được rèn luyện thuyết trình rất nhiều, và giáo sư hướng dẫn thường cho luyện kiểu đố nhanh trong lúc rehearsal
Cần xem slide đầu tiên chỉ là chỗ để hiện lên trong chốc lát khi bạn chưa nói, giống như bìa sách vậy
Ví dụ nếu người dẫn chương trình giới thiệu “diễn giả tiếp theo sẽ nói về BlahBlah” thì tôi đáp “Cảm ơn SoAndSo. Tôi là Godelski và slide tiếp theo tôi sẽ nói về BlahBlah”
Ngược lại, nếu họ giới thiệu “diễn giả tiếp theo là Godelski và sẽ trình bày công trình về BlahBlah” thì tôi chỉ nói “Cảm ơn SoAndSo. Slide tiếp theo” rồi chuyển luôn
Có nhiều biến thể, kể cả trường hợp không có phần giới thiệu, nhưng cốt lõi là không lặp lại thông tin mà người giới thiệu đã nói và thoát khỏi slide tiêu đề thật nhanh
Slide đó chỉ để cho biết ai đang nói và nói về cái gì; nếu bạn còn thông tin nào khác để truyền đạt cho khán giả thì không nên dừng lại ở slide đó
Có nhiều yếu tố khác trong cách cấu trúc và tổ chức slide nên khó khái quát, nhưng riêng slide đề cương thì tôi thấy khá hữu ích kể cả khi nó chỉ xuất hiện chưa đến 1 giây
Điều đó còn quan trọng hơn khi slide được đưa lên mạng
Slide thuyết trình được tạo ra để hỗ trợ lời nói nên khi đăng lên mạng thường không còn phù hợp, và sẽ rất tốt nếu có thể dễ dàng kèm theo ghi chú slide
Trong Google Slides thì cũng ổn, nhưng với PDF thì khó, còn với beamer thì có lẽ đã làm được hoặc có thể làm được, nên biết đâu ai đó có thể thúc đẩy thành một thông lệ mới
Các bài thuyết trình kỹ thuật của tôi khá được ưa chuộng, và cả những người không làm kỹ thuật nhưng quan tâm tới chủ đề cũng chuyền tay nhau xem slide trong công ty
Cấu trúc kể chuyện là chìa khóa, vì không có câu chuyện thì bài thuyết trình không thể hấp dẫn
Khi làm bài, tôi liên tục lướt qua các slide để kiểm tra xem mạch truyện có tự nhiên không
Trong lúc trình bày, tôi tránh để quá nhiều thông tin hiện ra cùng lúc trên màn hình, và dùng timeline của PowerPoint để slide dần hình thành trong lúc tôi nói
Nó gần như tạo cảm giác như đang dùng bảng trắng, và chẳng ai thích việc vừa chuyển slide là một bức tường chữ bật ra trước mặt
Không phải tôi hoàn toàn tránh slide chỉ có văn bản, nhưng hiếm khi đó là cách tốt nhất để truyền tải câu chuyện hay khái niệm của tôi nên tôi gần như không dùng
Trong quá trình làm bài, tôi cũng liên tục đọc lại để xem nó có đang quá kỹ thuật đến mức nhàm chán hay quá phi kỹ thuật đến mức nhàm chán không
Cân bằng là quan trọng; nếu đột nhiên phải đi quá sâu về mặt kỹ thuật thì vài slide sau cần kéo nó lên lại, và ngược lại cũng vậy
Dù ít chữ, tôi vẫn dùng rất nhiều hình minh họa vẽ tay để giải thích chính xác các khái niệm, nên kể cả khi in ra thì người xem vẫn hiểu và nắm được điều cần biết
Cuối cùng, dùng ứng dụng nào không quan trọng
Chỉ nghệ sĩ tồi mới đổ lỗi cho công cụ, và tôi dùng PowerPoint vì nó hỗ trợ Pencil trên iPad cùng một timeline animation đầy đủ, nên nếu dùng tốt thì gần như ở mức làm phim
Dù vậy, tôi chủ yếu dùng nó để chia slide thành những mảnh nhỏ hơn
Các bài thuyết trình kỹ thuật nên luôn bắt đầu bằng một spoiler
Người bận rộn hoặc đơn giản là tin lời bạn có thể nhận ngay thông tin quan trọng nhất rồi rời đi gần như lập tức
Người không đồng ý hoặc muốn xem bằng chứng cho lập luận thì có thể tiếp tục theo dõi
Cụm này thường dùng nhiều hơn trong ghi chú hoặc email, nhưng ý tưởng thì như nhau
Nếu nói trước điều sẽ xuất hiện ở cuối, mọi người sẽ hiểu phần bối cảnh đang dẫn tới đâu
Bạn vẫn có thể viết “xương sống” của câu chuyện, nhưng nếu muốn thuyết phục khán giả rằng cuối cầu vồng có một vụ nổ, thì hãy cho họ xem trailer trước
Không cần bắt khán giả phải “kiếm lấy” phần thưởng; cứ đi thẳng vào phần hay nhất, rồi giải thích phần còn lại cho những ai quan tâm
Điều này cũng xuất hiện trong nhiều bài đánh giá demo: https://web.archive.org/web/20220126051034/https://www.secon...
Tôi bắt đầu bằng phần tóm tắt, và khi phù hợp thì đặt ngay từ đầu cả đoạn mã tái sử dụng hoàn chỉnh có thể copy-paste
Đó là cách tôi muốn người khác làm cho mình, nên tôi cũng làm như vậy
Hãy gác cái tôi sang một bên và ưu tiên tính hữu ích
Nó buộc bạn phải nói trước vì sao mọi người nên quan tâm, và đẩy phần kém thú vị hơn ra sau, nên nếu hết giờ hoặc ai đó mất tập trung thì họ cũng không bỏ lỡ quá nhiều
[1] https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
Có thể xem đây là kiểu trình bày “I’m okay, the bull is dead”
https://www.computerworld.com/article/1702433/i-m-ok-the-bul...
Tôi hiểu rằng trong tình huống như vậy người ta có thể không đủ bình tĩnh để giải thích rõ ràng, nhưng ở đây có vẻ không phải trường hợp đó
Nếu đủ bình tĩnh, tốt hơn là nên đưa cho đối phương một lời giải thích 10–15 giây về chuyện đã xảy ra trước
Hãy nói kết luận và tác động trước, rồi bổ sung phần bối cảnh dẫn đến sự việc đó sau
Các bài thuyết trình kỹ thuật vẫn cần có câu chuyện
Chúng nên bắt đầu bằng một biến cố thu hút sự chú ý, tức là biến cố khởi đầu, giống như các kỹ thuật kể chuyện tiêu chuẩn
The Matrix bắt đầu khi Trinity sắp bị bắt, Bambi bắt đầu với cảnh mẹ nó bị bắn, còn Star Wars bắt đầu với một con tàu nhỏ bị một con tàu khổng lồ bắn laser truy đuổi
Một bài thuyết trình kỹ thuật hay sẽ đi theo cấu trúc của một câu chuyện hay
Trình tự là: biến cố khởi đầu, xây dần lên các cao trào nhỏ, lùi lại một chút, cao trào, kết luận
Nếu muốn trở thành một người thuyết trình kỹ thuật xuất sắc, bạn nên đọc sách về cách kể những câu chuyện hay
Ví dụ, những bài viết dài lê thê mở đầu kiểu “David sống trong một căn nhà ba phòng ngủ ở một vùng quê nào đó cùng với hai con chó boopy và bloppy...” làm tôi đóng tab ngay lập tức
Trước đây tôi từng học một lớp về thuyết trình rất hay do một diễn viên hài dẫn dắt, và lời khuyên tôi nhớ nhất là hãy cấu trúc bài nói như một hành trình anh hùng
Đó là một cấu trúc mà ai cũng biết: mọi thứ đều ổn, bi kịch ập đến, vấn đề được vượt qua, ăn mừng
Bạn có thể nghĩ nó không hợp với thuyết trình kỹ thuật, và không phải bài nào cũng cần như vậy, nhưng thực ra nó áp dụng được thường xuyên hơn nhiều so với tưởng tượng
Về cơ bản, bất kỳ thứ gì giải quyết một vấn đề đều có thể được kể theo cách này
Thế nhưng quá nhiều bài thuyết trình lại mở đầu bằng kiểu “Tôi sẽ nói về dự án X. Đây là dàn ý các slide. Vậy, X là gì?”
Thay vào đó, bạn có thể nói theo kiểu “Chúng tôi có rất nhiều thứ đang làm Y. Mọi thứ đều ổn cho đến khi Z xuất hiện. Sau đó thảm họa ập đến. Giải pháp hiện có A hoàn toàn không hiệu quả trong trường hợp này. Vì vậy chúng tôi tạo ra X. Nhưng nó không hoạt động vì ... nên chúng tôi phải ... và cuối cùng mọi thứ đã chạy được”
Tôi khuyên nên bắt đầu slide đầu tiên bằng một hình ảnh không có chữ
Hình đó trên bề ngoài có vẻ không liên quan gì đến chủ đề bài nói vốn nằm ở slide tiêu đề không đánh số
Khi đó mọi người sẽ tò mò về phần giải thích và chú ý lắng nghe
Sau khi giải xong câu đố, hãy chuyển sang slide thứ hai để đưa ra định nghĩa vấn đề hoặc câu hỏi nghiên cứu, rồi sau đó đi theo cấu trúc thông thường: tổng quan, phương pháp, dữ liệu, thí nghiệm, kết quả đánh giá, thảo luận và giới hạn, tóm tắt, kết luận và công việc tương lai
Tuy nhiên, điều này chỉ hiệu quả với thuyết trình miệng
Một kiểu slide deck quan trọng khác đang rất phổ biến ở các tập đoàn toàn cầu lớn gần giống như sự pha trộn giữa bài thuyết trình PowerPoint và tài liệu Word
Slide được nhồi đầy chữ để chỉ cần xem deck cũng hiểu được, và chúng được tạo ra không chỉ để thuyết trình mà chủ yếu là để gửi qua email cho người khác đọc
Vì lãnh đạo có thể không nghe phần trình bày mà chỉ lướt slide, nên người ta cố ý phá vỡ một số quy tắc của những slide tốt vốn dùng để hỗ trợ một bài nói hay
Ít nhất trong lĩnh vực của tôi là computer vision và machine learning, người ta đặt một hình minh họa lớn, đẹp và nếu có thể thì tự giải thích được ngay ở trang đầu
Nó có vai trò thu hút và giữ sự chú ý của người đang lướt qua PDF
Trong computer vision, bạn thường có thể tìm được thứ gì đó hấp dẫn về mặt thị giác, như hình ảnh nhấn mạnh tái dựng 3D hoặc phát hiện đối tượng
Hoặc bạn có thể dùng một biểu đồ cho thấy phương pháp của mình tốt hơn baseline bao nhiêu, nhưng điều đó có thể kém hấp dẫn hơn với những người không hiểu rõ ý nghĩa của các con số
Trong phần demo, từ lâu người ta đã học được rằng hãy bắt đầu từ phần hay nhất
Nếu bạn có phần mềm giám sát tuyệt vời, đừng bắt đầu bằng quá trình cài đặt, thiết lập thu thập metric, rồi cách kết nối frontend với cơ sở dữ liệu chuỗi thời gian trước khi cho thấy những biểu đồ đẹp mà trước đây chưa từng có
Thay vào đó, hãy cho thấy ngay những biểu đồ đẹp mà trước đây chưa từng có, rồi giải thích vì sao chúng hữu ích
Sau đó, chỉ khi mọi người đã quan tâm, bạn mới có thể dành thời gian cho họ thấy mình đã đạt được trạng thái đó như thế nào
Tôi đã xem quá nhiều bản demo mở đầu bằng một quá trình dài dòng, tẻ nhạt trước khi tới được phần hay, trong khi sẽ tốt hơn nhiều nếu họ cho thấy thứ ấn tượng trước
Đây là một cách làm cực kỳ xuất sắc cho các bài thuyết trình kỹ thuật
Nhưng nếu làm vậy trong phương tiện giải trí như tiểu thuyết hay chương trình TV thì gần như lúc nào cũng kém hấp dẫn hơn
Nếu không cần thông tin nền để hiểu một cảnh hành động, thì theo tôi có thể bỏ hẳn phần thông tin nền đó đi
Tôi chỉ mong nhịp độ đừng bị đẩy vọt lên rồi lại rơi quá nhanh về trạng thái không có gì xảy ra
Dù vậy, vẫn có lý do cho việc đưa phần quan trọng nhất của câu chuyện lên trước
Kiểu như mạch truyện của cuốn tiểu thuyết quá chậm, độc giả thử đọc thì bỏ cuộc trước khi có chuyện thú vị xảy ra, nên biên tập viên đề nghị: “Hãy đưa cảnh chiến đấu hay ở chương 10 lên đầu để cho thấy cuốn sách này định làm gì”
Cách đó hiếm khi thực sự hiệu quả
Tôi đã đọc mọi câu và mọi đoạn, nhưng vẫn chưa chắc bài gốc muốn truyền đạt điều gì
Ý là “hãy bỏ qua phần mở đầu” sao?
Khi bắt đầu một bài thuyết trình, tôi thường đưa ra một dàn ý ngắn về bài nói sẽ gồm những gì
Không phải lúc nào cũng có thể điều chỉnh nội dung theo khán giả, nhưng ít nhất nếu đưa trước mục lục hoặc bản tóm tắt, họ sẽ biết khi nào cần tập trung và khi nào có thể lơ đãng một chút
Những điểm cốt lõi cần được nhấn đi nhấn lại chỉ nên là 2~3 ý, không nên nhiều hơn
Và mẹo số 1 của tôi là: bạn càng muốn bài thuyết trình nghe tự nhiên, thì càng phải luyện tập nhiều từ trước
Người thuyết trình có kinh nghiệm rồi sẽ biết khi nào và bằng cách nào nên phá vỡ những quy tắc này
Dĩ nhiên là tái phát minh