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

אף על פי שהתחלתי לתכנת לפני עשרים שנים בערך, MBM הוא רק התוכנה המסחרית השניה שלי – מסחרית במובן של תוכנה מלאה שמבצעת משימות רבות, שמישהו משלם עליה כסף טוב, ושאם היא לא תעבוד כמו שצריך יקרו דברים רעים. אני כותב אותה בשפת Object Pascal בסביבת הפיתוח החדשה והמהממת Delphi XE2, אבל על כך בהזדמנות אחרת. את התוכנה המסחרית הראשונה כתבתי בשנת 2004, וזו היתה תוכנה לניהול אולם סוקרים.

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

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

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

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

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

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

המשך יבוא. בינתיים, חג פסח שמח לכולם!