ВІГЕРСОПЕДІЯ: Гарна сторона взаємних оцінок

Високоякісна технічна робота потребує певної допомоги від колег у вигляді рецензування, однак воно має бути проведено вміло.

Рецензування колегами (peer review) – це діяльність, у якій люди, які не є авторами певного результату роботи, перевіряють його на наявність дефектів і можливостей для вдосконалення. Рецензування колегами є потужним інструментом забезпечення якості в будь-якій технічній галузі, особливо в розробці програмного та апаратного забезпечення. Маючи за плечима десятиліття досвіду з перевагами рецензування програмного забезпечення колегами, я ніколи не працюватиму в команді, яка не практикує цей підхід.

Багато організацій стикаються з труднощами при впровадженні ефективної програми взаємного рецензування. Перешкоди для успішного проведення рецензій часто мають соціальний і культурний характер, а не технічний. Моя книга «Взаємне рецензування в розробці програмного забезпечення: практичний посібник» описує практичні деталі проведення рецензій. У цій статті розглядаються деякі з тих аспектів, пов’язаних із людським фактором, коли люди перевіряють роботу один одного. Наведені тут рекомендації можуть допомогти вашій програмі взаємного рецензування досягти успіху там, де інші зазнали невдачі.

Почухайте один одному спину

Просити колег вказати на помилки у вашій роботі – це набута, а не інстинктивна поведінка. Ми всі пишаємося роботою, яку виконуємо, та продуктами, які створюємо. Нам не подобається визнавати, що ми припускаємося помилок, ми не усвідомлюємо, скільки їх робимо, і нам не подобається, коли їх знаходять інші. Проведення успішних взаємних перевірок вимагає від кожного з нас подолати цей природний опір зовнішній критиці того, що ми створюємо.

Зайняті практики іноді неохоче витрачають час на перевірку роботи колеги. Вони можуть з підозрою ставитися до співробітника, який просить переглянути його код. Виникають питання: чи йому бракує впевненості? Чи хоче він, щоб ви думали замість нього? «Той, кому потрібен перегляд коду, не повинен отримувати зарплату як розробник програмного забезпечення», – сказав мені якось один розробник. Ці противники не цінують користі, яку можуть принести кілька пар очей.

У здоровій культурі розробки програмного забезпечення члени команди залучають колег для підвищення якості своєї роботи та збільшення продуктивності. Вони розуміють, що час, витрачений на перегляд результатів роботи колеги, – це не витрачений даремно час, особливо коли інші члени команди відповідають взаємністю. Я щось дізнавався з кожного рецензування, в якому брав участь – як автор чи як рецензент.

Джеральд Вайнберг запровадив концепцію «програмування без его» у 1971 році. Вайнберг визнав, що люди значною мірою пов’язують своє самосприйняття з результатами своєї роботи. Тому недолік, який хтось знаходить у вашій роботі, можна сприйняти як вашу особисту слабкість як розробника програмного забезпечення, а можливо, й як людини загалом. Щоб захистити своє его, ви не хочете знати про всі допущені вами помилки та можете намагатися раціоналізувати можливі баги. Захист его може призвести до того, що окремі члени команди почнуть вважати свій внесок у спільний проєкт особистою власністю, що стає перешкодою для ефективного взаємного рецензування.

Зауважте, що термін звучить як «програмування без его», а не «програміст без его». Фахівці у сфері програмного забезпечення повинні мати достатньо самолюбства, щоб довіряти своїй роботі та відстоювати її, але не настільки, щоб відкидати пропозиції щодо вдосконалення. Так само рецензент без его має виявляти співчуття та чуйність до своїх колег – хоча б тому, що одного дня вони поміняються ролями.

Ті, хто практикує культуру розробки програмного забезпечення, орієнтовану на якість, усвідомлюють, що успіх команди залежить від взаємодопомоги у виконанні роботи якнайкраще. Вони надають перевагу тому, щоб дефекти виявляли колеги, а не замовники. Вони розуміють, що рецензування не має на меті пошук цапів-відбувайлів для проблем із якістю. Я сприймаю виявлення моєї помилки колегою як «влучне спостереження», а не як особисту невдачу.

Нам Не Потрібні Ніякі Паршиві Відгуки!

