אוטומציה עסקית - עוד קצת על דרישות

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

ישנם שלושה סוגי דרישות:

1. דרישה עסקית - מבטאת את הרצון של הלקוח, מה הלקוח רוצה להשיג באופן כללי / על מה הוא מוכן ורוצה להשקיע את הכסף שלו.

2. דרישה פונקציונלית - מבטאת ביתר פירוט: מה אני רוצה להשיג.

3. דרישה טכנית - מבטאת איך אני רוצה להשיג.

הבדל בין דרישה עסקית לפונקציונלית

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

אז מדוע יש חילוק בניהם?

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

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

כשקיבלתי את הדרישה הזאת, הבנתי (וכנראה לא רק אני) שמטרתה היא יעילות בזמן והפיכת פעולה ידנית לאוטומטית.

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

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

ואי אפשר בלי אנלוגיה - דרישה עסקית ללא סיבה היא כמו חץ שנורה לעבר מטרה לא נכונה.

על מה חשוב להקפיד בכל פרויקט?

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

דווקא בגלל סיבה זאת, חשוב לדעת על מה אסור לוותר באף פרויקט - ולא משנה מה גודלו:

• דרישה עסקית - דרישה וסיבה.

• דרישות טכניות בסיסיות.

• אפיון המחליף את הדרישות הפונקציונליות.

צמצום סיכונים

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

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

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

אז מה הפתרון לסיכון הזה?

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

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

אהבתם?

מוזמנים להרשם מטה לקבלת פוסטים נוספים.