הכנתי הרצאה נהדרת. איך זה שהיא לא התקבלה לרברסים?

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

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

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

המסגרת הכללית

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

פרט לכך, יש כמה כללים קשיחים. כללים אלו לא נוגעים לתוכן ההגשות אלא יותר ל"מעטפת" ומטרתם גיוון התוכן:

הגבלה על מספר ההרצאות מכל ארגון/חברה.
הגבלה על מספר ההרצאות בטרק מכל ארגון.
הרצאה אחת בלבד לכל מרצה.

להצליח במספר טורנירים

השנה נשלחו לכנס למעלה מ-500 הגשות שחולקו ל-7 מסלולים: Ignites, Infrastructure, Backend, Craft, Culture, AI/ML, Frontend+Product. בסוף התהליך נבחרו 14 הרצאות Ignite, ו-6-7 הרצאות בכל אחד מהמסלולים האחרים.

המטרה של צוות התוכן היא שכל אחד מהמסלולים האלה יהיה אטרקטיבי בכללותו. כלומר: שתמהיל ההרצאות בכל אחד מהמסלולים יהיה כזה שהקהל ירגיש שהוא קיבל ערך גבוה, ולכן תהליך המיון/בחירה הוא שילוב בין הסתכלות על כל הגשה בנפרד לבין הסתכלות על המסלול בכללותו. למשל: במסלול ה-frontend יכולות להיות שתי הגשות נפלאות שהנושא של שתיהן הוא ה-Temporal API החדש ב-JavaScript. גם אם שתי ההגשות האלה הן בשתי רמות מעל כל ההגשות האחרות במסלול, סביר מאד להניח שרק אחת מהן תיכנס. למה? גיוון. בראייה כוללנית של הערך, לקהל עדיף לא לשמוע הרצאה שחופפת להרצאה קודמת.

ספציפית השנה נושאים כמו "Building a company brain" או "Running Agents in Production" היו מאוד פופולריים. הגשות שהתמקדו בנושאים כאלה מצאו את עצמן בתחרות קשה יחסית (ראו גם את ענן המילים).

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

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

אי-וודאות מהווה סיכון

בהגשה יש שני חלקים עיקריים: (i) ה-Description שהוא מעין טקסט "שיווקי" שיהיה חלק מהתוכנייה של הכנס - זה הטקסט שבאי הכנס יחליטו לפיו האם לבוא לשמוע את ההרצאה; (ii) ה-Outline שהוא המקום שבו המגיש יכול לספר לצוות מה יהיה התוכן - החלק הזה לא חשוף לקהל.

הגשה שמשאירה גם את ה-Description וגם את ה-Outline באותה רמת פירוט לא נותנת לצוות כלים לקבוע האם ההרצאה תהיה חדשנית או טריוויאלית. הנה דוגמא:

Outline

When the User Becomes an Agent: Rethinking the Stack
[1m] Who am I
[3m] Why the UI-first stack collapses when the user becomes an agent
[4m] What agents actually need from an API that humans never did
[5m] How identity, permissions, and audit have to change
[8m] Five Lessons from teams that have already made the shift
[3m] What the agent-native stack looks like

Outline שכזה מכניס את צוות התוכן למשחק של ניחושים: מה יהיו הלקחים שמוצגים בסעיף החמישי? איך נראית הארכיטקטורה שמוצגת בסעיף השישי? אי-הוודאות הזאת מייצגת סיכון והסיכון הופך לא פעם להחלטת דחייה. נקודת הכשל הזאת היא אחת הסיבות הנפוצות ביותר לאי-קבלת הרצאה. בניתוח שעשינו, ביותר מרבע מההגשות שלא התקבלו (לא כולל הגשות ל-Ignites), היו הערות של הצוות על כך שה-Outline לא אינפורמטיבי מספיק.

טיפ להמשך: תשקיעו ב-Outline. תכתבו אותו כך שמי שקורא אותו יוכל לדמיין את השקפים שתציגו.

טיפ נוסף: תשקיעו בשדה ה-Audience Takeaway. הרבה מחברי צוות התוכן מציינים את השדה הזה בתור אחד השדות המרכזיים שעוזר להם להבין/להיזכר על מה ההרצאה. השדה הזה צריך לענות על השאלה הבאה: מהו המשהו הממשי שהקהל יוכל להתחיל לחשוב/לעשות בצורה שונה ביום שלמחרת ההרצאה?

טוב על הנייר, לא תמיד טוב על הבמה

