The art of reviewing

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

פתרונות, פתרונות, פתרונות

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

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

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

_{טיוטת מבוא למאמר, "למה אנחנו לא עושים שעות נוספות", שנכתבה על ידי ירון.}

הצעתי לשנות את זה לזה כדי שיהיה יותר מושך כהקדמה:

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

_{הקדמה אחרונה למאמר, "למה אנחנו לא עושים שעות נוספות", שנכתב על ידי ירון.}

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

החלפת העבודה שלך בעבודות של אחרים מפחיתה את תחושת הבעלות המלאה.

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

מהיר ומלוכלך

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

1. פיתחתם את פיסת הקוד יחד (pair programming). 

2. זה שינוי כל כך קטן ששום דבר לא יכול להשתבש.

3. אתה מרגיש שלחץ זמן והערות גורמים לעיכוב.

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

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

נפגשים באמצע

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

• הוא בונה. אנו מתייחסים בכבוד לעמיתים ולעבודתם.

• גורם לך לחשוב. זה עוזר לך להרהר על עבודתך ומעודד אותך לחשוב על פתרונות אחרים.

• מורכב משאלות. למה עשית את זה ככה? מה הסיבה להגדרה הזו? האם חשבת על אפשרויות X ו-Y במקום רק Z?

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

אנו רואים במשוב עמיתים גורם לפתוח שיחה. ג'ואן, מפתחת Back-End ב-Easy LMS, מסבירה: "אני לא חושפת את הפתרון כולו, לפעמים רק חלק ממנו, אלא בעיקר דנה כיצד ניתן להשיג חלופה על ידי שיפוץ קוד. ולפעמים זה אומר פשוט לשבת ליד מישהו ולהדריך אותו, במקום לשחק פינג פונג דרך GitHub או BitBucket, הכלים בהם אנו משתמשים לסקירות קוד."

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

 _{דוגמאות לשיחת סקירת קוד ב-GitHub.}

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

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

לוקח יותר זמן, אבל בסופו של דבר זה משתלם

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

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

• שיתוף עמיתיך לעבודה היומיומית. אין איים מבודדים של עבודה.

• הגברת הביטחון ביצירה שאתה יוצר, כי מישהו אחר חושב ששווה להסתכל עליה.

• שיפור איכות העבודה. זוהי השקעה לטווח ארוך המונעת טעויות (יקרות).

מאמר זה נבדק בצורה שיחתית?