תור המשימות של מערכות מידע או ה IT backlog, ידוע לשמצה.
הוא לעיתים נותן תחושה שהזנב מקשקש את הכלב. שבעצם מערכות מידע הם אלה שקובעים מה יבוצע ומתי. מאחר ואף אחד לא אוהב להיות תלוי, שמו הרע של ה Backlog הולך לפניו...
מן הסתם, הדרך הטובה ביותר לקיצור תור המשימות (backlog) הוא ביצוען ביעילות ובמהירות, אבל מה נכון לעשות כשהתור מתארך?
בפוסט זה, נרחיב מעט על תור המשימות של מערכות המידע בארגון, נסביר מדוע נוצר ונדגיש ש:
"ניהול נכון של תור המשימות"="תאום ציפיות".
קצת על ה IT Backlog
ה Backlog הוא אותה רשימת משימות (פרויקטים, שינויים גדולים, שינויים קטנים, באגים, פיצ'רים וכיוצ') שהארגון מטיל על הצוות.ים הטכניים לבצע (כאן נתייחס למחלקת/אגף מערכות המידע של הארגון).
לרוב, כמות המשימות גדולה על קיבולת מערכות מידע ואז המשימות מתחילות להיערם ב- Backlog.
קושיה: אם מערכות מידע, היו מסוגלים לפתח כל משימה, במהירות, מבלי שיווצר Backlog, טוב לארגון? מסתבר שלא !
לארגון ישם מספר מגבלות שיש "לנרמל":
קיבולת הארגון לשינוים מהותיים: המסוגלות של משתמשים לשנות את תהליכי העבודה שלהם וסט הכלים היום יומי - מוגבל. אמנם אנחנו נוטים לכתוב על הפרודקטיביות של מערכות מידע , אבל מה עם הפרודקטיביות של הארגון? אימוץ שינוי מהווה סוגיה ארגונית כבדה.
סנכרון: כשמחלקה אחת מתחברת לשינוי, למשל - מאחר והיא יזמה אותו לפי צרכיה, אין זה אומר שמחלקה אחרת מתוכננת לאותו אתגר באותו זמן ובאותו סדר עדיפות.
לא כל הבקשות/צרכים/פרויקטים נכונים לארגון: על טרנדים אופנתיים שמעתם? מסתבר שהם חזקים גם בעולם הטכנולוגי, ויש משתמשים שלתפיסתם, שלעיתים היא צרה, או נובעת מזווית ראיה לגמרי אישית, ורחוקה מלראות תמונה ארגונית רחבה, דוחפים לשינוי, דוחפים "לחדשנות". והמחיר של המשמעויות של השינוי - לא קשור אליהם. כשמשתמשים אלה בעלי השפעה ויכולת להגדיר משימה - הארגון בבעיה.
"פילים לבנים" (כינוי לפרויקטים שעושים רעש גדול - אבל לא קורים. בדיוק כמו פילים לבנים בטבע...) - לרוב "פילים לבנים" קורים מהסיבות הנכונות: הארגון מייצר יוזמות שמטרתן פיתוח עסקי. ידוע שיוזמות בודדות מצליחות אבל רבות לא קורות. אותן יוזמות שלא קורות עדיין מכבידות מאד על גוף מערכות המידע. אם הקיבולת של מערכות מידע, היתה מספקת בכדי שפרויקטים אלה גם יראו אור - המחיר הארגוני היה כבד שבעתיים.
בארגון מושכל, מסיבות אלה, קיבולת ה IT מנוהלת. בארגון פחות מושכל, ה IT בד"כ מצומצם בפשטות מאילוצי תקציב, למערכות מידע אין קיבולת לבצע את כל המשימות. וטוב שכך.
כיצד מנהלים את תור המשימות של מערכות המידע ועולם התיעדוף
אם כך, תחת האילוץ של קיבולת מצומצמת, איך נכון נכון לנהל את ה Backlog?
להלן כמה עקרונות:
להעמיד צוות החלטה שבאפשרותו קבלת החלטה מושכלת בראיה רחבה של הארגון. הצוות יכול להיות דינאמי לפי הנושאים שעל הפרק. אולם סמכותו לא צריכה להיות מעורערת.
בטרם דיון על סדר העדיפות חייבים להביא נתונים התומכים בהחלטת התיעדוף. כדי לעשות זאת יש לבצע תהליך של ניתוח מערכות מקוצר המתמצת את הצורך ואת הנדרש לביצוע. להלן הנתונים העיקריים שיהיו על השולחן:
היתרונות של שינוי/תיקון - מכומת לכסף.
העלויות (כ"א פנימי, חיצוני, רישוי, תשתיות (ענן/עצמית/רכש)).
לוח זמנים ריאלי לביצוע נטו.
פרמטרים לניהול סיכונים, כמו: אתגרים/שאלות לא פתורות, ייתכנות טכנית, ייתכנות עסקית
גיל המשימה (FIFO חייב להיות גורם משפיע)
תקופת הרלוונטיות של המשימה. למשל: אם לא מבוצע תוך חודשיים, לא רלוונטי.
ישנם כמובן פרמטרים נוספים, אחרת שינויים כמו חוב טכני, EOL של רכיב, שינויים המשפיעים רק בעקיפין על שורת הרווח ואחרים חייבים למצא את דרכם לתוך הרשימה - אולם התחלנו עם הנתונים הפשוטים.
3. סידור הרשימה. המשימות אינן בגודל אחיד. ישנם פרויקטים שיארכו חודשים רבים וישנם שינויים או תיקונים שתוך שעות בודדות אפשר להשלים, גם צוותי הפיתוח בעלי קיבולת משתנה. ומשימת סידור הרשימה היא אומנות שהיעד שלה - הגברת הפרודקטיביות. לכן תהליך ה Dispatching / שילוח (השמת המשימה למבצע) חייב להיות מבוצע בידיo מקצועיות.
4. להלן "נגיעה" בעקרונות העבודה:
נגעת-נסעת! ניתן לשנות את הרשימה בכל מועד - עד לרגע שהתחילו לבצע אותה. מאותו רגע, הפסקה שלה משמעותה - אובדן ההשקעה שבוצעה עד כה + זמן Set-UP מחודש (תקורה נוספת). לכן: משימה ש"נגענו" בה בפיתוח - חייבת להסתיים.
ליווי, בקרה וניהול מדדי תפוקה באופן רצוף ושקוף הן למפתחים והן לארגון וטיפול מיידי בבעיות.
פירוק פרויקטים לרכיבים מספיק קטנים, שהם ברי ביצוע על ידי צוות או חלק מצוות במחזור פיתוח אחד.
הניתוח מלא, המגדיר בדיוק מה נדרש לעשות, יבוצע הכי קרוב שאפשר לתאריך התחלת הפיתוח (בלי קשר לתאריך הרישום או האישור של המשימה) בכדי להקטין ככל הניתן את השפעת השינויים על התוצר. מרגע שהסתיים הניתוח המלא - התהליכים בארגון עליהם הוא משפיע - בהקפאה ולא יתאפשרו שינויים עד לסיום הפיתוח.
ניהול התור בצורת FIFO כברירת מחדל מאחר והמשתמש/לקוח מצפים. אולם, במידה ויש שינויים בתוכנית, לשמור על קשר שוטף ושקיפות עם הלקוח. וכאן גם מגיע הדגש של הפוסט...
לדעת לומר לא
כאשר הארגון, או צוות קבלת ההחלטה מאשר ומכניס משימה ל backlog הוא מייצר ציפייה לביצועה אצל הלקוח/משתמש שמבין שהשאלה היחידה שנותרה פתוחה היא - תזמון.
אולם המציאות היא אחרת: בארגון דינמי, החי בתוך תחרות, שמנסה לחדש ולהביא עוד ועוד ערך ללקוחות שלו, נוספות המון משימות על מערכות מידע. המבול הזה נופל על ה Backlog ומערבל אותו היטב. סביר להניח שהמון משימות שכבר "תפסו ותק" בתור והתקרבו לתאריך ביצוען - יידחו מאחר והדחוף והחדש הוא קולני יותר, לעומת הדחוף שכבר יושב בנימוס ברשימה. מצב זה, בו משימה היושבת ב Backlog ויכולה "להתייבש" שם, לצבור ותק בסטטוס של "אוטוטו מבצעים" (המונח המקצועי הוא Starvation) מייצר אכזבות המבססות חוסר אמון וכרסום ביחסים בין מערכות מידע לשאר הארגון.
הדרך הנכונה, מכמה סיבות להתמודד עם הסיטואציה - היא לומר למשתמש/לקוח לא!
כלומר אם המשימה, בהתאם לקיבולת, לא תכנס בתאריך המצופה, בסבירות גבוהה מאד לביצוע, יש לתאם ציפיות עם המשתמשים ולהסיר אותה מה Backlog. פעם אחת - זה פשוט הוגן ואמיתי.
פעם שניה - ה"לא" הזה, נותן הזדמנות ליוזם השינוי לשכנע את הארגון מחדש בנחיצות ולעצור את הישיבה הפאסיבית ב Backlog או לפחות לקצר אותה.
עצם אמירת ה"לא" מחזירה את האחריות לתיעדוף למי שבאמת אמור לעשות אותו, בתזמון הנכון ועם הטיעונים המעודכנים וייתכן שגם נתוני קבלת החלטת התיעדוף משתנים. ובכן הארגון נמנע מ FINO (First In Never Out).
הקשר בין ה Backlog – ל ShadowIT
לא פעם, בהיעדר אמון בין צרכני האוטומציה והמחשוב בארגון לבין מערכות מידע, הראשונים יחפשו מעקפים - כי אף אחד לא רוצה להיות תלוי לשבט או לחסד של מישהו אחר. מעקפים אלה, לעיתים יכולים להסתיים ב ShadowIT ובכך נוצר "כאב ראש" גדול יותר לארגון. תאום ציפיות, בהכרח, יסייע להפחתת תופעה זו.
מכאן המסקנה - ניהול נכון של ה backlog הוא בעצם תיאום ציפיות.
לסיכום
אורך נכון של Backlog יהיה בין פעם וחצי לפעמיים הקיבולת האמיתית של מערכות מידע, פר תקופת תכנון. כל מה שלא נכנס לשם - צריך לחזור ללקוחות/משתמשים עם "לא". התשובה : "לא יקרה" תהווה בעצם טריגר לתיאום ציפיות ריאלי. היעדר תיאום הציפיות, ייצר התנהגות של בת-יענה ובעצם להתמרמרות גוברת והולכת בין המשתמשים/לקוחות לבין הארגון.