רוב השיחות על "פרויקט או צוות" מתחילות ממחיר — קבוע או לפי שעות — ונתקעות שם. אבל המחיר הוא תוצאה של ההחלטה, לא ההחלטה עצמה. השאלה האמיתית היא מי מחזיק את ההחלטות על מה נבנה, ומי נושא באחריות כשהתוצאה לא מה שציפו לה. המדריך הזה עונה עליה בחמישה חלקים: מה ידוע ומה משתנה, מטריצת אחריות, איך כל מודל מתמחר שינוי, שתי דוגמאות מסומנות, ומה מוסרים בסיום.
מה ידוע ומה משתנה? — שלוש שאלות לפני המודל
המודל הנכון נגזר משלוש תשובות. כולן על הצד שלכם, לא על הספק:
- כמה ברורה התכולה? אם אפשר לכתוב היום מה המערכת תעשה ומה לא — בפעולות של משתמש, לא בפיצ'רים — יש בסיס לפרויקט. אם התשובה היא "נדע כשנראה", פרויקט במחיר קבוע יהפוך לסדרה של הצעות שינוי.
- כמה ברור המשך? אם יש תאריך שתלוי בתוצר — השקה, חוזה עם לקוח, סבב גיוס — פרויקט נותן התחייבות לתאריך מול תכולה. אם העבודה פשוט ממשיכה כל עוד המוצר חי, אין "סוף" להתחייב אליו.
- מי ינהל את זה אצלכם? צוות מתמשך דורש מישהו בצד שלכם שמחליט כל שבוע מה הדבר הבא, עונה על שאלות ומקבל החלטות מוצר. בלי אדם כזה, הצוות ימציא את סדר העדיפויות בעצמו — או יחכה. פרויקט דורש פחות: מישהו שמאשר אבני דרך ועונה על שאלות בזמן.
כלל אצבע: שתי תשובות "ברור" מתוך השלוש — פרויקט. שתי תשובות "משתנה" — צוות. אחת-אחת — התחילו בפרויקט קטן שמברר את התכולה, והחליטו אחריו.
מטריצת אחריות — מי מחזיק מה בכל מודל
זו הטבלה שחוסכת את רוב המחלוקות אחר כך. חמישה תחומים, ובכל אחד — מי אחראי בפרויקט, ומי בצוות. "אחראי" כאן פירושו מי מקבל את ההחלטה ונושא בתוצאה שלה.
| תחום | פרויקט מוגדר | צוות מתמשך |
|---|---|---|
| מוצר — מה נבנה | אתם, פעם אחת, במסמך ההיקף; אחר כך רק דרך תהליך שינוי | אתם, כל שבוע או שבועיים, בתור העבודה; הצוות מייעץ ומעריך |
| תקציב | קבוע מול התכולה; חריגה היא בעיה של הספק, אלא אם התכולה השתנתה | קבוע לתקופה לפי הקיבולת; כמה 'יוצא' ממנו תלוי בסדר העדיפויות שלכם |
| איכות ו-QA | הספק — מול קריטריוני קבלה כתובים; אתם בודקים קבלה בסוף כל שלב | הספק — בדיקות, סקירת קוד ותקני פיתוח הם חלק מהקיבולת; אתם מאשרים כל פריט שנמסר |
| פיתוח — איך נבנה | הספק, בתוך האילוצים הטכניים שבהסכם (טכנולוגיות, סביבות, בעלות על הקוד) | הצוות, לפי תקנים שסוכמו; החלטות ארכיטקטורה גדולות — יחד |
| ייצור — ניטור, פריסות, תקלות | עד המסירה — הספק; אחריה — לפי הסכם תחזוקה נפרד, או אתם | הצוות, בהיקף ובשעות השירות שההסכם מגדיר — לא מעבר להן |
איך מתמחרים שינוי? — מחיר קבוע, שעות וקיבולת
כאן נכנס המחיר — אבל כשאלה על שינוי, לא על סכום. שלושת מודלי התמחור הנפוצים מתנהגים אחרת ברגע שמשהו משתנה, וזה מה שבאמת חשוב לדעת עליהם. חשוב להפריד: מודל התמחור (איך משלמים) ומודל השירות (פרויקט או צוות) הם שתי החלטות. פרויקט יכול להיות לפי שעות; צוות יכול להיות במחיר קבוע לחודש.
| מודל תמחור | מה משלמים עליו | מה קורה כשמשהו משתנה | הסיכון שלכם |
|---|---|---|---|
| מחיר קבוע | תוצר מוגדר, בלי קשר לכמה זמן לקח | הצעת שינוי כתובה: מה נוסף או ירד, כמה זה עולה, איך זה מזיז את התאריך. בלי אישור — אין שינוי | תכולה שלא הוגדרה מספיק מתגלה כסדרת שינויים; ספק שמתמחר נמוך ואז 'מוצא' שינויים |
| לפי שעות (Time & Materials) | זמן עבודה בפועל, לפי תעריף לתפקיד | פשוט עובדים על הדבר החדש; העלות מתעדכנת. השקיפות תלויה בדיווח | אין תקרה מובנית; בלי ניהול צמוד הסכום גדל בלי שהתוצר מתקדם |
| קיבולת (Retainer) | תפקידים במידת הקצאה מוגדרת לתקופה — למשל 'מפתח אחד במשרה מלאה ומעצב ברבע משרה' — במחיר קבוע לחודש | לא מתמחרים שינוי — מסדרים מחדש את התור. מה שנדחה, נדחה | קיבולת שלא מנוצלת כי אין מי שמחליט אצלכם; 'צוות' שבפועל הוא חצי משרה אם ההקצאה לא כתובה |
הכלל שחוזר בכל שלושת המודלים: מה שכתוב נאכף, מה שלא כתוב מתווכח. בקיבולת — ההקצאה לכל תפקיד, בכתב, לפני שמשתמשים במילה "צוות". במחיר קבוע — מסמך ההיקף וקריטריוני הקבלה. לפי שעות — הדיווח: מה נעשה, כמה זמן, ומה הושג.
שתי דוגמאות התקשרות — להמחשה
דוגמה א׳ — פרויקט: מערכת הזמנות ללקוחות עסקיים
חברת הפצה רוצה שהלקוחות העסקיים שלה יזינו הזמנות בפורטל במקום בטלפון, ויש תאריך: תחילת העונה. התכולה ברורה — קטלוג, סל, אישור אשראי, חיבור ל-ERP הקיים — ואין בחברה מי שינהל מפתחים. המודל: פרויקט במחיר קבוע מול מסמך היקף עם ארבעה שלבים וקריטריוני קבלה לכל שלב. באמצע הדרך המנכ"ל רוצה גם אפליקציה לנציגי השטח. זה לא נכנס "בדרך": נכתבת הצעת שינוי — מה נוסף, כמה עולה, ואיך זה מזיז את התאריך — והחברה בוחרת לדחות את זה לאחרי העונה. בסיום: מסירה של הקוד, החשבונות והתיעוד, והסכם תחזוקה נפרד לייצור.
דוגמה ב׳ — צוות: אותה חברה, שנה אחר כך
הפורטל חי, הלקוחות משתמשים בו, וכל שבוע עולות בקשות: דוח חדש, שינוי בתהליך האישור, האפליקציה לנציגים שנדחתה. החברה מינתה מנהלת מוצר שמחליטה מה הדבר הבא. המודל עובר לצוות בקיבולת מוגדרת — ההסכם כותב במפורש אילו תפקידים ובאיזו הקצאה, לרבעון, במחיר קבוע לחודש. אין יותר הצעות שינוי: מנהלת המוצר מסדרת את התור כל שבועיים, הצוות מעריך ומייעץ, וכל פריט שנמסר מאושר על ידה. ההסכם גם קובע מה הצוות עושה בייצור — ניטור, פריסות, טיפול בתקלות — ובאילו שעות. בסוף כל רבעון: דוח מה נמסר, ובדיקה אם הקיבולת מתאימה לרבעון הבא — למעלה, למטה, או חזרה לפרויקטים נקודתיים.
מה שמשתנה בין שתי הדוגמאות הוא לא הספק ולא המוצר — אלא מי מחליט, כמה ברור מה הלאה, ומי מנהל את זה אצל הלקוח. זה בדיוק מה ששלוש השאלות מהפרק הראשון בודקות.
יתרונות וחסרונות — בכנות, לשני המודלים
| השוואה | פרויקט מוגדר | צוות מתמשך |
|---|---|---|
| יתרונות | ודאות מחיר ותאריך מול תכולה; אחריות ברורה אצל הספק; דורש מעט ניהול מצדכם; קל להשוות הצעות בין ספקים | גמישות — הכיוון משתנה בלי משא ומתן; ידע נצבר בצוות שמכיר את המוצר; רציפות בייצור; קצב קבוע שאפשר לתכנן סביבו |
| חסרונות | כל שינוי עולה זמן וכסף; הספק מתמרץ להצמד להיקף גם כשהצורך השתנה; הידע עובר אליכם רק במסירה; 'סוף' שאחריו צריך לסדר תחזוקה | דורש מישהו אצלכם שמחליט כל שבוע; אין התחייבות לתוצר — רק לקיבולת ולאיכות; קל לשלם על קיבולת שלא מנוצלת; קשה יותר להשוות בין ספקים |
מה מוסרים בסיום — בכל מודל
בפרויקט יש יום מסירה. בצוות יש יום שבו ההתקשרות מסתיימת או מצטמצמת. בשני המקרים צריך להיות כתוב מראש מה עובר אליכם, כי זה הרגע שבו הכי קשה לדרוש את זה:
- קוד — מאגר הקוד על שמכם מהיום הראשון, לא מועבר בסוף. כולל היסטוריית השינויים.
- גישות וחשבונות — ענן, דומיין, חנויות אפליקציות, ספקים חיצוניים: בבעלותכם, עם גישה לספק — ולא להפך.
- תיעוד — איך מריצים, איך פורסים, מה התצורה של כל סביבה, ואילו החלטות ארכיטקטורה התקבלו ולמה.
- ידע — בצוות מתמשך זה החלק שהכי קל לאבד: מי שעבד על המוצר שנה יודע דברים שלא כתובים. תקופת חפיפה מוגדרת, בכתב, היא חלק מההסכם.
- מה נמסר מול מה הוזמן — בפרויקט: רשימה מול מסמך ההיקף. בצוות: מה נמסר בתקופה האחרונה ומה נשאר בתור.
איך זה עובד אצלנו
אנחנו עובדים בשני המודלים, ולעיתים קרובות בזה אחר זה: פרויקט MVP מוגדר שמסתיים במסירה, ואחריו — אם המוצר חי והכיוון משתנה — צוות מתמשך בקיבולת כתובה. בשני המקרים התפקידים, ההקצאה ומה שנמסר מוגדרים בהסכם, לא בשיחה. פרטי שני המסלולים נמצאים בעמוד השירות.
מסלול א׳ — פרויקט MVP מוגדר: תוצרים, היקף והחרגות, תנאי קבלה, ומה קורה אחרי המסירה. לפרטי מסלול הפרויקט
מסלול ב׳ — צוות פיתוח מתמשך: תפקידים והקצאות, חלוקת אחריות, קצב עבודה ודיווח, ואיך מתחילים ומסיימים. לפרטי מסלול הצוות
ואחרי שבחרתם מודל — איך בוחרים את הספק עצמו, ומה לשאול אותו, במדריך נפרד. איך בוחרים בית תוכנה — שאלות, סימני אזהרה ומה לבדוק