"הגעת ליעד" – האמנם?

בפרויקט ישנם לרוב מספר סוגי יעדים:

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

ככל שהיעד קרוב יותר יש חשיבות גדולה יותר להגדרתו בצורה ברורה ומדויקת. 

למה זה כל כך חשוב להגדיר יעד ברור למשימת הפיתוח הקרובה?

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

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

עוד צרות שניתן למנוע בעזרת הגדרת יעדים טובה:

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

 

הנה דוגמה להגדרות יעד שונות של אותו הפרויקט:

יעד: שיפור בשביעות רצון לקוחות מהפיצ'ר החדש של הזמנות אונליין.
האם היעד ברור? אם אתם אנשי הפיתוח האם אתם מבינים מה מצופה מכם? יודעים מתי לעצור?
ממש לא!
מה בכלל הנושא פה – ביצועי הפיצ'ר או שביעות רצון הלקוחות? יתכן שהפיצ'ר החדש יעבוד בצורה מדהימה ושביעות הרצון תהיה נמוכה בגלל תנאי הרכישה או המחיר.
ויתכן ששביעות הרצון תעלה בגלל שהורדנו מחירים למרות שהפיצ'ר של המכירות צולע. איך אנו בכלל מודדים שביעות רצון לקוחות, ואיזה שיפור אנו רוצים להשיג של 10% או של 50% ?

הנה ניסוח משופר:
הפיצ'ר החדש של הזמנות אונליין מקבל תעבורה של לפחות X כניסות תוך Y ימים (כפי שהיה בפיצ'ר הקודם) + תלונות שהיו בעבר על הפיצ'ר הקודם לא חוזרות על עצמן (בדיקה יומיומית של כל התלונות שנפתחות בנושא קניות אונליין למשך שבועיים) + הפיצ'ר ממשיך לעבור ריצות לילה ובדיקות רגרסיה XYZ .

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

 

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

 

הגדרת היעד בשפת ניהול הפרויקטים נקראת:

Definition of Done או בקיצור DOD

הגדרת היעד תעשה באמצעות מענה לשאלה – מה זה אומר  DONE . מה זה אומר שהמשימה בוצעה? מה יהיה חדש ושונה מבחינת הלקוח / המשתמש.

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

הנה כמה דוגמאות של DOD:

• הפיצ'ר החדש מותקן בסביבת WEB ורץ 5 שעות בלי עצירה.
• בסיס הנתונים קולט 3G רשומות בקצב X ונשאר יציב.
• מערכת האבטחה שלנו עומדת ב-5 שעות של סימולציית התקפה מסוג Y.
• חבילת טסטים X וגרסת מוצר Y רצים באוטומציה 24 שעות בלי ליפול.
• הכרטיס עובד במתח X , במוד Y במשך 10 שעות ולא מגיע לטמפרטורה Z.

יחד עם הלקוח

• יש חשיבות מאד גדולה לשוחח עם הלקוח, להציג לו את ה- DOD שניסחנו ולבקש פידבק.
• לפעמים יש הבדל בין הלקוח לבין המשתמש (כמו בטיטולים למשל, או במוצרים שאינם OEM) – יתכן שנכון יותר להגדיר יעד על פי משוב מהמשתמש.
• אם אין אפשרות לקשר עם הלקוח/משתמש, שוחחו עם מי שמכיר אותם ואת הצרכים שלהם הכי טוב. זה יכול להיות CEO, CTO , הביזנס, וכדומה.
• אם אין לכם לקוח/משתמש אחד בודד, בחרו אחד באקראי או מדגמית.

הבנו למה, עכשיו איך?

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

טכניקות להגדרת היעד (DOD)

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

 

1. Acceptance Criteria או בקיצור ACC

כדי לסייע לנו לנסח את היעד, את ה- DOD בצורה ברורה וחד חד ערכית אנחנו עושים שימוש בתבניות. התבנית עוזרת לנו לנסח "מבחן קבלה" או "קריטריון קבלה" – Acceptance Criteria.

הדבר דומה להקמת עמדת ביקורת טיב QA , בסוף קו ייצור. אם אנחנו מייצרים טבליות שוקולד אז בסוף קו הייצור יעמוד איש QA ויבדוק מדגמית: משקל מינימום: 100 גרם, רמת צמיגות: בין X ל Y, ריכוז גלוקוז: בין ערך A לערך B וכו'.

הקריטריון ינוסח באופן הבא:

Given –> When –> Then

התרגום המילולי בעברית:

בהינתן -> כאשר -> אז

הסבר:

בהינתן / GIVEN – מתאר את נקודת המוצא, מצב המוצא של המערכת, את הסביבה, הרקע.

כאשר / WHEN – תיאור של ההתנהגות או האירוע או הפעולה הנידונה.

אז / THEN – מה התוצאה הרצויה בעקבות אותה התנהגות/אירוע/פעולה.

דוגמאות:

• בהינתן שנפתח חלון הכנסת ססמה כאשר המשתמש מקליד ססמה שאינה נכונה אז תתקבל הודעה שגיאה בנוסח "ססמה שגויה, נסה/י שוב".
• בהינתן לקוח שרכש כרטיס אונליין, כאשר מתקבלת בקשה לביטול עסקה ולא עברו 48 שעות ממועד העסקה אז הפעולה תקבל סטטוס "אושר" ותתחיל פעולת "ביטול עסקה".
• בהינתן סביבה WEB עובדת ברקע, מרגע שהפיצ'ר החדש מתחיל לרוץ, לא תהיה נפילה של המערכת במשך 5 שעות לפחות.
• בהינתן בסיס נתונים עם לפחות 4G מקום פנוי, כאשר המערכת קולטת 3G רשומות בקצב X , אז לא יהיו נפילות.
• בהינתן מערכת אבטחה רצה ברקע, כאשר סימולציית התקפה מסוג Y רצה במשך 5 שעות, אז לא תתקבל התראה מסוג "חדירה למערכת".

 

2. איך נראה היעד

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

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

 

3. מבחן האורח

נכון שאומרים שאורח לרגע רואה כל פגע? כאן אנו מנצלים זאת לטובתנו!
בקשו ממישהו מחוץ לצוות לשמוע/לקרוא את ה- DOD שלכם ותשאלו אותו מה דעתו, מה הוא/היא הבינו. יש להם שאלות – מעולה! זכיתם! השאלות יכולות לרמוז על בעיות בהגדרת ה- DOD.

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

4. טכניקת ברור כוונות

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

אבל לי אין את התמונה הזו… לכן אני שואלת "למה הכוונה?"
הם עונים ואז בהתייחס לתשובה שלהם אני שוב שואלת "למה הכוונה?" , וכך שוב ושוב (כן, כן, אני חופרת חחחח).

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

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

 

סיכום

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

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

ככל שניטיב להגדיר את היעד ולדייק בו – כך נגדיל את הסיכוי שלנו להגיע אליו.

 

בהצלחה!
רוצים עזרה בניהול הפרויקט?  צרו קשר: PMinHebrew@gmail.com .