"תגיד, סיימתם עם המשימה הזו ?"

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

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

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

מקורות הרעש הלבן

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

השפעות הרעש הלבן

הרעש הלבן משפיע לרעה על היכולת שלנו לעמוד בהתחייבויות שלנו.

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

התמודדות עם הרעש הלבן

ישנם שלושה אלמנטים מרכזיים העוזרים לנו ביכולת ההתמודדות עם הרעש הלבן.

• סינון
• הפחתה
• מיקוד 

סינון

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

הפחתה

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

מיקוד

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

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

בקרה

הבקרה שאנו נדרשים לעשות היא רב מימדית.

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

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

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

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