ההערכה לוקחת 15 עד 30 דקות. אבל היא הופכת את השאלה "אפשר להוסיף את זה?", שבתיאוריה התשובה עליה תמיד כן, לשאלה "זה שווה 3 שבועות נוספים ו-37,000 ש״ח?". וזו כבר החלטה עסקית.
2. MoSCoW עם שיניים
MoSCoW (Must have, Should have, Could have, Won't have, כלומר חובה, רצוי, אפשרי ולא עכשיו) היא שיטה שכולם מכירים ומעטים מקפידים עליה. רוב הצוותים מסמנים הכול כ-Must have, כי אף אחד לא רוצה להיות זה שהוריד בעדיפות את הפיצ׳ר של מישהו אחר.
הפתרון: הצמידו תקציב. אם תקציב הפרויקט הוא 370,000 ש״ח, ה-Must have מקבלים 60% (כ-220,000 ש״ח), ה-Should have מקבלים 20% (כ-75,000 ש״ח), ה-Could have מקבלים 15% (כ-55,000 ש״ח), וה-Won't have יוצאים מהתוכנית. כשמגיעה בקשה חדשה עם תווית Must have, משהו שכבר נמצא ברשימת ה-Must have צריך לרדת ל-Should have. התקציב מכריח החלטות קשות שקונצנזוס לבד לא יביא.
זה עובד גם בשטח. כשבנינו את פלטפורמת הטרנספורמציה הדיגיטלית של Espresso Club (מותג הקפה מספר 2 בישראל), ההיקף היה יכול לגדול בלי סוף, כי לכל מחלקה היו רעיונות. בזכות MoSCoW עם הקצאת תקציב, המסירה הראשונה התמקדה בפיצ׳רים עם ההשפעה הגדולה ביותר, וכל השאר עבר לשלב הבא.
3. מסכימים על ההיקף ברמת הספרינט
הסכמה על היקף קבוע לכל הפרויקט מניחה שלא תלמדו שום דבר בדרך. במקום זה, הסכימו על היקף ברמת הספרינט.
כל שבועיים מנהל המוצר וצוות הפיתוח מסכמים: "אלה 6 עד 8 הדברים שנמסור בספרינט הזה." כל דבר חדש שעולה באמצע הספרינט נכנס ל-Backlog, לתכנון של הספרינט הבא. באמצע ספרינט נכנסים רק מקרי חירום אמיתיים, כמו באג ב-Production או בעיית אבטחה. "הרגע נזכרתי" הוא לא מקרה חירום.
ככה יש לכם גמישות ברמת הפרויקט (ההיקף יכול להתפתח) ומשמעת ברמת הספרינט (מה שהתחייבתם אליו נמסר).
מהעבודה שלנו. Check2Fly, מערכת הגבולות של ישראל בתקופת הקורונה, היא המקרה הקיצוני ביותר של היקף משתנה שטיפלנו בו. הממשלה עדכנה את מדיניות הנסיעות כמעט כל שבוע, ושינתה את כללי הכניסה 47 פעמים ב-12 חודשים. בנינו את הכללים כמנגנון עם ניהול גרסאות, כך שכל שינוי היה עדכון מוגדר ובדוק. כל אחד מהם עלה לאוויר ביום שבו הוכרז, והמערכת אף פעם לא ירדה.
חמשת המקורות הנפוצים ל-Scope Creep, ומה עושים עם כל אחד
בעלי עניין שמצטרפים באמצע
הסמנכ״ל שלא היה בפגישת הפתיחה רואה את הדמו ורוצה "עוד דבר אחד קטן". זה המקור הנפוץ ביותר, והקל ביותר לניהול: כל הבקשות עוברות דרך מנהל המוצר. אף אחד אחר, בשום צד, לא מתחייב לשום דבר בערוץ צדדי.
"כבר כשאנחנו שם"
"אנחנו ממילא בונים את פרופיל המשתמש, למה לא להוסיף התחברות דרך רשתות חברתיות?" כי התחברות כזו נוגעת בהזדהות, בניהול Sessions, במדיניות הפרטיות ובמיזוג חשבונות. בקשות "כבר כשאנחנו שם" נשמעות צמודות למה שכבר בונים, אבל הן כמעט אף פעם לא קטנות כמו שהן נשמעות. העבירו כל אחת מהן הערכת השפעה.
תגובה למתחרים
מתחרה משיק פיצ׳ר ומישהו נכנס לפאניקה: "אנחנו צריכים את זה גם, עד מחר." פיצ׳רים של מתחרים הם קלט לגיטימי לרודמאפ, ולא לספרינט הנוכחי. רשמו אותם, העריכו אותם ותעדפו אותם מול כל השאר, באותו מנגנון.
דרישות לא ברורות שמתרחבות תוך כדי פיתוח
בדרישה היה כתוב "חיפוש". הצוות בנה חיפוש טקסט בסיסי. בעל העניין ציפה לחיפוש שסולח על שגיאות הקלדה, לפילטרים ולהשלמה אוטומטית. זה לא Scope Creep. זה חור בדרישות. מונעים אותו כשכותבים תנאי קבלה לכל פיצ׳ר לפני שמתחילים לפתח. "חיפוש" הוא לא דרישה. "המשתמש יכול לחפש הזמנות לפי מספר הזמנה, שם לקוח או טווח תאריכים, והתוצאות מופיעות תוך 2 שניות" היא דרישה.
גילויים טכניים
הצוות מגלה שה-API של המערכת הישנה לא תומך בפורמט הנתונים שציפו לו. עכשיו צריך לבנות שכבת התאמה שלא הייתה בהערכה. זה היקף חדש אמיתי, וצריך להציף אותו מיד. גילוי טכני צריך להוביל לשיחה באותו יום על ההשפעה על לוח הזמנים, ולא לשעות נוספות בשקט כדי "לגרום לזה לעבוד".
איך בונים חוזה עם בית תוכנה ששומר על ההיקף
החוזה עצמו יכול לעודד Scope Creep או למנוע אותו. אלה הסעיפים שחשובים.
בהתקשרות שעתית (Time & Materials):
- תקרת תקציב חודשית, ואישור בכתב לכל חריגה ממנה
- בדיקה כל שבועיים של קצב ההוצאה מול התקציב המתוכנן
- זכות להעביר קיבולת ספרינט שלא נוצלה לפיצ׳רים אחרים
בהתקשרות בהיקף קבוע (Fixed Price):
- תהליך בקשות שינוי רשמי, שמוגדר במפורש בחוזה
- תעריף שעתי מוסכם לעבודה שמחוץ להיקף
- הגדרה ברורה של מה בתוך ההיקף, עם תנאי קבלה, ולא רק שמות של פיצ׳רים
- תקציב גמישות של 10% עד 15%, בניהול משותף, לשינויי היקף לגיטימיים
בשני המודלים:
- דיווח שבועי על תקציב ולוח זמנים
- תהליך אישור דרישות שקובע מי מוסמך לאשר שינויי היקף
- הגדרה של מה נחשב שינוי היקף דחוף, לעומת בקשת שינוי רגילה
שאלות נפוצות
Scope Creep גרוע יותר מול בית תוכנה או בצוות פנימי?
התדירות דומה, אבל מול בית תוכנה רואים אותו יותר, כי ההשפעה על העלות מיידית ומגיעה בחשבונית. בצוות פנימי הנזק זהה, אבל הוא מתחבא בלוחות זמנים שמתארכים ובהזדמנויות שהוחמצו. היתרון של Scope Creep מול בית תוכנה: מישהו שולח לכם חשבון, ואתם נאלצים להתמודד עם המחיר. צוות פנימי פשוט עובד שעות נוספות, ואף אחד לא סופר את העלות האמיתית.
כמה שינוי בהיקף זה נורמלי?
תכננו לשינוי של 15% עד 25% בהיקף במהלך הפרויקט. זו למידה והתאמה רגילות. אם ההיקף משתנה ביותר מ-30%, או שהתחלתם לבנות בלי מספיק אפיון, או שהדרישות העסקיות באמת לא יציבות. במקרה כזה, שקלו עבודה בשלבים, עם מחזורים קצרים יותר.
מחיר קבוע או התקשרות שעתית: מה מונע Scope Creep?
אף מודל לא מונע אותו לבד. במחיר קבוע מתמודדים עם Scope Creep כשאומרים לא לשינויים, וזה יכול לפגוע במוצר. בהתקשרות שעתית אומרים כן לכל דבר, וזה יכול לפגוע בתקציב. הגישה הטובה ביותר היא התקשרות שעתית עם התחייבות ברמת הספרינט ותקרת תקציב חודשית. ככה מקבלים גמישות בלי התחייבות פתוחה.
ומה אם בית התוכנה הוא זה שמרחיב את ההיקף?
זה קורה. לפעמים בצדק, כשהם מגלים מורכבות טכנית שדורשת עוד עבודה. לפעמים כדי להגדיל הכנסות. כדי להגן על עצמכם, בדקו כל הרחבת היקף מול הדרישות המקוריות. אם העבודה הנוספת נדרשת כדי למסור את מה שסוכם מלכתחילה, העלות על בית התוכנה. אם זה באמת היקף חדש, הוא עובר בתהליך בקשות השינוי.
איך Globalbit מטפלת בשינויי היקף?
אנחנו עובדים עם התחייבות ברמת הספרינט ועם תהליך בקשות שינוי רשמי לכל מה שמחוץ להיקף המוסכם. כל שינוי מקבל הערכת השפעה בכתב לפני שמתחילים לעבוד. הלקוח מחליט אם להמשיך לפי מספרים אמיתיים, בלי ניחושים. ביותר מ-200 פרויקטים, הגישה הזו שמרה על שינויי ההיקף בשליטה, והמוצרים המשיכו להתפתח לפי משוב אמיתי ממשתמשים. בואו נדבר על המבנה הנכון לפרויקט שלכם.
