קבלן משנה בפיתוח תוכנה - מה שכל לקוח צריך לדעת לפני שחותם

מה שקורה מאחורי הקלעים

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

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

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

שלושת המודלים - וכיצד לזהות כל אחד

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

White Label - קבלן המשנה עובד לגמרי מאחורי הקלעים. הלקוח לא יודע שיש צד שלישי. כל התקשורת, הקוד, והנוכחות הם של החברה שחתמתם עמה.
Referred Partner - החברה הראשית מציגה את השותף ללקוח. הלקוח יודע שיש מי שמבצע, ניהול ההסכם נשאר עם החברה הראשית.
Direct Subcontract - הלקוח יודע מי מבצע, לפעמים יש קשר ישיר, אבל האחריות החוזית נשארת עם מי שחתמתם עמו.

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

מתי זה עובד לטובתכם

יש מקרים שבהם מודל קבלן המשנה משרת את הלקוח טוב מאוד.

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

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

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

מתי זה עלול לפגוע בפרויקט

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

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

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

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

איך לדעת מה קורה אצלכם

לא צריך להיות חוקר. מספיק לשאול את השאלות הנכונות לפני שחותמים.

מי הצוות שיעבוד על הפרויקט - ואפשר להכיר אותם לפני ההתקשרות? האם כל הפיתוח מבוצע בבית? מי נקודת האחריות הבלעדית מהאפיון ועד המסירה? כמה פרויקטים מקבילים הצוות מנהל כרגע?

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

הסימנים שכדאי להכיר

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

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

אף אחד מהסימנים האלה הוא לא בהכרח דגל אדום. אבל כולם יחד - הם בהחלט שאלה שראויה לקבל תשובה כנה!

וריאציה נוספת: כשהעבודה יוצאת לחו"ל

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

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

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

למה Bit-Gem עובדת אחרת

ב-Bit-Gem בחרנו במודל One Stop Shop מקומי. הצוות שפוגש אתכם בפגישה הראשונה הוא הצוות שיפתח את הפרויקט. כל המפתחים שלנו הם עובדי החברה במשרה מלאה, יושבים במרכז הפיתוח שלנו באזור, ועובדים באותה שפה ובאותו סאב-טקסט תרבותי כמו הלקוחות שלנו.

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

מחפשים צוות שמבצע בעצמו מהאפיון ועד המסירה? דברו איתנו.