הגישה המסורתית לניהול פרויקטים (Waterfall) פותחה כדי להתמודד עם פרויקטים שבהם נקודת הפתיחה ידועה והמטרה ברורה. בפרויקטים כאלו יש מספר שלבים המוגדרים מראש ומבוצעים בצורה רציפה. בהתאם, הגישה המסורתית למבנה הארגוני הייתה מבנה היררכי מורכב המבוסס על צוותים פונקציונליים (מיומנויות ומקצועות אחידים).
שלבי הפרויקט היו עוברים בין הצוותים הפונקציונליים עם התקדמות הפרויקט. בכל שלב כל צוות ביצע את חלקו והעביר את התוצרים הלאה לצוות הבא, כאשר בכל שלב טיפלו בכל התכולה (Features) של הפרויקט בו זמנית והערך ללקוח נוצר רק בסוף התהליך (ציור מספר 1). המיקוד של הארגון היה בהשלמת משימות. לדוגמא, ארגון פיתוח עסק במשימות כגון איסוף דרישות, אפיון הדרישות ,פיתוח, בדיקות, אינטגרציה ומסירה ללקוח. המעברים בין הצוותים (Handoffs) גרמו גם לאיבוד ידע רב. כמות הממשקים והתלויות בין הצוותים הפונקציונליים הייתה גדולה ולכן חלק נכבד מתשומת הלב הניהולית הוקדשה לתיאום בין הצוותים.
הגישה המסורתית לניהול פרויקטים (Waterfall) פותחה כדי להתמודד עם פרויקטים שבהם נקודת הפתיחה ידועה והמטרה ברורה |
ציור מספר 1
בעולם ה-Waterfall תהליך הבדיקות, הוא שלב בפרויקט. לבודקים הייתה נקודת התחלה וסיום – בד"כ לקראת סיום הפרויקט. במקרים רבים הבודקים מהווים "שומרי סף" - Gate Keepers שמאשרים שחרור תוצרים. מנקודת המבט של ציר הזמן, שלב זה עלול להגיע מאוחר מדי (Late feedback). במצב של ריבוי תקלות (Bugs) קשה מאד לתקן את כולן בזמן סביר ולכן חלק מן התקלות מגיעות לסביבות הייצור. חשוב להזכיר שככל שהתקלות נמצאות מאוחר עלות תיקון התקלות הולכת ועולה בצורה משמעותית.
במציאות העסקית הנוכחית של אי וודאות ומורכבות, הגישה המסורתית אינה רלוונטית יותר. כדי להתמודד עם פרויקטים מורכבים דרושים צוותים בעלי מיומנויות מגוונות (מולטי-פונקציונליים). לארגונים הרוצים להישאר תחרותיים אין היום את הפריווילגיה להגיב לאט למצבים המשתנים ולכן המיקוד הוא ביצירת ערך מהיר ללקוחות ולא בהשלמת משימות. כדי להתמודד עם המצבים המשתנים, פותחו תפיסות חדשות כגון Agile או Lean-Agile. בהתאם, בסביבה אג'ילית הגישה למבנה הארגוני היא מבנה היררכי "שטוח" המבוסס על צוותים מולטי-פונקציונליים המכילים את כל המיומנויות והכישורים הדרושים לביצוע העבודה. לדוגמא, צוות יכלול מפתחים ובודקים שיכולים לסיים משימה בשלמותה ולייצר ערך מהיר ללקוחות (ציור מספר 2). כל דרישה עסקית (Feature) תעבור את כל השלבים עד להשלמתה ואישורה על ידי הלקוח, שבד"כ מיוצג על ידי ה-Product Owner עם מינימום תלויות בצוותים אחרים. כמות הממשקים של צוות מולטי-פונקציונלי קטנה משמעותית מצוותים פונקציונליים. מקבץ הכישורים השונים מאפשרים לצוות לבנות ולמסור תוצרים המבוססים על הדרישות העסקיות במהירות. כך גם כמות המעברים (Handoffs) ואיבוד הידע קטנים בצורה משמעותית ומגבירים את האפקטיביות של הארגון.
ציור מספר 2
בעולם ה-Agile תהליך הבדיקה, הוא משימה בפרויקט. לבודקים אין נקודת התחלה וסיום. הם מעורבים בכל שלבי הפרויקט ובכל הדרישות העסקיות (Features) החל משלב התכנון. מנקודת המבט של ציר הזמן, שלב זה בפרויקט מגיע מוקדם (Early feedback). כיון שהעבודה של הצוות היא על כל דרישה עסקית (Feature) בנפרד, כל תקלה מתוקנת מיידית ומאושרת. לכן, עלות התיקון נמוכה ומעט תקלות מגיעות לסביבות הייצור.
בצוות מולטי-פונקציונלי הבודקים מעורבים כבר משלב התכנון ולכן הם שותפים בכל פעילויות הצוות. זהו מצב של "איכות מובנית" בתהליך (Built-In Quality) שבו הבודקים אינם "שומרי הסף" (Gate Keepers) של הארגון אלא חלק אינטגרלי בתהליך. האחריות לאיכות וההחלטה על שחרור תוצרים עוברת לצוות. ההקדמה בציר הזמן של מעורבות הבודקים בתהליך הייצור מכונה "העברה לשמאל" – Shift Left.
כדי לאפשר לצוותים האג'יליים לעבוד בצורה אפקטיבית יש להגדיר דרישות עסקיות קטנות ככל האפשר המייצרות ערך ללקוח. ארגון אג'ילי מבוסס על צוותים מולטי-פונקציונליים שמשקיעים זמן קצר בבניית יחידות ערך קטנות (דרישות עסקיות). רק כך היתרון של מקבץ הכישורים השונים בצוות יבוא לידי ביטוי. הצוותים המולטי-פונקציונליים ימסרו את התוצרים המבוססים על הדרישות העסקיות באופן מדורג (Incremental). כל תוצר עסקי מוכן יימסר ללקוח לאישור (Acceptance) ולכן הצוותים יוכלו לייצר ערך מהיר ללקוחות. כיון שהעבודה תהיה על יחידות קטנות והתכנון יהיה לטווח קצר, היכולת להגיב לשינויים ולמנוע בזבוזים (Waste) תשתפר משמעותית.
בארגון אג'ילי ישנו דגש רב על האוטונומיה של הצוותים המולטי- פונקציונליים. על בסיס הדרישות העסקיות הצוות הוא זה שמעריך את גודל העבודה (Sizing) הדרושה כדי להשלים את התוצרים. ההערכה כוללת בתוכה את משימות הבדיקה כיון שהצוות אחראי על איכות התוצרים שלו. בהמשך הוא זה שמתכנן ומתחייב לתארכי מסירה לפי תאריך או לפי מסגרת זמן (Sprint/Iteration) ולתיאום עם הצוותים האחרים. אם ישנם מכשולים (Impediments) בדרך להשלמת התוצרים הצוות אחראי להעלות אותם בפני הגורמים הרלוונטיים. מדידת הצוותים תתבסס על ההערכות והתחייבויות של הצוות. תוצרי המדידה ישמשו בין השאר כנתונים לתהליך התחקור שהצוות מבצע (Retrospective) שמהווה את הבסיס לשיפור
כדי לאפשר לצוותים האג'יליים לעבוד בצורה אפקטיבית יש להגדיר דרישות עסקיות קטנות ככל האפשר המייצרות ערך ללקוח |
המתמיד של הצוות (Continuous Improvement).
ארגון המתבסס על צוותים מולטי- פונקציונליים צריך לבנות מערך תומך של תהליכי Lean-Agile ליצירת שרשרת ערך אפקטיבית. התהליכים החדשים יחדדו תפקידים קיימים ויגדירו תפקידים חדשים. לדוגמא, ארגון המדגיש שיתוף פעולה רציף עם הלקוחות (Customer Collaboration) צריך להגדיר תפקיד שמקשר בין הלקוח לבין הצוותים ומשמש "קולו של הלקוח" (Voice of the Customer). זהו בעצם ה-Product Owner שמגדיר ומתעדף לצוותים את ה-Backlog (הדרישות העסקיות) ומאשר את התוצרים עם סיומם. אישור התוצרים משמעותו שהצוות עמד בדרישות העסקיות במלואן ובכך יצר ערך משמעותי ללקוח. בנוסף, בעלי המקצוע השונים בצוותים חייבים מעטפת מקצועית של מומחים מתחומים שונים (SME - Subject Matter Experts). אלו יכולים להיות מנהלי פיתוח או בדיקות שיהיו אחראים על קביעת סטנדרטים מקצועיים לעבודה, הכשרת עובדים, פתרון בעיות מקצועיות, הנחייה ועוד.
הטמעת גישות אג'ייל המבוססות על צוותים מולטי-פונקציונליים יכולה להתבצע בכל ארגון, ללא קשר לסוג התוצרים שלו: פיתוח, שירות, ייצור ועוד. ארגונים שאמצו גישות אג'יליות ומתבססים על צוותים מולטי-דיציפלינריים חווים שיפור משמעותי באפקטיביות ובמהירות מסירת התוצרים העסקיים שלהם. חשוב לציין שהשינוי המבני, שבדרך כלל הוא חלק מהטמעת תפיסה אג'ילית בארגון, הוא תהליך איטי. ארגונים שונים פותרים את הנושאים הנ"ל בצורות שונות בכפוף לצרכים ולאילוצים שלהם.
בהצלחה.
https://www.linkedin.com/in/izipeled
054-3104023