ניתוח עסקי אפקטיבי בתעשיית ה- IT: צמצום הפרוייקט (1) סיכון (2) עלויות (3) משך

admin

כמה דברים לדון בהם

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

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

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

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

מי צריך לבצע ניתוח עסקי?

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

  • מהנדס תוכנה
  • ראש צוות
  • מנהל הפרויקט
  • מנהל מחלקת IT

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

אילו משימות מבצע אנליסט עסקי?

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

  • איסוף מטרות הפרויקט
  • יצירת היקף הפרויקט
  • זיקוק היקף הפרוייקט לדרישות הפרויקט
  • צמצום דרישות הפרויקט למפרט הטכני של הפרויקט

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

תרגיל 1: איסוף מטרות הפרויקט

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

הנה כמה טעויות נפוצות כי אנליסטים עסקיים שאפתנים יעשה בשלב זה:

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

פעולה 2: יצירת היקף הפרויקט

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

פעולה 3: שיפור של מטרות הפרויקט לדרישות הפרויקט

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

ישנם שני סוגים של דרישות הפרויקט חשוב:

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

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

  • השתמש במודל תרחיש במקרה
  • דיאגרמות של יחסי גומלין
  • דיאגרמות רצף
  • UML דוגמנות

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

פעולה 4: שיפור דרישות הפרויקט במפרט הטכני של הפרויקט

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

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

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

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

Leave a Reply