מתכנת שים לב: כך תעריך שעות עבודה בצורה נכונה

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

חכם, רשע, תם וזה שאינו יודע להעריך שעות

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

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

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

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

אז איך מעריכים שעות?

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

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

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

הכותב הוא מנהל פרויקטים בקבוצת CodeOasis המספקת שירותי פיתוח לסטארט-אפים וחברות בארץ ובעולם