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

מחקרים וספרים שנכתבו לאורך עשרות שנים, החל מ- An Information System Manifesto  של ג'יימס מרטין מ- 1984, דרך מחקר של IBM משנת 2006 ועד ה- Business Analysis Benchmark השנתי של פירמת הייעוץ IAG שנערך לאחרונה ב- 2008, מצביעים על קורלציה עמוקה בין החשיבות המיוחסת לעבודת ניתוח ואפיון המערכות לבין סיכויי ההצלחה של פרויקטי תוכנה.

ועדיין – שוב ושוב צפים הנתונים שמספרים לנו את מה שאנחנו כבר יודעים:

"טעויות באפיון הן המקור לרוב שגיאות בפרויקטי תוכנה"  - פורסטר, 2008

"בממוצע, 50% מזמן הפרויקט מוקדש לסבבי ניסוי וטעייה"   - CHAOS report, 2007

"בעיות באפיון הינן אחת מהסיבות המרכזיות לכישלונם של פרויקטים"   - פורסטר, 2008

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

לעניות דעתי זה כן אומר כמה דברים:

• החשיבות המיוחסת והזמן המוקצה לאיסוף וניסוח דרישות אינם מספיקים

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

• הכלים התומכים הניתנים למנתחי המערכות הם מועטים, חלקיים ולא מתאימים (במקרה הטוב)

• שיטות העבודה של מנתחי המערכות אינן כוללות פעולות אימות ותיקוף (validation and verification) מול הלקוחות, ודרישות הלקוח לא ממומשות במוצר הסופי

• ועוד ועוד...

מה דעתכם? איך זה שפרויקטים ממשיכים להיכשל בגין תכנון לקוי?

אריאל בן יוסף

iBridge - ניתוח מערכות מידע

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

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

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

מסקנה: לא ניתן לאפיין הכל מראש.

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

זיו -

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

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

אריאל

אני שואל את עצמי כבר שנים: מדוע גם אחרי ההתקדמות הטכנולוגית הפנטסטית (שהעניקה לנו כלים), ופיתוח שיטות חדשניות ומוכחות (כדוגמת Agile), עדיין נכשלים פרוייקטים בהמוניהם?

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

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