איך בוחרים בית תוכנה לארגון: השאלות שכדאי לשאול לפני שחותמים

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

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

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

מה בעצם בודקים כשבוחרים בית תוכנה?

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

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

אילו שאלות לשאול בית תוכנה בפגישה הראשונה?

שקיפות

1. איך אדע מה מצב הפרויקט בלי שאצטרך לשאול?

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

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

2. איך אתם מתמחרים שינוי באמצע הפרויקט?

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

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

הצוות

3. מי בפועל יעבוד על הפרויקט, ומי מהם יושב איתנו בפגישה הזו?

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

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

4. מה קורה אם מנהל הפרויקט שלנו עוזב באמצע?

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

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

תקלות

5. ספרו לי על פרויקט שאיחר. מה עשיתם?

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

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

6. מה נחשב תקלה קריטית, ותוך כמה זמן מטפלים בה?

תשובה טובה: הגדרה כתובה בהסכם השירות (SLA), עם זמן תגובה מוגדר, כולל מחוץ לשעות העבודה.

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

בעלות על הקוד

7. למי שייך הקוד, ואיפה הוא שמור?

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

נורה אדומה: הקוד אצל הספק, ותקבלו אותו "בסוף הפרויקט".

8. אם נחליט להיפרד, מה אנחנו מקבלים ותוך כמה זמן?

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

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

היום שאחרי ההשקה

9. מי מטפל במערכת אחרי שהיא עולה לאוויר?

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

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

10. איך נדע שהמערכת עושה את מה שלשמו הזמנו אותה?

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

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

איך בודקים שהתשובות נכונות ולא רק נשמעות טוב?

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

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

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

איך משווים בין הצעות מחיר של בתי תוכנה?

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

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

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

מתי המדריך הזה לא מתאים לכם

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

איך אנחנו עונים על השאלות האלה

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

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

רשימת עשר השאלות להורדה

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

להורדת רשימת עשר השאלות (PDF)