ספרו את החריגים בתהליך לפני שמשווים תכונות, ואז שאלו מי אחראי לשדרוג הבא. שתי השאלות האלה מכריעות בין מודול מדף לפיתוח מותאם, עם דוגמאות מתועדות.
עיקרי הדברים
- מודול מדף מצטיין בתהליך עם מעט חריגים, ומתחיל להתפרק ככל שרשימת החריגים גדלה.
- החריג היקר אינו זה שקורה נדיר, אלא זה שדורש החלטה אנושית בכל פעם שהוא קורה.
- שינויי גרסה הם עובדה מתועדת ולא הפתעה: Priority מציינת שמגרסה 25.1 עסקאות ה-API עוברות למכסה משותפת לכל המשתמשים, ושהשינוי קורה אוטומטית בשדרוג.
- Shopify מפרסמת גרסה חדשה כל שלושה חודשים, עם תמיכה של 12 חודשים לפחות לכל גרסה יציבה, וחפיפה של תשעה חודשים לפחות בין גרסאות עוקבות.
- מה שלא מגורסן משתנה בלי הודעה. Shopify מסמנת במפורש חלק מהממשקים שלה כלא מגורסנים.
ההחלטה בין מודול מדף לפיתוח מותאם נקבעת בשתי שאלות: כמה חריגים יש לתהליך שלכם, ומי אחראי לתקן כשגרסה חדשה משנה התנהגות. תכונות אינן מבחינות בין השניים. מספר החריגים ובעלות השדרוג כן.
הספירה שקודמת לכל שיחה עם ספק
לפני שמשווים מודולים, מודדים את התהליך. הספירה אורכת שעתיים ומשנה את כל השיחה:
- בחרו תהליך אחד, למשל מהזמנה עד גבייה.
- כתבו את המסלול התקין בשבעה עד תשעה צעדים, בלי תנאים.
- עברו צעד צעד ורשמו כל "אבל" שעולה מהעובדים.
- סמנו לכל "אבל" האם הוא נפתר בכלל קבוע או בהחלטה אנושית.
- ספרו רק את החריגים שדורשים החלטה אנושית. זה המספר שקובע.
- רשמו לכל חריג כמה פעמים הוא קרה בחודש האחרון, לפי נתונים ולא לפי תחושה.
תהליך עם אפס עד שניים חריגים כאלה הוא מקרה מובהק למודול מדף. תהליך עם שישה ומעלה כבר מתנהג כמנוע החלטות, וזו קטגוריית עבודה אחרת לגמרי. באמצע, בין שלושה לחמישה, ההכרעה עוברת לשאלת השדרוג.
מה בכלל נחשב חריג?
חריג הוא כל מקרה שבו שני עובדים עשויים לפעול אחרת באותו קלט. זו ההגדרה המעשית, והיא מייצרת רשימה מדויקת יותר מ"מקרה קצה":
- תנאי מחיר שנקבע בשיחה ולא במחירון.
- מסמך שמפוצל או מאוחד לפי שיקול דעת.
- לקוח שמקבל יחס שונה בגלל היסטוריה ולא בגלל סיווג.
- פריט שמטופל אחרת כי הוא הגיע פגום או חסר.
- אישור שנדרש רק מעל סכום מסוים, ולפעמים מתחתיו.
- החזרה שמזכה בחלקה, בהתאם למצב הפריט.
חריג שהוגדר בכלל כתוב אינו חריג יותר; הוא הפך לתנאי. חלק גדול מפרויקטי הפיתוח המיותרים מתחילים בכך שאף אחד לא הפך חריגים לכללים לפני שביקש הצעת מחיר. ראו מתי לא לבנות תוכנה מותאמת.
מי הבעלים של נתיב השדרוג?
| מה משתנה | במודול מדף | בפיתוח מותאם |
|---|---|---|
| גרסה חדשה של המערכת | הספק מוציא, אתם מחליטים מתי לקבל | אתם בודקים שההתאמה עדיין עובדת |
| התנהגות שהשתנתה בגרסה | הספק מתאים את המודול, בכפוף לתמיכה | האחריות אצלכם, כולל הגילוי |
| שינוי במודל הרישוי או במכסות | חל עליכם ומשנה עלות | חל עליכם וגם מחייב שינוי בקוד אם המכסה נוגעת לממשק |
| ממשק שמפסיק להיות נתמך | הספק אחראי לעדכן | אתם אחראים, ובלוח זמנים של הפלטפורמה |
| בדיקות אחרי שדרוג | לרוב אצל הספק | חייב להיות אצלכם, ורצוי אוטומטי |
| הידע על למה הוגדר ככה | אצל הספק ואצל המטמיע | אצלכם, אם תיעדתם |
השורה האחרונה היא זו שנוטים לזלזל בה. מודול מדף מוריד מכם עבודה טכנית, אבל גם מוציא מהבית את הידע למה התהליך מוגדר כפי שהוא. פיתוח מותאם עושה את ההפך בדיוק.
מה הספקים באמת מפרסמים על שינויי גרסה
אלה דוגמאות מתועדות, לא הערכות. הן מראות שנתיב השדרוג הוא נתון שאפשר לתכנן לפיו:
- Priority מסמנת יכולות בתיעוד עם מספר הגרסה שבה שוחררו, ומסמנת יכולות בפיתוח כ-Beta.
- Priority מתעדת שמגרסה 25.1 כל משתמשי ה-API חולקים מכסת עסקאות אחת, במקום חלוקה שווה בין המשתמשים, ושהשינוי קורה אוטומטית בשדרוג.
- Priority מתעדת שמגרסה 19.1 פורמט השגיאות של ה-REST API הוא JSON ולא XML.
- Priority מתעדת שמגרסה 21.0 אפשר להגדיר אזור זמן פר חברה דרך קבוע המערכת TZSERVER, ומזהירה שזה עלול להוביל להיסט שונה מהצפוי.
- Shopify מתעדת מחזור שחרור רבעוני עם שמות גרסה מבוססי תאריך, תמיכה של 12 חודשים לפחות בכל גרסה יציבה, וחפיפה של תשעה חודשים לפחות.
- WooCommerce מתעדת שמגרסה 8.2 אחסון ההזמנות בטבלאות ייעודיות הוא ברירת המחדל בהתקנות חדשות.
ארבע השורות הראשונות הן בדיוק סוג השינוי שהופך התאמה שעבדה שנתיים למשהו שדורש בדיקה. אף אחת מהן אינה הפתעה, מפני שכולן מפורסמות.
איפה משטח ההרחבה נמצא, ולמה זה משנה
לפני שמחליטים איפה לכתוב לוגיקה, כדאי לדעת אילו נקודות חיבור הספק מפרסם. פורטל המפתחים של Priority מציג, נכון לספטמבר 2026, את המקטעים הבאים: REST API, Web SDK, Priority SDK, Webhooks, ODBC, שרת MCP ואימות OIDC. מבחינת אימות מתועדים שלושה מסלולים: Basic, אסימוני גישה אישיים ו-OAuth2.
ההשלכה המעשית:
- לוגיקה שיושבת על ממשק מגורסן ומתועד ניתנת לבדיקה אוטומטית, ולכן ניתנת לשדרוג.
- לוגיקה שיושבת על התנהגות שאינה מתועדת עובדת עד השדרוג הראשון, ואז נשברת בשקט.
- ככל שיש יותר משטחי חיבור מתועדים, כך גדל הסיכוי שהתאמה תוכל להישאר מחוץ לליבה. זה ההבדל בין התאמה שמתחזקים לבין התאמה שמשכתבים.
- Shopify מסמנת במפורש חלק מהממשקים שלה כלא מגורסנים, ומציינת שהם עשויים להשתנות בכל עת. תלות בממשק כזה היא החלטה, ולא תאונה.
ראו גם Webhooks וטריגרים ב-Priority לגבי איפה כדאי לחבר לוגיקה שמגיבה לאירוע.
צורת העלות, בלי מספרים
- מה שגדל עם מספר החריגים. זה הגורם הדומיננטי, וההשפעה שלו אינה ליניארית: חריגים מתרבים כשהם מצטלבים זה עם זה.
- מה שגדל עם עסקאות. מכסות ממשק נמדדות לרוב בכתיבות ולא במשתמשים, ולכן צמיחה במכירות מזיזה עלות בלי שנוסף עובד.
- מה שגדל עם התאמות. לא זמן הכתיבה, אלא זמן הבדיקה בכל שדרוג.
- מה שגדל עם ותק ההתאמה. התאמה בת חמש שנים שאיש לא תיעד עולה יותר לשנות מהתאמה חדשה.
- מה שנשאר קבוע. תיעוד ההחלטות: למה הוגדר כך, ומה יקרה אם ישתנה.
קשור: בנייה מול קנייה, תוכנה מותאמת מול מוצר מדף.
מקורות
שאלות נפוצות
כמה חריגים מצדיקים פיתוח מותאם?
אין סף מוחלט, אבל יש כלל עבודה שימושי: ספרו רק חריגים שדורשים החלטה אנושית. עד שניים, מודול מדף כמעט תמיד עדיף. משישה ומעלה, אתם מתארים מנוע החלטות. בין שלושה לחמישה, שאלת השדרוג היא זו שמכריעה.
אפשר לשלב מודול מדף עם פיתוח מותאם?
כן, וזו הצורה הנפוצה ביותר בפועל. המודול מטפל במסלול התקין, והפיתוח המותאם מטפל בחריגים בשכבה נפרדת. התנאי היחיד הוא שהגבול ביניהם יהיה מוגדר: איזה נתון נולד איפה, ומי כותב אותו בסוף.
מה בודקים אחרי שדרוג של המערכת?
את החריגים, לא את המסלול התקין. המסלול התקין נבדק על ידי הספק. החריגים הם היחידים שנשענים על התנהגויות ספציפיות, ולכן הם אלה שנשברים. רשימת בדיקות שמכסה את החריגים שלכם היא התוצר הכי שימושי בפרויקט.
איך יודעים אם התאמה נשענת על התנהגות לא מתועדת?
שאלו את מי שכתב אותה להצביע על עמוד התיעוד שמתאר את ההתנהגות שהיא מסתמכת עליה. אם אין עמוד כזה, ההתאמה נשענת על תצפית ולא על התחייבות. זה לא בהכרח פסול, אבל זה חייב להירשם כסיכון ידוע.
להמשך קריאה
שירות רלוונטי
מערכות בהתאמה אישית
המערכת הפנימית שמחליפה את הגיליון שגדלתם ממנו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.