רואים שחורות: כך אימוץ תרחישי אימה יסייע לכם בחיזוק המוצר

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

Contributors

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

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

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

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

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

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

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

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

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

מהנחות למעשים

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

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

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

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

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

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

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


ד”ר רועי שילקרוט הוא מדען ראשי בחברות בארה”ב ובישראל, עמית מחקר במכון הטכנולוגי של מסצ’וסטס (MIT) בו הוא מרצה בנושאי בינה מלאכותית, ובעבר פרופ’ למדעי המחשב באוניברסיטת סטוני ברוק בניו-יורק. הוא פרסם מאמרים וספרים בנושא והוא חתום על מספר פטנטים בתחום.

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

הרשמה לניוזלטר

באותו נושא

הרשמה לניוזלטר

מעוניינים להישאר מעודכנים? הרשמו לרשימת הדיוור שלנו.

דילוג לתוכן