ענקית או בוטיקית, זולה או מקצוענית, בארץ או Offshore, כזו שידה בכול או בעלת התמחות נישתית - שוק בתי התוכנה הוא אוקיינוס אדום של אפשרויות. בתוך הסבך הזה קל מאוד ללכת לאיבוד. איך בוחרים?כיצד מתמחרים? מאיפה בכלל מתחילים? ומה צריך לעורר סימני שאלה?
הצעד הראשון בבחירת בית תוכנה הוא בירור עומק של הארגון עם עצמו: מה בעצם רצינו להשיג? האם זה מוצר או שירות שנבנה מאפס, או שמא מתיחת פנים למוצר קיים? האם הולכים על מודל Outsource מלא, או שמדובר ב-Extension כלשהו של ה-IT הארגוני? יחסים ארוכי טווח, או פרויקט נקודתי? ואולי עוד קודם: מהן היכולות והטכנולוגיות שכבר קיימות בארגון, ומהם הפערים?
ארגונים נופלים בזה שוב ושוב: נכנסים לפרויקטים גדולים מבלי להבין לשם מה. זה לגמרי לא עניין טריוויאלי: לכל שאלה כזאת, בשילוב גודל התקציב העומד לרשותנו, יש משמעות מרחיקת לכת בבחירת בית התוכנה. שלב תיאום הציפיות קודם כול עם עצמנו - הפיצ'רים הנדרשים, תקרת ההוצאה, הדחיפות ומשך הזמן המקסימלי שניתן להקצות לפרויקט, אם כדאי מלכתחילה לדאוג להתאמה לשפת התוכנה הקיימת, המיגרציה של הדאטה הארכיוני - כל אלה חיוניים לבירור מוקדם. המשמעות אינה התקבעות בדרישות, אלא הגדרת בסיס ראשוני להתקדמות.
לאחר הבהרת הנקודות הקריטיות וחידודן, אפשר לצאת לדרך. באופן טבעי, את החיפוש הראשוני מומלץ להתחיל בסביבה המוכרת: בקשת המלצות, קריאת ביקורות, אולי גם כינוס כמה פגישות גישוש לא רשמיות. עוד ב-To-do list שלנו: מומלץ מאוד לעבור על הפורטפוליו של החברות המציעות, לוודא שאיננו מעורפל מדי, ולהתנסות באפליקציות ובפיצ'רים דומים לאלה שאנחנו מתכננים. כדאי לחפש ביקורות ודירוגים באתרים אובייקטיביים יותר, ולא להסתפק בהמלצות הגנריות שבאתר התדמיתי. ואפרופו, אם האתר הוא מה שנקרא "חצי כוח" - זו בהחלט נורת אזהרה. הסנדלר אולי הולך יחף, אבל לא כדאי לבנות על זה.
פחות זה יותר
יש משהו קוסם בחברה שמעסיקה עשרות מתכנתים החולשים על כל סוגי הטכנולוגיות. כדאי רק לוודא כמה מזה רלוונטי לצורך שלנו כארגון. אם אנחנו מחפשים פתרון UX-י, פריצות דרך בעולמות הIoT- פחות יעזרו לנו. אם יש לנו אתגר סביב שימור הדאטה בענן, יכולות כמו למידת מכונה הן במקרה הטוב nice to have. ככלל, יש שיעדיפו התמחות בנושא ספציפי על פני ריבוי טכנולוגיות בפורטפוליו. לפעמים, כמאמר הקלישאה, פחות זה יותר.
באשר לגודל החברה המועמדת שלנו, הנה כלל אצבע שכדאי לשקול: להעדיף חברה פחות או יותר מאותו סדר גודל כשלנו. מול בית תוכנה גדול בהרבה, לא בטוח שנזכה ליחס ה-VIP, תשומת הלב ולוחות הזמנים שאנחנו מצפים לקבל, או שנראה בצד השני תחושת Ownership, מוטיבציה כנה ושותפות אמיתית. מנגד, לחברה קטנה בהרבה יהיה אולי קשה לעמוד בדרישות הסף של הפרויקט.
לצד גודל החברה, היכולות שלה והפורטפוליו שהיא מציגה, אפשר ללמוד לא מעט מפרקטיקות העבודה שלה. איך היא מנהלת פרויקט? כיצד היא מוודאת שמשימות לא נופלות בין הכיסאות? באיזה אופן אנשיה מתקשרים זה עם זה?אילו כלים טכנולוגיים משרתים אותם בתפעול השוטף? ושאלה בת זמננו: עד כמה היא ערוכה גם לעבודה מרחוק, ממש מהבתים הפרטיים, במקרה ששוב ניאלץ להסתגר?
לא פחות מהטכנולוגיה, חשובים גם יחסי האנוש. בין שמדובר ביחסים לטווח הארוך ובין שבפרויקט נקודתי, אנחנו עומדים לעבוד יחד שעות לא מעטות. חשוב להבין מראש - וגם את זה כדאי לברר מול הממליצים והביקורות - מהי מידת השקיפות שהחברה תנקוט מולנו? כיצד היא "תדלוור" את ההתקדמות? בפרט אם מדובר בפיתוח אג'ילי, שפידבק תוך כדי תנועה הוא חלק מהותי בו.
חברת תוכנה שמאמינה בשיטת BizDevOps (או DevOps 2.0), אשר שוברת את המחיצות בין צוותי הפיתוח, התפעול והצד העסקי, תראה בנו stakeholder טבעי ותחפש את המשוב הזה מיוזמתה. דמו להצגת ההתקדמות וקבלת חוות דעת בסוף כל ספרינט שבועי או דו-שבועי, זו התחלה טובה.
שפה משותפת; אינטרסים לאו דווקא
כדאי לחשוב על התהליך כחיפוש שותף, ולא כלקוח מול ספק קוד. טכנולוגיה, אומרת הסטטיסטיקה, היא רק 40-30 אחוז מההצלחה. אבל גם כימיה, אדיבות ושירותיות לא יספיקו. התקשורת מול בית התוכנה היא קריטית, ונגזרותיה אינן מעטות. חשוב לוודא שבצד השני מבינים היטב את הליבה העסקית, כלומר את הצורך התפעולי-עסקי שלנו ושל הלקוחות שלנו. בלי זה, אין סיכוי שיידעו להציע וליישם את ה-best practice מתוך ראייה רחבה של טכנולוגיות, מתודולוגיות ופתרונות חדשניים.
היבט נוסף נוגע לשפה עצמה. אין כמובן פסול במודל ה-Offshore, כשהמפתחים יושבים מעבר לים. צריך רק להביא בחשבון פערי שפה, תרבות ואזורי זמן. אנגלית היא כמובן חובה. קיים גם מודל של Nearshore, שלפחות מקרב בין השעונים ומאפשר קפיצה מהירה לאתרים השונים. אבל אם יש משהו שתקופת הקורונה לימדה אותנו, ודאי במדינה העשירה בבתי תוכנה כמו ישראל, הרי זה שגם קשרי עבודה טראנס אטלנטיים יכולים לעבוד כאן מצוין.
אבל עם כל הכבוד לשותפוּת, לא תמיד האינטרסים זהים. כדי למנוע חיכוכים מיותרים במורד הדרך, שלא לדבר על תרחישי קיצון כמו תביעות הדדיות, יש סעיפים שחשוב להניח על השולחן ולהבהיר מראש. מי מחזיק בקניין הרוחני של פיתוח מורכב? אצל מי ה-Source code? לא מובן מאליו - ובטח לא דפולטיבי בחוזה - שה-IP נותר שלנו. ובלי זה, עלולה להיווצר בעיה סביב נושא המונטיזציה.
עוד עניינים שמחייבים ליבון מוקדם: שמירת סודיות (NDA), אי תחרות (NCA), פרוטוקולי אבטחה (SSL), התמיכה שלאחר ההטמעה (למשל, על בסיס תיקון באגים בלבד), ועד כמה חשוף השותף ל-database ולשרתים שלנו. לא לכל המפתחים חייבות להיות גישה והרשאה לכלל הדאטה. קיימים גם מודלים של "קופסה שחורה", עם התממשקות טכנית (API) למידע ולשירותי הליבה מבחוץ.
זול מדי זה יקר
בתמחור הפיתוח יש שתי גישות עיקריות: Fixed price או תשלום פר שעות עבודה. על פניו, הגישה הראשונה מפתה יותר עבור הלקוח, אבל יש כאן קאץ' גדול: אם זה "חתול בשק" מבחינת הספק, הוא עשוי לתמחר עד 25% יותר. אפשר להבין אותו: הרי תמיד יש אירועים בלתי צפויים, היקפים שמשתנים תוך כדי תנועה, סבבי תיקונים ועוד עניינים לוטים בערפל.
אם ניתן להציג mockup-ים ו-use cases ברורים, אם יש ספציפיקציות ופרויקטים דומים מהעבר להראות, אפשר בהחלט לשקול את מודל הסכום הקבוע מראש. בפרט אם מדובר בפיתוח תוכנה ליניארי (מודל "מפל המים"). חשוב רק לוודא שכל שלב ושלב בפרויקט תחום היטב בזמן ובתכולה. אם מדובר בפיתוח בשיטה האג'ילית, סביר שתמחור לפי שעות עבודה והוצאות נוספות יתאים יותר.
ממש כמו בחיים הפרטיים שלנו, דרך טובה להיכנס למערכת יחסים היא לעשות את זה באופן מדורג. לבחון את השותף הפוטנציאלי בפרויקט נקודתי, להגדיל אט-אט את ההיקף והמשקל, לראות שיש עם מי לדבר ושהתוצאה משביעת רצון – ורק אז להעמיק את הקשר.
באשר לתקציב, ארגונים נוטים ללכת שבי אחר הצעות זולות מדי, ובסופו של דבר מגיעים להוצאה של פי שניים ויותר מכפי שתוכנן במקור. אם זה בגלל קוד שלא נכתב כהלכה, פחות מדי טסטים, היררכיה שגויה, חוסר בתיעוד או קשיי תחזוקה ועיבוד - החוב הטכני הולך ומצטבר, וכל תיקון רטרואקטיבי גוזל משאבים נוספים. כדאי לזכור: אנחנו לא מחפשים את ההצעה הזולה ביותר, אלא את ההצעה הקוסט-אפקטיבית ביותר; את המשתלמת ביותר מבחינת עלות-תועלת. מצאתם? תעבירו את זה הלאה.
