חברת פיתוח תוכנה בישראל

שלושה ספקים, שם אחד

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

«בית תוכנה» או «חברת תוכנה»

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

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

ארבעת הסעיפים שקובעים אם המערכת שלכם

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

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

שתי שאלות שמנבאות את התוצאה

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

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

מה קובע את לוח הזמנים והמחיר

שני מספרים, ושניהם ניתנים לספירה אצלכם לפני שמדברים עם ספק:

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

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

מתי נוכחות בישראל באמת נדרשת

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

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

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

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

איך אני עובד על זה

עיסוק בתחום מאז 2004, עבודה על מערכות AI מאז 2023, פרויקטים ללקוחות בארבע עשרה מדינות. אני השורה השלישית בטבלה למעלה: ארכיטקט עצמאי, לא בית תוכנה ולא ספק כוח אדם. לזה יש תוצאה שכדאי לומר במפורש, כי היא הסיבה לקרוא את הדף הזה כמשהו אחר מטיעון מכירה: מכיוון שאני לא מוכר תפוקת פיתוח, המסקנות «הגדירו את מה שכבר קניתם», «זה מתאים לצוות זול יותר במקום אחר» ו«אתם צריכים שני מתכנתים בפנים ולא ספק» לא עולות לי כלום, ולכן אני מגיע אליהן כשהן נכונות.

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