Що робити, якщо члени вашої команди не хочуть проводити взаємні перевірки? Недостатня обізнаність щодо перевірок, культурні особливості та звичайний опір змінам призводять до того, що перевірки використовуються недостатньо широко. Багато людей не розуміють, що таке взаємні перевірки, чому вони є цінними, у чому різниця між неформальними та формальними перевірками (так звані інспекції), а також коли і як їх проводити. Дехто вважає, що їхній проєкт недостатньо великий або важливий, щоб потребувати перевірок, проте будь-яка робота може отримати користь від погляду з боку.

Деякі люди заперечують, що рецензії забирають надто багато часу і сповільнюють проєкт. Але взаємні рецензії не сповільнюють вас – дефекти сповільнюють вас! Рецензії сповільнюють вас лише в тому випадку, якщо вони неефективно виявляють дефекти, якщо дефектів взагалі немає, або якщо ви не усуваєте ті, що все ж знаходите.

Автори, які подають свою роботу на перевірку, можуть відчувати, що їхня приватність порушується, оскільки вони змушені розкривати внутрішні деталі своєї роботи для загального огляду. Культура повинна наголошувати на цінності рецензій як інструменту співпраці, що не передбачає осуду, і слугує підвищенню якості та продуктивності. Ми маємо подолати вкорінену культуру індивідуальних досягнень і прийняти цінність співпраці.

Люди, які не хочуть проводити перевірки, будуть заперечувати, що перевірки не відповідають їхній культурі, потребам або часовим обмеженням. Існує переконання, що робота, виконана певними людьми (зазвичай самим мовцем), не потребує перевірки. Деякі члени команди не переймаються тим, щоб переглянути роботу колеги. Вони протестують: «Я занадто зайнятий виправленням власних помилок, щоб витрачати час на пошук чужих. Хіба ми всі не повинні виконувати свою роботу правильно?» Ці відмовки можуть відображати ставлення команди до якості, свідчити про опір змінам або виявляти побоювання щодо того, як взаємні перевірки можуть бути використані на шкоду окремим людям.

Стратегія: Подолання опору перевіркам

Відсутність знань легко виправити, якщо люди готові навчатися. Одноденний курс може дати членам команди спільне розуміння процесу. Участь керівництва у цьому курсі надсилає команді потужний сигнал: «Це достатньо важливо, щоб я витрачав на це час, тож це має бути важливим і для вас».

Як керівник, ви повинні розуміти культуру своєї команди та найкращі способи спрямування її членів до вдосконалення практик розробки програмного забезпечення. Чи існує спільне розуміння якості – і справжня відданість їй? Які попередні ініціативи змін виявилися успішними і чому? Які зазнали труднощів і чому? Хто є лідерами думок у групі та яке їхнє ставлення до перевірок коду?

Щоразу, коли ви просите людей працювати якимось новим способом, їхня негайна реакція – запитати: «А що мені з цього?» Це зрозуміла реакція, але це неправильне запитання. Правильне запитання звучить так: «А що нам із цього?» Можливо, я не отримаю двох годин користі від двох годин, витрачених на перевірку чужого коду. Однак інший розробник може уникнути десяти годин налагодження помилок пізніше в проєкті, і ми можемо випустити продукт швидше. Я вважаю цю колективну, групову вигоду переконливим обґрунтуванням для вжиття дій, орієнтованих на якість.

Таблиця 1 містить перелік переваг, які можуть отримати різні члени команди програмного проєкту від перевірки основних результатів життєвого циклу. Замовники також залишаються у виграші, отримуючи своєчасний продукт, який є більш надійним і стабільним та краще відповідає їхнім потребам.

Таблиця 1. Переваги від взаємних перевірок для різних проєктних ролей.

Впливові противники, які починають цінувати користь перевірок, можуть переконати інших членів команди спробувати їх. Менеджер з якості одного разу зіткнувся з розробником на ім’я Джуді, яка виступала проти того, що вона називала «перевірками, що поглинають час». Взявши участь у них під примусом, Джуді швидко побачила ефективність цього методу і стала головним прибічником у групі. Оскільки Джуді мала певний вплив на своїх колег, вона допомогла змінити ставлення розробників до перевірок – від опору до прийняття.

Поради для рецензентів

