אחרי שהכנתם מצגת, כתבתם לעצמכם סיכום של מה שאתם הולכים להגיד ואתם סגורים על דוגמאות הקוד שאתם רוצים להראות יש עדיין כמה צעדים קטנים שכדאי לקחת כדי להפוך את ההרצאה לכזו שאנשים יצאו ממנה עם תחושת וואו. מוזמנים לקרוא וליישם לפני הוובינר הבא או ההרצאה המקצועית הבאה שתעבירו.

1. נסו את זה בבית

הדבר הראשון הוא לוודא שהמשפטים באמת מתחברים אחד לשני והדרך היחידה לעשות את זה היא פשוט לנסות.

הפעילו בטלפון או במחשב את תוכנת ההקלטה, עמדו מול המראה (או המסך) ופשוט התחילו לדבר. עם השעון ובלי לעצור כשמתבלבלים.

למחרת הקשיבו להקלטה ורישמו לעצמכם שאלות או דברים שהיו לא ברורים או שלא הייתם מרוצים מהם. ככה ממשיכים פעמיים-שלוש בימים שונים עד שהטקסט נשמע זורם עם קשר חזק בין המשפטים והחלקים השונים בהרצאה.

2. מה יקרה אם?

אחרי שבנינו וחיזקנו את המסלול הנכון הגיע הזמן להתחיל לחקור. צפו או האזינו להקלטה וחפשו על המסך דברים שלא התיחסתם אליהם עד עכשיו: כפתורים שאפשר ללחוץ עליהם, נתיבים בקוד שלא הפעלתם ובאמת כל דבר שעשוי לקחת את ההרצאה שלכם לכיוון אחר.

לדוגמא נניח שאני מכין הרצאה על פיתוח jQuery Plugins ובמהלך ההרצאה כתבתי את הקוד הבא:

$.fn.greenify = function() {
    this.css( "color", "green" );
};

$( "a" ).greenify();

אז אפילו על הקוד הקטן הזה אפשר לשאול: מה אם מתחשק לי צבע אחר במקום ירוק? מה אם יהיו מספר אלמנטים על המסך? האם הפלאגין יצבע את כולם? מה אם ארצה להמשיך את השרשרת? איפה כותבים פונקציית עזר? מה יקרה אם נוסיף לעמוד עוד סיפריה שמשתמשת בדולר (למשל Zepto)? מה אם נרצה לכתוב את העיצוב בקובץ CSS נפרד?

לחלק מהשאלות אתם כבר יודעים את התשובות ועוד חלק מהשאלות ישלחו אתכם למסע חיפוש וגילוי. אל תוותרו על המסע הזה כי הוא ישלים לכם הרבה פינות ויעזור לכם לדבר יותר בביטחון על הדברים שאתם מציגים.

3. מה יכול להשתבש?

סוג נוסף של שאלות שכדאי מאוד לבדוק ולהכיר הוא "מה יכול להשתבש?". מה אם האלמנט שרציתם לא נמצא על העמוד? מה אם אין תקשורת? מה אם בסיס הנתונים ייפול?

כשאתם מציגים קוד אתם חייבים להכיר את המגבלות שלו. בדרך כלל ב Demos אנחנו מראים קוד ממש קטן ומוגבל שלא יתאים לעולם האמיתי כדי להעביר נקודה. חפשו את הפער בין הקוד שאתם מציגים לעולם האמיתי ועשו לכם רשימה של כמה שיותר דברים שיכולים להשתבש כשהרעיון שאתם מדברים עליו יגיע למערכת אמיתית.

מקור נוסף לבעיות פוטנציאליות הוא אתרי השאלות ובראשם Stack Overflow. לכו לחפש שאלות של אנשים על הנושא הזה שאתם באים לדבר עליו, לכו ל Reddit ותראו על מה אנשים מדברים, מה מטריד אותם או מה מלהיב אותם. אם זה פרויקט קוד פתוח לכו לקרוא את רשימת ה Issues הפתוחים והסגורים שלו. וודאו שאתם מגיעים להרצאה אחרי שהבנתם לפחות 8-10 דרכים שהקוד יכול להישבר וכמובן איך לצאת מהן.

בהרצאה האמיתית תוכלו לבחור מהרשימה שלכם בור או שניים כאלה ולהזהיר את הקהל שלא יפלו בו.

4. חפשו את ההיסטוריה והסיפורים שמסביב

מה היה השם הקודם של mLab? מה היתה שפת התכנות הראשונה ש Heroku תמכו בה? מי הקים את החברה והאם היא סטארט-אפ או שייכת לגוף גדול? או אם נחזור לדוגמא של jQuery - מי כתב את jQuery במקור? מתי? מה היה הפלאגין הראשון שנכתב? כמה פלאגינים יש בעולם? איפה מוצאים פלאגינים טובים?

ככל שתכירו יותר סיפורים, היסטוריה ומורשת על הנושא שאתם באים לדבר עליו כך יגדל הביטחון שלכם בשיחה ותוכלו לשלב בהרצאה אנקדוטות שאנשים לא תמיד מכירים.

רובנו לא מעבירים הרצאות 5 פעמים בשבוע (ומי שכן ממילא יודע את כל מה שכתוב כאן). יש לכם הזדמנות שאני לא יודע מתי תקרה שוב לעמוד מול אנשים ולספר להם על מוצר או טכנולוגיה שמלהיבים אתכם. כדאי לנצל אותה ולהגיע כמה שיותר מוכנים כדי שגם אתם וגם הקהל שלכם תרוויחו בגדול.