פיתוח תוכנה בהתאמה אישית

שלוש אפשרויות, לא שתיים

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

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

בדיקה שאפשר לעשות לפני שמדברים עם מישהו

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

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

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

מה מייקר פיתוח בהתאמה אישית

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

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

למה חברות עם מערכת עובדת מחליפות אותה

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

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

שלוש אלה הן תלונות ארכיטקטוניות ולא פונקציונליות, והחלפה שנבחרה לפי טבלת פונקציות נוטה לשחזר את שלושתן.

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

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

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

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

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

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