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