להתחיל במקום חדש

English version

מצמצתי לרגע, ועברו חודשיים. 

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

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

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

עד כאן, הקשיים ההתחלתיים. 

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

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

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

1. בניית רשתות בטיחות וכלים שיאפשרו לצוותים לקבל מידה מסויימת של ביטחון במוצר שהם בונים. 
2. תוך כדי 1, צבירת מוניטין ושיפור התקשורת. 
3. בניית תהליכים שיעזרו לצוות הבדיקות לתקשר עם צוותי הפיתוח ולעזור להם בזמן אמת עם הפיצ'רים בניגוד למצב הנוכחי בו אנחנו מספיקים להגיע לפיצ'ר כשהוא בשלבי סיום. זה כנראה יצריך שימוש בחלק מהמוניטין שצברנו קודם. 
4. יצירת קהילת בדיקות, או לחילופין, סיפוח של כל הבודקים לצוות אחד לטובת יישור קו בכל מה שקשור לכישורי הבודקים ולאסטרטגיית הבדיקות, כמו גם יצירת ערוץ תקשורת נוסף בין הצוותים. 
5. אחרי שדברים מתחילים להתייצב - פירוק הצוות המרכזי והטמעת אנשי הבדיקות בתוך צוותי הפיתוח, כשהמטרה היא גם לשדר מידע החוצה, אבל בעיקר להכניס את תהליכי הבדיקות לתוך הצוותים על ידי חניכה פנימית של המפתחים וסיוע בהעברת האחריות על תחזוקת בדיקות המערכת מצוות חיצוני לצוותי הפיתוח. 
6. כנראה שיחד עם 5, הגדרה מחדש של צוות הבדיקות תחת כותרת אחרת. לפחות בתחילת הדרך, הצוות הזה יהיה אחראי על המשך תיאום בין הצוותים השונים וסיוע לבודקים השונים לא ללכת לאיבוד בתוך הצוותים החדשים שלהם. מהמרחק הנוכחי, הרעיון של Engineering productivity נשמע לנו מסקרן, כמו גם גלישה לצד של ניטור המערכת וייבוא מסקנות פנימה, אולי תחת מחלקת operations. אני חושב שיש לנו שנה-שנתיים (או יותר) לפני שנצטרך להתעסק בזה. 

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

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

זהו, פחות או יותר.

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