תמחורים, בדיקות ותרגילי נשימה

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

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

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

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

ראשית בואו נבין מהו תמחור?

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

מתי אנו נדרשים לתמחר?

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

מדוע אנו מתמחרים בדיקות?

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

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

כיצד נעריך את זמני הבדיקות?

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

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

בשלב א – תתקיים פגישה בהשתתפות מנהל הפרויקט ומפתח.

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

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

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

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

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

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

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

אז עם מה אנחנו מתמודדים? מהם המרכיבים של אותה דרישה?

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

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

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

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

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

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

וכמובן הכי חשוב... 

.