נורה אדומה: הצעה בלי אף סיכון. בכל פרויקט יש סיכונים. אם בית התוכנה לא ציין אף אחד, או שהוא לא חשב מספיק לעומק, או שהוא אומר לכם מה שאתם רוצים לשמוע.
3. ארכיטקטורה, מעבר לרשימת פיצ׳רים
פיצ׳רים מתארים מה התוכנה עושה. ארכיטקטורה מתארת איך היא בנויה, ולמה הבחירות האלה חשובות. הצעה בלי ארכיטקטורה היא כמו תוכנית של בית שמראה את הקומות ולא את היסודות.
מה לחפש:
- בחירת טכנולוגיות, עם הסבר קצר לכל בחירה
- תרשים מערכת ברמה גבוהה, שמראה את הרכיבים המרכזיים ואיך הם מדברים ביניהם
- הגישה למסד הנתונים ושיקולי זרימת המידע
- המלצות לתשתית ולאחסון, עם התייחסות לגדילה
- גישת אבטחה שמתאימה לתעשייה שלכם
נורה אדומה: בית תוכנה שדוחה את כל החלטות הארכיטקטורה לשלב האפיון הטכני, בלי להציע שום כיוון ראשוני. בית תוכנה מנוסה יודע להציע גישה כבר על בסיס הדרישות שלכם.
4. לוח זמנים מציאותי, עם תלויות
"12 שבועות מתחילת הפרויקט" זה לא לוח זמנים. זו תקווה. לוח זמנים אמיתי מראה שלבים, אבני דרך, זמני סקירה ואת הפריטים בנתיב הקריטי, שקובעים אם הלו״ז יחזיק.
מה לחפש:
- שלבים מוגדרים (אפיון, עיצוב, פיתוח, בדיקות, עלייה לאוויר)
- זמני סקירה של הלקוח שמובנים בלוח הזמנים (בדרך כלל 3 עד 5 ימי עבודה לכל סבב)
- מרווח ביטחון לנעלמים (בתי תוכנה טובים מוסיפים 15% עד 20%)
- תלויות שעלולות להשפיע על הלו״ז (גישה ל-API, נתונים מהלקוח, זמינות של ספקים חיצוניים)
- הבחנה בין זמן קלנדרי לזמן עבודה
נורה אדומה: לוח זמנים שמראה רק את העבודה של בית התוכנה, בלי המשימות שלכם. סבבי הסקירה שלכם, הנתונים שאתם צריכים לספק וההחלטות שאתם צריכים לקבל נמצאים גם הם בנתיב הקריטי.
5. תמחור שקוף
תעריף לשעה עוזר, אבל שקיפות אמיתית היא לראות איך התקציב מתחבר לעבודה עצמה.
מה לחפש:
- פירוט עלויות לפי שלבים או לפי אבני דרך
- הפרדה ברורה בין רכיבים במחיר קבוע לרכיבים משתנים
- ההנחות שעליהן ההערכה נשענת (גודל צוות, אורך ספרינט, שעות עבודה)
- איך מתמחרים שינויי היקף
- מה קורה אם ההערכה מתבררת כרחוקה מהמציאות, לכל כיוון
נורה אדומה: מספר אחד בשורה התחתונה, בלי פירוט. אם אתם לא רואים לאן הכסף הולך, אתם לא יכולים לבדוק אם ההערכה סבירה, וגם לא לאתר את המקור כשהעלויות יחרגו.
6. מי בצוות, ובכמה אחוזי משרה
מי באמת יעבוד על הפרויקט שלכם? לא הבכירים שמציגים בשלב המכירה, אלא המפתחים, המעצבים ואנשי ה-QA שיכתבו את הקוד.
מה לחפש:
- תפקידים מוגדרים עם רמת ניסיון (מפתח בכיר, מעצב ברמת ביניים, ראש צוות QA)
- אחוזי הקצאה (משרה מלאה, או חלוקה עם פרויקטים אחרים)
- שמות של אנשים כשאפשר, עם הניסיון הרלוונטי שלהם
- התפקיד והזמינות של מנהל הפרויקט
- איך הצוות גדל או קטן בין שלבי הפרויקט
נורה אדומה: "נשבץ את הצוות המתאים", בלי פרטים. אתם לא שוכרים מותג. אתם שוכרים אנשים, ומגיע לכם לדעת מי הם.
7. תוכנית בדיקות ו-QA
הסעיף הזה מגלה כמה ברצינות בית התוכנה לוקח איכות. אם הבדיקות הן הערת שוליים בהצעה, הן יהיו הערת שוליים גם בפרויקט.
מה לחפש:
- סוגי הבדיקות שכלולים (יחידה, אינטגרציה, End-to-End, ביצועים, אבטחה)
- החלק של הבדיקות מכלל המאמץ (20% עד 30% זה בריא, פחות מ-15% מדאיג)
- מעורבות של QA לאורך כל הפיתוח, ולא רק בסוף
- תהליך בדיקות קבלה (UAT) והתמיכה בו
- מדדי ביצועים, ואיך יאמתו אותם
נורה אדומה: בדיקות שמתוארות בשורה אחת או בפסקה אחת. QA צריך לקבל פרק שלם, לא משפט.
8. תמיכה אחרי ההשקה והעברת ידע
ההצעה צריכה להתייחס למה שקורה אחרי ההשקה. ביום שהתוכנה עולה לאוויר מתחילים החיים התפעוליים שלה.
מה לחפש:
- תקופת אחריות, ומה היא מכסה
- אפשרויות תמיכה אחרי ההשקה, ומחירים
- תוכנית העברת ידע (תיעוד, הדרכות, נהלי מסירה)
- המלצות לתחזוקה והערכת עלויות שוטפות
- אפשרויות SLA לתמיכה ב-Production
נורה אדומה: הצעה שנגמרת ב"עלייה לאוויר". אם בית התוכנה לא חשב על מה שקורה אחרי ההשקה, הוא לא חושב על ההצלחה של התוכנה שלכם לאורך זמן.
איך משווים בין הצעות
כשיש לכם שתיים או שלוש הצעות על השולחן, תתאפקו ואל תשוו קודם את השורה התחתונה. השוו לפי הממדים האלה:
| ממד | משקל | מה משווים |
|---|
| הבנת הבעיה שלכם | גבוה | כמה מדויק הם שיקפו את היעדים והאילוצים שלכם |
| שקיפות בסיכונים | גבוה | כמה סיכונים הם זיהו, וכמה ספציפית |
| גישה טכנית | בינוני | האם הארכיטקטורה מתאימה להיקף ולמורכבות שלכם |
| לוח זמנים מציאותי | בינוני | מרווחי ביטחון וניהול תלויות |
| שקיפות בעלויות | בינוני | רמת הפירוט ותיעוד ההנחות |
| מחויבות הצוות | בינוני | אחוזי הקצאה ושמות של אנשים |
| רצינות הבדיקות | בינוני | החלק מהמאמץ שמוקדש ל-QA |
| תכנון לאחר ההשקה | נמוך עד בינוני | אחריות, תמיכה והעברת ידע |
המחיר חשוב, אבל הוא בא אחרון. הצעה של 450,000 ש״ח עם היקף ברור והערכת סיכונים כנה היא השקעה טובה יותר מהצעה של 300,000 ש״ח, שהגיעה למספר הנמוך כי הסתירה מורכבות.
מבחן השיחה
עוד טכניקה אחת לסיום. אחרי שקראתם הצעה, התקשרו לבית התוכנה ושאלו שלוש שאלות הבהרה. לא שאלות נוחות, אלא שאלות אמיתיות על הגישה שלהם:
- "תסבירו לנו איך הערכתם את המאמץ בארכיטקטורת מסד הנתונים."
- "מה הסיכון הכי גדול שאתם רואים בפרויקט, שלא מופיע בהצעה?"
- "אם נצטרך לחתוך 20% מהתקציב, מה הייתם ממליצים להוריד?"
התשובות יגידו לכם יותר מההצעה עצמה: כמה הן ספציפיות, כמה הן כנות, וכמה מהר האנשים מולכם יודעים לחשוב על פשרות.
איך אנחנו כותבים הצעות
ההצעות שלנו מגיעות בדרך כלל ל-15 עד 25 עמודים, כי אנחנו מכניסים תרשימי ארכיטקטורה, הערכת סיכונים ופירוט מלא של השלבים. אנחנו כותבים את ההנחות במפורש, כדי שלא יהיו הפתעות כשהפיתוח מתחיל. אנחנו נוקבים בשמות של אנשי הצוות, בהקצאה של כל אחד ובניסיון הרלוונטי שלו. ותמיד יש אצלנו פרק על מה לא כדאי לבנות, כי לדעת מה להשאיר בחוץ חשוב בדיוק כמו לדעת מה להכניס.
אותו סטנדרט ממשיך לעבודת האפיון שבאה אחרי ההצעה. עבור AIG ישראל חקרנו, עיצבנו ואפיינו את מערכת תביעות הביטוח הדיגיטלית המלאה הראשונה בישראל. היא מכסה ביטוח רכב, רכוש, בריאות, נסיעות וביטוח כללי, והדרך מהבריף ועד אפיון מוכן לפיתוח לקחה שלושה חודשים. ב-WeShoes עברו ארבעה חודשים מתחילת הפרויקט ועד תוכנית מוכנה לפיתוח: ארכיטקטורת UX, עיצוב UI, מערכת עיצוב לכמה מותגים, חוזי API ומודלים של נתונים. בשני המקרים, המפתחים של הלקוח יכלו לבנות ישירות מהמסמכים.
שאלות נפוצות
מה צריכה לכלול הצעת מחיר לפיתוח תוכנה?
הבנה של הבעיה העסקית, הערכת סיכונים כנה, סקירת ארכיטקטורה, לוח זמנים עם תלויות, תמחור מפורט לפי שלבים, פירוט הצוות ואחוזי ההקצאה, תוכנית בדיקות, ותוכנית לתמיכה ולהעברת ידע אחרי ההשקה.
כמה מהתקציב צריך ללכת על בדיקות?
בין 20% ל-30% מכלל המאמץ זה בריא, ופחות מ-15% מדאיג. בפרויקט שהגיע אלינו להצלה, ההצעה המקורית הקצתה לבדיקות 5% בלבד.
איך משווים בין כמה הצעות של בתי תוכנה?
אל תתחילו מהמחיר. השוו קודם את הבנת הבעיה ואת השקיפות בסיכונים, ואחר כך את הגישה הטכנית, לוח הזמנים, פירוט העלויות, הצוות והבדיקות. המחיר בא אחרון.
רוצים לראות איך זה נראה אצלכם? בקשו הצעה לפרויקט שלכם.