Динаміка відносин між рецензентами та автором робочого продукту є критично важливим аспектом рецензування. Автор повинен достатньо довіряти рецензентам і поважати їх, щоб бути відкритим до їхніх коментарів. У свою чергу, рецензенти повинні поважати здібності автора та його наполегливу працю.

Рецензенти повинні ретельно добирати слова, коли піднімають певне питання. Фраза «Я не побачив, де ці змінні ініціалізуються» може викликати конструктивну відповідь; більш звинувачувальне «Ви не ініціалізували ці змінні» може розізлити автора. Своє спостереження можна сформулювати у вигляді запитання: «Чи не надає цю послугу вже інший компонент?» Або вказати на момент непорозуміння: «Я не побачив, де цей блок пам’яті звільняється».

Слово «ви» рідко доречне у відгуках. Спрямовуйте свої коментарі на кінцевий продукт роботи, а не на автора. Кажіть «У цьому документі відсутній розділ 3.5 із шаблону» замість «Ви пропустили розділ 3.5». Рецензенти та автори мають співпрацювати поза межами рецензій, тому дотримуйтесь професіоналізму та взаємної поваги, щоб уникнути напружених стосунків. Рецензії не повинні формувати авторів, які мріють помститися своїм кривдникам. Помста – це не найкраща мотивація для участі в колегіальних рецензіях.

Коли чернетка моєї книги «Рецензування в розробці програмного забезпечення» проходила рецензування (що цілком природно!), один віддалений рецензент написав: «Як ви взагалі примудрилися» упустити якийсь момент, який він вважав важливим. Потім він додав: «Господи, Карле». Я поважав досвід цього рецензента і цінував його думку, але він міг би висловити свої зауваження більш тактовно. (Насправді я вже розглядав його питання, просто він цього не помітив.) На щастя, я не образився, і це стало чудовою історією для наступного розділу.

Автор, який виходить із наради з рецензування з відчуттям особистої образи або професійного приниження, добровільно більше не подаватиме свою роботу на перевірку. Помилки – це вороги на рецензуванні, а не автор чи рецензенти. Створіть культуру конструктивної критики, де члени команди прагнуть навчатися у своїх колег і виконувати роботу краще наступного разу.

Криміналізація помилок

Мій колега Філ якось розповів мені, що його керівник вимагав проводити перевірки коду щоразу, коли проєкт опинявся в скруті, з негласною метою знайти винного. Філ став першою жертвою на одному з проєктів. За його словами, команда перевірки виявила лише незначні проблеми, однак керівник потім скрізь розповідав, що проєкт затримується через те, що код Філа кишить помилками! Не дивно, що невдовзі Філ покинув ту токсичну компанію. Виділяти окремих розробників для «покарання» у вигляді перевірки їхньої роботи – це вірний спосіб знищити культуру рецензування коду.

Нещодавно я почув історію від менеджера з якості, який успішно впроваджував програму перевірок протягом двох років. Потім менеджер з розробки оголосив, що виявлення більше п’яти помилок під час перевірки буде враховуватися проти автора під час оцінювання продуктивності. Це дуже занепокоїло членів команди розробників. Воно створювало небезпечне враження, що метою перевірки є покарання людей за допущені помилки. Це перетворює на злочин помилки, яких ми всі припускаємося, і налаштовує членів команди один проти одного.

Неправильне застосування результатів перевірки таким чином може призвести до численних дисфункціональних наслідків:

Розробники можуть не подавати свою роботу на перевірку, щоб уникнути покарання за свої результати.

Члени команди можуть відмовлятися перевіряти роботу колеги, щоб не стати причиною чиєгось покарання.

Рецензенти можуть не вказувати на недоліки під час перевірки, а натомість повідомляти про них автору в приватному порядку, щоб вони не зараховувалися проти автора. Це підриває відкриту зосередженість на якості, яка має характеризувати взаємне рецензування.

Команди рецензентів можуть нескінченно сперечатися про те, чи є щось справжнім дефектом, оскільки дефекти зараховуються проти автора, тоді як зауваження чи прості запитання – ні.

Автори можуть переглядати дуже невеликі фрагменти роботи, щоб не знаходити більше п’яти помилок під час одного перегляду. Це призводить до неефективних і витратних за часом перевірок.

