פיתוח תוכנה לפי דרישה

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

לכל עסק יש משימות שוטפות שמבוצעות בקביעות ע"י תוכנות המדף שהוא רכש. השאלה מה עושים עם משימה שתוכנת המדף לא ערוכה לבצע?

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

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

קושי זה מרתיע עסקים רבים מלפתח יישומים משלימים גם כשברורה להם התועלת העצומה שיכולה להיות להם.

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

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

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

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

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

מדוע זה קורה?

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

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

לכן לפני שאתה פונה למפתח, הקדש הרבה זמן ומחשבה לשאלות הבאות:

  1. מה מטרתו של היישום?
  2. איזה בעיות הוא אמור לפתור?
  3. איזה יכולות צריכות להיות לו ?
  4. כיצד נראית רשימה מלאה של כל מה שיישום ידע לעשות בפרטי פרטים?
  5. איך יראה הממשק להזנת הנתונים ליישום? (אם יש כזה)
  6. איך יראה הפלט של היישום? (דוחות, תדפיסים, תוצאות חישובים, טבלאות גרפים וכו)

בשלב הבא:

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

 

כלל שני – סגור באופן סופי את נושא העלות –  עוד לפני תחילת הפיתוח.

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

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

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

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

כלל שלישי – הקפד לקבל מהמפתח הסכם כתוב לפני אישור הפרויקט

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

הסכם זה חייב לכסות את הנושאים הבאים לפחות:

  1. המפרט המדויק של היישום
  2. לוח זמנים סגור מראש להשלמתו
  3. עלות סופית מוסכמת מראש ותנאי התשלום.
  4. אחריות המפתח לתקינות היישום

כמובן שיתכנו גם סעיפים נוספים שיש לסכם בכתב  – לדוגמא: במקרים של יישום גדול – כדאי לסכם מראשון גם לוח זמנים לשלבי ביניים.

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

בהצלחה!