כמה עולה פיתוח בפריוריטי?

שאלה שחוזרת

גובים על אפיון?

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

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

איך מחייבים

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

כשיורשים פיתוח של מישהו אחר

החלק היקר הוא ההבנה — ואותו אנחנו מקצרים

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

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

ולמה הביצועים בדרך כלל משתפרים

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