Как мы узнаем, что кто-то херово работает? (памятка нанимающему менеджеру про онбординг)

Таким был оригинальный заголовок памятки, которой я поделился с тимлидами. Вот ссылка на итоговый текст на английском, который пошел в базу знаний. Там немного более отполированные формулировки.

А ниже привожу оригинал.

Мы рассматриваем некоторые шаблоны поведения, которые являются красными флагами.

Применительно к онбордингу - это означает, что как только мы видим красные флаги - нужно приложить дополнительные усилия чтобы проанализировать ситуацию подробнее.

1. Время реакции в удаленной коммуникации (естественно, речь про рабочее время).
Норм: отвечает сразу или в течение минут, изредка через полчаса-час
Не норм: несколько раз отвечал с большой задержкой (полчаса, несколько часов)
Не норм №2: всегда отвечает с существенной задержкой (10-20 минут)

2. Посещение офиса в случае гибридного формата работы
Норм: ходит в офис столько дней, сколько договаривались. Проводит там большую часть рабочего дня (типа 7+ часов). В случае отклонений - предварительно спрашивает менеджера
Не норм: не ходит в офис обговоренное количество дней, хотя в договоре гибрид, без каких-либо объяснений или вопросов
Не норм №2: проводит в офисе несколько часов и уходит, без каких-либо объяснений
Короче, любое не обсужденное отклонение от обговоренного формата работы.

3. Регулярность коммитов в гит
Норм: коммиты несколько раз в неделю, в идеале каждый день
Не норм: коммит раз в неделю или тем более отсутствие коммитов в течение недели+

4. Реакция на отсутствие работы
Норм: сообщает, что закончил, интересуется что еще можно сделать
Норм №2: сообщает, что закончил + ищет сам что еще можно сделать (напр. сам выбирает задачу из бэклога)
Не норм: тихо сидит и ничего не делает, ждет, пока к нему сам обратится менеджер

5. Работа со своими задачами на доске (при условии, что информирован, что нужно самостоятельно работать со своими задачами на доске):
Норм: на доске задачи находятся большую часть времени в актуальных статусах, редкие (реже 1 раза в неделю) случаи, когда задача на несколько дней зависла. Актуализирует статусы сразу или каждые 1-2 дня
Не норм: забивает на актуализацию статусов
Не норм №2: ведет свои задачи, но постоянно "забывает", и исправляет только после указания менеджера

6. Работа с блокерами:
Норм: если его задача застряла, прилагает явные усилия, чтобы ее завершить - общается с другими людьми, уведомляет менеджера, задает вопросы, пытается разобраться
Не норм: встретив блокер, бросает задачу либо сразу, либо после 1 неудачной попытки что-то выяснить
Не норм №2%: никогда не возвращается к заблокированным на другой стороне задачам

7. Повторение ошибок:
Норм: сделав ошибку и получив объяснение, в следующий раз учитывает это и не повторяет аналогичную ошибку
Не норм: несколько (2+) раз повторяется ситуация, когда после объяснения снова и снова повторяет одни и те же ошибки

8. Оценка сроков
Норм: иногда ошибается, иногда угадывает, в целом видно что ответственно относится к договоренностям и пытается в них попадать, в случае отклонения - сообщает
Норм №2: берет адекватный запас и почти всегда попадает в оценку
Не норм: большинство раз (50%+) не попадает в свои оценки, никак не эволюционирует в этом со временем
Не норм №2: выйдя за срок - молчит, ничего не сообщает
Не норм №3: выйдя за срок, назначает новый срок, который тоже пропускает
Не норм №4: очевидно, что всегда во много раз (3+) завышает сроки

9. Вопросы:
Норм: задает вопросы, когда сталкивается с трудностями. Вопросы соответствуют уровню компетенции
Не норм: не задает вопросы или задает слишком мало, тратит время на безуспешные попытки разобраться самому
Не норм №2: задает слишком много вопросов (в том числе то, что легко найти самому), или вопросы, не соответствующие уровню компетенции (то что и так должен знать по своему резюме)

10. Первое впечатление
Норм: видно, что старается произвести хорошее впечатление на старте работы
Не норм: сразу забивает болт и даже не пытается как-то себя проявить на старте

(часть не влезла в пост, следующим сообщением)

(продолжение документа)

Как проходит онбординг разраба в общем случае?

Онбординг проходит примерно следующие стандартные этапы (можно использовать как чеклист):
1. Подготовка к работе (до нескольких дней) - получить доступы, развернуть проект, и т.п.
2. Ознакомпление с проектом (1-3 дня) - познакомиться с командой, почитать конфлюенс, посмотреть доску в Jira, посмотреть репозитории и т.п.
3. Выполнение нескольких простых задач, чтобы втянуться в процессы
4. Выполнение задач, соответствующих компетенции - соло, чтобы проверить скиллы
5. Выполнение задач со сроками - чтобы проверить навыки оценки сроков
6. Выполнение задач в команде (напр. на эпике) - чтобы проверить навыки командной работы
7. Получить фидбек от нового сотрудника - на свежий взгляд, что стоило бы улучшить в проекте
На определенном этапе (срок выбирается по ситуации), нужно выбрать время и проанализировать объем сделанной работы за период (например, за 2 недели), соответствует ли он заявленной по резюме компетенции. Повторить 2-3 раза, пока не станет ясно, что всё ок.

P.S. был глюк, что посты местами поменялись ) поправил

Тут довольно интересный эпизод произошел, и я впервые отредактировал свой пост. Событие нетривиальное, считаю такое надо пояснять. Да и это навело на некоторые мысли, которыми тоже хотелось бы поделиться.

Со мной связались и попросили удалить из поста имя челика, который не приходил в офис, врал что работает над задачей и т.п., вторая история из поста. Было довольно логичное объяснение, которое находится в юридической сфере. Я не был в курсе такой особенности.

После еще одной истории документа (которая будет в следующих постах), я собирался поподробнее остановиться на теме, почему я позволяю себе выносить суждения о том, что такое хорошо и что такое плохо, и более того, почему это полезно и почему этим стоит заниматься другим. Ведь есть расхожее мнение, что "не судите" и всё такое.

Еще когда работал разрабом, я задумывался - неужели людям не стремно просто не работать месяцами, или отвратительно вести себя с коллегами, или еще что-то такое делать, что повредит их репутации, даже если вынести за скобки совесть. Тогда еще ходили байки про "черные списки", в которые можно попасть, если будешь создавать проблемы. А ответ был простой )

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

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

Если система поощряет негативное поведение - негативного поведения будет становиться больше. Есть люди, которые буквально считают, что неэтично указывать на то, что кто-то сделал гадость. Это потихоньку подтачивает ветку относительно высокой производительности труда, на которой мы все сидим. Все пока держится на том, что большинство людей ведут себя культурно, не мучают друг друга и более или менее стараются делать то, за что им заплатили.

Мы живем в довольно странном мире, в котором люди все меньше и меньше убеждены, что хорошее поведение должно поощряться, а плохое - принижаться. Причем первого не может существовать без второго, так как если все всех хвалят - стирается граница, что есть хорошо. Это задачка, которую людям еще предстоит решить )

Взгляд за кулисы - как я проектный офис запускал.

Еще одна история про рабочий документ, который назывался "Документ-презентация Проектного Офиса".

Это было в середине 2021 года. В компании были довольно серьезные проблемы с менеджментом, там был управленческий рак (об этом явлении я рассказывал тут), так как я был в разработке, мне в первую очередь была понятна проблема работы продактов на стыке с разработкой - их было очень много, но при этом почти никто из них не мог выполнять базовые, казалось бы, вещи - провести бизнес-анализ и написать требования.

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

Я к тому моменту уже попробовал себя там в роли delivery manager, в роли и.о. директора по разработке, и на момент написания дока - снова занялся проектами и решал, чем хочу заниматься дальше в компании.

У меня на руках был успешный проект, который мы вдвоем с одним разрабом выполнили за 2,5 месяца от идеи до завершения (5 недель, если только разработка), и на котором я обкатал довольно успешно свою упрощенную версию фреймворка для проектного управления (которую до сих пор использую, если надо делать что-то сложное). При чем мне было ясно, что по тем методам, по которым вели разработку другие люди в компании - аналогичный проект занял бы при самом лучшем сценарии полгода, а более вероятно - год или более.