Культура перевірки в команді виробить негласну мету – знаходити якомога менше дефектів, а не виявляти їх якнайбільше.

Менеджери мають повне право вимагати від членів команди подавати свою роботу на перевірку та рецензувати результати роботи, створені іншими. Однак менеджери не повинні оцінювати окремих співробітників на підставі кількості дефектів, виявлених під час таких перевірок. Будь-який досвідчений менеджер і без подібних детальних даних знає, хто є сильним виконавцем у команді, а хто відстає.

Відгуки без кордонів

Програмні проєкти часто передбачають участь команд, які співпрацюють у кількох часових поясах, на різних континентах, у різних організаційних і національних культурах та з різними рідними мовами. Виклики взаємного рецензування в таких випадках включають як логістику комунікації, так і культурні чинники.

Різні культури по-різному ставляться до критики роботи колеги. Люди з певних країн або географічних регіонів схильні уникати конфронтаційних або критичних дискусій. Одного разу колега намагалася запровадити програму взаємного рецензування у своїй великій компанії в Міннеаполісі, штат Міннесота. Дещо розчарована, вона розповіла мені: «Люди приходили на зустрічі з рецензування, але всі вони такі “по-міннесотськи ввічливі”, що ніхто не хотів говорити нічого негативного про роботу іншого. Тож ніхто не вказував на помилки, які вони помітили». Дбати про почуття інших – це чудово, але проблеми все ж таки потрібно визнавати і вирішувати.

Якщо ви стикаєтеся з мультикультурною проблемою, дізнайтеся про способи налагодження співпраці між представниками різних культур та скоригуйте свої очікування щодо взаємних перевірок. Обговоріть ці делікатні питання з учасниками перевірки, щоб кожен розумів, як їхні відмінності впливатимуть на процес перевірки. Якщо учасники географічно роз’єднані, спробуйте провести початкове очне навчання перед початком перевірок. Там ви зможете розглянути культурні та комунікаційні чинники і допомогти членам команди навчитися ефективно працювати в умовах віддаленості одне від одного.

Зобов’язання керівництва

Ставлення та поведінка керівництва суттєво впливають на ефективність проведення перевірок в організації. Відданість керівництва виходить далеко за межі словесної підтримки або надання членам команди дозволу на проведення перевірок. Вам не потрібен їхній дозвіл: ви є професіоналом, якому довіряють виконувати свою роботу найкращим чином, як ви самі вважаєте за потрібне.

Нижче наведено кілька чітких ознак того, що керівництво підтримує взаємні перевірки. Якщо у вашій організації більшість із цих індикаторів відсутня, ваша програма перевірок, швидше за все, зазнає труднощів.

Забезпечення ресурсів і часу для розробки, впровадження та підтримки ефективного процесу перевірки.
Встановлення політик, очікувань та цілей щодо практики перевірки.
Забезпечення включення перевірок та завдань з доопрацювання до графіків проєктів.
Забезпечення доступності навчання для учасників та відвідування навчання ними самими.
Ніколи не використовувати результати перевірки для оцінки ефективності окремих осіб.
Притягнення людей до відповідальності за участь у перевірках та за конструктивний внесок у них.
Публічне заохочення першопрохідців перевірок для підкріплення бажаної поведінки.
Протидія іншим менеджерам та клієнтам, які ставлять під сумнів необхідність перевірок.
Повага до судження команди перевірки щодо оцінки якості матеріалів.
Запит звітів про стан роботи програми, скільки вона коштує та вигоди команди від перевірок.

Рецензуйте свій шлях до успіху

Якщо ви серйозно ставитеся до якості програмного забезпечення, ви визнаєте, що припускаєтеся помилок, просите колег допомогти їх знайти і охоче перевіряєте результати їхньої роботи. Ви відкинете власне его, щоб скористатися досвідом і поглядом своїх колег. Коли ви по-справжньому усвідомите переваги взаємного рецензування, вам буде некомфортно, якщо хтось інший не перевірить будь-який важливий результат вашої роботи.

Я думаю, що це гарне місце, щоб зупинитися.

Оригінальна стаття – The Soft Side of Peer Reviews, переклад та ревью – Іван Вільчавський. Зображення з оригінальної статті.