#рецепт
Как включаться в работу на новом месте
Здравствуй, дорогой читатель. Этот пост будет слегка сумбурным и не подкрепленным какими-то прочитанными ресурсами или словами экспертов. Просто мое мнение в чистом виде. И что самое неприятное, так это то что это мнение основано на том, чего я не делал сразу или делал скверно.
Я хочу поговорить о следующем: ты прошел собес, оформился, начался твой первый день и поехал онбординг (если он есть, ха). Речь пойдет не об онбординге для менеджеров как таковом, где разъясняется как все устроено с маленькой буквы. А именно о "КАК все устроено".
Если решать вопрос буквально, то обычно есть обучающий курс, страница новичка или регламент для менеджера/тимлида о том как надо онбордить. И формально ты действительно узнаешь доступы, какие фичи есть в проекте, на каких технология он делается, где лежит документация, культуру поведения в компании и тд. Но я очень сомневаюсь что это даст то самое понимание с большой буквы лично для тебя, глубинное.
Я пришел к следующему рецепту из 5 шагов:
1. Дневник людей;
2. Сделать работу каждого руками;
3. Дневник изменений;
4. Личный проект по онбордингу;
5. Регламенты работы менеджера.
Давай подробно разберем каждый из них.
Дневник людей
Ты вел когда-нибудь дневник себя самого? Вот тоже самое, но только про вон тех ребят. По каждому коллеге пиши заметки. Сегодня Василий Петрович был бодрячком, делай проброску в топик кафки поля по задаче. Нужно записывать не так много:
- Настроение и поведение;
- Интересы и вещи которые раздражают;
- Привычки;
- Сильные стороны (это самое сложное).
Ценность этой информации не в том что она документирована и по ней можно предъявлять или манипулировать людьми (не надо так делать). По этим записям ты научишься чувствовать людей и сможешь раскрыться как руководитель на новом месте гораздо быстрее. Процесс наблюдений выработает привычку быть внимательным к коллегам и понимать их, процесс записи научит структурировать образ о человеке, а процесс просмотра этих записей потом позволит заметить негативные или позитивные тенденции.
Сделать работу каждого руками
Под каждым имей в виду каждого стейкхолдера. Хочешь понять разработчиков и особенности их работы? Попросись сделать что-то простое сам, с помощью чего ты сможешь понять почему у ребят так долго идет ревью или бомбежку от IDE. Ну и конечно ты станешь к ним ближе, потому что их проблемы буквально станут твоими проблемами и ты их переживешь.
И не надо говорить что ты не разработчик/аналитик/девопс. Полно простых вещей, в которых можно разобраться за день и выполнить работу. Не боги горшки обжигают.
Нужно взять по задаче у каждого из членов команды, но еще лучше напроситься к бизнесовым стейкхолдерам (в продуктовой/внутренней разработке это возможно). Если что-то из этого можно сделать в режиме "парного программирования", то вообще шикарно.
Дневник изменений
Записывай то что происходило точки зрения процессов. Сегодня у нас 10% отставание от графика, заказчик ругался, пред-прод упал. Записывай именно факты и особенно те, у которых есть численное выражение. В дальнейшем это позволит тебе увидеть зависимости между явлениями.
Пример - ретро было введено месяц назад, за счет решения проблем уменьшили техдолг и скорость выкатки релизов сократилась в 2 раза. Это уже косвенное подтверждение правильно принятых решений.
Такие причинно-следственные связи нужны чтобы можно было видеть картину целиком. Ну и это открывает путь к ТОС, системного мышлению, cause&effect и т.п
Как включаться в работу на новом месте
Здравствуй, дорогой читатель. Этот пост будет слегка сумбурным и не подкрепленным какими-то прочитанными ресурсами или словами экспертов. Просто мое мнение в чистом виде. И что самое неприятное, так это то что это мнение основано на том, чего я не делал сразу или делал скверно.
Я хочу поговорить о следующем: ты прошел собес, оформился, начался твой первый день и поехал онбординг (если он есть, ха). Речь пойдет не об онбординге для менеджеров как таковом, где разъясняется как все устроено с маленькой буквы. А именно о "КАК все устроено".
Если решать вопрос буквально, то обычно есть обучающий курс, страница новичка или регламент для менеджера/тимлида о том как надо онбордить. И формально ты действительно узнаешь доступы, какие фичи есть в проекте, на каких технология он делается, где лежит документация, культуру поведения в компании и тд. Но я очень сомневаюсь что это даст то самое понимание с большой буквы лично для тебя, глубинное.
Я пришел к следующему рецепту из 5 шагов:
1. Дневник людей;
2. Сделать работу каждого руками;
3. Дневник изменений;
4. Личный проект по онбордингу;
5. Регламенты работы менеджера.
Давай подробно разберем каждый из них.
Дневник людей
Ты вел когда-нибудь дневник себя самого? Вот тоже самое, но только про вон тех ребят. По каждому коллеге пиши заметки. Сегодня Василий Петрович был бодрячком, делай проброску в топик кафки поля по задаче. Нужно записывать не так много:
- Настроение и поведение;
- Интересы и вещи которые раздражают;
- Привычки;
- Сильные стороны (это самое сложное).
Ценность этой информации не в том что она документирована и по ней можно предъявлять или манипулировать людьми (не надо так делать). По этим записям ты научишься чувствовать людей и сможешь раскрыться как руководитель на новом месте гораздо быстрее. Процесс наблюдений выработает привычку быть внимательным к коллегам и понимать их, процесс записи научит структурировать образ о человеке, а процесс просмотра этих записей потом позволит заметить негативные или позитивные тенденции.
Сделать работу каждого руками
Под каждым имей в виду каждого стейкхолдера. Хочешь понять разработчиков и особенности их работы? Попросись сделать что-то простое сам, с помощью чего ты сможешь понять почему у ребят так долго идет ревью или бомбежку от IDE. Ну и конечно ты станешь к ним ближе, потому что их проблемы буквально станут твоими проблемами и ты их переживешь.
И не надо говорить что ты не разработчик/аналитик/девопс. Полно простых вещей, в которых можно разобраться за день и выполнить работу. Не боги горшки обжигают.
Нужно взять по задаче у каждого из членов команды, но еще лучше напроситься к бизнесовым стейкхолдерам (в продуктовой/внутренней разработке это возможно). Если что-то из этого можно сделать в режиме "парного программирования", то вообще шикарно.
Дневник изменений
Записывай то что происходило точки зрения процессов. Сегодня у нас 10% отставание от графика, заказчик ругался, пред-прод упал. Записывай именно факты и особенно те, у которых есть численное выражение. В дальнейшем это позволит тебе увидеть зависимости между явлениями.
Пример - ретро было введено месяц назад, за счет решения проблем уменьшили техдолг и скорость выкатки релизов сократилась в 2 раза. Это уже косвенное подтверждение правильно принятых решений.
Такие причинно-следственные связи нужны чтобы можно было видеть картину целиком. Ну и это открывает путь к ТОС, системного мышлению, cause&effect и т.п