ראיון עם מנהל QA בכיר

ראיינו את רונן יוריק, עד לאחרונה דירקטור QA בחברת supportspace וכיום שותף ו CEO בחברת AutoJedi – המתמחה בבדיקות תוכנה.

מה עיקר חשיבות תפקידו של מנהל QA ?

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

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

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

מהם האתגרים בתפקיד ?

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

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

עיקרי תפקידם של אנשי הQA בחברה:

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

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

3.  גוף ה QA הוא צומת מרכזית בחברה, במקום בו צוות ה QA חזק, כולם יבקשו את השירותים שלו, לדוגמא ב supportspace כולם רצו שירותי QA לא רק צוות הפיתוח.

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

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

האם צוות QA יכול להיות צוות מוביל?

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

האם המחלקה נתפסת כוועדת ביקורת או כתרומה גדולה לפיתוח?

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

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

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

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

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

מהי תפיסתך הניהולית בחברה ?

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

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

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

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

האם אתה מעריך כי השכר והתגמול לאנשי ה QA הינם בהתאם לתרומתם?

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

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

Images courtesy of digitalart / FreeDigitalPhotos.net