מחיר קבוע או לפי שעות: איך לתמחר פרויקט פיתוח בלי להפסיד

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

שלושת המודלים: מה כל אחד באמת אומר

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

לפי שעות (Time and Materials). משלמים על שעות עבודה בפועל לפי תעריף מוסכם, בדרך כלל עם הערכת שעות מראש ודיווח חודשי או שבועי. הסיכון של הערכה שגויה נשאר אצלכם, ובתמורה יש גמישות מלאה: אפשר לשנות כיוון באמצע בלי משא ומתן על כל שינוי. המודל עובד טוב כשיש אמון וכשמישהו מהצד שלכם קורא את הדיווח, ורע כשאף אחד לא מסתכל על השעות עד שמגיעה החשבונית.

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

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

מילון קצר

• היקף (Scope) - הרשימה המפורשת של מה הפרויקט כולל ומה הוא לא כולל. הבסיס לכל מחיר.
• אפיון (Specification) - המסמך שמתאר את ההיקף: משתמשים, מסכים, תהליכים, חיבורים למערכות אחרות.
• הערכת שעות (Estimate) - ניחוש מקצועי של כמות העבודה. לא התחייבות, אלא אם נכתב אחרת.
• מרווח ביטחון (Contingency) - תוספת שהספק מגלם במחיר קבוע כדי לכסות הפתעות. אתם משלמים עליה גם אם ההפתעות לא הגיעו.
• בקשת שינוי (Change request) - דרישה שלא הייתה בהיקף המקורי, מתומחרת ומאושרת בנפרד.
• קריטריון קבלה (Acceptance criteria) - הגדרה כתובה של מתי תוצר נחשב מסור: מה צריך לעבוד כדי שהתשלום ישולם.
• ריטיינר (Retainer) - סל שעות חודשי קבוע במחיר קבוע, לעבודה שוטפת שלא מתאימה לתמחור כפרויקט.

איפה יושב הסיכון בכל מודל

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

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

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

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

למה מחיר קבוע לא קיים בלי אפיון כתוב

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

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

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

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

איך מטפלים בשינויים באמצע הדרך

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

קודם כל, הבחנה שחוסכת ויכוחים. יש שלושה סוגי "שינויים", ורק אחד מהם עולה כסף:

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

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

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

המודל ההיברידי: מחיר קבוע לכל אבן דרך

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

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

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

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

מה חייבת לכלול הצעת מחיר טובה

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

1. היקף והפניה למסמך. על איזה אפיון או רשימת דרישות ההצעה מבוססת, בגרסה ובתאריך.
2. פירוט לפי מודולים או מסכים. לכל חלק במערכת - שעות משוערות או מחיר. זה מה שמאפשר להשוות בין הצעות ולחתוך היקף בלי לפתוח משא ומתן מחדש.
3. חיבורים למערכות חיצוניות בנפרד. חיבור לתוכנת חשבוניות, לסליקה או ליומן הוא סעיף משלו, כי הוא תלוי בצד שלישי ולרוב חורג מההערכה.
4. מה לא כלול. סעיף מפורש. עיצוב גרפי, הזנת נתונים היסטוריים, הדרכה, אפליקציה לנייד, תמיכה אחרי מסירה - כל מה שלא ברשימה הזו יהפוך לבקשת שינוי.
5. עיצוב, בדיקות והטמעה. האם עיצוב המסכים כלול, כמה סבבי תיקונים, מי מבצע בדיקות, ומי מעלה את המערכת לשרת.
6. לוח זמנים ואבני דרך. תאריכים או משכים, ומה תלוי בתשובות ובחומרים שלכם.
7. תנאי תשלום. מה משולם מתי, ומול איזה תוצר.
8. תעריף לשינויים. מחיר לשעה נוספת ותהליך אישור לבקשות שינוי. גם בהצעת מחיר קבוע.
9. אחריות אחרי מסירה. כמה זמן תיקון תקלות כלול במחיר, ומה קורה אחרי.
10. תחזוקה ואחסון. מה עולה להחזיק את המערכת בחיים אחרי ההשקה: שרת, עדכונים, גיבויים, תמיכה. פירטנו את זה במאמר על עלות תחזוקת מערכת אחרי ההשקה.
11. בעלות על הקוד והנתונים. משפט אחד שקובע שהקוד, מסד הנתונים והחשבונות אצל ספקי הענן שייכים לכם עם התשלום.

דגלים אדומים בהצעת מחיר

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

דוגמה: אותו פרויקט בשלושה מודלים

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

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

לפי שעות. ההערכה הייתה 320 שעות, כלומר 80,000 שקלים. בפועל נעשו 384 שעות, והחשבונית הסופית 96,000 שקלים. לא היה ויכוח אחד: שינוי מסך הטכנאי והחתימה הדיגיטלית פשוט נכנסו לדיווח. הבעיה היחידה היא שאת הסכום הסופי ידעתם רק בסוף, ואם לא הייתם קוראים את הדיווח השבועי, הייתם מגלים אותו בחשבונית.

מחיר קבוע. הספק לקח את 320 השעות, הוסיף מרווח ביטחון של שלושים אחוז וכתב 104,000 שקלים. החתימה הדיגיטלית הייתה בבירור מחוץ להיקף ותומחרה כבקשת שינוי ב-8,000 שקלים. שינוי מסך הטכנאי הפך לוויכוח: באפיון נכתב "מסך טכנאי" בלי פירוט, הספק טען שזה שינוי, אתם טענתם שזה מה שהתכוונתם. הוא נגמר בפשרה של 5,000 שקלים ושבועיים של מתח. סך הכל 117,000 שקלים, ומערכת שנמסרה בדיוק לפי המסמך - כולל הדברים שבמסמך היו טעות.

אבני דרך. הפרויקט חולק לארבעה שלבים: אפיון ומסכים ב-10,000 שקלים, ליבת המערכת למנהל ב-38,000, מסך הטכנאי והחיבור לחשבוניות ב-34,000, והרצה, תיקונים והדרכה ב-10,000. סך הכל 92,000 שקלים. שינוי מסך הטכנאי התגלה כשהטכנאים ראו את המסכים המצוירים בשלב הראשון, לפני שהשלב השלישי תומחר, ולכן נכנס למחיר שלו בלי דיון. החתימה הדיגיטלית הגיעה אחרי השלב השלישי ותומחרה כפריט נפרד ב-6,500 שקלים. סך הכל 98,500 שקלים, שידעתם אותם שלב אחרי שלב.

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

מתי כל מודל מתאים

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

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

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

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

שורה תחתונה

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

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