מהו פרק הזמן שעובר מרגע הכניסה לתפקיד חדש עד הרגע שבו עולה המחשבה "על מה לעזאזל הוא חשב כשהוא עשה את זה ככה…"?
יום? יומיים? שבוע? שבועיים? חודש???
כנראה שאחת התשובות היתה נכונה. לא?
וכמה זמן עבר מאותו משפט עד הרגע שבו העברתם את ידכם בשיערכם מתוך מבוכה ואמרתם לעצמכם "איך זה שלא הבנתי קודם כמה מחשבה הוא באמת השקיע בזה…"?
צעדים ראשונים
ראוי שנאמץ מידה רבה של ענווה וצניעות כשאנחנו נכנסים לתפקיד, או מקבלים פרויקט שכבר נמצא בשלב כלשהו של פיתוח.
סביר להניח שמי שהיה לפנינו בתפקיד, לא היה טיפש גמור שעשה רק נזקים. וכמו שאנחנו רוצים לחשוב שאנחנו משאירים "חותם" חיובי כשאנו עוזבים תפקיד (עקב קידום, סיום פרויקט, שינוי קריירה), כך רצו גם קודמינו. כל עוד לא הוכח אחרת – צריך להתייחס לדברים שעשו קודמינו, כמו שהיינו רוצים שיתיחסו למעשים שלנו.
הדברים נכונים ביתר שאת לבעיות ישנות שמובאות לשולחננו, והפתרון נראה ממש בהישג יד – במקרים כאלה הדבר הנכון ביותר הוא לעצור לרגע ולבדוק – אם הפתרון כל-כך נגיש, מדוע זה לא בוצע כבר בעבר? אולי יש עוד פרמטרים שלא חשבנו עליהם והם אלה שיגרמו לפתרון לקרוס כמגדל קלפים?
החפזון לשלוף פתרון קל במקרים שכבר הובאו בפני קודמנו – עלול אף הוא להיות מלכודת שנתקשה מאוד להחלץ ממנה.
אופס, טעינו…
מעבר להיבטים החברתיים השליליים של הכפשת קודמינו, קיים הסיכוי הסביר שבזכות הנסיון שלהם ובגלל חוסר הנסיון שלנו – אנחנו לא מצליחים להבין את גדולתו של הפתרון שניתן, ודווקא הרצון שלנו לשפר – יגרום לנזק.
ככל שפרק הזמן בו האדם שהחלפנו היה בתפקידו, גדול יותר, כך גדולה כמות המקרים הקיצוניים, המיוחדים והמוזרים שבהם הוא נתקל, איתם הוא היה צריך להתמודד. מי שלא חווה "על בשרו" את הצפת נחל איילון בחורף גשום, או מחיקה בטעות של חלקים נרחבים מבסיס הנתונים המרכזי יתקשה לדמיין התמודדות עם מצב תיאורטי כזה.
אולי בעצם לא טעינו?
כדי לאזן את התמונה – צריך לאמץ, במינון הנכון, גם את הכלל "כבדהו וחשדהו" – אם היה מקרה מיוחד שנפתר באופן שלא ברור לנו עד הסוף – צריך לבדוק האם מדובר בפתרון מבריק, או באלתור חובבני.
צריך לנסות, באמצעות היכולות והנסיון שלנו, להחליט באיזו אפשרות מדובר – ולפעול בהתאם, תוך הבנה של הסיכון, ניתוח קר של הנתונים, והתעלמות מתחושות אגו – לעומת הכבוד בו נזכה בגין "הברקה", מחיר המבוכה עקב "תיקון" של משהו תקין עלול להיות גבוה מכפי שנוכל לעמוד בו.
המהירות המטורפת של המציאות לא מאפשרת לנו לפעמים "לעצור ולחשוב", או ללמוד לעומק את מה שעשו קודמינו. חפיפה בין בעלי-תפקידים מסתכמת לפעמים בימים בודדים, שמספיקים רק להעביר את הדברים החשובים בראשי פרקים. מעטים הם האנשים שזוכים בתקופת הכשרה אינטסיבית, שמאפשרת להם להכנס לתפקיד עם "ארגז כלים" מלא.
מה עושים עם זה עכשיו?
הדברים האמורים, נכונים לתפקידים בדרגים השונים, מתוכניתן ועד מנהל הפרויקט, ממעצב גרפי ועד סמנכ"ל תפעול (ויש עוד הרבה "מ… עד…" שאפשר להוסיף, אני מניח שהרעיון ברור). כל בעל-תפקיד מגיע עם המטען האישי שלו שמורכב מהידע שאותו הוא רכש בהכשרות הפורמליות והלא-פורמליות, מהנסיון שלו, שכולל הצלחות וכשלונות, מהתכונות האישיות שלו – ירידה לפרטים או ראיה רוחבית, חשיבה מתמטית אנליטית או אינטואיציה ורגש, עבודה לפי סדר וכללים או חשיבה מחוץ לקופסא ופריצת מסגרות.
כל תכונה באה עם יתרונתיה וחסרונותיה – לדוגמא – גמישות מחשבתית יכולה להתבטא כדבר חיובי בפתיחות לרעיונות חדשים, או כדבר שלילי בחוסר עקביות.
האדם שהיה לפנינו – שונה מאיתנו, הוא ניגש להתמודד עם בעיות בדרך שונה, מנקודת מבט אחרת, עם נסיון וכלים אחרים – במקום שנחשוב "על מה לעזאזל הוא חשב כשהוא עשה את זה ככה…", ראוי שנאמץ את המחשבה "אני גם רוצה להבין למה הוא עשה את זה ככה", רק אחרי שנבין, או לפחות נוודא שמיצינו את כל שביכולתנו כדי להבין, רק אז נהיה במקום שבו נוכל להחליט לבטל את מה שהיה מתוך ניתוח מושכל ולא מתוך אגו.
ההצלחה שלנו בתפקיד מבוססת בין השאר, גם על מה שהשאירו לנו קודמנו, לטוב ולרע. עלינו להחליט האם אנחנו ממשיכים לבנות על היסודות שהכינו לנו, או מחליפים ומחזקים חלק מהם.
בידינו הדבר.
** עדכון לפוסט (תודה למ.ק. שעזרה לי בהתלבטות) **
בתפקיד האחרון שלי בצבא תליתי שלט בכל חדר בזו הלשון (לפחות זו רוח הדברים):
"תמיד צריך להתיחס לדברים שעשו לפניך כאילו הם נעשו בצורה הנכונה, הטובה והיעילה ביותר שאפשר, ולא צריך לשנות שום דבר, או שהם נעשו באופן הכי לא יעיל, שגוי ומוזר, וצריך לעשות את זה מחדש.
החוכמה היא לדעת להחליט באיזה אופן לפעול מבלי לגרום נזק!"
** תודה **
תודה לאיריס בייר המוכשרת שעיצבה עבורי את תמונת הכותרת.
למי שתהה – כל ה"שטויות" לכאורה שיש למנהל היוצא, הן כלל לא שטויות אלא דברים שהמנהל החדש פשוט לא מבין עדיין. לכל ביטוי יש משמעות אמיתית, צריך ללמוד קצת על עולם התוכן הרלוונטי. שלושת הביטויים עם סימן השוויון לקוחים מתחומים שונים של תוכנה.
היה מעניין? רוצים לקרוא פוסטים נוספים מיד עם פרסומם? בצד שמאל יש תיבת הרשמה. נא להרשם ותקבלו ראשונים כל פוסט חדש.
7 מחשבות על “קודמינו בתפקיד לא היו טפשים”
יפה… מסכימה עם כל מילה
"טיפשים" אולי לא. "טיפשים" זה מונח בוטה מדי, והמלכודת הזו של הנחת הטיפשות היא בעיקר נחלתם של מתחילים, או אנשים עם מוסר עבודה ירוד משהו.
יחד עם זאת, מה לעשות יעקב… איך אומרים… we're all dealt different cards. יש אינטליגנטים יותר ויש אינטליגנטים פחות. מוכשרים יותר ומוכשרים פחות. בריאי-נפש יותר ובריאי-נפש פחות. המפתח הוא להבין, שברוב המוחץ של המקרים, אותו אדם ששגה (לדעתנו) לא עשה זאת מתוך רוע. אולי חוסר מחשבה, אולי חוסר עומק, או חוסר הבנה, אפילו רשלנות… אבל לא רוע.
למשל, אין שום דבר בעולם שישכנע אותי שאותו בחור, ס' ר' (מעברנו המשותף), לא היה יציב במיוחד מבחינה מנטאלית באותו היום שבו הוא כתב קוד אסמבלר בו הוא מאפס רג'יסטר ומיד אח"כ בודק אם הוא אפס. זה דורש אישיות אקסצנטרית במיוחד; ועם כל ה-"סימפטיה", אני לא חושב שהוא היה אדם רע.
מצא חן בעיני הביטוי "הנחת הטיפשות" – והחיבור שלו למתחילים. זו הסיבה שהפוסט מדבר על המחשבות בכניסה לתפקיד. זהו פרק הזמן שבו הגאווה וההערכה העצמית הם בשמיים. אט אט מבינים שהחוכמה לא חונה רק אצלנו, להפך אנו נהיה הטפשים אם נתייחס בחוסר הערכה למעשים של קודמנו.
הפוסט הזה נכתב בעקבות משפטים שנאמרו כחלק מתעמולת בחירות – המנהג להשמיץ את ראש העיר המכהן.
כמובן שההקשר לחוויות שהיו לי בצבא קפץ מעצמו.
ואם כבר הזכרת אסמבלר – מי שמגחך כשהוא נתקל לראשונה בפקודת NOP, כנראה חושב "בשביל מה צריך את הדבר המיותר הזה…"
אין מקום לבקר את קודמנו בטרם למדנו כל *ביט* בקוד שלו, עקרון "עובד – אל תיגע" הוא אחד החשובים ביותר שישנם ללא תלות באיכות הקוד הקיים, אלא רק אם יש בעיה קונקרטית שצריך לפתור או שינוי מוגדר שצריך לבצע.
דוגמא לקוד רע שצריך לשנות *אם כבר נוגעים* ולא לפני כן
if(i<<31){
…
זה רלוונטי יותר לעולם התוכן מאשר לטכנולוגיה עצמה. הBUSINESS LOGIC הוא הערך המוסף העיקרי של התוכנה, הוא זה שצריך להקפיד לשמר כל עוד לא נבחן מחדש באופן מקיף ויסודי. פתרון טכני ספציפי אפשר תמיד לבחון מחדש, ואם כבר מדברים על זה, שני עקרונות רלוונטיים:
* הפרדה טובה בין השניים נחוצה בדיוק לכן, בכדי שנוכל לטפל בצדדים הטכניים – המימוש עצמו – ולשפרם מבלי לשבש את הפונקציונליות עצמה.
* כשמדברים על חשיבות התעוד, זה בדיוק המקום – כי לרוב מתעדים דווקא את הטכנולוגיה ופחות את המניע הפונקציונלי.
זה באמת רלוונטי יותר לעולם התוכן, אך גם פתרונות טכנולוגיים צריכים להבחן באותה שיטה (במיוחד בקוד עתיק וחסר תיעוד)