איך כותבים RFP לפיתוח תוכנה שמביא הצעות טובות

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

RFP חלש עולה לכם יותר ממה שנדמה

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

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

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

שמונה סעיפים שמגנים על ההשקעה שלכם

1. ההקשר העסקי (כדי שיתחרו על הבנה, ולא על ניחוש)

שתי פסקאות על החברה, על מה שהוביל לפרויקט ועל מי יהיה מעורב. זהו.

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

כסו שלושה דברים:

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

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

2. הבעיה, במונחים עסקיים (כדי לקבל פתרונות, ולא רשימות פיצ׳רים)

זה הסעיף הכי חשוב ב-RFP, וזה שרוב החברות כותבות לא נכון.

מה רוב הלקוחות כותבים: "אנחנו צריכים פורטל לקוחות עם SSO, הרשאות לפי תפקיד, דשבורד, מודול דוחות, מערכת התראות ואינטגרציה ל-SAP ול-Salesforce."

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

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

עשו את אותו הדבר לכל פיצ׳ר, ותארו את הבעיה שהוא פותר:

אחר כך חלקו את הרשימה לשתיים: מה חייב להיות בהשקה, ומה נחמד שיהיה אחריה. כך בתי התוכנה יודעים איך להגדיר את ההיקף. תקציב של 300,000 ש״ח אולי יכסה את מה שחייב, ותקציב של 750,000 ש״ח אולי יכסה הכול. בלי סדרי עדיפויות, כל בית תוכנה מנחש מה הכי חשוב לכם.

3. מדדי הצלחה (כדי שתוכלו לדרוש תוצאות)

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

• "הפחתה של 40% בשיחות למוקד תוך 6 חודשים מההשקה"
• "500 משתמשים בו-זמנית, עם טעינת עמוד מתחת ל-2 שניות"
• "אינטגרציה מלאה ל-SAP, עם עדכון סטטוס הזמנה בזמן אמת"

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

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

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

1. בתי התוכנה מנפחים בגלל אי-הוודאות. כשהם לא יודעים מה התקציב, הם לא יודעים מה הסיכון. בית תוכנה חכם מוסיף 30% עד 50% כדי לכסות את הלא נודע. אתם משלמים פרמיה על הניחוש.
2. אתם מקבלים הצעות לפרויקטים שונים. בית תוכנה אחד מניח 150,000 ש״ח ומציע MVP. אחר מניח 600,000 ש״ח ומציע פלטפורמה מלאה. אי אפשר להשוות ביניהם, כי הם תמחרו דברים שונים.
3. בתי התוכנה הטובים מוותרים עליכם. בית תוכנה מנוסה יודע ש"תקציב תחרותי" אומר הרבה פעמים שהלקוח עוד לא הקצה משאבים בפנים. הוא עובר לפניות של לקוחות שמוכנים.

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

כך נראה מה שכל רמת תקציב קונה בדרך כלל, באפליקציית Web בהתאמה אישית:

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

5. לוח זמנים ואילוצים (כדי שהפתעות לא יפוצצו את התקציב)

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

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

חלקו את האילוצים לקבועים ולגמישים:

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

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

6. הקשר טכני (כדי שההערכות יתבססו על המציאות)

ככל שתשתפו יותר הקשר טכני, ההערכות יחזרו מדויקות יותר:

• מערכות שצריך להתחבר אליהן (CRM,‏ ERP, חברות סליקה, מסדי נתונים ישנים)
• דרישות רגולציה (חוק הגנת הפרטיות, GDPR,‏ SOC 2,‏ HIPAA,‏ PCI-DSS)
• סביבת האחסון (AWS,‏ Azure, שרתים מקומיים, היברידי)
• קוד, API או נתונים קיימים שעליהם יבנו

מלכודת אחת שכדאי להיזהר ממנה: אל תכתיבו סטאק טכנולוגי מסוים, אלא אם יש לכם סיבה עסקית חזקה. "חייב להיבנות ב-Python/Django" מוציא מהמשחק בתי תוכנה שאולי היו מספקים מהר וזול יותר בטכנולוגיה אחרת. כתבו את האילוצים במקום: "חייב לרוץ על תשתית ה-AWS שלנו" או "חייב לעבוד עם מסד ה-PostgreSQL הקיים שלנו". תנו לבית התוכנה להמליץ על הטכנולוגיה. זה חלק ממה שאתם משלמים עליו.

7. מה אתם רוצים לקבל בהצעה (כדי שבאמת תוכלו להשוות)

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

קבעו מבנה אחיד למה שאתם מבקשים:

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

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

8. קריטריוני ההערכה (כדי שיתחרו על מה שחשוב לכם)

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

הנה נקודת פתיחה. שנו את המשקלות לפי המצב שלכם:

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

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

מה להשאיר בחוץ

חמש טעויות ששורפות זמן וכסף

שולחים ל-50 בתי תוכנה

יותר תשובות לא אומר יותר אפשרויות טובות. זה אומר 50 הצעות בינוניות, ואין זמן לבדוק אף אחת מהן. סננו מראש 5 עד 8 בתי תוכנה לפי תיק עבודות, ניסיון בתעשייה ושיחות ראשונות, ושלחו את ה-RFP רק לרשימה הקצרה.

מותחים את התהליך לשלושה חודשים

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

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

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

מבקשים מחיר קבוע על דרישות מעורפלות

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

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

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

אין לכם Product Owner מוכן

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

סימנים שמנבאים הצלחה

אחרי 16 שנה ויותר מ-200 פרויקטים, אנחנו רואים דפוסים ב-RFP שמנבאים שוב ושוב אם הפרויקט יצליח. השתמשו בהם כדי לבדוק את ה-RFP שלכם לפני ששולחים:

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

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

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

שאלות נפוצות

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

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

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

כל בית תוכנה צריך לקבל את אותו RFP? כן. מסמכים זהים מביאים הצעות שאפשר להשוות. התאימו רק את מכתב הפנייה.

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

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

כדאי לשלם על שלב אפיון לפני הפיתוח המלא? כמעט תמיד כן. שלב אפיון בתשלום (2 עד 4 שבועות, בדרך כלל מ-15,000 ש״ח, ויכול להגיע ל-45,000 ש״ח) נותן לכם תוכנית פרויקט מפורטת, ארכיטקטורה טכנית והערכת עלות מדויקת, לפני שאתם מתחייבים לפרויקט של מאות אלפי שקלים. הוא גם בודק את מערכת היחסים כשהסיכון עוד נמוך. תחשבו עליו כמו על בדק בית לפני שקונים דירה. בית תוכנה שמציע אפיון בתשלום מהמר על התהליך של עצמו, וזה סימן טוב.

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