על טכנולוגיה ופסיכולוגיה

מטרתו של המאמר היא לערוך לקוראים היכרות עם פיל. 

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

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

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

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

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

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

1. ליעל ולשפר את עבודת האוטומציה ואמינותה.
2. להפוך את האוטומציה נגישה לכל אחד ללא צורך בידע מקצועי בתכנות.

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

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

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

• לרב, המשכורות בפיתוח גבוהות יותר מאלו המשולמות ב QA
• בארגונים רבים כח האדם בפיתוח מנוסה יותר מבחינת ותק והכשרה
• (יש לא מעט ארגוני QA שנשענים על עבודת סטודנטים או עובדים זמניים)
• בהרבה חברות מקובל שמסלול הקידום של אנשי QA איכותיים הוא מעבר לפיתוח

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

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

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

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

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

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

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

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

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

האוטומציה – שדה קרב

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

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

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

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

סיכום

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

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

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

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

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

כי כמו שאמרנו:
לפתור בעיות מעולם הפסיכולוגיה באמצעות כלים מעולם הטכנולוגיה – זה לא עובד!