יום רביעי, 10 בנובמבר 2010

כמה כללים למצגת אפקטיבית

שמתי לב שדווקא לאנשים טכניים יש קושי בהעברת מצגת. למה?
  • כיוון שהרבה פעמים הם בכלל "נודבו" למשימה ותעזבו אותי באימא 'שלכם.
  • כיוון שקשה לנו לפעמים להבין שגם אם יש ידע טכני ליושבים מולם הוא אינו בהכרח רחב בתחום של ההרצאה.
  • כי קשה לאדם טכני להיות שיווקי, זה אפילו עלול להיראות לו לא טבעי; אבל כל הרצאה היא שיווקית בראש וראשונה.
הכוונה כאן היא לא למצגת טכנית נטו, כלומר אין הכוונה להדרכה, אלא למשל לנסות לשווק תוכנה פנימית שיצרנו במחלקה למחלקות אחרות, או לשכנע אנשים להתחיל להשתמש בתוכנת ניתור הבאגים שלנו; זה יכול להיות מצגת lesson learned או סיכום גרסה וכד'.
אספתי מספר כללי אצבע למצגת מוצלחת ואני מתכוון לשתף.


  • מטרתנו היא לשכנע את היושבים מולנו במשהו. כל עמוד שאתם מסיימים לכתוב, תקראו שוב ותסבירו לעצמכם למה כל משפט תורם למטרה הכללית. אם הוא לא עושה את זה - נסחפתם. תמחקו אותו.
  • אף פעם אל תניחו מראש שתצליחו במטרה.
  • אם המטרה חשובה, או אם ברור מראש שתוכן המצגת לא יתקבל על הכל, או אפילו עלול לפגוע בחלק מהאנשים שיהיו בפגישה - דברו איתם לפני. הראו להם, אם צריך, את המצגת. עשו קואליציות והגיעו להסכמות עם אלו שיוצאים פחות טוב. אם אתם רוצים לשכנע, עדיף שתדברו עם לפחות חלק מהמוזמנים לפני, תציגו את מה שרציתם, קבלו פידבקים, תקנו את מה שצריך. אין לכם מושג (או שכן) כמה נעימה יכולה להיות ישיבה כזו. תחשבו על זה.
    לא, אנשים טכנים יקרים, אני לא מתכוון לוותר על מה שיש לכם לומר. ממש לא. אבל אם אתם מציגים lesson learned ואומרים שבעייה עיקרית היא בזמני הפיתוח, ואלה יתחממו ויענו לכם שאתם לא פחות בעייתיים ויתחיל ויכוח, וזאת מול כל הקודקודים - כולם מפסידים. מצטער, לפעמים פוליטיקה, או יש כאלה שיאמרו התחשבות, זה דבר הכרחי.
  • אם אתם מנסים לשכנע במשהו: אנשים יקבלו את מה שאתם "מוכרים" לא בגלל שהם דברים צודקים, לא כיוון שהם מועילים לחברה, לא כי אתם חכמים, לא כי אתם יפים. אנשים יקבלו את מה שאתם אומרים בגלל ידידה טובה שלי, אמילי שמה. ומה אמילי אומרת? - אני, מה יצא לי (מזה)? ככל שפנימו את זה יותר מהר כך זה יעזור לכם יותר.
    הכוונה אינה בהכרח טובות הנאה אישיות, אני מקווה שלא, אלא דברים כמו מידע אמין וזמין, חסכון בשעות עבודה וכד'.
  • הטקסט על המצגת לא נועד להעביר את כל הוראות השימוש של המוצר / יומן יומיומי של גרסה וכד'. הטקסט בכל דף נועד להכיל את הדברים החשובים שאת רוצה להעביר בנושא זה, הדברים שעל הנוכחים לזכור. הסיכום כביכול. נ-ק-ו-ד-ה. אף אחד לא יקרא את כל מה שאתם אומרים - כי אתם אומרים את זה ממילא. איש לא יזכור את כל מה שאתם אומרים גם אם זה רשום (במלואו). אולי זה יפריע להם להתרכז בהרצאה אם הם יקראו את הטקסט.
    לדוגמא: אם הכוונה בדף זה היא לומר שכלקח הקטנו את ה-down time במעבדה: הסבירו איך, תגידו מה יש היום מול מה שהיה, אבל הטקסט צריך להיות:
    - הכנסנו נהלים חדשים:
      - אודיט לפני הבדיקות.
      - הכנסת רמת העדיפות על כל קריאה לצוות הטכני.
      - הרצה אוטומאטית קבועה של בדיקת המערכת.
    וכו'.
    בע"פ תסבירו מה זה האודיט הזה (לא זו לא מישהי מהודו), מה טוב בעדיפויות וכד'.
  • לבוא לבוש מסודר. לא להחזיק משהו בידיים לאורך זמן, לא להחזיק ידיים בכיסים. האמינו לי שידים בחוץ מרגיש פחות טוב, אבל נראה טוב יותר. לא לזוז כאחוזי תזזית. מומלץ: להסריט את עצמכם כמה דקות מציגים בפרטיות ולראות את התוצאה.
  • הצג את עצמך ואת תפקידך. אם צריך - כמה מילים על ניסיונך.
  • עליך לערוך חזרות חוזרות ונישנות. אתה לא אמור להסתכל על המצגת בזמן ההצגה (חוץ מכאשר אתה מעביר עמודים).
  • אם הזמן הוא שעה, וודא שלבד בחזרה אתה מסיים תוך 45 דקות.
  • עמוד בזמנים בזמן אמת.
  • לדאוג שכל, אבל כל אחד בחדר מקבל קשר עין.
  • אל תדבר רק לכיוון אחד של הקהל.
  • לא להסחף למקומות לא רצויים. אפשר לשאול, אפשר לענות, אבל הישיבה מנוהלת על ידכם.
  • לחייך מידי פעם, להכניס גוונים לקול. כדאי לערב את הקהל בשאלות.
  • להגיע לפחות 15 ד' לפני ולוודא שהכל עובד (מקרן, רשת, USB, שיש מפתחות לחדר ישיבות).
  • לבוא עם העתק של הפרזנטציה. אם תהיה הפסקת חשמל או תשרף הנורה של המקרן - עדיין יהיה שלד ההרצאה בידיך.
  • לוודא שכל המצגת היא באותם פונטים, ובכמה גדלים קבועים (כלומר אם הכותרת היא פונט בגודל 16, שיהיה אותו הגודל בכל עמוד).
  • בעמוד הראשון, שער, ובו הנושא בשורה וגם שמו של המציג.
  • לא יורדים שורות! כאמור למעלה, רק משפטים קצרים של מהות העניין צריכים להיות מוגשים. אנשים פשוט לא יזכרו יותר (ואולי גם לא את זה!).
  • כל מונח שעשוי לא להיות ברור: תנו הגדרה (אפילו בתחתית העמוד). לא תמיד אנשים יטרחו לשאול.
  • נסו להבין אילו שאלות עשויות להישאל ונסו לתת עליהן מענה.
  • אם אתם מכניסים נתונים הבאים ממקור מסויים, או בכלל יש הרחבות חשובות לנושאים שעליהם אתם מדברים, אבל שלא חייבים להיות במצגת (ששוב - אמורה להיות קצרה ולעניין) - שימו אותם בדפים בסוף, אחרי עמוד הסיכום והתודה. ואם איזה נודניק ישאל: רגע, איך אתם יודעים? -בבקשה הנה מלא המידע. חשוב בכ"ז לא להיגרר מצד שני למקומות שאתם לא רוצים להגיע אליהם.
  • כל דף אמור להכיל את ידידתנו אמילי. זה הכי חשוב.
  • בסוף - סיכום קצר של עד שלשה נושאים מרכזיים מרכזיים. ואמילי.

