Перевірка ефективності роботи розробника програмного забезпечення: 6 прикладів відгуків
Конкретний зворотний зв’язок щодо продуктивності, часто у формі «оглядів продуктивності», відіграє центральну роль у розвитку розробників програмного забезпечення. У цій статті ми покажемо кілька практичних прикладів того, як давати зворотний зв’язок розробникам програмного забезпечення в різних ситуаціях, таких як співбесіди з працівниками, щорічні оцінки працівників або оцінки продуктивності - тобто в будь-яких формах індивідуальних бесід і контактів.
Важливість зворотного зв’язку для розробників програмного забезпечення
Чому зворотний зв'язок такий важливий (і складний) для розробників програмного забезпечення\*?
Мотивуючий зворотній зв’язок для розробників програмного забезпечення для інтровертів
Розробники програмного забезпечення традиційно більше зацікавлені в роботі з технічними деталями, ніж у роботі з іншими людьми. Тому для менеджерів може бути складним завданням ефективно та мотивуюче надавати зворотній зв’язок, особливо для більш інтровертних розробників програмного забезпечення.
Однак, як керівник розробників програмного забезпечення, ви повинні навчитися конструктивно передавати як позитивні, так і негативні відгуки під час оціночних співбесід, щоб розробники програмного забезпечення були дійсно мотивовані до реалізації виявленого потенціалу розвитку. Наступні приклади зворотного зв’язку в цій статті допоможуть вам у цьому.
Якщо вас цікавить загальне уявлення про регулярні індивідуальні зустрічі, перегляньте нашу статтю на цю тему: Посібник: 6 порад для успішних розмов 1 на 1.
Увага: оцінюйте розробників програмного забезпечення індивідуально
Для довідки: дослідження показують, що розробники програмного забезпечення традиційно більш інтровертовані. Однак тенденція полягає в тому, що серед розробників програмного забезпечення з’являється все більше різноманітних типів особистості. Тому ви завжди повинні уважно придивлятися та оцінювати, який тип особистості сидить навпроти вас, і спілкуватися відповідно до цього.
Джерело: Еволюція особистісного профілю інженерів-програмістів
Зворотній зв’язок: запитання та опитування
Питання та опитувальник для інтерв'ю зі зворотним зв'язком
Співбесіда з оцінювання розробника програмного забезпечення: типові запитання
Одне застереження, перш ніж я дам вам багато прикладів, шаблонів і фраз для вашої співбесіди з розробником програмного забезпечення: звичайно, у багатьох ситуаціях має сенс керувати питаннями, щоб спочатку перевірити спільне розуміння статус-кво - і не тільки в ІТ-індустрії.
Ось чому я склав кілька запитань для оцінювання працівників у розробників програмного забезпечення:
🎯 1 на 1 запитання для розробників програмного забезпечення: Фокус
- Що відволікає вашу увагу від роботи?
- Коли ви востаннє відчували стан потоку на роботі? Як легко вам увійти в потік?
- Коли і як ви помічали, що перевищили свій особистий «ліміт незавершеного виробництва»? Що ми могли б змінити, щоб допомогти вам досягти належного WIP у майбутньому?
- Як у вашій команді розподіляються внески в обговорення? Як ви роздумуєте про свою роль у цьому?
- Хто наші клієнти як компанія і як ваша робота конкретно сприяє задоволенню потреб клієнтів?
- Чого ви хочете навчитися, коли думаєте про своїх колег у компанії та за її межами?
Це дасть вам гарне уявлення про те, як розумно підійти до такого оціночного інтерв’ю. Якщо ви також хочете провести спеціальне опитування, я можу надати вам початковий шаблон.
Співбесіда з оцінювання розробника програмного забезпечення: опитування
Відповідні опитування можуть допомогти зробити розвиток розробників програмного забезпечення вимірюваним у часі.
Однак вони також можуть дуже добре слугувати інтерактивною основою для спільної дискусії.
Наступне опитування фокусується на чотирьох різних сферах, які є важливими для розробників програмного забезпечення. Ці твердження зазвичай оцінюються за шкалою, наприклад, від 1 (повністю не згоден) до 7 (повністю згоден).
🪞Опитування для зустрічі з працівниками: Для розробників програмного забезпечення
- Я ставлю під сумнів нашу роботу, базуючись на моєму розумінні наших #TeamZiele та потреб наших #Kunden.
- Я активно сприяю постійному вдосконаленню нашої команди. #TeamPlay
- Я знаю виклики і проблеми наших #Kunden.
- Мої робочі завдання, як правило, дуже швидко просуваються, навіть якщо необхідний зовнішній #Feedback.
Примітка: У цьому шаблоні співбесіди з працівниками згода з пунктами перевірки стану здоров'я (опитувальник) запитується за шкалою від 1 до 7.
Як я вже говорив, у програмному забезпеченні Echometer One-on-One ви знайдете багато шаблонів, які допоможуть вам розвивати співробітників під час співбесід з ними. Зокрема, для гнучких команд є також шаблони, які частково розроблені в інтерактивній та візуальній формі. Простий приклад цього ви можете знайти тут - не соромтеся переглянути наш інструмент, натиснувши кнопку нижче.
Шаблон індивідуальної бесіди Software Echometer
- Погляньте на зазначені тут області. Де, на вашу думку, і ви, і ваша команда маєте найбільший потенціал для вдосконалення?
Джерело: Echometer 1:1 Meeting Software
Як ви можете бачити на зеленій кнопці, ви навіть можете безкоштовно використовувати ці шаблони в нашому інструменті для зустрічей 1 до 1 Echometer. У нас також є багато інших шаблонів для запитань і цілих шаблонів для коучингу.
У нашому блозі є інша стаття, якщо вас цікавлять детальні шаблони для різних зустрічей віч-на-віч (наприклад, щотижневих, щорічних, 1-1 зі складними співробітниками…): 15 перевірених шаблонів зустрічей 1-1 для редагування (безкоштовно) .
А тепер до суті - перейдемо до конкретних прикладів і фраз для зворотного зв’язку з розробниками програмного забезпечення.
Шаблон для зворотного зв’язку з розробниками програмного забезпечення
Загальний шаблон для зворотного зв'язку з розробниками програмного забезпечення
Уникайте класичних методів зворотного зв’язку, таких як бутерброд зворотного зв’язку
Часто шаблони для зворотного зв’язку в особистих розмовах базуються на методі сендвіча. Будь ласка, уникайте цього з розробниками програмного забезпечення. “Розмови навколо”, не допомагають нікому в обговореннях з працівниками, і особливо розробники програмного забезпечення часто реагують на такі методи алергічно (див.: Критика сендвіч-методу для отримання зворотного зв’язку).
Розробники програмного забезпечення зазвичай розуміють, що коли менеджери дають загальні позитивні відгуки, то це лише інструмент, щоб змусити іншу людину почуватися краще.
На щастя, це теж працює краще.
Радикальна відвертість: метод зворотного зв’язку, який краще працює для розробників програмного забезпечення
Замість того, щоб загортати свій відгук на зустрічі один на один в балаканину у вигляді сендвіча, я рекомендую використовувати метод Radical Candor як основу для вашого шаблону відгуку. До речі, він корисний не тільки в індустрії програмного забезпечення, але й у приватному секторі - давайте заглибимося.
Радикальна відвертість означає надання максимально чесних і прямих відповідей під час оціночних інтерв’ю. Водночас, це також означає проявляти емпатію та зосереджуватися на благополуччі іншої людини. Радикальна відвертість показує, що вам не потрібно обирати щось одне: Або бути прямим і чесним, або чуйним і уважним. Натомість, ви можете бути і тим, і іншим одночасно:
Ще нижче: Що таке радикальна відвертість?
Розробники програмного забезпечення будуть вдячні, якщо ви відразу перейдете до суті негативних відгуків.
Шаблон зворотного зв’язку для розробників програмного забезпечення на основі Радикальної Відвертості
Цей шаблон базується на моделі SBI (ситуація, поведінка, вплив). Він допоможе вам спілкуватися щиро, прямо і водночас ввічливо.
Дивіться також “Правила надання зворотного зв’язку”
Ось інструкції для окремих частин шаблону зворотного зв’язку:
Шаблон зворотного зв’язку, частина 1: Підготовка заздалегідь
Перед тим, як надати відгук, витратьте кілька хвилин на обдумування наступних пунктів:
- Ситуація: Яку ситуацію ви маєте на увазі?
- Поведінка: Яку поведінку ви спостерігали з боку людини?
- Вплив: Який вплив мала поведінка людини (на вас та інших)?
- Побажання: Якого стану ви хочете досягти і чому? (Увага: Йдеться не про те, щоб безпосередньо бажати певної поведінки - це частина заходу (див. нижче). Йдеться, скоріше, про ширший контекст того, чому наслідки є для вас проблемою.)
- Дія: Які пропозиції ви можете запропонувати людині? Які зміни в поведінці можуть наблизити нас до цільового стану? Яку підтримку ви можете запропонувати?
Найкраще записувати пункти коротко, щоб нічого не забути під час розмови.
Шаблон зворотного зв’язку, частина 2: Початок розмови
Замість того, щоб починати з довгого бутерброда зворотного зв’язку під час індивідуальної зустрічі, тепер ви можете почати розмову безпосередньо з ситуації:
- “Я хотів поговорити з вами про ситуацію, коли ми…”
Опишіть ситуацію, а потім запитайте:
- “Ви ще пам’ятаєте цю ситуацію?”
Шаблон зворотного зв’язку, частина 3: Поведінка
Потім ви можете обговорити поведінку людини, яку ви спостерігали під час оціночної співбесіди:
- “Ви похитали головою і сказали…”
Перш ніж говорити про ефект, дайте співрозмовнику можливість прокоментувати своє сприйняття або спогад:
- “Чи правильно я відображаю це з вашої точки зору?”
Дайте людині можливість описати свою точку зору на речі. Намагайтеся, щоб обидві точки зору були представлені в кімнаті на рівних, не коментуючи їх. Обмежтеся питаннями про зміст точки зору іншої людини.
Шаблон зворотного зв’язку, частина 4: Вплив
Лише в цій частині йдеться про обговорення наслідків поведінки. Спочатку залишайтеся максимально об’єктивними:
- “У мене склалося враження, що після того, як ви [спостерігали за поведінкою], мій колега Марк виглядав дуже ображеним і більше не бажав продовжувати співпрацювати з нами”.
Однак, якщо наслідки зачіпають і вас, важливо розповісти і про це. Звичайно, ви завжди повинні залишатися професіоналом, але ви також можете проявити свою людську сторону:
- “Я сам, чесно кажучи, був збентежений цією ситуацією, і з того моменту розмова стала для мене неприємною”.
Шаблон зворотного зв’язку, частина 5: Побажання
Висловіть свій конкретний запит у цій частині оціночної співбесіди:
- “Для мене важливо, що ми знову знайшли хорошу основу для співпраці з нашим колегою Марком”.
Знову поставте його в контекст:
- “Крім того, для мене дуже важливо, щоб ми разом працювали над тим, щоб підтримувати добру співпрацю та стосунки з усіма сусідніми спеціалізованими галузями”.
Також зробіть посилання на відповідні цілі, які пояснюють, чому ви маєте таке бажання:
- “Тільки завдяки добрим стосункам ми можемо досягти наших цілей як команда в цій компанії. Для мене також важливо, щоб ми мали гарну репутацію як команда всередині компанії”.
«Мені подобається працівник, але він не показує бажаних результатів. Як я можу підійти до цього у зустрічах 1:1?»
Вирішіть цю проблему
"Я часто не знаю, чи був я занадто твердим – або занадто м'яким – в моїх 1:1, щоб мати позитивний вплив".
Вирішіть цю проблему
"Я не можу розпізнати жодних закономірностей чи тенденцій у моїх знімках 1:1. Все здається ізольованим".
Вирішіть цю проблемуШаблон зворотного зв’язку, частина 6: Вимірювання
Перед тим, як представити власні ідеї рішень, ви можете поставити відверті запитання під час індивідуальної бесіди:
- “У мене є кілька ідей з цього приводу. Але спочатку я хотів би почути вашу думку: Як, на вашу думку, ми можемо досягти мети?”
Потім ви можете поділитися своїми ідеями. Домовтеся разом про обов’язкові та конкретно визначені подальші дії. Зафіксуйте це письмово.
Шаблон зворотного зв’язку, частина 7: Відмова
Запитайте, чи була оціночна співбесіда корисною для співрозмовника і чи залишилися у нього запитання без відповідей. Домовтеся про наступну зустріч, коли ви будете говорити на цю тему.
Продемонструйте свою вдячність за відкритий діалог і подякуйте людині за її розуміння та співпрацю.
Шаблон зворотного зв’язку, частина 8: Проаналізуйте свій відгук ретроспективно
Наприкінці кожної сесії зворотного зв’язку ви повинні поставити собі наступне запитання:
- Чесність: Чи поділився я своїм відгуком чесно і без прикрас?
- Вдячність: чи відчуває людина цінність мого відгуку?
Якщо ви можете відповісти “так” на всі запитання, ваша сесія зворотного зв’язку пройшла дуже добре. Якщо ні, не хвилюйтеся. Подумайте про те, як ви можете сформулювати питання по-іншому в майбутньому. І знову ж таки, більшість з цих порад стосуються не лише ІТ-індустрії програмного забезпечення.
На цьому етапі я хотів би зазначити, що, звичайно, існує програмне забезпечення для спрощення відповідних обговорень зворотного зв’язку, а також для довгострокового коучингу розробників програмного забезпечення.
Наше програмне забезпечення для індивідуальних зустрічей пропонує різні шаблони для зустрічей співробітників з розробниками програмного забезпечення і навіть робить розвиток співробітників вимірюваним. Погляньте на наш інструмент і спробуйте наступний шаблон:
Ніяких світських розмов, ніяких незручних пауз. Цей шаблон 1:1 просто завжди працює.
💬 З шаблону:
- Яким досягненням ви пишаєтеся, яке я, можливо, не помітив?
- Яка невелика зміна одразу покращила б вашу роботу?
- На що б ви хотіли приділяти більше часу на роботі?
…
Тепер давайте почнемо за допомогою цього шаблону оціночної співбесіди і розглянемо кілька практичних прикладів!
Приклади зворотного зв’язку під час зустрічей 1:1: Якість коду, власність
Приклади зворотного зв’язку з розробниками програмного забезпечення під час індивідуальних зустрічей
Приклад зворотного зв’язку з розробниками програмного забезпечення під час зустрічей 1 на 1: Якість коду
З Танею 👩🏼🦰 в ролі керівника команди та Марком 👨🏽 в ролі співробітника.
Опишіть ситуацію
“На нашому останньому перегляді коду ми переглянули ваш запит на злиття для реалізації нової функції в інформаційній панелі. Код був функціонально правильним і відповідав вимогам.”
“Так, я пам’ятаю!”
Спостережувана поведінка
“Я коментував уривки, які були досить складними і важкими для читання. Наприклад, був метод з більш ніж 50 рядками, який поєднував кілька обов’язків. Однак ви лише поверхово прокоментували цей коментар і не заглиблювалися в нього далі”.
“Для мене це зауваження звучало як необов’язкова пропозиція. Мені здалося, що змінювати рішення знову займе занадто багато часу”.
Вплив
“У будь-якому випадку, ваш коментар мене трохи розчарував, якщо чесно, і замість того, щоб наполягати на виправленні від вас, я просто покращив метод сам, тому що я все одно вже продумав свій шлях у коді”.
“О, я не знав про це”.
Мета і бажання
“Наша спільна мета - зробити наш код не лише функціональним, але й таким, що легко підтримується та зрозумілим для всіх”.
“Це саме те, як я це бачу!”
Заходи
“Які ваші пропозиції щодо того, як ми можемо покращити якість коду в таких випадках у майбутньому?”
“Мені б допомогло, якби в коментарях було легше зрозуміти, чи пропонується покращення, чи вимагається”.
“Добре, давайте зробимо це - я ще раз підніму це питання на зборах команди. Крім того, з моєї точки зору, все ж потрібне подальше спостереження з вашого боку.”
“Як щодо того, щоб ми одразу перейшли до парного програмування наступної теми, щоб ви могли поглибити моє розуміння вимог до якості коду?”
Висновок
“Звучить як два хороших продовження! Тоді давайте так і зробимо. Я б хотіла поставити дату в своєму щоденнику на середину наступного тижня, щоб почати парне програмування”.
“Гаразд, чекаю з нетерпінням!”
Приклад зворотного зв’язку з розробниками програмного забезпечення під час зустрічей 1 на 1: Власність
З Танею 👩🏼🦰 в ролі керівника команди та Марком 👨🏽 в ролі співробітника.
Опишіть ситуацію
“Марку, я хотів би поговорити з тобою про останнє завдання, де ми розробляли нову функцію для процесу експорту. Ця функція вже запущена, але в процесі її реалізації виникли певні проблеми.”
“Так, я пам’ятаю. Що саме ви маєте на увазі?”
Спостережувана поведінка
“Я помітив, що було кілька тривалих затримок після того, як код був переданий на тестування. Наприклад, на деякі коментарі від колег з QA не було відповіді кілька днів. Також траплялося, що мені доводилося двічі нагадувати про пропущену рецензію”.
“Гм, я розумію. Чесно кажучи, було досить багато роботи, і я думав, що тестування триватиме паралельно”.
Вплив
“В результаті нам довелося відкласти наше розгортання через цю проблему”.
“О, я навіть не знав про це. Я думала, що ти зв’яжешся, якщо щось буде терміново”.
Мета і бажання
“Наша мета - звести до мінімуму непотрібні затримки, а також навчити розробників мислити як власників під час впровадження. Це означає, що кожен активно стежить за тим, щоб його тікет пройшов від початку до кінця –, і це також включає комунікацію з QA”.
“Я розумію, що ви маєте на увазі. Я, безумовно, хочу, щоб процеси йшли більш злагоджено”.
Заходи
“З вашої точки зору, що ми можемо зробити, щоб ви могли діяти більш проактивно і проявляти відповідальність у таких ситуаціях?”
“Я думаю, що було б корисно, якби ми встановили більш чіткі очікування, наприклад, щоб я щодня перевіряв відкриті питання під час етапу тестування. Так я зможу переконатися, що нічого не залишилося недоробленим”.
“Звучить непогано. І я б запропонував, щоб для наступних великих завдань після того, як код буде доопрацьовано, ви склали короткий план того, як ви хочете довести тему до запуску в реальному часі. Ви можете показати цей план мені або колезі з QA”.
“Згоден. Тоді я сам зможу краще стежити за ситуацією”.
Висновок
“Чудово. Давайте запишемо ці два заходи таким чином: Ви робите щоденні перевірки під час етапу тестування і плануєте подальші дії для наступного великого завдання. Це можливо для вас?”
“Так, це підходить. Я запишу це прямо в свій щоденник”.
“Чудово. Я впевнений, що це матиме велике значення. Під час нашої наступної особистої зустрічі ми ще раз подивимося на статус наших заходів. Дякую!”
Ведення за допомогою запитань: шаблон для зустрічей 1:1
Мудрість з управлінської літератури говорить: керуйте, ставлячи запитання. І в цьому є багато сенсу.
Якщо ви регулярно і безперервно проводите зустрічі 1-на-1, на яких ви разом зі співробітником розмірковуєте над темою зворотного зв’язку (задаючи питання), то проблеми не можуть “накопичуватися”.
Тому я хотів би запропонувати вам ще один шаблон, який ви можете використовувати в нашому інструменті Echometer разом зі своїм співробітником. В принципі, ви також можете використовувати цей шаблон на регулярній основі.
Спробуйте їх, просто натиснувши на кнопку нижче (вхід не потрібен):
Початок
- Як пройшов ваш тиждень?
📊 Оновлення проєкту
- Як просуваються ваші поточні проєкти? Чи є великі успіхи чи перешкоди?
- Чи є технічні проблеми, які ви хотіли б обговорити або обміркувати разом?
💻 Якість коду та розробка
- Як ви ставитеся до якості своєї роботи останнім часом?
- Чи є сфери, в яких ви хотіли б вдосконалитися або навчитися новим навичкам?
🤝 Команда, співпраця та наступні кроки
- Як відбувається співпраця в команді? Чи є прогалини в комунікації?
- Чи ефективно інструменти та процеси, які ми використовуємо, підтримують вашу роботу?
- Як ви уявляєте свою кар'єру в найближчі один-два роки?
- Чим я можу допомогти вам досягти успіху?
Висновок
- Що ви найбільше чекаєте в найближчі місяці?
- Чи є у вас інші питання чи проблеми?
⁉️ Перевірка настрою (опитування)
Оцінка ефективності Приклади відгуків Приклади відгуків: Командна робота, відповідальність
Приклади зворотного зв’язку з розробниками програмного забезпечення в огляді ефективності
Примітка: Традиційні атестації, як правило, непопулярні як серед розробників програмного забезпечення, так і серед менеджерів, і багато хто стверджує, що хороші індивідуальні зустрічі є достатніми і повинні замінити атестації. Див: “Атестація - це безглуздо і образливо”, Forbes.
Однак часто атестація все ще залишається заздалегідь визначеним форматом у компанії. Звісно, це не повинно заважати вам проводити оцінювання ефективності як діалог на рівні очей зі своїми працівниками, а не обмежуватися оцінюванням зверху вниз. Наступні приклади діалогу віч-на-віч показують, як це може працювати.
Примітка: Як уже згадувалося, шаблони оцінювання працівників, звичайно, можуть допомогти у конструктивному спілкуванні з ними. Наступна публікація в блозі може допомогти вам, якщо ви більше зацікавлені в цій темі: 5 шаблонів для регулярних перевірок співробітників .
Приклад зворотного зв’язку для інженерів-програмістів у відгуках про роботу: Командна робота
З Танею 👩🏼🦰 в ролі керівника команди та Марком 👨🏽 в ролі інженера-програміста.
Опишіть ситуацію
“Коли я оцінював пункт \‘Team Work\’ у вашому шаблоні аналізу ефективності, мені, на жаль, вдалося поставити лише 5 з 10 можливих балів. Я хотів би пояснити вам це, щоб дати вам справедливий шанс покращити цей пункт.”
“О, добре. Будь ласка, допоможіть мені це зрозуміти.”
Спостережувана поведінка
“Я помітив, що в останні місяці траплялися ситуації, коли співпраця з командою не була оптимальною. Наприклад, у нашому останньому спринті було кілька випадків, коли ти працював над завданнями наодинці, хоча їх можна було б краще вирішити разом з іншими. Одним з конкретних прикладів була інтеграція нового API. Ми розглядали варіант, щоб ви з Алексом працювали над цим разом, але ти взявся за більшість кроків самостійно і лише мінімально залучав Алекса”.
“Я думав, що буде ефективніше зробити це швидко самому. Я не усвідомлював, що це сприймається як проблема”.
Вплив
“Однак це призвело до втрати прозорості в команді. Пізніше Алекс мав труднощі з залученням до суміжних завдань, оскільки не знав, як саме налаштований API. Я також отримував відгуки від інших членів команди, що вони іноді не відчували себе достатньо залученими і їм було важко отримати підтримку від вас, коли у них виникали питання”.
“Це мене дивує, якщо чесно. Я думав, що допоможу, коли мене попросять”.
Мета і бажання
“Наша мета як команди - не лише ефективно працювати, але й ділитися знаннями та залучати кожного. Це зміцнює співпрацю і гарантує, що ми всі можемо представляти один одного. У майбутньому я хотів би, щоб ви більше використовували свою роль носія знань у цій команді, щоб активно ділитися знаннями та розширювати можливості інших членів команди. Командна продуктивність важливіша за індивідуальну”.
“Гаразд, я розумію, що ви маєте на увазі. Думаю, я просто занадто зосередився на власній продуктивності”.
Заходи
“Що могло б допомогти вам приділяти більше уваги залученню команди до роботи та обміну знаннями?”
“Я міг би взяти за звичку уточнювати, хто і як може працювати над великими завданнями на самому початку. Можливо, ми також могли б створити щось на кшталт старту для завдань, щоб узгодити грубі архітектурні рішення і визначити завдання, які хтось має виконувати самостійно або які ми навіть повинні робити в парі”.
“Звучить непогано. У мене також виникла ідея: як щодо того, щоб ти не тільки звітував про прогрес на наших щотижневих зустрічах команди, але й активно ділився інсайдами щодо коду та архітектурних рішень?”
“Це хороша думка. Це може допомогти полегшити нашим недосвідченим колегам подальшу роботу над моїм кодом”.
Висновок
“Чудово. Тоді ми запишемо подальші дії в наш шаблон для оцінки ефективності:
- Відтепер ви будете активно ділитися своїми знаннями та архітектурними рішеннями з командою у щотижневиках.
- Відтепер ти будеш проводити зі своїми темами ознайомчу зустріч з іншим розробником, щоб ви разом опрацьовували рішення і ділили між собою реалізацію.
“Звучить непогано.”
“OK. Обидва заходи я хотів би спочатку занотувати для перегляду через два місяці. Тоді ми зможемо обговорити статус під час нашої особистої зустрічі і побачити, як нам діяти далі.”
“Так, а потім подивимося, чи не зможеш ти покращити свій бал за “командну роботу”. Я хотів би отримати хоча б 8 з 10”.
“Я радий це чути! Я абсолютно вірю, що це реально, і буду підтримувати вас, де тільки зможу”.
“Дякую!”
Приклад відгуку для інженерів-програмістів Оцінки ефективності: Власність
Перейдемо до наступного прикладу індивідуальної бесіди, яка стосується зворотного зв’язку з розробником програмного забезпечення на тему власності.
Як завжди, з Танею 👩🏼🦰 в ролі керівника команди та Марком 👨🏽 в ролі інженера-програміста.
Опишіть ситуацію
“Коли мені довелося оцінювати пункт \‘Відповідальність\’ у вашому шаблоні аналізу ефективності, я зміг поставити лише 6 з 10 балів. Я хочу пояснити вам, чому це так, і дати вам можливість розвиватися в цій сфері.”
“Вау, це мене трохи дивує. Зрештою, я брав участь у такій кількості тем, як мало хто інший у команді. Будь ласка, поясніть мені.”
Спостережувана поведінка
“В останні місяці я помітив, що часто виникають затримки у виконанні ваших завдань. Є кілька прикладів, коли коментарі QA або огляди коду залишалися без відповіді протягом тривалого періоду часу. В результаті, ваші теми з’являлися лише після тижнів затримок. Одним з конкретних прикладів було виправлення помилки експорту. Ви відповіли на відгуки від QA лише після неодноразових запитів, і зміни були запущені лише через три тижні”.
“Так, я пам’ятаю. Я працював над двома іншими темами одночасно і не зміг так швидко написати відгук”.
Вплив
“Це вплинуло на швидкість і продуктивність всієї команди. QA довелося кілька разів повторно перевіряти, що обмежило їхні можливості. План випуску також довелося відкласти. Крім того, виникає відчуття, що ви не берете на себе повну відповідальність за доопрацювання своїх проблем, що негативно впливає на командну динаміку. Деякі члени команди сказали мені, що вони не впевнені, чи можуть вони покластися на вас, коли йдеться про залежності”.
“О, вибачте за це. Я не знав про це. Я намагався виконувати завдання паралельно, але, мабуть, це не дуже добре вийшло”.
Мета і бажання
“Моя мета полягає в тому, щоб ви зосередилися на меншій кількості тем, але взяли на себе повну відповідальність за кожне завдання від початку до кінця. Це означає, що ви не тільки пишете початковий код, але й забезпечуєте оперативну обробку відгуків QA і виконання теми за графіком. Таким чином, ми можемо уникнути того, щоб завдання залишалися відкритими довше і блокували інші”.
“Це має сенс. Я часто відчував себе перевантаженим, тому що у мене було занадто багато тем одночасно. Можливо, дійсно краще зосередитися на меншій кількості завдань”.
Заходи
“Як ми можемо допомогти вам зосередитися на кількох темах і взяти на себе відповідальність за їхню повну реалізацію?”
“Я міг би спробувати обмежити себе максимум двома темами на спринт і ніколи не працювати більше ніж над трьома темами одночасно. Я також повинен заблокувати фіксовані слоти в моєму календарі для регулярної роботи над коментарями та відгуками, щоб нічого не залишилося позаду”.
“Звучить розумно. Крім того, я думаю, що було б добре, якби ви могли проактивно просити про допомогу в наших стендапах, якщо ви працюєте над багатьма темами одночасно. Зазвичай має бути хтось, хто може перебрати на себе якусь тему”.
“Гаразд, справедливо.”
Висновок
Давайте зафіксуємо ці заходи як ціль на наступні два місяці:
Менше роботи паралельно:
- Ви берете максимум дві теми за один спринт і не працюєте більше ніж над 3 темами паралельно.
- Вимагайте активної підтримки від команди в стендапах
- Фіксовані слоти в календарі для опрацювання коментарів і переглядів.
“Звучить реалістично. Давайте зробимо так”.
“Чудово. Через два місяці ми побачимо, чи спрацювали ці заходи, і чи зможемо ми знову підвищити вашу оцінку за критерієм “Власність"" в оцінці ефективності”.
“Дякую, Таня. Я постараюся застосувати це на практиці. Раніше я завжди отримував найвищі оцінки за “Власність”. Як ви гадаєте, чи отримаю я її знову до наступного оцінювання?”
“Я задоволений цим. Так, я вважаю, що за допомогою цих заходів можна досягти швидкого покращення. Давайте обговоримо стан справ і те, чи потрібна вам підтримка, під час наших двотижневих індивідуальних зустрічей”.
“Дякую! Так, я був би радий, якби ми змогли досягти тут помітного поліпшення протягом декількох тижнів!”
Щорічний діалог Приклади відгуків: Бажання змінити роль
Приклади зворотного зв’язку з розробниками програмного забезпечення у щорічному огляді
Якщо ви вже проводите регулярні індивідуальні зустрічі з розробниками протягом року або оцінюєте їхню роботу, то, ймовірно, вам більше не потрібні детальні щорічні зустрічі. Обмін інформацією про результати роботи, відгуки та подальший розвиток вже має бути постійним діалогом:
Тим не менш, є компанії, які потребують класичної щорічної оцінки.
💡
Якщо ви, як менеджер розробників програмного забезпечення, вже проводите регулярні зустрічі 1:1 або оцінювання ефективності, щорічний огляд має бути лише формальністю:
Розробник програмного забезпечення вже повинен знати про відгуки і вже повинен працювати над потенціалом розвитку.
Тож якщо вам, як менеджеру розробників програмного забезпечення, доводиться виконувати формальність зустрічі наприкінці року (можливо, на додаток до регулярних індивідуальних зустрічей), давайте також розглянемо приклад щорічного оцінювання працівника з розробником програмного забезпечення.
До речі, ще одна порада: Якщо ваша перша особиста зустріч з новим співробітником не за горами, можу порекомендувати нашу статтю на цю тему: 5 порад для індивідуальних зустрічей з новими працівниками .
Зразок порядку денного та шаблон щорічної зустрічі з розробником програмного забезпечення
- Огляд та ефективність
- Успіхи: Які проекти чи завдання пройшли успішно? Де очікування були перевищені?
- Виклики: Що не спрацювало так добре і чому? Як можна подолати ці виклики в майбутньому?
- Рефлексія: Як розробник бачить власну ефективність? Який зворотній зв’язок від команди чи керівника?
- Співпраця та командна культура
- Комунікація: як сприймається співпраця в команді та з керівником?
- Робоча атмосфера: чи є потенціал для покращення культури команди або робочого середовища?
- Відгуки про лідерство: як менеджер може краще підтримувати розробника?
- Зворотній зв’язок від розробника: Чи є пропозиції щодо покращення процесів, інструментів або культури роботи?
- Баланс між роботою та особистим життям: Як ви ставитеся до свого поточного робочого навантаження? Чи є понаднормові або стресові фактори?
- Ресурси: чи є інструменти, процеси та рамкові умови достатніми для ефективної роботи?
- Експертиза, цілі та розвиток
- Сильні сторони: Які технічні, методологічні або соціальні навички характеризують розробника?
- Подальше навчання: Які нові технології або навички розробник хоче вивчити? Чи є відповідні курси, конференції або проекти?
- Кар’єрні цілі: Яку посаду або відповідальність розробник прагне отримати в середньо- та довгостроковій перспективі? Які кроки ведуть до цього?
- Фокус проекту: над якими проектами або технологіями розробник хотів би працювати більш інтенсивно?
- Винагорода
- Винагорода за результатами діяльності: чи потрібно коригувати зарплату або бонуси?
- Висновок
- Короткострокові цілі: Які конкретні цілі варто поставити на наступний рік?
- Домовленості: Які наступні контрольні точки для відповідних заходів?
Нижче наведено типовий приклад зворотного зв’язку в рамках підсумкової оцінки або щорічної оцінки ефективності: Прохання працівника про зміну ролі.
Приклад зворотного зв’язку на щорічних зборах: Бажання змінити роль
З Танею 👩🏼🦰 в ролі керівника команди та Марком 👨🏽 в ролі інженера-програміста.
Вступ і ситуація
“Марку, радий, що сьогодні ми можемо поговорити про твій річний звіт і твої цілі. Чи є якісь конкретні теми, які є особливо важливими для тебе?”
“Так, я думав про свій подальший розвиток. Я міг би уявити, що розвиваюся в напрямку архітектури програмного забезпечення. Ця тема давно мене приваблює, і я хотів би більш інтенсивно займатися архітектурними рішеннями та стратегічним управлінням технологіями.”
“Це захоплююче, Марку. Я радий, що ти маєш такі чіткі цілі. Давай поговоримо про те, як ми можемо підготувати тебе до них. Є кілька моментів, в яких, на мою думку, тобі потрібно розвиватися далі, перш ніж ми зробимо наступний крок”.
Залиште відгук
“По-перше, я хотів би підкреслити, що цього року ви досягли значного прогресу, особливо в якості ваших реалізацій та у роботі з новими технологіями. Ви також продемонстрували, що бачите ширшу картину, наприклад, з впровадженням нової системи кешування”.
“Дякую, я радий це чути!”
“Коли я думаю про роль архітектора програмного забезпечення, я все ще бачу деякі вимоги, які, на мою думку, не виконуються в повній мірі. Наприклад, спілкування з командою та залучення інших до прийняття технічних рішень є ключовим компонентом. Я все ще бачу в тобі потенціал. Ти часто приймаєш рішення самостійно, не залучаючи команду на досить ранніх етапах”.
“Гаразд, я це розумію. Я не хотів нікого затримувати, але я розумію, що це не ідеально для ролі архітектора”.
Мета і бажання
“Саме так. Архітектор програмного забезпечення - це також коуч і комунікатор. Йдеться про залучення інших до роботи, передачу технічних концепцій та спільну розробку рішень”.
“Це має сенс. Я також усвідомлюю, що поки що не можу донести свої думки про архітектуру до членів моєї команди настільки ж ефективно”.
Заплануйте заходи
“Я думаю, що ми можемо разом попрацювати над цим, щоб ви могли претендувати на цю роль протягом наступних 6 місяців. Як щодо того, щоб визначити конкретні заходи?”
“Із задоволенням. Що ти маєш на увазі?”
“Перш за все, я хотів би, щоб ви модерували процес прийняття рішень щодо архітектури програмного забезпечення, а не приймали рішення самі. Як щодо модерації архітектурного старту для кожної з наступних основних тем? Метою було б підтримати колег у процесі прийняття рішень, а потім дозволити їм самим впроваджувати рішення”.
“Це звучить добре. Так я вчуся застосовувати свій вплив як коуч, а не втілювати все сам.”
“Крім того, я думаю, що є хороші курси для підготовки розробників до ролі архітектора програмного забезпечення. На цих курсах, безумовно, будуть розглядатися не тільки hard skills, а й soft skills, необхідні для цієї ролі.”
“Так, я вже фактично підібрав курс.”
Висновок
“Чудово, тоді я зафіксую наступне для нашої щорічної зустрічі:
- Мета розробки: Архітектор програмного забезпечення
- Заходи:
- Модерування архітектурних кік-оффів у команді
- Участь у курсі для архітекторів програмного забезпечення
Звичайно, ми постійно обговорюємо ці теми на наших особистих зустрічах, але наступна офіційна перевірка відбудеться під час нашого аналізу ефективності через 3 місяці.
“Звучить добре. До того часу ми вже повинні багато чого досягти.”
“Я теж так думаю! Якщо тим часом вам спадуть на думку інші речі, як я можу підтримати вас у цьому, будь ласка, звертайтеся до мене в будь-який час.”
“Чи можемо ми тоді через 3 місяці знову поговорити про мою бажану зміну ролі?”
“Звичайно, я не можу нічого обіцяти щодо зміни ролі. Але я взяв до уваги ваше бажання і намагаюся підтримати вас якнайкраще.”
“Дякую!”
Висновок: зворотній зв’язок з інженерами-програмістами під час зустрічей 1:1, атестацій та щорічних оцінок
Висновок: Мотивуючі відгуки для розробників програмного забезпечення
Приклади та шаблони показують, що надавати мотивуючий зворотний зв’язок розробникам програмного забезпечення під час індивідуальних зустрічей та зустрічей наприкінці року не так вже й складно, чи не так? Залишайтеся щирими та доброзичливими, не ходіть навколо та покажіть, що ви зацікавлені у спільному рішенні.
Якщо вам вдасться втілити \‘Radical Candor\’ у ваших розмовах з працівниками та за їх межами, виявляючи повагу та чесність, реакція може бути навіть більш позитивною та конструктивною, ніж ви думаєте.
Щасти вам у наступних сесіях зворотного зв’язку!
А якщо вам подобаються хаки, які роблять ваше життя простішим, я рекомендую наше програмне забезпечення Echometer. Ви можете спробувати його абсолютно безкоштовно.
Наше програмне забезпечення для індивідуальних зустрічей пропонує різні шаблони для зустрічей співробітників з розробниками програмного забезпечення і навіть робить розвиток співробітників вимірюваним. Погляньте на наш інструмент і спробуйте наступний шаблон:
Ніяких світських розмов, ніяких незручних пауз. Цей шаблон 1:1 просто завжди працює.
💬 З шаблону:
- Яким досягненням ви пишаєтеся, яке я, можливо, не помітив?
- Яка невелика зміна одразу покращила б вашу роботу?
- На що б ви хотіли приділяти більше часу на роботі?
…
