פרויקט חדש יוצא לדרך עם תאריך השקה בלוח. בפגישת הפתיחה כולם מסכימים שהלו"ז סביר. שלושה שבועות לפני התאריך מתברר שמסך התשלומים תלוי בספק חיצוני שעוד לא נתן גישה לסביבת בדיקות, ושמנהל המוצר והמנכ"ל מבינים אחרת את המשמעות של "דוחות בזמן אמת". התאריך זז, והפעם הראשונה שמישהו קורא לזה "עיכוב" היא כבר הרביעית שהוא זז.
התרחיש הזה מוכר כמעט לכל מי שניהל פיתוח. בדרך כלל אף אחד לא התעצל ואף אחד לא כתב קוד גרוע. העיכוב נקבע הרבה לפני כן.
העיכוב נולד בשבועות שלפני הקוד
פרויקט שמתחיל בלי אפיון ברור כמעט תמיד מגלה את החורים באמצע הפיתוח, כשכל תיקון יקר פי כמה. מפתח שמגלה בשבוע השישי שיש שלוש דרכים שונות לפרש דרישה צריך לעצור, לשאול, לחכות לתשובה ולשנות עבודה שכבר נעשתה. את זמן ההמתנה אף אחד לא כלל בהערכה.
לכן ההשקעה הכי משתלמת בפרויקט היא הזמן שמשקיעים לפני שמתחילים לפתח. אפיון טוב לא מבטיח שהכל יעבוד חלק, אבל הוא מוציא החוצה את השאלות הגדולות כשעוד זול לענות עליהן.
שבע סיבות שחוזרות
1. דרישות שכל אחד מבין אחרת. משפט כמו "המשתמש יוכל לנהל את ההזמנות שלו" מכסה יום עבודה או חודש, תלוי מי קורא אותו. אם אי אפשר לכתוב עליו קריטריון קבלה אחד שאפשר לבדוק, הדרישה עוד לא גמורה.
2. תלויות חיצוניות שלא נבדקו. ספק תשלומים, מערכת CRM של הלקוח, API של גורם ממשלתי או בנקאי. הזמן שלוקח לקבל גישה, מפתחות ואישורים לא מופיע בשום הערכה של מפתח, והוא יכול לעמוד לבדו על שבועות.
3. החלטות שמחכות לאדם אחד. כשמפתח צריך תשובה ומי שמחזיק בה נמצא בפגישות עד יום חמישי, כל שאלה עולה ביום עבודה. פרויקט עם עשרים שאלות כאלה מאבד שבועות בלי ששום דבר "נתקע" רשמית.
4. הערכה כמספר יחיד. "שישה שבועות" נשמע החלטי, אבל הוא מסתיר טווח. הערכה בוגרת אומרת מה סביר, מה המקרה הגרוע, ומה הידוע והלא ידוע שמפריד ביניהם.
5. הרחבת היקף בהדרגה. כל בקשה קטנה נראית סבירה בנפרד. יחד הן מוסיפות פרויקט שלם, ואף אחד לא החליט על כך במפורש. מי שלא מנהל רשימה של "מה נכנס ומה יוצא" מגלה את זה בדיעבד.
6. בדיקות בסוף. כשה-QA מתחיל רק אחרי שהפיתוח "גמור", כל באג שהוא מוצא חוזר למפתח שכבר עבר לנושא אחר. הסבב הזה נוסע בין צוותים ומתארך.
7. הכל בגרסה הראשונה. הצוות מנסה לבנות את המוצר המלא ולא את הגרסה שמלמדת משהו. MVP שמוגדר היטב מקטין סיכון, כי הוא מביא תשובות אמיתיות מוקדם.
בפרויקטים שאנחנו מקבלים לניהול, הדפוס הזה חוזר: הצוות מתחיל לכתוב קוד, ובאמצע הדרך מתברר שממשק לשירות חיצוני עובד אחרת ממה שהניחו, או שהגדרה עסקית אחת פתוחה לשתי פרשנויות. לכן אנחנו מתחילים כל פרויקט ברשימת תלויות ושאלות פתוחות, וסוגרים כל אחת מהן לפני שהיא חוסמת עבודה.
רשימת בדיקה לפני שמתחילים
שעה שמקדישים לרשימה הזו בפגישת פתיחה חוסכת בדרך כלל שבועות בהמשך. היא לא דורשת כלים מיוחדים, רק מסמך משותף ונכונות לומר "עוד לא יודעים" כשזה המצב.
לפני שמסכימים על תאריך, כדאי לוודא שיש תשובה לכל אחד מהסעיפים:
- לכל פיצ'ר מרכזי יש קריטריון קבלה שאפשר לבדוק, ולא רק תיאור כללי.
- כל התלויות החיצוניות ברשימה אחת, עם שם של אדם אחראי בצד השני ותאריך שבו מקבלים גישה.
- מי מחליט על מה, ומה זמן התגובה המצופה ממנו. אם לא ברור, זה יתברר בשבוע הרביעי.
- מה לא נכנס לגרסה הראשונה, כתוב. רשימת ה"לא" חשובה כמו רשימת ה"כן".
- הערכה כטווח, עם הנחות מפורשות. כשהנחה מתבררת כשגויה, יודעים בדיוק איזה חלק מהלו"ז מושפע.
- הגדרה של "גמור": מה צריך לקרות כדי שמשימה תיחשב סגורה, כולל בדיקה.
סימנים מוקדמים שהלו"ז בבעיה
אין צורך לחכות לתאריך כדי לדעת. יש כמה סימנים שמופיעים שבועות לפני:
- משימות שנשארות ב"בתהליך" יותר משבוע בלי הסבר ברור.
- שאלות פתוחות לאותו אדם שחוזרות בכל סבב יומי.
- הדמו שבסוף שלב מראה מסכים ולא תהליך שלם שרץ מקצה לקצה.
- ההערכה של הפיצ'רים הבאים מתחילה להיאמר בנימה של "נראה", ולא כמספר.
- רשימת הבאגים גדלה מהר יותר ממה שסוגרים.
כל אחד מהם בנפרד יכול להיות רעש. שניים ביחד הם סיבה לעצור לשעה ולשאול מה בדיוק חוסם, ומי יכול לפתור את זה היום.
מה עושים כשהעיכוב כבר קרה
הטעות הנפוצה היא להוסיף עוד מפתחים. בפרויקט שמתעכב בגלל דרישות לא ברורות או תלות חיצונית, הוספת אנשים מגדילה את עלות התיאום ולא מזיזה את הצוואר בקבוק. קודם מזהים מה בדיוק חוסם, ואז מחליטים אם הפתרון הוא החלטה, גישה, חיתוך היקף או אנשים.
חיתוך היקף הוא הכלי הכי מוערך פחות. פיצ'ר שמשפיע על עשירית מהמשתמשים ועולה שלושה שבועות עבודה יכול לצאת בגרסה הבאה, והשחרור לא נפגע.
לפרק את הפרויקט לשלבים שאפשר למדוד
פרויקט שמתוכנן כארבעה חודשים רציפים מגלה בעיות בחודש הרביעי. פרויקט שמחולק לשלבים קצרים, שבכל אחד מהם יש תוצר שאפשר להריץ ולהראות, מגלה אותן כבר בשבוע השלישי. זה ההבדל בין עיכוב של שבוע לעיכוב של רבעון.
כדאי גם לשים בשלב הראשון את החלק הכי מסוכן ולא את הכי נעים. אם האינטגרציה עם הספק החיצוני היא מה שיכול להפיל את הלו"ז, מתחילים ממנה. כך מקבלים תשובה על עצם האפשרות כשעדיין יש מרחב תמרון.
איך אנחנו עובדים על זה
בפרויקטים שאנחנו מנהלים בשיטת מיקור חוץ, התהליך מתחיל באפיון ודרישות ולא בצוות. אחריו מגיעה תוכנית עבודה עם לוחות זמנים שאנחנו מתחייבים אליהם, ורק אז מרכיבים את הצוות. הפיתוח עצמו נעשה בשלבים, מתחיל ב-MVP וחותך זמן ופיצ'רים שאין בהם צורך, ואחריו QA, שחרור, הטמעה ותפעול.
בכל שלב יש תוצר שהלקוח רואה ומאשר, כך שסטייה מהתוכנית מתגלה כשהיא עדיין קטנה. כשנדרש שינוי, אנחנו מציגים אותו כהחלטה: מה נוסף, מה יוצא, ומה ההשפעה על התאריך. ההחלטה נשארת של הלקוח, אבל היא מתקבלת בעיניים פקוחות.
הסדר הזה קיים בדיוק בגלל הסיבות שלמעלה. תוכנית עבודה שנבנית על אפיון חלש היא תחזית, ולא התחייבות.
השורה התחתונה
עיכובים בתוכנה הם בדרך כלל תוצאה של החלטות שנדחו, תלויות שלא נבדקו ודרישות שלא הוגדרו, ופחות של איכות העבודה של המפתחים. מי שמשקיע את השבועות הראשונים בהוצאת השאלות הקשות לאור, מקצר את הדרך יותר מכל כלי ניהול. ההערכה הטובה ביותר היא זו שאומרת בכנות מה עדיין לא ידוע.
אם אתם מעדיפים שמישהו ייקח על עצמו את האפיון, תוכנית העבודה והמעקב אחריה, אפשר לקרוא על מודל מיקור החוץ.
