בחירת חברת פיתוח היא החלטת ספק, צוות וארכיטקטורה באותו זמן. חברה יכולה להציג אתר מרשים ולמסור את הפרויקט לצוות שלא פגשתם. לכן צריך לבדוק לא רק מה היא בנתה, אלא מי בנה, איך מתקבלות החלטות ואיך נראית אחריות כשהמציאות משתנה.
1. מי עובד על הפרויקט בפועל
בקשו להכיר את ה-Tech Lead ואת מי שכותב את רוב הקוד. שאלו אם יש Outsourcing, כמה פרויקטים הצוות מנהל במקביל ומי זמין כשיש תקלה. Account Manager טוב הוא תוספת; הוא לא תחליף לשיחה ישירה עם המהנדסים.
2. האם הם מבינים את הבעיה לפני הפתרון
בשיחת היכרות טובה תשמעו שאלות על משתמשים, מדד הצלחה, תהליך קיים וסיכון עסקי. אם השיחה עוברת מיד ל-React, AWS או AI, כנראה מוכרים לכם יכולת טכנית לפני שהוגדרה המטרה.
3. איך נראית התקדמות שבועית
בקשו לראות דוגמה לעדכון שבועי: גרסה חיה, מה הושלם, מה חסום ומה מחליטים השבוע. צילום מסך של Jira הוא לא התקדמות. דמו של מוצר עובד מאפשר לזהות סטייה בשבוע השני ולא בחודש החמישי.
4. למי שייכים הקוד והחשבונות
ה-Repository, סביבת הענן, הדומיין, האנליטיקס וחשבונות החנויות צריכים להיות בבעלות החברה שלכם מהיום הראשון. החוזה צריך לציין העברת קניין רוחני וגישה מלאה. בלי זה, החלפת ספק הופכת לאירוע מסוכן ויקר.
5. איך עובדים עם שינויי סקופ
שינויים יקרו. השאלה היא אם הם מתועדים ומתומחרים לפני ביצוע. חפשו מנגנון פשוט: שינוי, השפעה על מחיר וזמן, אישור ואז עבודה. בלי מנגנון כזה Fixed Price הופך למאבק או לחשבונית מפתיעה.
6. מה קורה אחרי Production
שאלו על ניטור, גיבויים, זמני תגובה, תיקוני אבטחה והעברת ידע. מוצר שאין לו Owner אחרי ההשקה צובר תקלות מהר. תחזוקה צריכה להיות סעיף מתוכנן, לא הבטחה כללית של ׳נהיה שם׳.
דגלים אדומים
הצעה בלי מה לא כלול, הבטחה לכל דדליין לפני אפיון, סירוב לתת גישה לקוד, תיק עבודות בלי יכולת להסביר החלטות, או מחיר נמוך משמעותית מכל השוק. כל אחד מהם יכול להיות מקרי; שניים יחד מצדיקים עצירה.