הצעת מחיר טובה לא מספיקה. לפני שמעבירים מקדמה, צריך לדעת איך נראית העבודה מהרגע שבו הפרויקט נפתח: מי יהיה איש הקשר, מתי תראו גרסה עובדת, ואיפה נשמרים הקוד וההחלטות. אלה שאלות פשוטות שחוסכות אי הבנות יקרות.
בשבוע הראשון: הופכים הבטחה לתוכנית
קובעים פגישת פתיחה עם מי שיבנה את המוצר בפועל. עוברים על המשתמשים, זרימת הליבה, מה נכלל בגרסה הראשונה ומה נשאר בחוץ. בסיום צריכה להיות תוכנית קצרה עם אבני דרך, אחריות לכל צד, שאלות פתוחות ותאריך לדמו הראשון. אם אין מסמך כזה, קשה לדעת בהמשך האם עיכוב הוא תקלה או שינוי בתכולה.
בכל שבוע: לראות מוצר, לא רק לקבל עדכון
דמו של גרסה עובדת מראה מה הושלם ומה עדיין לא. עדכון כתוב יכול להוסיף החלטות, חסמים והצעד הבא, אבל הוא לא מחליף בדיקה של הזרימה עצמה. כדאי לקבוע מראש מועד קבוע להדגמה ומקום אחד שבו מרוכזות ההערות. כך אפשר לתקן כיוון מוקדם, לפני שהצטברו שבועות של פיתוח בכיוון הלא נכון.
איך מנהלים בקשה חדשה
כל פרויקט משתנה. ההבדל הוא האם השינוי מתועד: מה מבקשים, למה, מה ההשפעה על מחיר ולוח זמנים, ומי מאשר. בקשה קטנה לכאורה יכולה לדרוש שינוי במסד הנתונים, בהרשאות ובבדיקות. בקשו הערכת השפעה לפני שמתחילים, כדי לשמור על הבחנה בין תכולה מוסכמת לבין תוספת.
הקוד והגישה צריכים להיות ברורים מראש
בררו מי מחזיק את ה-Repository, חשבונות הענן, הדומיין ושירותי הצד השלישי. בקשו הרשאות צפייה כבר במהלך הפרויקט והגדירו בחוזה בעלות ומסירה. בסיום צריך לקבל קוד, הוראות התקנה, רשימת שירותים פעילים וגישה למערכת הניטור. גם אם תמשיכו עם אותו צוות, כך לא נוצרת תלות מיותרת.
רשימת בדיקה לפני המקדמה
בקשה טובה מבית התוכנה כוללת חמישה דברים: תוכנית לגרסה הראשונה, תאריך לדמו, איש קשר טכני, דרך מסודרת לאשר שינויים, ורשימת נכסים שיימסרו. אם אחד מהם חסר, בקשו להשלים אותו בהצעה. לא צריך מסמך של 50 עמודים; צריך תשובות שאפשר לחזור אליהן בעוד חודש.