בחלק (יחסית קטן) מההגשות ה-Outline מציין שחלק מסוים יהיה ב-live coding או live demo. הערך של האלמנט הזה ברור: זה מרגש, זה מעורר עניין, ועל פי רוב זאת דרך מצוינת להבהיר נקודה מסוימת. כשהרצאה כזאת נבחנת האלמנט הזה הוא גם פעמון אזהרה. למה? כי זה משהו שיכול להתקלקל בזמן אמת מול הקהל. למשל: מחשב של מרצה שלא מצליח להקרין על הציוד של האולם. או: כישלון להתחבר ל-WiFi, מה שמאד יכול לקרות בכנס שבו נמצאים מעל 1,000 איש בתוך שטח מוגבל. ובנוסף לזה: האם המרצה יצליח להכין גיבוי שיהיה מספיק טוב ושיצליח להעביר את המסר הרצוי במקום הדמו? החששות האלה לא פוסלים את ההגשה אבל הם כן משקפים גורם סיכון שבסופו של דבר פוגע בדירוג (הכמותי או האיכותני) שההגשה מקבלת.

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

רוחב

רברסים הוא כנס שפונה לקהילה רחבה מאד של מתכנתים. הקהילה הזאת לא מוגדרת על פי חתך טכנולוגי מסוים, בניגוד לכנסים כגון: NodeTLV, PyCon Israel או AWS Summit Tel Aviv. לכן, כשיש הרצאה שהמוקד שלה הוא טכנולוגיה ספציפית צוות התוכן ישאל את השאלה הבאה: "כמה הטכנולוגיה נישתית?" או בצורה אחרת: "איזה חלק מהקהל במסלול הזה יתעניין בה?". אם ההערכה היא שקהל היעד מצומצם מדי, דירוג ההגשה ייפגע. במילים אחרות - עם כל הכבוד לקהילת הראסט (ויש הרבה כבוד) הרצאה כמו "Six Amazing Rust Patterns" פחות תתאים לכנס שלא ממוקד על שפת תכנות ספציפית. מאידך יש מקרים שבהם הרצאה נישתית לכאורה דווקא יכולה לעניין קהל רחב. למשל "איך בניתי רובוט שמשחק שחמט?". לא הרבה אנשים יבנו רובוט כזה, עדיין הלקחים שיעלו בהרצאה כזו, האתגרים הטכנולוגיים, היוזמה, יכולים להיות מעניינים ורלוונטיים לכולם. לפעמים סיפור נישתי יכול להוות השראה.

מדריכים לימודיים (Tutorials)

יש הגשות שמהותן היא ללמד על איך להשתמש בכלי טכנולוגי כלשהו: ספרייה, פריימוורק, דאטה-בייס, שירות, וכו'. גם הגשות כאלה צריכות לעבור את משוכת הרוחב שהוסברה מקודם. בנוסף, נבדקת בהן השאלה האם יהיה בהרצאה ערך מוסף מעבר ל-tutorials שניתן למצוא ברשת (או ליצור בעזרת ה-LLM החביב עליכם). למשל: האם ההרצאה תסתפק בסקירה של הפונקציונליות של הכלי המגניב, או שהיא גם תקדיש חלק משמעותי ליתרונות ולחסרונות שלו אל מול כלים שמתחרים בו?

מי מגיש ומאיפה

אחד הדברים שנבדקים בכל הגשה הוא כמה המגיש/ה מנוסה בנושא הספציפי של ההרצאה. בכל הגשה יש שדה ("How did you become knowledgeable about the topic") שהמגיש ממלא על עצמו. בנוסף אנחנו מסתכלים על מקורות כגון עמוד הלינקדאין של המגיש, או משוחחים איתו כדי לוודא שיש לנו תמונה טובה של המומחיות שלו. דוגמא: הרצאה על הנחלת תרבות מיטיבה בצוותי פיתוח ממגיש שנמצא בתפקיד הניהולי הראשון שלו, לעומת הרצאה דומה ממגיש שכבר כמה שנים בתפקידי הובלה וכעת הוא גם מנהל קבוצות. הפרספקטיבה העמוקה יותר שיש למגיש השני היא נקודה שתוסיף לדירוג של ההגשה שלו.

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

עוד חומר

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

לסיום

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

ולפני שניפרד נחזור אל הנקודה החשובה ביותר, שאיתה גם התחלנו:

תמשיכו לנסות!

בהצלחה. נתראה בכנס.

"הכנתי הרצאה נהדרת. איך זה שהיא לא התקבלה לרברסים?"