פרויקט תוכנה שנתקע הוא אחת הבעיות הנפוצות אצל עסקים שמזמינים פיתוח מספק חיצוני. הלו"ז מתארך, ההדגמות לא מראות התקדמות, ובכל פגישה מופיעה סיבה חדשה. הדחף הראשון הוא להחליף ספק. לרוב זה לא הצעד שכדאי להתחיל בו.
סימנים שהפרויקט באמת נתקע
- הלו"ז זז יותר מפעם אחת, בלי הסבר ברור
- ההדגמות מראות מסכים אבל לא תהליך שעובד
- אף אחד לא יכול להגיד במדויק מה כבר גמור ומה נשאר
- כל שינוי קטן נדחה או מתומחר כעבודה חדשה
- אין לכם גישה לקוד, לשרתים או לתיעוד
סימן אחד הוא עדיין לא אבחנה. שניים או יותר הם סיבה לעצור ולבדוק.
שלב 1: עוצרים ומרכזים מה יש
לפני כל החלטה צריך תמונת מצב אחת מסודרת. מאספים את החוזה וההצעה המקוריים, את מסמך הדרישות, את רשימת המשימות או דוח ההתקדמות, גישה לקוד ולסביבות העבודה, ורשימה של מה ששולם עד היום.
אם הספק מתקשה לתת גישה לקוד שאתם משלמים עליו, זה כבר מידע חשוב.
שלב 2: מפרידים בין שלוש שאלות
פרויקט נתקע מאחד משלושה מקורות, ולפעמים משילוב ביניהם. לכל מקור יש תיקון אחר.
- הדרישות לא ברורות. כל צד הבין משהו אחר וההגדרה משתנה תוך כדי עבודה. התיקון: לכתוב מחדש מה צריך להיות מוכן בסוף כל שלב ולהסכים על כך.
- הצוות לא מסוגל. חסר ניסיון בטכנולוגיה, או שהאדם שהתחיל כבר לא בפרויקט. התיקון: חיזוק הצוות או החלפה ממוקדת.
- הניהול לא עובד. אין מי שמחזיק את התמונה, מתאם בין הצדדים ומסמן סטיות בזמן. התיקון: מנהל פרויקט שמייצג את הצד שלכם.
הרבה פרויקטים נתקעים בגלל הסוג השלישי. אם מחליפים ספק בלי לטפל בו, אותה בעיה חוזרת עם ספק חדש.
שלב 3: חוות דעת טכנית בלתי תלויה
מי שבודק צריך להיות גורם שאין לו אינטרס בתוצאה. הוא עובר על הקוד והארכיטקטורה, בודק מה באמת עובד ומה רק נראה כאילו, ומעריך כמה עבודה נשארה. בלי זה, כל המידע שמגיע אליכם הוא ממי שיש לו אינטרס.
הבדיקה לא חייבת להיות ארוכה. מטרתה לענות על שאלה אחת: אפשר לבנות על מה שקיים, או שצריך להתחיל מחדש בחלקים ממנו.
שלב 4: מחליטים
- ממשיכים עם אותו ספק, אם הבסיס הטכני תקין והבעיה בניהול או בדרישות. מוסיפים ניהול וקובעים אבני דרך חדשות.
- משנים את המבנה: ספק אחד לחלק שעובד, וגורם אחר לחלקים שנתקעו.
- מחליפים ספק, אם הקוד לא שמיש, אין גישה אליו, או שהאמון נשבר. לפני כן מוודאים מה אפשר לקחת איתכם.
ההחלטה היא עסקית ולא רק טכנית. היא תלויה בתקציב שנותר, בלחץ הזמן ובמה שהפרויקט אמור להביא לעסק.
איך מונעים שזה יחזור
- אבני דרך קצרות, ובכל אחת הדגמה של משהו שעובד
- קריטריוני קבלה כתובים לכל פיצ'ר
- גישה שלכם לקוד ולסביבות מהיום הראשון
- תשלום שקשור להתקדמות ולא רק לזמן
- אדם אחד אצלכם שאחראי על הפרויקט, או מנהל פרויקט חיצוני
סעיפי בעלות על הקוד ותנאי תשלום כדאי לבדוק עם עורך דין. זה מדריך כללי ולא ייעוץ משפטי.
מתי כדאי להכניס מנהל פרויקט או CTO חיצוני
אם אין אצלכם מי שיודע לשאול את השאלות הנכונות בצד הטכנולוגי, זה הרגע. מנהל פרויקטים טכנולוגיים חיצוני מייצג אתכם מול הספק, בודק את מצב הפרויקט ומחזיק את הלו"ז. אם הבעיה רחבה יותר, CTO חיצוני בהיקף שעות יכול ללוות את ההחלטות הטכנולוגיות של העסק. לתמונה כוללת: הובלת טכנולוגיה וחדשנות.