תחושת הסיפוק (או לכל הפחות, מעבר המשימה ל"Done") בסיום פיתוח פיצ׳ר חדש, היא נהדרת. פרוייקט שתכננת, לעיתים מאפס, קרם פונקציות וטסטים והפך לפיצ׳ר שיעשה טוב ללקוחות החברה וכמובן לחברה עצמה. החגיגה בעיצומה, אבל האם לרגע עצרנו וחשבנו ״למה?״ או ״מה עכשיו?״ - אני חושב שלפעמים זה הרבה יותר חשוב אפילו מהפיתוח עצמו.
בעולם שרוב הצוותים הם מעורבים, כוללים אנשי ונשות פיתוח, דאטה, פרודקט ועיצוב - לא צריך לצור מחיצות, כולם צריכים להכיר הכל, להבין הכל, להוביל ביחד. הבנה של הסיבות לבחירת הפיצ׳ר, הקהל שישתמש בו וצורת השימוש בו קריטית לפיתוח שלו. בהתאם, גם תעזור לפתח אותו בצורה שתגרום לך להבין אם הוא עובד טוב, נכון ואיך אפשר לקחת אותו קדימה.
כמוביל טכני בצוותי ה-Growth של מאנדיי, אני נחשף כל שבוע לפיצ׳רים שונים ומשונים באיזורים מגוונים. אומנם הליבה של טסט זה הפיצ׳ר שהוא מציע ליוזר, אבל אני לא נותן לעצמי להשאר באיזור הנוחות הזה ומלווה את הצוות משלבי המחקר ועד שלבי הניתוח. הבנת המכלול מאפשרת לי להתחבר, ברמה הרעיונית, וגם להכווין את הקוד שנכתב, כך שנוכל לשחרר בזמן הנכון, לאנשים הנכונים ובדרך הנכונה. המטרה שלנו, בסוף, היא לא רק לשחרר פיצ׳ר, אלא להגיע למסקנות הנכונות ולהחליט על השלבים הבאים בזמן הקצר ביותר ובצורה האיכותית ביותר.
שלב ההוכחות
אני מאמין שצריך להיות חלק בתהליך עוד משלב ההיפותזות. לדעתי, זה השלב הכי חשוב בתהליך. הצוות מתכנס לפגישה ובה מציגים בעיה, הבעיה חייבת להיות נתמכת בדאטה.
נתחיל מKPI, מה היעד של הצוות שלנו? במקרה שלי, כמות הנרשמים. ומכאן אפשר להתקדם לבעיות השונות ש״מתכבות עם זה, לדוגמא: ״50% מהאנשים לא עוברים את מסך ההרשמה״.
אוקיי - הגיוני, זה דאטה שמשקף את המציאות. מה עכשיו? רגע לפני שנתחיל, כדאי לנסות להשיג חיתוכי דאטה נוספים (האם יש ייחוד לסוגי קהלים? האם ההתנהגות זהה כשממלאים email או מתחברים דרך gmail וכד׳.) וכמובן מידע איכותני (qual) על התנהגות היוזרים, אפשר לשבת ולשתף בהיפותזות לזה.
התרומה של המפתח פה קריטית - גם בשלב החשיבה, גם בשלב המחקר (כן, מותר לכם ללמוד sql) אך גם לפני, כתהליך מתמשך, בסיוע לאנליסטים בהוספת מדידות רלוונטיות במרחב הקוד בכדי שיגיעו לשלב ההיפותזות עם כמה שיותר מידע.
לאט לאט ההיפותזות מתחילת למלא את הדף (או בסיוע WorkCanvas, למי שמעוניין), כולם יכולים לשתף ולהציע.
זה מקום בטוח וכל אחד יוסיף מה שהוא מרגיש שמשפיע, אפילו דברים קטנים. דמיינו ממש ״שמש אסוצסיציות״ כמו ביסודי - פשוט זורקים הכל.
סיימנו? נתחיל למצוא רעיונות לכל היפותזה. סיימנו? צריך לדרג את הרעיונות.
גם פה נכנס דאטה לעניין - לרוב נדרג בשימוש במודל RICE (או דומה לו) ול״השקעה״ (Effort) מצד הפיתוח יש כמובן משקל נכבד בהחלטה. כדאי להיות מובלים בדאטה פה. האם עשינו משימות דומות וכמה זמן לקח לבצע אותן? האם משימות דומות שעשינו ״הזיזו את המחט?״ - אתם הגורם שיכול לספק את המטריקות הרלוונטיות לקוד שכתבתם ולהבין יחד עם הצוות.
אפיון ותכנון
אז בחרנו פתרון אחד, לדוגמא ״להדגיש את הכפתור של Gmail ולהציג אותו ראשון״ - אחלה דבר.
איך ניגש למשימה בראייה שנותנת משקל לדאטה? נשאל שאלות לפני שנתחיל:
למה עושים את זה? - כאמור, הדאטה אמור להוכיח את זה. וכן, יותר אנשים (במקרה הזה) נרשמים דרך Gmail, אז אנחנו מאמינים שאם ״נסליל״ יותר אנשים להרשמה דרך הערוץ הזה, יותר אנשים ירשמו.
איך עושים את זה? - פשוט לשנות זה נחמד, אבל איך נדע שצדקנו? איך נדע שהזזנו משהו? ברוב המקרים אנחנו מציעים להשתמש בAB-Test, במיוחד כשיש ״מספיק״ דאטה והנקודת החלטה מאוד פשוטה - יוזר נכנס לדף ההרשמה ורואה חוויה אחת מתוך שתיים. לעשות טסט זה יחסית פשוט - יש המון כלים חיצוניים ואפשר גם לפתח פנימית.
בסופו של דבר, החלק המרכזי של Ab-Test מחובר לקוד, צריך לדאוג שהקוד ידע להציג שתי חוויות שונות, לתעד את זה (בעזרת events המחוברים למערכת tracking פנימית או שרכשתם) וכמובן לאפשר לחבר את זה למטריקות הרלוונטיות שרוצים למדוד, כמו הרשמה מוצלחת.
צריך למדוד משהו? - כבר ציינו שחשוב למדוד ״כניסה לחוויה״ ו״הצלחה״, אבל אולי אפשר עוד דברים? מדידה נכונה, אפילו מאסיבית, יכולה לעזור (אומנם לעיתים יקרה, אך בדיעבד, שווה את ההזדמנויות שנגלה) ולהוביל אותנו קדימה לקראת המשימות הבאות. לדוגמא:
א. איזה סוגי יוזרים מגיעים - האם יש הבדל בין שפות? או מכשירים? או אולי קמפיינים פרסומיים מסויימים? צריך לתעד הכל ובזמן הנכון ובצורה הנכונה. בעיקרון אפשר וכדאי לצור event אחד שעליו נעמיס את כל המידע, כך שנוכל בהמשך, בעזרת צוות האנליסטים, לנתח ביעילות ומהירות.
ב. האם יש בעיות נוספות בחוויה שאנחנו לא יודעים עליהם - אולי אנשים מתקשים להרשם בemail כי הם מקבלים ״error state" בגלל שגיאות בכתיבת האימייל? אולי יש לנו באג? תחשבו כמה קל להוסיף עוד event שסופר כמה פעמים אנשים נכנסו למצב ״error״ בהרשמה שלא היו אמורים להגיע אליו? כמה היפותזות נוספות, או לכל הפחות, bug fixes, נמצא כך?
גם דאטה טכני זה דאטה - ציינתי למעלה events, שהם אירועים ״ביזנסים״ שעוזרים לנתח את חווית המשתמש. אבל מה עם ביצועים? כן, גם להשתמש בכלים שמכוונים ביצועים כמו Sentry לאיסוף תקלות, או Datadog לאיסוף כמות קריאות, כשלונות ואורך ביצוע תהליכים זה קריטי. זה יתן לנו תמונה על היעילות של הקוד, ההשפעה של הפיצ׳ר החדש על שרתי החברה, מעבר לחווית המשתמש, הצפת מקרי קצה וכד׳. בסוף זה דאטה שממנו נמצא את הבעיות ונחליט על פיו אם יש הזדמנות מתאימה.
נצא למסע
הכל מוכן, לוחצים על ״Start Test״ וכולם מחכים במתח לראות מה יקרה. אבל באמת כולם, חשוב להדגיש, לא פשוט ״נזרוק״ על האנליסט הצוותי את כל פרטי הפיצ׳ר וה-events השונים שהוספנו. נעבוד איתו ביחד. נייצר ביחד את השאילתות, ננסה לגלות אם שכחנו משהו, אם יש עוד הזדמנות, ובעיקר - נעקוב אחרי ביצועי הקוד בעצמנו.
נסתכל על הAB-Test - כמה אנשים נכנסו וקיבלו כל וריאנט (אולי אין מספיק או יש באג בחלוקה?), איך הביצועים באופן כללית (האם אין נפילה משמעותית במטריקות החשובות לנו?) וכמובן האם הכל מתנהג כשורה - הזמנים לא התארכו, אין תקלות, המידע הנוסף שאספנו באמת מגיע בצורה שציפינו וכד׳.
נשב כולם ביחד שוב ונחליט מה עכשיו - במקום שמש, נפנה לדיאגרמת הסתעפויות. למעשה נצור שרטוט של התהליך שהיוזר עובר וכל מה שיכול לקרות. לדוגמא: הסתפעות ראשונה יכולה להיות מסוג ״יש עלייה בכמות הלחיצות על Gmail״, ומכאן נוכל להסתעף הלאה אל שתי אפשרויות: ״מסיימים/לא מסיימים את תהליך ההרשמה עם Gmail״.
הגיוני, נכון? ובכן, בטסטים יותר מסובכים יכולים להיות עשרות הסתעפויות, והסוד הוא להשתמש בדאטה בשביל לתעדף על מה להסתכל - כלומר כמה אנשים יעברו בכל ״מסלול״ ובאיזה אחוז משהו השתנה. דרך אגב, במקרה הזה אחזיר אותנו לשלב האפיון והתכנון - האם דאגנו לפזר events ברחבי הקוד שיעזרו לנו להבין יותר טוב את התרשים?
מהסתעפות זאת, אפשר להסתעף לעוד מקרים, לדוגמא, ״אנשים חזרו אחורה ונרשמו עם אימייל״ או ״אנשים עזבו את האתר״ וכד׳, אינסוף מקרים. על כל מקרה, לפי החשיבות, נחזור להתחלה ונייצר היפותזות ופתרונות. זה מעגל שמוביל את הצוות.
הדאטה הוא למעשה החיבור בין חברי צוות בעולם הפיתוח, ויש לו חלק משמעותי בכל הנוגע לתכנון, ביצוע ומעקב אחר פיתוח פיצ׳רים. אם נבין יותר טוב למה אנחנו עושים משהו ונהיה חלק מהפתרון, נוכל באמת להזדהות איתו ולמפות את מכלול השיקולים שנדרשים בעת הפיתוח ושחרור הפיצ׳ר. התקשורת תהיה טובה יותר, יהיו פחות ״פינות״ ותחושת האחריות תוביל להצלחה, במקרה הטוב, או לפחות להבנה מיידית של ״מה השתבש״ ו״מה לעשות״ עכשיו.
התהליך הוא מעגלי, ומשתפרים בו ככל שמתמידים. זה כמובן דורש זמן ותקשורת טובה בין חברי הצוות, הבנה של עולם הדאטה והמוצר וכמובן כלים רלוונטים שיסייעו בתיעוד, הצגה וניתוח של הדאטה, אך ברגע שהכל יתחבר, יבואו גם הנצחונות, מבטיח.
האזנה לפרק 
קריאת הבלוג 
צפייה בוידאו 
שאלות / פידבק