יום רביעי, 3 בנובמבר 2010

איך להתמודד עם משימה מעורפלת של בדיקה דחופה של מוצר חדש

אתה חדש בתחום - או לא, עובד בחברת היי-טק, יושב במשרד שאנן, ולפתע אתה מקבל טלפון מסמנכ"ל הפיתוח: אתה יכול לבוא רגע?
נתעלם מהשאלה הרטורית המעצבנת (לא, לא בא לי לבוא - אני באמצע מלחמות המאפיה) ונלך לחדר.
שב. תראה (מצביע למסך) ביקשתי מהצוות של מוטי לבנות אלגוריתם חיפוש שיחלק את התוצאות לקטגוריות (לא רעיון רע, נכון?). אתה לוחץ כאן, כאן אתה משנה קטגוריה, אגב ההגדרות משתנות כל הזמן לפי מידע שמקבלים מהמשתמשים. שמע אני הולך להציג את זה בערב מול משקיעים, פגישה שתקבע את עתיד החברה, אז תדאג שזה יעבוד, בסדר? עוד 6 שעות הפרזנטציה מתחילה. טוב אני חייב לרוץ.
עכשיו ברצינות, מה עושים? ברור שאין זמן לחפור בדרישות (אם יש בכלל) וכד', לא תמיד מנהל המוצר זמין ועוד. אז הנה כמה כללי אצבע:
  • קודם כל אם באמת הכוונה להציג למישהו, אז צריך להחליט מראש מה היו בדיוק הסנריו שיוצגו, ולעשות את מרב הבדיקות עליהם ועל סביבתם הקרובה. אבל זו הייתה רק דוגמא.
  • 30 דקות: כן חשוב לדבר עם מנהל המוצר ולהבין את מטרת המוצר, שימוש "רגיל" של משתמש קצה וכד', לרשום שימושים חשובים / נפוצים.
  • 30 דקות: לדבר עם הפיתוח (שמן הסתם יודע יותר מאיתנו כי בלי להסביר לו הוא לא יוכל לפתח) שבוודאי יודע היכן המקומות הפגיעים ומה חשוב שיתבצע. לצרף לרשימה הקודמת.
  • לנסות לקבל כמה שיותר expected results שאפשר מהגורמים לעיל.
  • 15 דקות: לסגור את הרשימה של הדברים חשובים ביותר לבדיקה ולסדר לפי סיכונים.
  • לוודא שכולם בסביבה וזמינים לעזרה מיידית.
  • 45 דקות: מעבר ראשוני על התוכנה. פשוט לעבור עמוד עמוד, תפריט תפריט, ובזריזות. נכון שזה נשמע כמו בזבוז, אבל זה ייתן לך קצת פרספקטיבה על המוצר ויאתר בעיות בסיסיות ביותר. אפילו פונקציה חשובה פחות כמו מה חדש תתגלה כחשובה מאוד אם היא מקריסה את המערכת או מראה טקסט של מפתח משועמם שהיה צריך לכתוב כמה מילים כתופסי מקום והא כתב משהו על המקצוע של אחותו של העמית שלו.
  • עברו שעתיים יקרות מאוד, כי בעיות צריך לתקן ואח"כ לבדוק, אז מתחילים לחפור. מתחילים בפעולות קלות ועוברים לקשות. רבע שעה ראשונה עדיף שר"צ הפיתוח או מנהל המוצר יישבו איתך ופשוט יעקבו אחריך. את התוצאות צריך לשמור, אפילו ב"קצרנות" על נייר. כל דבר שלא ברור תוך 5 דקות - בניגוד לבד"כ כשמומלץ לנסות ולהבין יותר לעומק - ללכת לפיתוח/מנהל המוצר ולשאול. כל באג - לכתוב ולתת עדיפויות. באג שחייבים לתקן, ללכת במיידי לפיתוח, להציג, לוודא הבנה ושהתיקון מיושם במקום, לחזור ולהמשיך בבדיקות.
הדברים החשובים כאן הם המידע (על המוצר), וסדרי עדיפויות. החלק השני הוא שלך בלבד, והוא לא פשוט. את צריכה להתעלם משקיעה באנליזה של באג שאולי הוא לא קריטי לעכשיו ובריכוז עילאי ממש לרוץ על שאר הפונקציונליות.
בנוסף, מניסיון, יש תופעות שלפעמים קל להתעלם מהן, במיוחד לבודק עם פחות ניסיון. למשל בלהט הבדיקה מתעלמים שלפעמים בכפתור מסוים יש ללחוץ יותר מפעם אחת בכדי שיעבוד. אולי בתת-מודע אנו אומרים לעצמנו שהכי חשוב שיעבד היטב בסוף, אבל זו יכולה להיות כשלעצמה בעיה חמורה או תסמין לבעיה חמורה אחרת.

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

רשומות פופולריות