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

 


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

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

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

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

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

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

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

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

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

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

בעלי העניין

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

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

לדעת לשאול את השאלות הנכונות ולתעד

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

להתמקד בצורך העסקי או ביכולות של הכלי?

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

אישור הדרישות

כשהאפיון היה מוכן, הוא נשלח ללקוח לאישור.

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





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

שלב הפיתוח והיישום

בחזרה לאותו פרויקט...

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

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

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

לסיכום

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

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



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

תגובות

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

    השבמחק
  2. מאמר מאד מקצועי - תודה רבה. אין ספק שהגדרת דרישות לפרוייקט הוא החלק המשמעותי ביותר בהצלחת הפרוייקט

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

      מחק
  3. כמנהלת פרוייקטים אני נתקלת בזה לא מעט. מתחברת מאד למה שכתבת

    השבמחק

הוסף רשומת תגובה

פוסטים פופולריים מהבלוג הזה

איך ההרצאה הראשונה שלי בבית ספר הכינה אותי לחיים המקצועיים?

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

לא רופאה, אבל מנתחת