למידה נכונה של מוצר במקום עבודה חדש | ניסים אריאל

אתגר

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

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

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

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

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

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

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

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

שונויות

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

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

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

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

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

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

עיקרון מנחה

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

והייתי רוצה ברשותכם להציע קווים לדמותה של הלמידה הזו.

מתאר

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

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

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

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

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

חלקים

השלב הראשון בלמידה הוא החלק שעונה על השאלה – "מה זה", מה יש בפנינו. והוא יכלול שני חלקים: חלק ראשון Front וחלק שני Backend. החלק הראשון יתמקד בהבנה יסודית - מה התהליך שישנו בפנינו שמממש את מטרת המוצר, איך מתחילים מנקודה מסוימת ובסוף מקבלת את התוצאה הרצויה. זה אומר - מעבר על ה-Flow של המוצר end to end מספר רב של פעמים עד שהתהליך כולו יושב היטב בראש,  עד שכל שלב משמעותי בו עושה הגיון ברור בדרך למטרת המוצר. כמו כן, שרטוט ומיפוי של התהליך, תרשימי זרימה, התבוננות בהכרחיות כל חלקי בתהליך, ואחר כך – שאילת שאלות במידת הצורך. לאחר שמתחילה להתקבל תמונה ברוה יותר של המוצר יש לעבור להיכרות יותר מעשית עם המוצר - לעבור את כל ה-flow שלו באופן מעשי מקצה לקצה, לראות תוך כדי משחק איך כל חלק בונה את התהליך ולמה הוא הכרחי, פשוט לשחק עם המוצר עד שמתגבש ההיגיון שלו.

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

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

החלק השני יתמקד בהבנה של מה יש בארכיטקטורה כלפי התהליך. יש להכיר כמה דברים: את מערכת היחסים בין ה-client ל-server ברמת API, את מכלול החלקים המרכיבים את ה-Backend, אם זה אומר איזה חלק מקבל ערכים, איזה חלק מפעיל עליהם מתודות ומניפולציות, איזה חלק מאכסן אותם ומסדר אותם, איזה בסיס נתונים עובד ברקע – SQL או NOSQL, מה היחסים בין Data ל-Metadata  ומה מסדר אותם כיחידת output, מה הגישה שיש לכם כבודקים ביחס לחלקים האלה, עם איזה סביבת Cloud עובדים וכו', באיזה שפה כתוב ה-Backend וה-Front. יש לחתור למגע עם החלקים האלה מבחינה מעשית, אם זה אומר שאילתות SQL כדי לראות את הטבלאות, משתמש ל-AWS על מנת לראות איפה מאוכסנים דברים שונים ונתונים שונים. לא רק לדעת שזה קיים, אלא במידת האפשר לגעת בזה בפועל.

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

השלב השני בתהליך הלמידה ירד יותר ברזולוציה וייענה לשאלה – "איך זה עובד?" וגם הוא יכלול שני חלקים: חלק ראשון Front וחלק שני Backend. החלק הראשון יתמקד בקומפוננטות שבונות את המוצר ברמת ה-Front. יש לבצע מיפוי של כל החלקים שבונים את המוצר, ממש לרשום אותם בטבלה אחד אחד. אחרי כן לגשת לכל אחד מהם ולהשתמש בו, להתעסק בו, לבדוק את כל פרטי הפרטים שבו עד שהוא ברור, לגשת לשאול מה עושה זה ולמה זה ולסכם בכתב אם יש צורך.... יש לטחון את המוצר כמה שניתן להספיק end to end, ולהכיר היטב את כל הפיצ'רים והקומפוננטות, אפילו הייתי אומר להתחיל לבדוק אותם מעט. בתום השלב יש לשבת עם בודק וותיק וליישר אתו קו בנושא, מה הבנו ומה חסר ויש להשלים, בחלק הזה האחריות כבודק להחזיק עמדה וסבלנות באה לביטוי בצורה משמעותית. ברמת הזמן זהו החלק הגדול והמשמעותי.        

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

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

חלוקת הכח

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

סיכום

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

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

בהצלחה לכולם!