למרות שהתפיסה האג'ילית צמחה בארגוני תוכנה עבור פרויקטי תוכנה, מסתבר שניתן ליישם את עקרונותיה גם לפרויקטים שאינם פרויקטי תוכנה. אחד המאפיינים המשותפים לפרויקטים אלה, המצביע בברור על התאמתה של התפיסה האג'ילית לניהולם, הוא הקושי לחזות מראש את צורת מוצרם הסופי. לכן, בדומה לתהליכי פיתוח פרויקטי תוכנה, יש לנהלם בתהליך המאפשר הבנה הדרגתית של מהות וצורת המוצר הסופי, הכנסת שינויים, והבעת מגוון דעות
פורסם 02/04/13 צילום: shutterstock
הקדמה
מה משותף לפרוייקטים כמו הטמעת ערכים ארגוניים, בניית מערך להערכת עובדים, ותכנון לו"ז לפרוייקט חדש במדינה לא מוכרת? בין השאר, פרוייקטים אלה מאופיינים באי הידיעה מה תהיה תוצאתם הסופית וכן מהי הדרך בה ילך הארגון בסופו של דבר במהלך הפרוייקט. יחד עם זאת, במקרים רבים, מיד לאחר קבלת החלטה על ביצועם של פרוייקטים מסוג זה, קיימת נטיה לתכננם לפרטי פרטים למשך תקופה ארוכה (נניח שנה), כאשר התכנון מופקד בידי קבוצת עובדים קטנה בארגון. במקרים כאלה, על מתכנני הפרוייקטים להניח הנחות רבות שאינן מתגשמות בסופו של דבר ממספר סיבות.
ראשית, חלק מהשינויים המבוצעים בתחילת הפרוייקט, הופכים את התהליכים המתוכננים בהמשכו ללא רלוונטיים היות והתנאים הארגוניים השתנו; שנית, הבנתם של המעורבים בפרוייקט משתפרת ככל שמתקדם הפרוייקט, ולאורה של הבנה זו, מסתבר לעיתים שיש לבצע מהלכים שונים בהמשך מאלו שהוחלט עליהם בתהליך התכנון; ולבסוף: מסתבר שבתהליך התכנון המוקדם שולבו פעילויות שאין בהן צורך בסופו של דבר, או לחילופין, מתבהר כי יש לשלב בפרוייקט אלנטים חדשים שלא היה ידועים בתהליך תכנונו.
תופעות אלה אינן מאפיינות רק תהליכים ארגוניים בהם עוסקים/ות מנהלים בכלל ומנהלי/ות משאבי אנוש בפרט. אחד התחומים בהם בעיות אלה באו לידי ביטוי וגרמו להפסדים משמעותיים הוא פיתוח תוכנה. בעיות מסוג זה הביאו לגיבושה של התפיסה האג'ילית לפיתוח תוכנה ((Agile Software Development בעשור הראשון של המאה הנוכחית. גיבושה של הגישה התרחש דווקא בהקשר לפרוייקטי תוכנה, משתי סיבות. ראשית, פיתוח תוכנה הוא פרוייקט לא מוחשי שיש לו השלכות פיננסיות מוחשיות (בשונה למשל מפרוייקטים של שינויים תרבותיים שהשלכותיהם הכספיות אינן ברורות תמיד). שנית, אחוז הכשלונות של פרוייקטי תוכנה היה כה גדול (הן במונחי עלות ואין במונחי איחור בלוחות הזמנים), כך שמנהלי הפרוייקטים ולקוחותיהם לא יכלו יותר להתעלם מבעיות אלה.
כיום, התפיסה האג'ילית לניהול פרוייקטי תוכנה מיושמת בפרויקטי תוכנה רבים בעולם ומציעה אלטרנטיבה לגישות מסורתיות לפיתוח תוכנה. הנתונים מלמדים כי פרויקטי תוכנה המיישמים מתודולוגית פיתוח אג'ילית מצליחים להתמודד בהצלחה עם הבעיות המאפיינות פרויקטי תוכנה. כך למשל, על פי סקר שנערך בשנת 2010 ע"י חברת [1]VersionOneוהמבוסס על בחינתם של אלפי פרויקטי תוכנה שפותחו בתהליך פיתוח אג'ילי, מסתבר כי 70% מהפרויקטים שנסקרו קיצרו את זמן הפיתוח (time to market)ו- 65% מהפרויקטים שפרו את איכות התוכנה. הנתונים מראים על שיפורים גם בניהול שינויים, במוראל חברי צוות הפיתוח, ובתיאום הציפיות בין העוסקים בפיתוח התוכנה לעוסקים בפן העסקי בארגונים שנסקרו. ממצאים דומים נמצאו בסקרים קודמים שבוצעו ביחס לפיתוח תוכנה אג'ילי.
במאמר זה אציג תחילה את התפיסה האג'ילית (סעיף 2) ולאחר מכן אדגים את יישומה לניהול פרויקטים שאינם פרויקטי תוכנה (סעיף 3).
פיתוח תוכנה אג'ילי
משמעות התואר Agile היא זריז, גמיש, והוא מתייחס ליכולתו של גוף להתאים את עצמו כראוי לסביבה משתנה. הניסיון המצטבר ביחס לניהול פרויקטי תוכנה מלמד שרצוי שגם תהליכי פיתוח תוכנה יהיו בעלי תכונות אלה. בפרט, התפיסה האג'ילית לפיתוח תוכנה מבוססת על הנחת העבודה כי תהליכי פיתוח תוכנה מאופיינים בשינויים רבים, ולכן, יש לבנות עבורם מנגנון ניהול המתמודד בהצלחה עם מאפיין זה. בנוסף, התפיסה האג'ילית שמה את הדגש על פיתוח תוכנה איכותית, הן מבחינת קיום דרישות הלקוחות והן מבחינת העדר באגים. רעיונותיה של התפיסה האג'ילית מיושמים באמצעות מספר מתודולוגיות פיתוח תוכנה אג'יליות, כמו למשל, Extreme Programming, Lean Software Development, Crystal, Scrum,.
בהמשך הסעיף זה, אתאר את עקרונות הגישה האג'ילית ופרקטיקות עקריות ביישומה.
עקרונות התפיסה האג'ילית לפיתוח תוכנה
להלן אציג את המנשר (מניפסט) של התפיסה האג'ילית, המכיל ארבעה עקרונות. כהקדמה לסעיף 3, הקוראים מתבקשים לחשוב על מידת הרלוונטיות של עקרונות אלה לפרוייקטים שאינם פרוייקטי תוכנה.
Individuals and interactionsover processes and tools – עקרון זה מנחה את הסטת המיקוד מהתהליכים והכלים המעורבים בפרוייקט אל האנשים המעורבים בו. על פי עקרון זה, יש להשקיע משאבים בכלי הפיתוח, אך יש להדגיש ולהשקיע יותר בתמיכה בגורם האנושי ולעודד שיתוף הפעולה בין בעלי העניין השונים.
Working softwareover comprehensive documentation – עקרון זה משדר את המסר כי ייעודם של פרויקטי תוכנה הוא ייצור תוכנה באיכות גבוהה. על-פי עקרון זה, מתודולוגיות פיתוח המייצרות תיעוד מקיף, המעכב את תחילת הפיתוח (לעיתים בסדר גודל של שנים), אינן מאפשרות להתמודד בהצלחה עם העובדה שתהליך פיתוח תוכנה מאופיין בשינויים רבים, וכתוצאה מכך, במקרים רבים, מסמכי האפיון והתכן של מוצרי תוכנה אינם תואמים את מוצר התוכנה עצמו. לעומת זאת, מתודולוגיות פיתוח תוכנה אג'יליות מתמקדות בפיתוח איכותי של המוצר, תוך ייצור רק אותם מסמכים שיש להם ערך עבור המפתחים והלקוחות.
Customer collaborationover contract negotiation – עקרון זה משנה את תפיסת מיקומם של הלקוחות בניהול פרוייקטים. בשעה שמתודולוגיות פיתוח תוכנה מסורתיות אינן מבוססות לעיתים על קשר רצוף עם הלקוחות, וכך לעיתים, מוצרי התוכנה המפותחים על-ידן אינם מתאימים בסופו של תהליך הפיתוח לצרכי הלקוחות, תהליכי פיתוח תוכנה אג'ילים מבוססים על קשר ושיתוף פעולה רציפים עם הלקוחות, המאפשרים להתמודד בהצלחה עם השינויים התכופים המאפיינים פרויקטי פיתוח תוכנה.
Responding to changeover following a plan – עקרון זה מנחה מתודולוגיות פיתוח תוכנה אג'יליות להוביל תהליך פיתוח המאפשר להתמודד בהצלחה עם שינויים, תוך שמירה על איכות תוכנה גבוהה. בניגוד למתודולוגיות פיתוח תוכנה מסורתיות הבולמות לעיתים הכנסת שינויים, מתודולוגיות פיתוח תוכנה אג'יליות מנחות תהליך פיתוח המקדם בברכה הכנסת שינויים המתבקשים בעקבות הבנה טובה יותר של דרישות המערכת המפותחת ככל שמתקדם תהליך הפיתוח, מבלי להביא לגידול בעלות יישום שינויים.
יישומה של התפיסה האג'ילית לפיתוח תוכנה
כאמור, פיתוח תוכנה אג'ילי מיושם על ידי מספר מתודולוגיות פיתוח תוכנה שכל אחת מהן מיישמת את רעיונות התפיסה האג'ילית באופן המייחד אותה. למתודולוגיות אלה מספר מאפיינים משותפים, שחלקם מוצגים להלן. גם כאן, הקוראים מוזמנים לבחון את יישומם לפרוייקטים שאינם פרוייקטי תוכנה.
גרסאות ואיטרציות קצרות (short releases and iterations): תהליכי פיתוח תוכנה אג'ילים מבוססים על גרסאות קצרות (של כחודשיים) המחולקות לאיטרציות של שבוע-שבועיים, שבמהלכן אין משנים את שהוגדר ע"י הלקוח/ה כתכולת האיטרציה. בסיומה של כל איטרציה, התוכנה מוצגת ללקוח/ה לקבלת משוב ולקביעת הדרישות שתפותחנה באיטרציה הבאה.
צוות שלם (whole team): מושג זה מתייחס לעובדה שעל צוות הפיתוח להיות מורכב מכל בעלי התפקידים המשתתפים בתהליך פיתוח התוכנה. במילים אחרות, התפקידים הנלווים לפיתוח עצמו (כמו, ניתוח מערכות ובדיקות) משולבים בעבודת צוות הפיתוח. רעיון זה בא לידי ביטוי במספר אופנים. למשל, צוות הפיתוח יושב בחלל אחד המעודד תקשורת פנים אל פנים, וכל חברי הצוות משתתפים בהצגת המוצר ללקוחות בכל איטרציה ובשמיעת דרישות הלקוחות.
בדיקות מקיפות ((exhaustive testing:תהליכי פיתוח תוכנה אג'ילים מייחסים חשיבות לבדיקות יחידה (unit tests) ובדיקות קבלה (acceptance tests) אוטומטיות, כך שניתן להריצן ללא מאמץ בכל שלב של פיתוח המערכת, לבדוק גם פיתוח קודם (regression tests), ולוודא שהכנסת שינויים עברה בהצלחה ללא הכנסת באגים חדשים. בדיקות אוטומטיות אלה משולבות בתהליך הפיתוח עצמו.
שיתוף פעולה עם הלקוח/ה ((customer collaboration: מתודולוגיות פיתוח תוכנה אג'יליות משלבות את לקוחות הפרויקטים בתהליך הפיתוח. כך, ניתן בכל עת לקבל משוב ישיר מהלקוחות ולהתקדם בהתאם לצרכיהם, מבלי להניח הנחות על צרכים אלה, שלעיתים מתבררות כמוטעות.
מדדים (measures): על מנת לנווט את תהליך הפיתוח כך שהמוצר המפותח יפותח באיכות גבוהה, תהליכי פיתוח תוכנה אג'ילים מלווים במדדים עליהם מחליטים בעלי העניין בפרויקט בהתאם לצרכיהם.
יישום הגישה האג'ילית לניהול פרויקטים: לאו דווקא לפרויקטי תוכנה
למרות שהתפיסה האג'ילית צמחה בארגוני תוכנה עבור פרויקטי תוכנה, מסתבר שניתן ליישם את עקרונותיה גם לפרויקטים שאינם פרויקטי תוכנה. אחד המאפיינים המשותפים לפרויקטים אלה, המצביע בברור על התאמתה של התפיסה האג'ילית לניהולם, הוא הקושי לחזות מראש את צורת מוצרם הסופי. לכן, בדומה לתהליכי פיתוח פרויקטי תוכנה, יש לנהלם בתהליך המאפשר הבנה הדרגתית של מהות וצורת המוצר הסופי, הכנסת שינויים, והבעת מגוון דעות.
להדגמת רעיון זה, אתאר להלן ניהול אג'ילי של פרוייקט הערכת עובדים. בסיום הצגת התהליך, ננתחו על-פי התפיסה האג'ילית, כולל המיומנויות והעקרונות האג'ילים העיקריים שיושמו בו. תיאור התהליך מבוסס על נסיון רב של הכותבת בהטמעת ניהול אג'ילי בארגונים שונים. על מנת למקד את ההצגה ולהדגיש את העקרונות האג'יליים שבאו בו לידי ביטוי, אניח במהלכו מספר הנחות. בתום קריאת התהליך, הקוראים מוזמנים ליצור וריאציות על הנחות אלה ולבנות תסריטים אלטרנטיביים המיישמים את התפיסה האג'ילית.
בניית מערך להערכת עובדים
נניח שמדובר בחברה בה עובדים כ- 100 עובדים ב- 6 מחלקות. לאחרונה, החברה מצליחה מאוד במכירותיה וההנהלה חשה כי חסר לה מנגנון מובנה לתגמול העובדים שתרמו לגידול במכירות.
באופן מסורתי, סביר להניח שמחלקת משאבי אנוש היתה מתבקשת ע"י הנהלת הארגון לבנות תהליך הערכה מפורט, ולאחר מכן היתה מכנסת את מנהלי/ות המחלקות ופורשת בפניהם/ן את התוכנית שבנתה.
התהליך האלטרנטיבי שיוצג להלן מבוסס על הגישה האג'ילית. תהליך זה משתף את כל עובדי החברה בתהליך ובונה יחד עימם את ההערכה במספר איטרציות. תהליך זה מנחה תהליך למידה שמהלכו משפרים המעורבים את הבנתם ביחס למהות ההערכה כך שתתאים לצרכי החברה ועובדיה, שהם, בסופו של דבר, מודעים לדרך הטובה ביותר להעריכם.
התנעת הפרוייקט: הזמנת העובדים להיות שותפים בבניית תהליך ההערכה
בשלב ראשון, הנהלת החברה שולחת דוא"ל לכל העובדים בו היא מסבירה את הסיבות לרצונה להגדיר תהליך הערכת עובדים. מטרתו של דוא"ל זה היא הפגת חששות טבעיים העולים ביחס לתהליכי הערכת עובדים, היות ולעיתים תהליכים כאלה פוגעים בעובדים במקום לתגמלם.
על הדוא"ל להזמין את כל המעוניינים להשתתף בתכנון התהליך להתנדב לקבוצת עבודה. חשוב להבהיר את חשיבות השתתפותם של העובדים בתהליך היות והם אלה היודעים באופן הטוב ביותר את עבודתם וכיצד זו הובילה להגדלת מכירות החברה, ולכן חשוב שתובנותיהם תשתקפנה בתהליך ההערכה שיבנה.
חשוב לתאר את אופן פעילותה של קבוצת העבודה:
– הקבוצה תפגש אחת לשבועיים למשך שעה;
– הפגישה תתקיים בשעה שבה רוב העובדים נמצאים בחברה, כדי לאפשר לכל המעוניינים/ות להשתתף בה;
– בין הפגישות יתבקשו חברי הקבוצה להשקיע בפרוייקט שלוש שעות בשבועים לביצוע משימות שיוגדרו על ידם;
– ארבע השעות שתוקדשנה לתהליך בכל שבועייים (שעה פגישה + 3 שעות עבודה) תהוונה חלק משעות העבודה של העובדים והיקף משימותיהם השוטפות יצומצם בהתאם בשעתיים בכל שבוע.
בדוא"ל זה יוצגו גם שני התפקידים האג'ילים הבאים:
– לקוח/ה: היות וההנהלה היא זו שבקשה את הפרוייקט, היא לקוחתו. מחויבותה תבוא לידי ביטוי בהשתתפות בפגישות הדו-שבועיות באמצעות נציג/ה מטעמה. נציג/ת הנהלה, כלקוח/ת הפרוייטק, י/תתן משוב לגבי השגת היעדים שההנהלה מבקשת להשיג באמצעות תהליך ההערכה. על מנת לעודד את השיח בנושא ולקדמו, כדאי לאפשר גישה לנציג/ה זה/ו גם במהלך השבועיים בין פגישה לפגישה לשאילת שאלות.
– ראש הפרוייקט –coach:תפקיד ה- coachבפרוייקטים אג'יליים הוא הובלת הפרוייקט בהתבסס על תוצרי הביניים של הפרוייקט ומשוב הלקוח/ה. במקרה שלנו, בתפקיד זה יכול/ה לכהן נציג/ת מחלקת משאבי אנוש אך אין הכרח בכך. קיימים מקרים בהם עדיף דווקא כי נציג/ה מחלקה אחרת ת/יכהן בתפקיד זה.
בסיום הדוא"ל יופיע מועדה של פגישת התנעה (בת שעה) שבה יתחיל תהליך בניית מערך ההערכה. חשוב לתת די זמן לעובדים לחשוב על הנושא ולבקש מהמעוניינים לאשר את השתתפותם עד כשבוע לפני הפגישה.
נניח שמתוך 100 עובדי החברה, 25 עובדים התנדבו לקחת חלק בתהליך וכל 6 המחלקות מיוצגות בקבוצה זו.
כעת, ה- coachשולח/ת דוא"ל לעובדים שהביעו רצון לקחת חלק בתהליך ומבקשם להציע רעיונות ליישום בפגישה. בחברה בה לא נהוג היה לקיים דיאלוג מסוג זה עם העובדים, יתכן ולא תתקבלנה הצעות לארגון הפגישה; אין להבהל מכך, אלא לחילופין, להפנים עוד יותר את חשיבות שיתופם של כל העובדים בבניית הערכתם במטרה לחזק את האמון בינם לבין ההנהלה.
איטרציה ראשונה
פגישה מס' 1 – פגישת התנעה: לפגישה יגיעו כאמור 25 העובדים/ות שהביעו עניין להיות שותפים לתהליך הגדרת תהליך ההערכה. את הפגישה יש להתחיל בשעה שנקבעה והיא תנוהל ע"י ה- coach. מבנה הפגישה המוצג להלן מדגים כיצד ניהול אג'ילי מאפשר לכל הנוכחים להשמיע את דעתם.
5 דקות:הסבר הרקע שהוביל לפרוייקט והצגת אופן עבודת הקבוצה.
10 דקות:בקשה מהמשתתפים להתחלק לצוותים של 5 עובדים כך שכל מחלקה תיוצג בכל צוות. היות ולא כל המחלקות מיוצגות באופן שווה בקבוצת העבודה, יש ליצור את המצב הקרוב ביותר למצב זה.
20 דקות:המטלה המוצגת לצוותים היא העלאת נושאים שחשוב לדעתם לקדם בדרך לבניית תהליך הערכה. מכל הנושאים שיידונו בכל קבוצה, על כל קבוצה יהיה להחליט על נושא אחד שהוא החשוב ביותר לדעתה לקידום הנושא.
15 דקות:כל קבוצה מציגה במליאה במשך כ- 3 דקות את הנושא שבחרה כחשוב ביותר. הנושא נכתב על לוח.
נניח שהוצעו הנושאים הבאים:
– הגדרת תפקידים בארגון
– אופני תגמול אפשריים (הועלה ע"י שתי קבוצות)
– השפעת אופן ההערכה על ביצועי העובדים
– בחינת יעילות תהליך ההערכה
10 דקות: בפני המשתתפים מוצגת בקשה לקבל על עצמם את קידום אחד מהנושאים שנרשמו על הלוח. ניתן כמובן לאפשר מצב בו כמה עובדים יעבדו על אותו נושא, אך חשוב שיהיה עובד/ת אחד/ת שיהיה אחראי/ת על הנושא ויתאם ביניהם. יש להדגיש כי עד לפגישה הבאה יש לעבוד על ביצוע המשימה לא יותר מ- 3 שעות, וכי בפגישה הבאה בוחרי/האחראים על המשימות יתבקשו להציג את עבודתם במשך כ- 10 דקות. על הצגה זו יהיה לכלול את תהליך העבודה במהלך השבועיים, תוצרי העבודה, והצעד הבא שנראה להם מתאים לקידומו.
שבועיים: עבודה על הנושאים הנ"ל; ה- coach זמין/ה לשאלות.
איטרציה שניה
40 דקות: הנושאים מוצגים ע"י האחראים עליהם על-פי המבנה שתואר לעיל; כל נושא מוצג במשך 10 דקות.
5 דקות: משוב נציג/ת ההנהלה.
15 דקות: בחירת נושא אחד מתוך 4 הנושאים, התתמקדות בו וחשיבה על משימות שיש לבצען לקידומו. נניח שנבחר הנושא "הגדרת תפקידים בארגון".
באופן דומה למתואר בפגישה הראשונה, הנושא מחולק לתת משימות והקצאת משימה לחברי/ם מתנדבים מקבוצת העבודה.יש לקחת בחשבון שיתכן וחלק מהמתנדבים יבחר להפסיק להשתתף בתהליך. חשוב להבין את הסיבות לכך ולקחתן בחשבון בהמשך, אך אין צורך לשכנעם/ן להשאר להיות חלק ממנו.
בשלב זה לאחר שעברו שבועיים מתהליך ההתנעה, נקבע מועד להוצאת גרסה ראשונה של הערכת העובדים, למשל, חודש מתאריך הפגישה השניה (כלומר, איטרציה זו והאיטרציה הבאה). חשוב להדגיש כי הגרסה הראשונה של תהליך ההערכה תהיה זמנית ומטרתה היא קבלת משוב מהעובדים ומההנהלה. גרסה ראשונה זו תאפשר לבחון את הכיוון המתגבש על ידי צוות קבוצת העבודה של תהליך ההערכה ואופן קבלתו ע"י כל העובדים בארגון.
במהלך השבועיים הבאים המתנדבים יעבדו על משימותיהם, אותן יתבקשו להציג בפגישה הבאה.
איטרציה שלישית
פגישה זו תוקדש לבניית פיילוט לתהליך ההערכה, כמתואר להלן.
20 דקות:הצגת המתנדבים את המשימות עליהן עבדו בשבועיים האחרונים.
5 דקות:משוב נציג/ת ההנהלה.
20 דקות:בניית פיילוט לתהליך ההערכה בקבוצות עבודה שיש בהן ייצוג למחלקות השונות, כולל בחינה של מדדים להערכת יעילותו.
15 דקות:הצגת הקבוצות את תוצריהן והחלטה על תוצר אחד שהעבודה בשבועיים הקרובים תתמקד בו.
במהלך השבועיים הבאים תבנה גרסת הפיילוט. היות ובזמן הפגישה לא נותר זמן לתכנון תהליך בנייתו, ניתן לתאם פגישה נוספת בת שעה לתכנונו בה ישתתפו המעונינים להיות פעילים בבניית הפיילוט. במהלך השבועיים הבאים, כל חבר/ת בצוות שהתנדב להיות פעיל בבניית הפיילוט יקדיש שעתיים לנושא.
למרות שלכאורה נראה כי שעתיים הן זמן קצר מאוד, יש לזכור שאנו דנים בבניית פיילוט שדי שיכלול מס' קטן מאוד של שאלות (גם שאלה אחת או שתיים עשויות למלא מטרה זו).
פגישה מס' 4: הגדרת הפיילוט
בפגישה זו תוצג הגרסה שגובשה ויוכנסו בה שינויים במידת הצורך. לאחר הפגישה תושק הגרסה הראשונה של תהליך ההערכה. בעת הפניה לעובדים להתייחס לפיילוט (בכל תהליך שנוסח), יש להקצות זמן מוגדר לביצועו (למשל, שבוע). הקצאת זמן זו תאפשר לקבוצה המובילה לנתח את התוצאות בזמן נתון ולבחון את המשך בניית תהליך ההערכה.
כאן מסתיים תהליך בנייתה של הגרסה הראשונה של תהליך ההערכה לאחר ששה שבועות מפגישת ההתנעה של הפרוייקט. הקוראים מוזמנים להשוות משך זמן זה עם זמן הגדרת תהליך הערכת עובדים אותו חוו. חשוב לשים לב שבמהלכם של ששה שבועות אלה, מתקיים שיח בארגון על התהליך היות ורבים מהעובדים מעורבים בו, הן לצורך ביצוע המשימות כחלק מקבוצת העבודה והן במקרה בהם התקיימה פניה אליהם ע"י חברי/ות קבוצת העבודה. במידה והתהליך מנוהל בכנות ומשדר מסר של שיתוף עובדים, יש לשמוח על תגובות חיוביות אך יש לצפות גם להתגדויות; יש לזכור כי אם לא מועלות התנגדויות, יתכן ולמעשה לא מורגש שינוי.
בסיום הפיילוט, תהליך הגדרת תהליך ההערכה ממשיך באופן דומה באיטרציות של שבועיים שבמהלכן מנוסחות גרסאות משופרות של תהליך ההערכה, בהתאם להתפתחויות בחברה והבנת העובדים את חשיבות (אי-) הכללתו של מרכיב מסויים בתהליך. ניתן לבקש ממתנדבים חדשים להצטרף לקבוצה המובילה, אך אין הכרח.
ניתוח הפרוייקט מנקודת מבט אג'ילית
באופן טבעי, לא כל העקרונות והפרקטיקות האג'ליות יושמו בפרוייקט זה באופן זהה ליישומם בפרוייקטי תוכנה; יחד עם זאת, קל להבחין ביישום הגישה האג'ילית בפרויקט זה, כמתואר להלן.
1.לו"ז הפרוייקט: היות ובתחילת הפרויקט לא ברור היה כיצד יש להגדיר את תהליך ההערכה, היה צורך בהגדרת תהליך המאפשר הבנה הדרגתית של מהותו בחברה המסויימת בה מדובר. האיטרציות הדו-שבועיות, שבמהלכן נבנות גרסאות תהליך ההערכה, אפשרו ללמוד בהדרגה הן את נקודת מבטה של ההנהלה והן את דעת העובדים. לו"ז הפרוייקט, המוצג להלן, משקף תכונה זו של הפרוייקט:
2.מחוייבות:חברי/ת קבוצת העבודה והלקוח/ה (נציג/ת הנהלה) היו מחוייבים לתהליך;
3.תוצרים:
– בכל איטרציה הוגדרו תוצרים שאפשרו את המשך העבודה על הפרוייקט בהתאם למשוב ההנהלה;
– התוצרים הוצגו בתחילת כל איטרציה;
4. משימות:
– על-פי משוב הלקוח/ה, פורקו משימות לתת-משימות שזמן ביצוען הוערך ברזולוציה של שעות (עד 3 שעות בכל איטרציה) ע"י חברי/ות קבוצת העבודה שהיו אחראים על ביצוען;
– משימות לביצוע הוקצו בכל פגישה לחברי/ות קבוצת העבודה על-פי בחירתם/ן;
5. מדדים: הוגדרו מדדים שאפשרו לבחון את התקדמות הפרויקט;
6.Whole team: נציגי/ות כל המחלקות היו מיוצגים בתהליך; התקיימה בינהם אינטראקציה הן בפגישות הדו-שבועיות והן ביניהן;
7.אינטגרציה רציפה: התקיימה אינטגרציה רציפה של הנעשה בכל שבוע ובחינת ההמשך.
הניתוח הנ"ל משקף ערכים אג'ילים, כמו שיתוף פעולה, שקיפות, מחויבות, שונות (diversity), ומשוב, שיחד עשויים לאפשר לכל פרויקט להתקדם ולעמוד ביעדיו במועד.
סיכום
במאמר ניהול פרויקטים אג'ילי, שפורסם בבולטין העמותה לניהול פרוייקטים בישראל – PMI, מתוארים שני פרוייקטים נוספים שאינם פרוייקטי תוכנה, אך פותחו בתהליך אג'ילי. בפרויקט הראשון תוכנן תהליך הטמעתה של מתודולוגיית פיתוח חדשה בארגון; בפרויקט השני נבנה call centerבאחד מהמוסדות להשכלה גבוהה בישראל. במאמר Agile Knowledge Managementמודגם יישומה של התפיסה האג'ילית לניהול ידע. כמובן, שהמיומנויות האג'יליות לא מבוצעות בפרוייקטים שאינם פרוייקטי תוכנה באופן זהה לאופן ביצוען בפרויקטי תוכנה; יחד עם זאת, מיומנויות אלה מנחות תהליכים שבהם מיושמים עקרונות אג'ילים.
ניתן לראות כי התפיסה האג'ילית ניתנת ליישום בפרויקטים מסוגים שונים, לאו דווקא פרויקטי תוכנה, שאחד המאפיינים המשותפים להם הוא אי ידיעת מהותו וצורתו של המוצר הסופי בתחילת הפרויקט. התפיסה האג'ילית מתאימה לניהולם של פרויקטים אלה הודות לתמיכתה בתהליכי למידה, תמיכה המאפשרת להתקדם בניהול הפרויקטים תוך שיפור הדרגתי בהבנת צרכי בעלי העניין של הפרוייקט.
לסיכום, אחד מהמסרים העיקריים של מאמר זה הוא שעבור ניהולם של פרויקטים המאופיינים ברמת אי-ודאות גדולה ובאי-ידיעת פרטי המוצר הסופי מראש, רצוי לשקול את אימוץ התפיסה האג'ילית. תובנה זו ביחס לסוג הפרויקטים עבורם מתאים ליישם את הגישה האג'ילית מבוססת על העובדה שהגישה האג'ילית תומכת בתהליכי למידה, המהווים חלק בלתי נפרד מתהליכי פיתוח תוכנה בפרט, ומתהליך ניהולם של פרויקטים שמוצרם הסופי אינו ידוע, בכלל.
על המחברת פרופ' אורית חזן:
פרופ' אורית חזן היא ראש המחלקה לחינוך למדע וטכנולוגיה בטכניון. תחום המחקר שלה הוא הוראת מדעי המחשב והנדסת תוכנה.
בנוסף לעיסוקה במחקר ובהוראה בטכניון, היא מקדמת תוכניות לקידום החינוך למדע וטכנולוגיה בישראל, בין השאר, ע"י חיזוק קשרי הגומלין ושיתופי הפעולה בין האקדמיה, מערכת החינוך, התעשייה וצה"ל.
בעשור האחרון היא יעצה לארגוני הי-טק בהקשר לניהול שינויים בכלל והטמעת ניהול פרוייקטי תוכנה בגישה האג'ילית בפרט.
בשנים 2006-2010, פרופ' חזן עמדה בראש ועדת התוכנית למדעי המחשב בתיכון של משרד החינוך ובשנים 2006-2008 כיהנה כסגנית דיקן לימודי הסמכה של הטכניון.
פרופ' חזן פרסמה יותר מ- 100 מאמרים בז'ורנאלים ובקבצי מאמרים של כינוסים וכן שלושה ספרים. ספרה השני Agile Software Engineeringמתמקד בניהול אג'ילי ופורסם ב- 2008 בהוצאת Springer.
מגזין "סטטוס" מופק ע"י: 
Tags: אג'ילי אסטרטגיה מורשת ניהול ניהול פרויקטים תרבות ארגונית
