בודק מצטיין – טיפים לעבודת צוות ותקשורת טובה

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

 

עבודת צוות

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

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

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

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

 

נושא התקשורת מחולק לשני נושאים עיקריים:

  1. תקשורת בכתב

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

שלושה עקרונות חשובים בעת כתיבת דו"ח על באג הינם שלושת ה- "C":

1- בהירות (Clarity)– האם הדו"ח ברור ואין בו דו משמעות?

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

2- שלמות (Completeness) – האם משהו חסר?

  • תאר מה בדיוק קרה ומדוע זו בעיה.
  • הוסף מידע המסביר כיצד איתרת את הבעיה, כולל שחזור מלא של כל הנתונים והצעדים שבוצעו.
  • העזר בצילומי מסכים (screen shots) ועדויות נוספות.

 3- תמציתיות (Concision) – וודא שהמידע שייך ולא מרבה במילים, התמקד בפרטים החיוניים.

 

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

 

2. תקשורת בעל פה

בעבודתו של הבודק ישנן הרבה התרחשויות יומיומיות הדורשות ממנו את היכולת לתקשר ישירות עם בני אדם אחרים,

  • שאילת שאלות לגבי התוכנה ופירוש התשובות המתקבלות
  • ריאיון לתפקיד או משימה בפרויקט
  • הצגת סטאטוס משימות

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

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

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

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

 

לסיכום

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

 

 

 

תקשורת ושת"פ בניהול צוות בדיקות

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

במודל הפיתוח האג'ילי (בפרט בגישת ה – scrum) המבנה הארגוני של צוות הבדיקות אמור לסייע רבות ביצירת תקשורת בריאה וברמת שיתוף הפעולה בין צוותי הבדיקות והפיתוח. בגישה זו הצוות בדרך כלל יכלול: 2-3 מפתחים, מאפיין, נציג לקוח, בודק ור"צ (scrum master). ולכן, בעוד שבגישות הקיימות התקשורת בין צוות הבדיקות לשאר הצוותים היא בד"כ פורמאלית, הרי שבגישה זו עיקר התקשורת הינה ישירה ובלתי אמצעית. מעבר לכך, גם האחריות על הבדיקות הינה של כל הצוות ולא רק של הבודק ולכן התקשורת מטבע הדברים תהיה יותר פשוטה וקלה לניהול.

 

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

 

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

 

להלן כמה טיפים לניהול שיחות קשות:

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

 

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

רוצים לשמוע עוד? דברו איתנו

מלאו פרטים ונחזור אליכם בהקדם