התופעה שמשתקת את אנשי הפיתוח – מה זה Analysis paralysis?

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

מקור: Pexels

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

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

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

הבעיה של אנשי הפיתוח

“Analysis paralysis or paralysis by analysis is the state of over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect paralyzing the outcome.” 

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

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

מקור: CC by Allan Ajifo

עדיף לטעות מאשר לא להחליט

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

1. a/b testing – ברוב המקרים לא מדובר החלטה הרת גורל, וניתן לחשוב על כל החלטה כעל ניסוי. לכל ניסוי יש כמה תוצאות אפשרויות, אנחנו בוחרים אחת ובודקים אם ההשערה שלנו התאמתה. כך אנו בעצם מנטרלים את המחשבה שקבלת ההחלטה היא משהו סופי, ויותר קל לנו לקבל אותה.

2. מניעה והתרעה – אם יהיו לנו מנגנונים שידווחו לנו במהירות על טעות, אז נוכל לשלוט יותר בהשלכות שלה ויהיה לנו יותר קל לקבל החלטות. לדוגמה, אם יש לנו short feedback loop עם ארגון הבדיקות שלנו, או אפילו עם הלקוחות שלנו, אז נוכל לקבל פידבק מהיר על ההשפעה של ההחלטה שלנו ולפעול בהתאם לפידבק.

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

הסטייל חשוב, אך העיקר לא להיות משותקים

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

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

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

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

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

כתב אורח

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

הגב

16 Comments on "התופעה שמשתקת את אנשי הפיתוח – מה זה Analysis paralysis?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
ראש צוות צעיר
Guest
ראש צוות צעיר

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

יצחק
Guest

ב"ה

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

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

גוגל עשתה את זה בעבר, היום זה קצת פחות וחבל

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

ברלד
Guest

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

ילדה ללא שם
Guest

נשמעת חברה שאפשר לוותר עליה….

אורי
Guest

באיזה חברה אתה עובד?

אנונ
Guest

לא הספקתי לקרוא את הכתבה כי אחרי השורה הראשונה גילתי יששש עוד פודקאסט ישראלי!!

הקהילה בארץ מעלה רמה.

דורה
Guest

איזה פודקאסט.

ערן
Guest

אחלה פוסט!!!

רונן
Guest

ממש לא נראה לי שככה עובדים בגוגל. להיפך.

ארכיטקט תוכנה רונן
Guest
ארכיטקט תוכנה רונן

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

Jonathan
Guest

לייק. בייחוד הקטע של להעביר את קבלת ההחלטות לצוות ולעודד אותו לעשות את זה

Ilia
Guest

i've encountered that a lot of time, but didn't know it comes with that name and that explanation.
Good to know!

נורמן
Guest
שירה
Guest

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

מנהל וותיק
Guest

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

שירן ארכיטקט תוכנה רונן
Guest
שירן ארכיטקט תוכנה רונן

הבנתי את הבעיה. לא הבנתי את הפיתרון

wpDiscuz

תגיות לכתבה: