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

Инструмент 3: артефакты

Большинство пакетов при чтении вызывает мысль: ууух, понаписал-то! Каждый норовит описать себя супергероем. Настоящего супергероя же отличает одна критически важная деталь -- пруфы. Каждый факт нужно подтверждать таким пруфом, которые еще называют артефактами. Имплементировал фичу? Прикрепи PR. Придумал дизайн? Прикрепи дизайн документ. Пишешь, что фича была важна? Прикрепи оживленные дискуссии. Пишешь, что поднял метрики? Прикрепи графики (а еще лучше ссылки на систему мониторинга). Пишешь, что починил критический баг? Прикрепи пользовательские жалобы. Вся информация, которая не подкреплена артефактами, считается hearsay, и, в теории, не учитывается при принятии решения. На практике же, сбор пруфов ляжет на плечи вашего менеджера, причем в кратчайшие сроки, пока заседают комитеты. Стоит ли удивляться, что он плохо справится с этой задачей.

Разумеется, чтобы прикреплять артефакты, нужно собирать артефакты. Это очень удобно делать в баг-трекере: создаешь себе задачу и дампишь в нее все ссылки и важную информацию по мере работы над проектом. А уж список проектов за полгода-год запомнить обычно не составляет труда, хотя можно и создать задачу с задачами.

Собрать артефакты -- простая часть. Вот вы своим улучшением серверного фреймворка уменьшили p90 latency на 10% на всех серверных приложениях вашей команды. Сделали скриншоты метрик latency "до" и "после", красиво показав снижение в момент деплоя вашего изменения. Сделали еще скриншот долгосрочной стабильности новых значений в течении недели. И уже потираете руки, как вас отблагодарят за это бонусом! Однако, рано радоваться. Да, вы собрали артефакты, подтверждающие ваше заявление об улучшении. Но вы не собрали самого главного артефакта, который дает ответ на вопрос: и чо?

Невозможно отрицать, что снижение p90 latency на 10% -- это улучшение. Но есть не менее важный второй вопрос: а насколько это лучше? Если вы разрабатываете рекламную платформу с 1M QPS, то это революционная технология. А если batch сервис, который вызывается раз в неделю, то это эквивалент сэкономленных пяти центов в год. Вторая половина артефактов должна подтвердить, что ваши улучшения действительно полезны, и насколько. Как это сделать? Пока не изобретен объективный прибор, измеряющий пользу, для этого мы пользуемся коллективным мнением более опытных коллег. Иначе говоря, пользу подтверждает артефакт под названием peer feedback. Вы просите коллег, которые считаются экспертами в том деле, в котором вы считаете, что принесли пользу, подтвердить и квантифицировать эту пользу. Да-да, комментарии от коллег собираются исключительно для решения этой задачи. Написание коллегами хвалебных поэм кандидату совершенно бесполезно, и игнорируется при принятии решений. В фидбэке должно быть написано: "признанный эксперт X в домене Y подтвердил, что достигнутый кандидатом результат Z в домене Y действительно важен и сложен на уровень L".

Итого, кандидат должен предоставить артефакты, подтверждающие достижение результата; коллега-эксперт должен предоставить артефакт (peer feedback), подтверждающий ценность и сложность этого результата, а также вклад кандидата в этот результат. Менеджер кандидата же должен всех напрячь, и убедиться, что на все эти вопросы есть нужные ответы.

Меня часто спрашивают, что делать, если артефакты собрать сложно? Кандидат что-то отрефакторил, ну и что тут измеришь? Во-первых, если есть коллега-признанный эксперт в этой системе, то его фидбэк -- это уже вторая половина необходимых артефактов. Но на одних словах не выедешь, действительно нужна еще первая половина. Но тут все максимально просто: если просто ваш пулл реквест сделал жизнь кучи людей проще, то он и есть необходимый артефакт, подтверждающий проделанную работу. Чтобы выглядеть совсем хорошо, можно приложить статистику вызовов вашего кода командами тех коллег, которые подтверждают важность этой работы.