אני רוצה רגע להידחף
קודם כל, חשוב לי לומר - כל מה שאני עומד לכתוב כאן אינו הערה אישית, כי אני לא מכיר אותך, או את החברה, ואין לי מושג ירוק מה הציפיות שלהם ממך.
 
עם זאת, אני כן מזדהה (לא מעט אפילו) עם התחושה הכללית של קובי - בודק תוכנה יחיד בחברה, לא משנה איך עוד קוראים לו, הוא מנהל הבדיקות בחברה. יש לו מנהל אישי, אבל הוא הסמכות המקצועית העליונה בכל מה שקשור לבדיקות תוכנה. למה? כי אין אף אחד אחר בסביבה. בכנות, עם חמש וקצתשהו שנות ניסיון - אני יודע לומר שמשימה כזו גדולה עלי בחצי מידה (תרגום - אני די בטוח שאני יכול להתמודד איתה, אבל אני יודע שההתחלה תהיה קשה ומלאה טעויות). אני יודע לומר שלפני שלוש שנים, משימה כזו הייתה גדולה עלי בסדר גודל או שניים (תרגום - הייתי מפשל שם בצורה כואבת). יותר מזה, הודות לאפקט dunning-kruger- לפני שלוש שנים גם הייתי פחות מודע לפער הזה. (אילוסטרציה -
https://understandinginnovation.files.wordpress.com/2015/06/dunning-kruger-0011.jpg?w=640 ).
 
כאשר סטארט-אפ מפרסם מודעת גיוס לבודק תוכנה ג'וניור, הוא אומר "מה שחשוב לי מבודק תוכנה הוא מדרגת שכר נמוכה". האמירה הזו, בלי קשר למי שנשכר, מצביעה על בעיה נפוצה הרבה יותר מדי של הבנת הערך שאמור להגיע מבדיקות תוכנה. לכן, כיוון שכל אחד יכול להיות בודק תוכנה ואין ערך בהתמקצעות (כך על פי התפיסה הבעייתית), אפשר לתפוס מישהו עם מעט ניסיון וזה יוסיף את אבקת הקסם שאנחנו צריכים.
לכן, כאשר סטארט-אפ עושה כזה דבר, מדובר בזילות של מקצוע הבדיקות. בלי שום קשר למי שמאייש את המשרה.
 
הדבר השני הוא מצד העובד - עם שנתיים ניסיון, אני מניח שיצא לך להיתקל כבר בדברים שעובדים עקום "כי ככה כתבו את זה פעם, ועכשיו יקר מדי לשנות את זה" (או, כמו שקוראים לזה אצלנו "מסיבות היסטוריות"). הטעויות שתעשה בתחילת הדרך (וכולם עושים טעויות) ייגררו לאורך לא מעט זמן. הדרכים בהן תפעל יגדירו תהליכים ויצרו הרגלים אצל כולם (כולל, אגב, את הציפיות משאר הבודקים שאולי יגייסו בעתיד - כבודק תוכנה יחיד, אתה צריך ליצור רושם של סופרמן). אין לי ספק שאתה תלמד המון בתהליך הזה, ואין לי ספק שתעשה גם לא מעט דברים טובים. אבל כשאתה מקבל משרה כזו, הסיכון שאתה מציע לעסק לקבל (והעסק, שבמקרה הגרוע, לא מבין חצי דבר בבדיקות תוכנה, מקבל בלי להבין) די משמעותי - תהליכי בדיקות שלא מתאימים למוצר המפותח יכולים לגרום למגוון בעיות -
האטה בקצב הפיתוח, בזבוז זמן על תיקון דברים מיותרים, הכנסה של שגיאות נוספות לתוך המערכת, ומרמור כללי במקום העבודה. המקרה הגרוע ביותר של פרוייקט בדיקות שנכשל איננו "מפטרים אותי", אלא "המקום בו אני עובד קורס". נשמע קצת פטאלי, אבל במקומות קטנים, ההשפעה של כל אדם גדולה מאוד. במקרה היותר נפוץ, הטעויות שתעשה יעלו לחברה לא מעט כסף לאורך הזמן.
הגדרת תהליכים היא עבודה קשה מאוד (אנחנו כרגע מגדירים תהליכים בצוות, עם לא מעט אנשים מנוסים למדי ובהקשר שאנחנו מכירים היטב, ואנחנו מזיעים לא מעט בתהליך הזה), ואני מוכן להבטיח לך שאם תסתכל לאחור בעוד שנה מהיום, יהיו לא מעט דברים שתאמר עליהם "בדיעבד, הייתי צריך לפעול אחרת". במיוחד, אגב, במקומות בהם תשים לב שהגדרת תהליך בלי להתכוון לזה - פשוט על ידי איך שעבדת.
 
כאשר שולי הטעות נמוכים (אין לסטארט אפ רזרבות תקציביות כמו שיש לחברה גדולה יותר, וכשיש לך רק מוצר אחד ורק צוות אחד, המוצר הזה לא יכול לקרטע בלי להפיל את החברה), הבחירה האחראית היא למצוא מישהו שכבר עבר סבב אחד של טעויות כאלה ויודע לא לחזור עליהן, או לפחות למצוא מישהו שראה מקרוב את הבחירות ואת הטעויות שעשו אחרים ולמד מהן. כשאתה מקבל משרה כזו ואין לך את הרקע הזה, שים לב למשקל שמונח לך על הכתפיים.
 
אחרי שאמרתי את זה - אני עדיין מאחל לך בהצלחה, ואם יהיו לך שאלות או התלבטויות, אשמח לנסות לעזור (ואני בטוח שגם קובי ישמח לתרום עצה או שמונה).
 
(ובלי קשר, המלצה, מחק את המילה "איכות" מהמילון שלך, אם איכות תהיה רק הבעיה שלך, הפרוייקט ייכשל לפני שתספיק לומר ג'ק רובינזון)