С другой стороны, на тот момент прошел уже почти год, как я был менеджером на той или иной роли, и мне уже было не интересно (плюс я убедился, что это не работает), выполнять такую работу без полномочий. То есть, вы можете как угодно хорошо понимать, как эффективнее выполнить проекты, но если есть какое-то количество участников, которые не хотят менять свой подход к работе, то без карт-бланша и полномочий вы с ними ничего не сделаете. Плюс мне уже не хотелось тащить в соло это дело, поэтому нужно было 1-2 человека.

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

В основном это выражалось в отсутствии требований (буквально, задача на несколько месяцев работы могла быть написана в три строчки), абсолютно бестолковом управлении бэклогом и приоритетами, в результате чего происходили постоянные переделки и сроки раздувались раза в три (была даже фича, которую делали несколько лет), плюс у руководства постоянно была ложная информация о распределении ресурсов разработки, получаемая со слов продактов.

В общем-то никакого rocket science не предлагалось, идея сводилась к внедрению супер базовых стандартов проектного управления и передаче функции управления проектами. Сам док и чем это кончилось - в следующем посте )

"Презентация проектного офиса" (это название данного документа) вызывает у меня смешанные чувства.

С одной стороны - идея была хорошая. Сейчас, спустя дополнительные 5 лет опыта менеджмента командами разработки, я вижу ту ситуацию ровно так же, как тогда.

С другой стороны - питч слабый ) ну вернее, это не питч. Когда я писал этот документ, я судил слишком по себе - что это будет вдумчиво прочитано, проанализировано и будет принято решение на основании оценки пользы для компании.

Я там вырезал всю коммерческую тайну, изменил названия и имена, но, грубо говоря, третий проект в таблице выполнен в 10 раз дешевле (буквально) в деньгах, чем второй. Имея примерно +/- одинаковый уровень комплексности.

Думаю, сегодня питч бы заключался вместо документа в нескольких фразах:
"Я сделал систему расчета бюджета всех проектов разработки за 2,5 месяца и X (мизерная сумма денег, ~1 оклад разработчика). Теперь Вы видите, сколько тратится на ключевые для бизнеса фичи. Уверен, Вы не понимаете, почему некоторые из них стоят так дорого. Они и не должны. За полгода я могу сократить вдвое бюджет этих проектов, если у меня будет карт-бланш. Могу рассказать детали."

Но тут дело было не в питче. Эта идея была обречена изначально. Присутствовал конфликт интересов между продуктовым департаментом и IT, и я это предлагал руководителю IT, который (я полагаю) не хотел развивать этот конфликт.

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

Пост-фактум анализируя ту ситуацию, я понял, что если ты не общаешься напрямую с собственником, у которого деньги в игре, то в бизнесе ты в никакой принципиальной стратегической роли не играешь, как бы твоя роль ни называлась.

Наконец, мой совет здесь: если вы видите в этом потенциал, всегда стоит попробовать. Даже если вы придумали что-то классное, и это оказалось не востребовано - вы с каждой такой ситуацией тренируетесь и увеличиваете свой профессиональный капитал.

P.S. Ниже сам документ, анонимизированный.

Лидерство vs. администрирование.

Когда я только пришел стажером в айтишку, у меня был бэкграунд многолетнего руководства в онлайн играх. И мне сразу бросилось в глаза, насколько по другому все устроено в коммерческих коллективах. Например: нанимают нового руководителя, он говорит людям что-то делать и в 99,9% случаев они... просто делают это. А еще - насколько малое количество руководителей в коммерческой деятельности обладают лидерскими качествами.

Лидерские качества - это не обязательно что-то хорошее. Заводила группы подростков, которые травят других детей - тоже обладает лидерскими качествами. Но профессиональный менеджер должен понимать разницу между лидерством и администрированием.

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

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

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

Лично у меня есть очень простой критерий для оценки лидерских качеств - предлагаю вам провести умственный эксперимент: представьте, что вам больше не платят за работу, или что за любую работу теперь платят одинаково. Продолжите ли вы вести дела со своим текущим руководителем или нет? И если вы менеджер - кто продолжит вести дела с вами завтра, если вычеркнуть фактор денег?