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