בוגר מחזור י׳ הנדסת תוכנה בטכניון, מיכאל רבינוביץ' מנחה את הפרוייקט הטכנולוגי בטכניון מטעם ארגון הבוגרים. המטרה כאן היא גם להכיר לחניכים בוגר נוסף מקרוב, דרך ההתנהלות וההתייעצות עמו כמנחה, וגם לתת אימפקט חברתי אמיתי דרך הנגשת כלים טכנולוגיים לאלו שלא יצליחו להגיע אליהם בצורה אחרת.
ישבתי איתו לשמוע על התהליך שעברו החניכים ושכדאי מאוד שכולנו נעבור כדי להיות מפתחים טובים יותר.
כמיטב המסורת, אני אשמח אם תספר לי על המסלול שלך.
המסלול שלי אולי מתחיל שנה ומשהו לפני התואר.
כנער בתיכון הייתי חנון די טיפוסי. לצד הרבה משחקי מחשב, אומנם הייתי מעורב בכמה פעילויות חברתיות אבל האינטרקאציה עם אנשים אחרים תמיד דרשה מידה של מאמץ מודע ולרוב לא הייתה נינוחה.
החלטתי לעבוד על זה דרך שנת שירות שתכריח אותי לעבוד עם אנשים בסקייל רציני, ומפה לשם מצאתי את עצמי בשנת שירות בקומונה בקריית טבעון, ממש ליד הבית שלי. זה אמנם לא בדיוק סיפור מרגש של יציאה מהבית, אבל זה אפשר לי ולשאר חברי הגרעין שלי (כולנו מטבעון) להיכנס ישירות לעניינים היות וכבר הכרנו את הקהילה שבה מצופה מאתנו לפעול.
עבדתי בבקרים בהוראה בחטיבת הביניים ואחר הצהריים הייתי מדריך קבוצות שונות מבתי הספר בישוב (במצטבר עבדתי עם בערך 60 חניכים אחר הצהריים, רובם בכיתות ח' עד י').
בכל ערב היינו יושבים בקומונה ומדברים על תפיסות חינוכיות וחוויות מההדרכה, ומשם התחילה ההתמקצעות שלי בחינוך בלתי-פורמאלי והעניין שלי בתקשורת של אנשים.
אני חושב שזו הייתה השנה הראשונה שבה באמת למדתי לעבוד עם אנשים, וזה לימד אותי באיזשהו מקום גם להעריך יותר את עצמי. גיליתי שאני מסוגל להיות ממש טוב בהתנהלות שלי עם אנשים אחרים. זה אמנם הצריך מאמץ מודע, אבל זה אפשרי.
את הכלים האלה ואת אלו שהתפתחו מאז בעזרת הבסיס הזה הבאתי גם לפרוייקט השנתי עם החניכים, כדי ללמד אותם את הכישורים הרכים שהופכים קוד מאנקי או מהנדס מנותק למפתח טוב.
אז מה הכישורים האלו ומה כל כך חשוב בהם?
אני רחוק מלהיות טכנולוג על חלל, אבל הערך המוסף שלי הוא לחבר את הטכנולוגיה לאנשים. להיכנס איתם לפרטים, להבין מה הם באמת צריכים (להבדיל ממה שהם יודעים לבקש) ולוודא שאנחנו נותנים להם ערך בטווח זמן רלוונטי.
למעשה במהות שלי אני בא לספק פתרונות בעזרת תוכנה. אני אוהב כלים וטכנולוגיות, אבל יותר מעניין אותי מה הערך שאפשר להביא ואיך לעשות את זה הכי ענייני.
וזה נשמע טריוויאלי, הרי כולם רוצים לתת ערך. אבל לעיתים קרובות מדי נוצר מצב שיש לך אנשים טכניים חזקים שרוצים להגיע לכל מקרי הקצה ולא יודעים לעצור ולתת מוצר מספיק טוב, או את אלה שרוצים רק לעשות POC וללכת הביתה.
אבל לרוב אנשים בכלל לא מאתגרים את הלקוח ומנסים לחקור מה הוא באמת צריך. זו מיומנות נפרדת.
הלקוח לא תמיד מבין בטכנולוגיה, והוא לא בהכרח יודע איך לנסח דרישה. הוא כנראה לא חושב כמו מתכנת ולא מחזיק מודל מידע טבלאי בראש שלו שאחר כך אפשר לממש בקוד. את כל הדברים הללו צריכים לתשאל ולדלות ממנו.
אנשים לא מדברים על הכישורים הרכים האלה כמשהו שהוא קריטי ולא מכשירים לדבר הזה ברוב המקומות, שזה חבל.
אני גם לא חושב שזה דבר שקשה ללמוד, אפשר לראות את זה בקלות בפרוייקט השנתי שעשינו.
ספר לי עוד על התהליך שעשית עם החניכים במהלך הפרוייקט.
אם היית מסתכל מהצד על פגישת הלקוח הראשונה שלנו בסמסטר א', היית רואה בעיקר אותי מדבר עם הלקוחות ומסכם, כשהחניכים פחות מעורבים. בסוף הפגישה הסטודנטים עוד הסתכלו עלי המומים ואמרו "אנחנו לא הבנו שום דבר ממה שהלקוחות אמרו. איך הגעת מכל זה לרשימה ברורה של דרישות?".
זה ברור וטבעי שהסטודנטים התחילו ממצב של לא לדעת איך לדבר עם לקוחות (וגם לא איך לעבוד בגיטהאב ולקבל Code Review ולמעשה שום דבר). אז התחלנו בללמוד את ה flow הבסיסי באופן פרונטאלי.
אחר כך היה לנו שלב לימוד טכנולוגיות לצורך הפרוייקט שהסטודנטים עברו באופן עצמאי אחרי הכוונה נפלאה של בוגר פסגות נוסף (תודה גדולה לאורי מרקוביץ'), למשל כדי ליצור דאשבורדים אסטתיים ללקוחות.
אחרי השלב הזה, השאלה הגדולה הייתה "מתי אפשר להעביר גרסא ראשונה ללקוח ומה יהיה בה".
למזלנו, כבר בפגישה הראשונה היה יחסית ברור לנו מה סט הדרישות המינימאלי שיאפשר לנו להתחכך עם המידע של הלקוחות שעתיד להיות לב המערכת שלנו.
זה היה ממש נחמד להגיע לנקודה הזו תוך חודש וחצי ולהחיל לקבל משוב מהלקוחות שזה באמת נתן להם ערך.
כמובן שאחרי ששחררנו את הגרסא השאלה הבאה הייתה "מה אנחנו יכולים לשפר באופן איטרטיבי?"
ככה המשכנו.
ברקע של כל זה היה תהליך למידה של הסטודנטים בכל מה שקשור לכישורים רכים ותקשורת עם הלקוחות.
את הפגישות הראשונות אני ניהלתי גם לו"זית וגם דיונית. כל מייל ללקוח היה עובר mail review דרכי, כדי שלא יהיו פאשלות מביכות (משהו שלמדתי את הנחיצות שלו אחרי הרבה "תקריות דיפלומטיות" שאני גרמתי עם מיילים לא מפוקחים בצבא, והרמ"ד שלי היה צריך לפתור).
חווינו הרבה תסכול בהתחלה גם בכל מקום שבו גילינו שלא הבנו את דרישות הלקוח כמו שחשבנו.
עם הזמן הגענו למצב שבו אני רק מזמן ופותח את הפגישה אבל לא מדבר מעבר לתיווך. גם הסטודנטים למדו להיות פחות מתוסכלים מאי בהירות בדרישות ולהשאיר יותר זמן לתיקונים הנדרשים.
בכל מקום שבו הייתה אי הבנה לגבי הדרישות, הייתה לנו הזדמנות לשקף ללקוחות בצורה ברורה - האם הם מעדיפים להשאיר כאן בעיה פתוחה ולהתקדם לפיצ'ר הבא, או להתעכב על התיקון כי המערכת לא תיתן ערך אם זה לא ישתפר.
בסוף השנה הסטודנטים כבר היו מסוגלים לארגן בעצמם את רוב הפגישות מול הלקוח (גם הניהוליות וגם הטמעת תכולות חדשות), אפילו בלי נוכחותי.
בנושא הפוליטיקה הארגונית, הקפדנו גם ככל האפשר שאם יש בשורות רעות, עדיף שאני אהיה זה שיבשר אותן כדי למנוע דם רע בין המשתמשים וצוות הפיתוח.
בסמסטר ב' הם כבר שחו בחומר, וכמעט ולא הייתי צריך לדבר במפגש עם הלקוחות, שזו ההצלחה האמיתית.
ואיך אתה מתאר את החוויה שלך כמנחה בינתיים?
אני נהניתי, וזה הרגיש משמעותי, בעיקר מול הסטודנטים, אבל חשוב להגיד שאנחנו עדיין לא בטוחים במבנה של העניין הזה.
באיטרציה הזו הפרוייקט נחשב כפרוייקט תעשייתי שבאופן מפתיע התארך לשני סמסטרים. באיטרציה הבאה אנחנו נעשה את זה כפרוייקט שנתי מלכתחילה.
זה נתן לכולנו המון סיפוק להגיע עד ללקוח, לראות אותו משתמש במוצר, מקבל ערך, מופתע מהטכנולוגיות ומקבל תיאבון לדברים חדשים.
קחו בחשבון שזה לא היה קלי קלות. זה יכל לקחת ממני קשב של בערך שעתיים בשבוע, אפילו יותר כשהיינו מבקרים את הלקוחות בצפת.
זה ממש מספק לראות את החניכים ואת התוכנית עצמה נותנים ערך לקהילה. לפחות עבור מי שמחפש את המעורבות החברתית הזאת. אם לא, אז יהיה לכם כיף יותר לפרוש איזה קרנל וזה לגמרי בסדר.
בטווח הארוך - אם השנה הבאה תעבור בצורה טובה, היכולת שלנו לתת אימפקט טכנולוגי אמיתי על החברה תהיה מאוד גדולה.
רק תחשוב על זה שיש 2 סניפים של פסגות תוכנה, ועם עוד כמה מנחים נוכל להרים 2-3 פרוייקטים כאלו בשנה. בגלל שאנחנו כבוגרים אחראיים נישאר בסביבה זה אומר שנוכל גם להעביר אותם משנה לשנה במקום לתת להם למות בקיץ כשהחניכים מתגייסים ועוברים הלאה. רק תדמיין מה נוכל להשיג לאורך זמן ואיזה ניסיון זה ייתן לכל מי שעובר דרך הפרוייקט הזה.
מה המסר שלך לדורות הבאים?
בגדול - דברו עם אנשים.
אל תסמכו על המבנה ההיררכי של הארגון כדי שייצג את התקשורת הכי יעילה מול הלקוח.
בצבא חוויתי פעם סיטואציה שבה הדרישות היו צריכות לעבור מהרמ"ד של הלקוחות לרמ"ד שלנו ולחלחל חזרה למטה במעין טלפון שבור מעוות. אין שום סיבה שדרישות הלקוח יעברו דרך 5 מתווכים וכמובן ישתנו לחלוטין בדרך.
בנוסף לזה כשאין תקשורת ישירה נוצרת נטייה למפתחים להתייחס ללקוחות כמו לאידיוטים וללקוחות להתייחס למפתחים כאל חייזרים.
העצה שלי היא שתלכו לדבר עם אנשים פנים אל פנים (או זום לזום).
לקוחות שמרגישים בנוח לבוא ולבקש פיצ'רים ולהתלונן על באגים אמנם יוצרים עוד עבודה, אבל זה אומר שיש להם אמון בך כמפתח או כצוות והם מצפה שתוכלו באמת לעזור להם.
אז תדברו עם אנשים, ואזהרה חמורה - אם המקצוע שלכם הוא לא מחקר טהור, אתם תצטרכו לדבר עם אנשים.
ואם כבר צריך, אז כדאי שתלמדו להיות טובים בזה!
לפרידה, מיכאל השאיר את החוקים שהוא ניסח עם הצוות שלו, והוא מזמין גם אתכם לחשוב, מה החוקים להתנהלות אחראית בצוות שלכם?
