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