Сегодня обсуждали (и еще в процессе, несмотря на поздний час) онбординг сотрудников с коллегами-руководителями. Очень много мыслей в целом и пищи для размышлений на будущее.
Впечатления двоякие. С одной стороны многое можно улучшить, есть много идей для нашего онбординга. Но с другой — приятно осознавать, сколько всего уже сделано, сколько хороших вещей мы даем ребятам в компании. Главное, что сейчас сильно не хватает системности и полноты. Уверен, что тот майндмап, который у нас коллективно получилось составить, нам сильно поможет двинуть эту тему вперед.
Несмотря на то, что прямо сейчас для нас в бэке это не самый приоритетный вопрос, надеюсь, возьмем его в проработку в следующем году. Уже накидываю планы на следующий год )
UPD. В итоге получилось 2.5 часа ) Честно говоря, было непросто, но теперь у нас есть артефакт, включающий весь опыт разных компаний от Озон и Яндекса до Volvo Trucks )
#текущее
Впечатления двоякие. С одной стороны многое можно улучшить, есть много идей для нашего онбординга. Но с другой — приятно осознавать, сколько всего уже сделано, сколько хороших вещей мы даем ребятам в компании. Главное, что сейчас сильно не хватает системности и полноты. Уверен, что тот майндмап, который у нас коллективно получилось составить, нам сильно поможет двинуть эту тему вперед.
Несмотря на то, что прямо сейчас для нас в бэке это не самый приоритетный вопрос, надеюсь, возьмем его в проработку в следующем году. Уже накидываю планы на следующий год )
UPD. В итоге получилось 2.5 часа ) Честно говоря, было непросто, но теперь у нас есть артефакт, включающий весь опыт разных компаний от Озон и Яндекса до Volvo Trucks )
#текущее
👍3🔥3❤2🌚1
Есть у нас один документ, который нам кажется естественным, но на самом деле есть не у всех. Многие компании и команды имеют что-то немного похожее, но большинство просто страдает без него.
Этот документ мы называем технический план или техническое ревью. Не путать с ADR (Architectural Decision Record), наш вариант отчасти фиксирует решения, но содержит еще кучу дополнительной полезной информации, начиная от плана решения задачи, заканчивая оценками этапов, указанием рисков и исследовательских частей.
Когда-то давно я принес идею этого документа от Алексея Катаева из SkyEng. Лет семь назад на одной из TeamLead Conf он рассказывал о том, как разбирались с оценками задач, и я зацепился за этот инструмент, адаптировал под наши реалии и с тех пор мы живем с ним. Конечно за столько лет он сильно видоизменился: дополнялся и дорабатывался, появлялись новые процессы. Например, валидация техплана: тимлид изучает задачу и техплан, валидирует техническое решение, оценки, помогает разработчику с задачей.
В какой-то момент я осознал, что этот процесс протекает по-разному у разных тимлидов и жизненно необходимо синхронизироваться. В пятницу с тимлидами собрались и накидали майндмэп этого процесса, адаптировали это под текущие требования и реалии, зафиксировали всё. Уверен, что теперь будет гораздо легче проводить валидацию, а ее результаты будут более единообразными и управляемыми. Другими словами, отлично поработали, соберу из этого еще текстовую памятку, будем становиться лучше )
Это был не совсем обычный формат встречи в рамках нашего TeamLead Club (о нем тоже как-нибудь расскажу). Мы запустили цикл воркшопов (если можно их так назвать), где будем разбирать реальные кейсы из нашей работы. Думаю, что такой подход даст максимум пользы.
P.S. Для нас это был первый опыт такого рода встреч, если и вы хотите достигать на встречах большего, а может быть вообще не знаете, как прийти к желаемому результату, то рекомендую посмотреть здесь — http://facilab.pro, очень полезный ресурс.
#текущее
Этот документ мы называем технический план или техническое ревью. Не путать с ADR (Architectural Decision Record), наш вариант отчасти фиксирует решения, но содержит еще кучу дополнительной полезной информации, начиная от плана решения задачи, заканчивая оценками этапов, указанием рисков и исследовательских частей.
Когда-то давно я принес идею этого документа от Алексея Катаева из SkyEng. Лет семь назад на одной из TeamLead Conf он рассказывал о том, как разбирались с оценками задач, и я зацепился за этот инструмент, адаптировал под наши реалии и с тех пор мы живем с ним. Конечно за столько лет он сильно видоизменился: дополнялся и дорабатывался, появлялись новые процессы. Например, валидация техплана: тимлид изучает задачу и техплан, валидирует техническое решение, оценки, помогает разработчику с задачей.
В какой-то момент я осознал, что этот процесс протекает по-разному у разных тимлидов и жизненно необходимо синхронизироваться. В пятницу с тимлидами собрались и накидали майндмэп этого процесса, адаптировали это под текущие требования и реалии, зафиксировали всё. Уверен, что теперь будет гораздо легче проводить валидацию, а ее результаты будут более единообразными и управляемыми. Другими словами, отлично поработали, соберу из этого еще текстовую памятку, будем становиться лучше )
Это был не совсем обычный формат встречи в рамках нашего TeamLead Club (о нем тоже как-нибудь расскажу). Мы запустили цикл воркшопов (если можно их так назвать), где будем разбирать реальные кейсы из нашей работы. Думаю, что такой подход даст максимум пользы.
P.S. Для нас это был первый опыт такого рода встреч, если и вы хотите достигать на встречах большего, а может быть вообще не знаете, как прийти к желаемому результату, то рекомендую посмотреть здесь — http://facilab.pro, очень полезный ресурс.
#текущее
👍3✍2🔥2🌚1
State of DevOps Russia 2025
На днях вышло большое исследование от Express42 о состоянии DevOps в России в 2025 году. Полную версию можете получить тут — https://devopsrussia.ru/
Я изучил этот документ на 90 страниц и выделил несколько интересных моментов для себя, о них и расскажу.
🧰 Инструменты
В качестве управления конфигурациями подавляющее большинство все еще использует самописные и shell-скрипты, хотя их объем снижается. При этом растет популярность инструментов автоматизации таких как Ansible и Terraform. Мы тоже пользуемся ими.
В качестве CI/CD все чаще используют GitLab CI и Jenkins. Рад, что мы угадали с этим трендом и не придется переезжать в ближайшем будущем. Предположу, что такой тренд связан с растущей популярностью on-premise-решений, всем хочется большей уверенности в завтрашнем дне на фоне ухода зарубежных сервисов и блокировок российских аккаунтов. Об этом говорит и лидерство среди систем контроля версий on-premise GitLab CE.
При этом доля компаний, использующих зарубежные коммерческие сервисы для ведения задач и документации увеличилась. Да, речь тоже о решениях на своих серверах, но, кажется, есть некоторое разочарование в отечественных SaaS-решениях, их доля сократилась. Мы продолжаем пользоваться Yandex Tracker, но для построения полноценной экосистемы требуется большой объем доработок.
Лидером среди «облаков» стал Yandex Cloud, почти половина компаний так или иначе его используют. Второй — Selectel. Оба провайдера — наши технические партнеры, активно пользуемся их услугам.
🔐 Информационная безопасность
Тема архиважная и эта важность растет очень быстро. Даже совсем маленькая компания уже не может игнорировать этот вопрос, особенно в свете новых штрафов за утечки ПД.
Метрики ИБ. Три четверти участников исследования используют метрики ИБ в своей работе, вот топ-4:
- время восстановления после инцидента (Recovery Time Objective);
- количество нарушений политик безопасности (Security Policy Violations);
- количество критических уязвимостей (Critical Vulnerability Count);
- время реагирования на инциденты (Incident Response Time).
Чаще всего инструменты ИБ интегрируются в системы CI/CD, при этом все еще остаются 22% компаний, которые совсем их не используют. Больше половины компаний используют shift left-подход и встраивают проверки безопасности в ранние стадии.
Большая часть опрошенных используют Open Source-решения для ИБ, а главным фактором выбора таких решений являются функциональные возможности инструмента.
Топ сложностей при использовании инструментов ИБ:
- недостаток технической экспертизы у команды внедрения (45,5 %);
- совместимость с существующими системами (42,3 %);
- высокая стоимость (41 %).
🤖 ИИ в работе
Более 75% респондентов так или иначе используют ML/AI-инструменты в своей работе.
Топ направления для использования ИИ в работе:
- автоматическая генерация кода;
- создание документации;
- анализ кода на наличие ошибок;
- автоматическое создание тестовых сценариев;
- аналитика и управление данными;
- анализ кода на наличие уязвимостей.
Пожалуй на этом я закончу. Цели уместить 90 страниц в один пост у меня не было. Если интересно, лучше читать полную версию. Я отметил для себя только самое актуальное. Например, я совсем ничего не написал про DevEx (Developer Experience) или IDP (Internal Development Platform), хотя это в разной степени представлено и у нас.
#TLDR #исследования #обзор
На днях вышло большое исследование от Express42 о состоянии DevOps в России в 2025 году. Полную версию можете получить тут — https://devopsrussia.ru/
Я изучил этот документ на 90 страниц и выделил несколько интересных моментов для себя, о них и расскажу.
Главные выводы коротко:
- эффективность команд выросла;
- ИБ продолжает распространяться;
- фокус на IDP растет, особенно в бигтех;
- ИИ в работе использует большинство;
- переход на российское ПО идет, но достаточно медленно;
- растёт популярность on-premise-решений;
- растет степень автоматизации.
🧰 Инструменты
В качестве управления конфигурациями подавляющее большинство все еще использует самописные и shell-скрипты, хотя их объем снижается. При этом растет популярность инструментов автоматизации таких как Ansible и Terraform. Мы тоже пользуемся ими.
В качестве CI/CD все чаще используют GitLab CI и Jenkins. Рад, что мы угадали с этим трендом и не придется переезжать в ближайшем будущем. Предположу, что такой тренд связан с растущей популярностью on-premise-решений, всем хочется большей уверенности в завтрашнем дне на фоне ухода зарубежных сервисов и блокировок российских аккаунтов. Об этом говорит и лидерство среди систем контроля версий on-premise GitLab CE.
При этом доля компаний, использующих зарубежные коммерческие сервисы для ведения задач и документации увеличилась. Да, речь тоже о решениях на своих серверах, но, кажется, есть некоторое разочарование в отечественных SaaS-решениях, их доля сократилась. Мы продолжаем пользоваться Yandex Tracker, но для построения полноценной экосистемы требуется большой объем доработок.
Лидером среди «облаков» стал Yandex Cloud, почти половина компаний так или иначе его используют. Второй — Selectel. Оба провайдера — наши технические партнеры, активно пользуемся их услугам.
🔐 Информационная безопасность
Тема архиважная и эта важность растет очень быстро. Даже совсем маленькая компания уже не может игнорировать этот вопрос, особенно в свете новых штрафов за утечки ПД.
Метрики ИБ. Три четверти участников исследования используют метрики ИБ в своей работе, вот топ-4:
- время восстановления после инцидента (Recovery Time Objective);
- количество нарушений политик безопасности (Security Policy Violations);
- количество критических уязвимостей (Critical Vulnerability Count);
- время реагирования на инциденты (Incident Response Time).
Чаще всего инструменты ИБ интегрируются в системы CI/CD, при этом все еще остаются 22% компаний, которые совсем их не используют. Больше половины компаний используют shift left-подход и встраивают проверки безопасности в ранние стадии.
Большая часть опрошенных используют Open Source-решения для ИБ, а главным фактором выбора таких решений являются функциональные возможности инструмента.
Топ сложностей при использовании инструментов ИБ:
- недостаток технической экспертизы у команды внедрения (45,5 %);
- совместимость с существующими системами (42,3 %);
- высокая стоимость (41 %).
🤖 ИИ в работе
Более 75% респондентов так или иначе используют ML/AI-инструменты в своей работе.
Топ направления для использования ИИ в работе:
- автоматическая генерация кода;
- создание документации;
- анализ кода на наличие ошибок;
- автоматическое создание тестовых сценариев;
- аналитика и управление данными;
- анализ кода на наличие уязвимостей.
Пожалуй на этом я закончу. Цели уместить 90 страниц в один пост у меня не было. Если интересно, лучше читать полную версию. Я отметил для себя только самое актуальное. Например, я совсем ничего не написал про DevEx (Developer Experience) или IDP (Internal Development Platform), хотя это в разной степени представлено и у нас.
#TLDR #исследования #обзор
🔥5✍1👍1🤯1🌚1👀1
Сегодня будет про доступность сервисов, ЦОДы и «девятки».
Когда обсуждают требования к системе, часто можно услышать от заказчика, что он хочет, чтобы система работала хорошо. Что тут скажешь, нормальное желание, только вот неизмеримое. Сразу возникает вопрос: а что значит «работает хорошо»? Здорово, что уже много всего придумано, можно просто использовать три показателя: SLA, SLO, SLI. Чуть подробнее, что это:
🔹 SLA (Service Level Agreement) — соглашение об уровне сервиса. Пример: «Сервис доступен 99,9% времени».
🔹 SLO (Service Level Objective) — цель доступности. Например: «99,9% запросов выполняются быстрее 100мс». Таких показателей может быть несколько.
🔹 SLI (Service Level Indicator) — конкретный измеряемый показатель. Например: «количество ошибок 5xx», «успешные транзакции».
Хотел поговорить об SLA и невыполнимых обещаниях, которые можно случайно дать. Есть одна приземляющая реальность, о которую разбиваются любые девятки — это доступность ЦОД (центр обработки данных, дата-центр).
🖥 Немного про tier’ы
Все ЦОДы классифицируются по уровню надежности — Tier (классификация Uptime Institute). Всего бывает четыре уровня:
🔸 Tier I — базовый уровень, доступность 99.671% или простой до 28.8 часов в год;
🔸 Tier II — с резервированием критических компонентов, доступность 99.749% или простой в год до 22 часов;
🔸 Tier III — с обеспечением непрерывности обслуживания, доступность 99.982% или простой до 1.6 часов в год;
🔸 Tier IV — максимальная отказоустойчивость, доступность 99.995% или простой максимум 26 минут в год.
Знаете, сколько ЦОД уровня Tier IV в мире есть прямо сейчас? Около 50 штук, а в России в 2024 году был открыт первый — «Москва-2» (почитать о нем можно здесь).
UPD. Спасибо коллегам за уточнение в комментах, таких влияний на доступность системы может быть огромное множество и я привел пример лишь одной из них.
#полезное
Когда обсуждают требования к системе, часто можно услышать от заказчика, что он хочет, чтобы система работала хорошо. Что тут скажешь, нормальное желание, только вот неизмеримое. Сразу возникает вопрос: а что значит «работает хорошо»? Здорово, что уже много всего придумано, можно просто использовать три показателя: SLA, SLO, SLI. Чуть подробнее, что это:
🔹 SLA (Service Level Agreement) — соглашение об уровне сервиса. Пример: «Сервис доступен 99,9% времени».
🔹 SLO (Service Level Objective) — цель доступности. Например: «99,9% запросов выполняются быстрее 100мс». Таких показателей может быть несколько.
🔹 SLI (Service Level Indicator) — конкретный измеряемый показатель. Например: «количество ошибок 5xx», «успешные транзакции».
Хотел поговорить об SLA и невыполнимых обещаниях, которые можно случайно дать. Есть одна приземляющая реальность, о которую разбиваются любые девятки — это доступность ЦОД (центр обработки данных, дата-центр).
Все ЦОДы классифицируются по уровню надежности — Tier (классификация Uptime Institute). Всего бывает четыре уровня:
🔸 Tier I — базовый уровень, доступность 99.671% или простой до 28.8 часов в год;
🔸 Tier II — с резервированием критических компонентов, доступность 99.749% или простой в год до 22 часов;
🔸 Tier III — с обеспечением непрерывности обслуживания, доступность 99.982% или простой до 1.6 часов в год;
🔸 Tier IV — максимальная отказоустойчивость, доступность 99.995% или простой максимум 26 минут в год.
Знаете, сколько ЦОД уровня Tier IV в мире есть прямо сейчас? Около 50 штук, а в России в 2024 году был открыт первый — «Москва-2» (почитать о нем можно здесь).
Мысль проста: если ваш сервис живёт в одном ЦОД, вы физически не можете честно заявлять доступность выше, чем уровень доступности этого ЦОД. Просто помните об этом, когда обещаете такие показатели.
UPD. Спасибо коллегам за уточнение в комментах, таких влияний на доступность системы может быть огромное множество и я привел пример лишь одной из них.
#полезное
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3🤔2🤩1🌚1
Вчера с «сообщниками» обсудили стратегию. Начали с осознания того, а что вообще такое стратегия, каждый внутри компании воспринимает это понятие по своему. Кто-то представляет себе документ на 50 слайдов, кто-то — набор OKR, кто-то — просто «куда мы вообще идём». Оказалось, что сформулировать определение для этого понятия весьма непросто. Очень сильно влияет прошлый опыт: в каких компаниях ты работал, что там называли стратегией и была ли она вообще. Я для себя заметил любопытную зависимость: чем крупнее компания, тем шире и многослойнее у людей представление о стратегии.
Здорово, что получилось обсудить и усреднить наш опыт. Надеюсь, теперь будет меньше сложностей, когда я соберусь готовить стратегию. Оказалось, что нередко от руководителей среднего звена хотят в каком-то виде стратегию, при этом не дав более верхнеуровневое понимание. Правда такой запрос, как показалось, есть только в достаточно больших компаниях. Вероятно это связано с тем, что стратегия компании глобально определена (не думаю, что Яндекс живет без нее).
При подготовке к обсуждению ребята поделились интересной статьей о стратегических фокусах, а я принесу ее вам — https://agile-organizations.ru/tpost/ed4892gim1-ierarhiya-strategicheskih-fokusov-kak-vi Не важно, работаете вы в IT или производите корм для животных, это может быть интересно и полезно.
#текущее
Здорово, что получилось обсудить и усреднить наш опыт. Надеюсь, теперь будет меньше сложностей, когда я соберусь готовить стратегию. Оказалось, что нередко от руководителей среднего звена хотят в каком-то виде стратегию, при этом не дав более верхнеуровневое понимание. Правда такой запрос, как показалось, есть только в достаточно больших компаниях. Вероятно это связано с тем, что стратегия компании глобально определена (не думаю, что Яндекс живет без нее).
При подготовке к обсуждению ребята поделились интересной статьей о стратегических фокусах, а я принесу ее вам — https://agile-organizations.ru/tpost/ed4892gim1-ierarhiya-strategicheskih-fokusov-kak-vi Не важно, работаете вы в IT или производите корм для животных, это может быть интересно и полезно.
#текущее
👍2🤔2🌚1💯1
Я всегда проектировал архитектуру решений у нас в компании. Считал себя таким архитектором-любителем. На предыдущем месте работы, по воле случая мне в прямое подчинение достались архитектор и несколько DBA. Тогда работа с такими специалистами для меня была в новинку, я о таких единорогах читал только в книгах, поэтому внимательно следил за всем, что они делают и немного изучал теорию. Позже, я тоже принимал участие в проектировании архитектуры и валидации отрисованных схем. Сейчас я снова проектирую сам или помогаю лидам проектировать решения. Недавно, кстати, мы перешли на отрисовку схем по стандарту C4, но об этом в другой раз.
Так вот, я вписался принять участие в архитектурной ката. Термин необычный, архитектурные ката — это групповые упражнения, которые помогают развивать навыки проектирования систем. Слово ката из японского языка, по сути это приём, который ученики отрабатывают, повторяя его многократно. Архитектурные ката возникли из-за простого желания: архитекторам программного обеспечения нужно попрактиковаться в разработке архитектур ПО, а такое случается очень редко. Проектирование архитектуры системы относительно общего цикла производства ПО это очень маленькая часть: быстрый цикл проектирования и очень долгий цикл разработки. Поэтому практики и не хватает.
Так вот, в середине декабря соберемся с ребятами из разных компаний в команды и будем соревноваться в проектировании архитектур. Устроено все примерно так: собираемся, организатор приносит задачу, мы проектируем архитектуру, слои сервисов и инфраструктуры (делаем свои ката), потом защищаем. Далее этап оценки получившейся архитектуры экспертом.
Я все же считаю себя дилетантом в этом вопросе, но ребята сказали, что так даже лучше — большему научишься :) Что ж, посмотрим, потом расскажу, как прошло.
Так вот, я вписался принять участие в архитектурной ката. Термин необычный, архитектурные ката — это групповые упражнения, которые помогают развивать навыки проектирования систем. Слово ката из японского языка, по сути это приём, который ученики отрабатывают, повторяя его многократно. Архитектурные ката возникли из-за простого желания: архитекторам программного обеспечения нужно попрактиковаться в разработке архитектур ПО, а такое случается очень редко. Проектирование архитектуры системы относительно общего цикла производства ПО это очень маленькая часть: быстрый цикл проектирования и очень долгий цикл разработки. Поэтому практики и не хватает.
Так вот, в середине декабря соберемся с ребятами из разных компаний в команды и будем соревноваться в проектировании архитектур. Устроено все примерно так: собираемся, организатор приносит задачу, мы проектируем архитектуру, слои сервисов и инфраструктуры (делаем свои ката), потом защищаем. Далее этап оценки получившейся архитектуры экспертом.
Я все же считаю себя дилетантом в этом вопросе, но ребята сказали, что так даже лучше — большему научишься :) Что ж, посмотрим, потом расскажу, как прошло.
🔥7👍4🤩2😎1
В пятницу проходила церемония награждения Tagline Awards, где наша компания представляла несколько работ. Больше всего я конечно ждал результатов в номинации «Лучшая работа с highload». Мы уже брали серебро в highload с другим проектом, тем не менее, я был уверен, что в этом году мы должны войти в тройку.
Мы сделали очень крутой проект. Может быть по общепринятым меркам мирового highload цифры и не впечатляющие, но для интернет-магазина небольшого производства игрушек всё более чем серьезно: около 4500 RPS, до 2000 заказов за 5-7 секунд, время формирования ответа бэкенда при этом до 70мс. Учитывая особенности и ограничения проекта, это просто героические цифры. Я очень горжусь ребятами, которые работали над этим проектом.
Про сам проект и технические детали я расскажу в другой раз, сегодня про признание в отрасли. Итак, мы взяли бронзу! Это отличный результат! Я очень рад, что такую классную работу оценили по достоинству. Если кто-то из причастных читает это, знайте — вы крутые спецы и доказали это всем. Уверен, это далеко не предел!
Мы сделали очень крутой проект. Может быть по общепринятым меркам мирового highload цифры и не впечатляющие, но для интернет-магазина небольшого производства игрушек всё более чем серьезно: около 4500 RPS, до 2000 заказов за 5-7 секунд, время формирования ответа бэкенда при этом до 70мс. Учитывая особенности и ограничения проекта, это просто героические цифры. Я очень горжусь ребятами, которые работали над этим проектом.
Про сам проект и технические детали я расскажу в другой раз, сегодня про признание в отрасли. Итак, мы взяли бронзу! Это отличный результат! Я очень рад, что такую классную работу оценили по достоинству. Если кто-то из причастных читает это, знайте — вы крутые спецы и доказали это всем. Уверен, это далеко не предел!
🔥9👏8🏆6❤2
Карьерное планирование
Увы, архитектурная ката была перенесена из-за форс-мажора, но на этой неделе оставалась еще одна интересная встреча — карьерное планирование 2026. Встречу вела София Андрикова, сертифицированный Executive и Карьерный коуч ICF, эксперт по оценке Hogan, BasePro, DISC&DF.
Честно говоря, помимо полезных материалов, рабочих инструментов и подходов, которые теперь остались со мной и, уверен, помогут мне в планировании следующего года и не только, я совершенно под другим углом посмотрел на себя и свои профессиональные качества. Подробностей не будет, мне самому нужно еще подумать об этом.
Еще оказалось весьма непросто описать самого себя. Мне повезло и в практической работе в парах мне досталась сама София. Разобрали, как это делать правильно. Самое полезное конечно — взгляд со стороны, особенно, когда помогает профи.
В целом для себя отметил, что многие не задумываются о том, куда они собираются прийти в карьерном плане. Параллельно вчерашней встрече, эта тема всплыла и в книге, которую я сейчас читаю/слушаю. Но в книге эта тема раскрывается со стороны руководителя, который помогает своим сотрудникам двигаться в важном для них направлении. Есть над чем подумать и здесь.
Увы, архитектурная ката была перенесена из-за форс-мажора, но на этой неделе оставалась еще одна интересная встреча — карьерное планирование 2026. Встречу вела София Андрикова, сертифицированный Executive и Карьерный коуч ICF, эксперт по оценке Hogan, BasePro, DISC&DF.
Честно говоря, помимо полезных материалов, рабочих инструментов и подходов, которые теперь остались со мной и, уверен, помогут мне в планировании следующего года и не только, я совершенно под другим углом посмотрел на себя и свои профессиональные качества. Подробностей не будет, мне самому нужно еще подумать об этом.
Еще оказалось весьма непросто описать самого себя. Мне повезло и в практической работе в парах мне досталась сама София. Разобрали, как это делать правильно. Самое полезное конечно — взгляд со стороны, особенно, когда помогает профи.
В целом для себя отметил, что многие не задумываются о том, куда они собираются прийти в карьерном плане. Параллельно вчерашней встрече, эта тема всплыла и в книге, которую я сейчас читаю/слушаю. Но в книге эта тема раскрывается со стороны руководителя, который помогает своим сотрудникам двигаться в важном для них направлении. Есть над чем подумать и здесь.
👍3🤔3🏆2
Понемногу выходим из праздничного анабиоза.
В преддверии Нового года был на встрече с коллегами, где мы играли в «Новогодний свояк» — аналог своей игры, только вместо ответов на вопросы нужно было рассказывать истории из своей профессиональной деятельности на выбранную тему и ситуацию.
До меня наконец доехал подарок за мои истории ) Полистал, это будет интересно. Может еще расскажу об этой книге.
В преддверии Нового года был на встрече с коллегами, где мы играли в «Новогодний свояк» — аналог своей игры, только вместо ответов на вопросы нужно было рассказывать истории из своей профессиональной деятельности на выбранную тему и ситуацию.
До меня наконец доехал подарок за мои истории ) Полистал, это будет интересно. Может еще расскажу об этой книге.
👍5🔥3⚡2
Много сказано про рынок труда в IT для разработчика. Если коротко — сейчас не лучшие времена. Но пока ни разу не встречал материалов на тему рынка для руководителей. Вчера был на встрече с Верой Маневич, HRD Ozon Tech. Обсуждали ситуацию на рынке труда в IT в целом и в частности затронули тренды рынка труда для руководителей. Простите, получился лонгрид, TL;DR )
Общая обстановка
В нашей стране сфера руководителей не так хорошо развита как сфера инженеров. Индустрия не успевает готовить качественных вождей, обычно просто ставят тех, кто хотя бы «говорит не заикаясь». Если вспоминать то, что последние несколько лет происходило на рынке труда: был период, когда все нанимали, потом все сокращали. Сейчас ситуация неоднозначна и очень зависит от компании — кто-то нанимает, кто-то сокращает, кто-то набирает стажеров. Вера говорит, и я соглашусь с этим, что для руководителей стресс в такой ситуации еще выше, чем для инженеров: часто совершенно не ясно, что будет дальше. Что удивительно, такая тенденция наблюдается по всему миру, а не только у нас. Наверное у нас осложняется экономическими факторами, но все же.
Еще одно открытие: C-level руководителей на рынке сейчас переизбыток. Они обучились, купили консалтинг, платят коучам, упаковались и пытаются себя продавать. Правда обычно спецы такого уровня не ходят по рынку в поисках, они переходят из одной компании в другую.
Если говорить о мидлменеджерах, то ситуация с наймом их извне прежняя: они хуже приживаются с рынка, в отличии от инженеров, поэтому был и есть тренд растить их внутри, как следствие таких вакансий достаточно мало.
Тренды
Дисклеймер: это уже обсуждается или внедряется у зарубежных коллег, у нас тоже может быть, но это не точно. И еще — размер компании имеет значение, это нужно учитывать.
🍀 AI. Вроде бы ворвался стремительно, но никому не ясно, как все же с этим быть, эффективно это или нет. В любом случае, руководителю надо об этом думать, надо использовать и точечно внедрять. Интересная история о Netflix из первых уст. При внедрении ИИ они начали с легализации его в компании и сокращении непонимания политики компании — проговорили моменты по использованию, чтобы люди не думали, что их уволят, если они не будут использовать ИИ. Но стоить помнить, «обмазывание» ИИ без повода это булшит.
🍀 Возвраты в офис. Тренд зарубежный, но там возник из-за того, что собственники бизнеса и владельцы помещений одни и те же люди, им это просто приносит деньги. Но при этом офис определенно создает некую «магию» и бывает эффективней удаленной коммуникации. Неуправляемая (важно, именно неуправляемая) удаленка равна карантину у школьников дома, так что в этом вопросе нужны правила и контроль. При этом маленькие компании такие условия диктовать не могут (строгий возврат в офис), т.к. это их конкурентное преимущество перед бигтехами, конкурировать по финансам возможности нет.
🍀 Руководитель-технарь. Любой руководитель должен быть технарем, а уже потом руководителем. Надо разбираться в архитектуре, понимать технику и т.д. Считается, что команды под управлением таких руков быстрее двигаются вперед. Главный совет: не надо писать код, если ты сильный руководитель, такое нужно не всегда и не всем. Лучше искать компанию, где будут требоваться именно управленческие навыки.
🍀 Управление скоростью. Это самый призрачный тренд, но он существует. Скорость — это стратегическое преимущество. Скорость принятия решений часто медленнее скорости разработки. Надо убирать барьеры и бюрократию. Ситуация еще хуже, чем с ИИ, ни у кого нет понимания, как это сделать, как управлять скоростью.
🍀 Меньшие, но более профессиональные команды. Крупные компании делают ставки на более сильных спецов. Пусть их будем меньше в количестве, но они сделают тот же объем работы быстрее, чем большая по численности команда из менее квалифицированных специалистов.
Главный вывод — продолжайте учиться и развиваться и тогда у вас все будет хорошо (думаю, что если вы в ИТ, то у вас нет проблем с саморазвитием). «Любой умный образованный человек работу обязательно найдет».
Общая обстановка
В нашей стране сфера руководителей не так хорошо развита как сфера инженеров. Индустрия не успевает готовить качественных вождей, обычно просто ставят тех, кто хотя бы «говорит не заикаясь». Если вспоминать то, что последние несколько лет происходило на рынке труда: был период, когда все нанимали, потом все сокращали. Сейчас ситуация неоднозначна и очень зависит от компании — кто-то нанимает, кто-то сокращает, кто-то набирает стажеров. Вера говорит, и я соглашусь с этим, что для руководителей стресс в такой ситуации еще выше, чем для инженеров: часто совершенно не ясно, что будет дальше. Что удивительно, такая тенденция наблюдается по всему миру, а не только у нас. Наверное у нас осложняется экономическими факторами, но все же.
Еще одно открытие: C-level руководителей на рынке сейчас переизбыток. Они обучились, купили консалтинг, платят коучам, упаковались и пытаются себя продавать. Правда обычно спецы такого уровня не ходят по рынку в поисках, они переходят из одной компании в другую.
Если говорить о мидлменеджерах, то ситуация с наймом их извне прежняя: они хуже приживаются с рынка, в отличии от инженеров, поэтому был и есть тренд растить их внутри, как следствие таких вакансий достаточно мало.
Тренды
Дисклеймер: это уже обсуждается или внедряется у зарубежных коллег, у нас тоже может быть, но это не точно. И еще — размер компании имеет значение, это нужно учитывать.
Главный вывод — продолжайте учиться и развиваться и тогда у вас все будет хорошо (думаю, что если вы в ИТ, то у вас нет проблем с саморазвитием). «Любой умный образованный человек работу обязательно найдет».
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥3🤔1🌚1💯1👨💻1
Сегодня буду впервые принимать участие в книжном клубе. Обсуждать будем книгу «Эффективный конфликт. Как защищать интересы и управлять сложной коммуникацией» авторов Александры Клименко, Юрия Клименко, Михаила Ромашова.
Уверен, что не в каждом книжном клубе удается обсудить книгу вместе с автором. Сегодня как раз такой день, Александра Клименко будет вместе с нами и можно будет из первых уст получить ответы на вопросы. Обсудить известную книгу с автором, это очень круто. Честно говоря, я даже немного взволнован😛
Есть правда небольшая проблема — с момента прочтения книги я успел прочесть еще три. Впечатления и мысли немного «перемешались». Постараюсь успеть подготовиться. Ну и о самой встрече расскажу, если будет интересно.
Ссылка на аудиоверсию книги
Уверен, что не в каждом книжном клубе удается обсудить книгу вместе с автором. Сегодня как раз такой день, Александра Клименко будет вместе с нами и можно будет из первых уст получить ответы на вопросы. Обсудить известную книгу с автором, это очень круто. Честно говоря, я даже немного взволнован
Есть правда небольшая проблема — с момента прочтения книги я успел прочесть еще три. Впечатления и мысли немного «перемешались». Постараюсь успеть подготовиться. Ну и о самой встрече расскажу, если будет интересно.
Ссылка на аудиоверсию книги
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥4👏2🆒2❤1🤔1
Сегодня компании, в которой я начинал как руководитель и работаю до сих пор, 12 лет!
Все 12 лет я был ее частью, частью чего-то меняющегося и растущего, взрослеющего и строгого, доброго и веселого, невероятно профессионального, поддерживающего и всегда очень разного. И это отлично!
Открою главную тайну: в какой-то момент я ушел из компании, но спустя полгода вернулся. А вернулся я к людям, которые здесь работают! Это не для красного словца, чистая правда!
Что ж, поздравляю Braind с днем рожденья! Многая лета! Окунулся в прорубь сегодня за ваше здоровье! 🥂
Все 12 лет я был ее частью, частью чего-то меняющегося и растущего, взрослеющего и строгого, доброго и веселого, невероятно профессионального, поддерживающего и всегда очень разного. И это отлично!
Открою главную тайну: в какой-то момент я ушел из компании, но спустя полгода вернулся. А вернулся я к людям, которые здесь работают! Это не для красного словца, чистая правда!
Что ж, поздравляю Braind с днем рожденья! Многая лета! Окунулся в прорубь сегодня за ваше здоровье! 🥂
❤8👍5👏4🍾3
С недавних пор я любитель аудиокниг. К счастью, вождение автомобиля по большей части процесс, не требующий когнитивной нагрузки, могу нормально послушать книги и уловить смысл. Хочу поделиться списком того, что я успел послушать (и иногда прочесть) за последние три месяца.
📚 Эффективный конфликт. Как защищать интересы и управлять сложной коммуникацией
Авторы: Александра Клименко, Михаил Ромашов, Юрий Клименко
С этой книги началось знакомство с аудиверсиями книг, ее же обсуждали вместе с автором, было круто. Свои мысли по обсуждению я так и не оформил в пост здесь, но они записаны, может еще вернусь к ним. Очень рекомендую этот практикум по манипуляциям )
📚 Радикальная прямота. Как управлять людьми, не теряя человечности
Автор: Ким Скотт
Когда-то смотрел мок-интервью на позицию CTO и там упоминали эту книгу, с тех пор все хотел ее прочесть, наконец послушал. Я бы сказал, что идеи этой книги стоит применять с умом и не всем они подойдут.
📚 Цель. Процесс непрерывного улучшения
Авторы: Джефф Кокс, Элияху Голдратт
Давно лежала в закладках. Мне очень нравятся книги в стиле бизнес-романа, это банально интереснее ) Получил удовольствие и кое-что вынес для себя, рекомендую к прочтению.
📚 45 татуировок менеджера. Правила российского руководителя
Автор: Максим Батырев
Много слышал и давно хотел прочесть. Кажется, книга немного устарела, тем не менее, стоило закрыть и эту часть, тоже было полезно. На самом деле интересно читать истории из жизни, какими бы выводами они не заканчивались )
📚 Идеальный руководитель. Почему им нельзя стать и что из этого следует
Автор: Ицхак Адизес
Кажется, это классика, но это не точно ) Есть еще книги этой серии (наверное это можно назвать серией), планирую прочесть и их.
📚 РБК Pro: практикум для руководителя. Как поддержать настрой в команде и не перегореть самому
Авторы: Владимир Герасичев, Арсен Рябуха, Иван Маурах
Неожиданно наткнулся в рекомендациях. Это было неожиданно хорошо, очень рекомендую к прочтению.
А прямо сейчас я читаю:
📚 Легко не будет. Как построить бизнес, когда вопросов больше, чем ответов.
Автор: Бен Хоровиц
Пока мне нравится, поделюсь, как закончу. Это текстовый формат, поэтому идет медленно — нужно выделять время на чтение, а его сейчас очень мало.
📚 Думай медленно... Решай быстро
Автор: Даниэль Канеман
Ну, это шедевральный путеводитель по когнитивным искажениям с пруфами и примерами ) Треть я уже послушал, пока очень хорошо.
Этот набор выше значительно изменил мое восприятие окружающей действительности, на многие вещи я теперь смотрю иначе. Скажем так, с большим пониманием, хотя с этим у меня вроде бы никогда не было проблем, но сейчас набор моих взглядов стал еще шире.
На фото: мыс Хобой, Байкал, где я недавно побывал.
📚 Эффективный конфликт. Как защищать интересы и управлять сложной коммуникацией
Авторы: Александра Клименко, Михаил Ромашов, Юрий Клименко
С этой книги началось знакомство с аудиверсиями книг, ее же обсуждали вместе с автором, было круто. Свои мысли по обсуждению я так и не оформил в пост здесь, но они записаны, может еще вернусь к ним. Очень рекомендую этот практикум по манипуляциям )
📚 Радикальная прямота. Как управлять людьми, не теряя человечности
Автор: Ким Скотт
Когда-то смотрел мок-интервью на позицию CTO и там упоминали эту книгу, с тех пор все хотел ее прочесть, наконец послушал. Я бы сказал, что идеи этой книги стоит применять с умом и не всем они подойдут.
📚 Цель. Процесс непрерывного улучшения
Авторы: Джефф Кокс, Элияху Голдратт
Давно лежала в закладках. Мне очень нравятся книги в стиле бизнес-романа, это банально интереснее ) Получил удовольствие и кое-что вынес для себя, рекомендую к прочтению.
📚 45 татуировок менеджера. Правила российского руководителя
Автор: Максим Батырев
Много слышал и давно хотел прочесть. Кажется, книга немного устарела, тем не менее, стоило закрыть и эту часть, тоже было полезно. На самом деле интересно читать истории из жизни, какими бы выводами они не заканчивались )
📚 Идеальный руководитель. Почему им нельзя стать и что из этого следует
Автор: Ицхак Адизес
Кажется, это классика, но это не точно ) Есть еще книги этой серии (наверное это можно назвать серией), планирую прочесть и их.
📚 РБК Pro: практикум для руководителя. Как поддержать настрой в команде и не перегореть самому
Авторы: Владимир Герасичев, Арсен Рябуха, Иван Маурах
Неожиданно наткнулся в рекомендациях. Это было неожиданно хорошо, очень рекомендую к прочтению.
А прямо сейчас я читаю:
📚 Легко не будет. Как построить бизнес, когда вопросов больше, чем ответов.
Автор: Бен Хоровиц
Пока мне нравится, поделюсь, как закончу. Это текстовый формат, поэтому идет медленно — нужно выделять время на чтение, а его сейчас очень мало.
📚 Думай медленно... Решай быстро
Автор: Даниэль Канеман
Ну, это шедевральный путеводитель по когнитивным искажениям с пруфами и примерами ) Треть я уже послушал, пока очень хорошо.
Этот набор выше значительно изменил мое восприятие окружающей действительности, на многие вещи я теперь смотрю иначе. Скажем так, с большим пониманием, хотя с этим у меня вроде бы никогда не было проблем, но сейчас набор моих взглядов стал еще шире.
На фото: мыс Хобой, Байкал, где я недавно побывал.
🔥5❤4👍2🤔1
Всем привет. Что ж, месяц был насыщенным, это видно по постам, которых не было. Расскажу, чем же я занимался.
Я добил обе книги из предыдущего поста и успел послушать еще одну: «Управление в условиях кризиса: Как выжить и стать сильнее» Ицхака Адизеса. Небольшая книжка, в которой доступно рассказано о том, почему кризис это все же про возможности. Часто этой фразой прикрываются и прикрывают всякое, но если хотите понять смысл — не пожалейте два часа. Сейчас взял паузу с книгами, кажется, что надо немного передохнуть, слишком много профессионального в моей жизни. Но следующие я наметил — «Выбор. Правила Голдратта», скорее всего еще будет «Цель 2», посмотрим.
В рабочих делах было много всего. Ключевой задачей выберу новые показатели перформанса разработчиков, которые я пересобрал, потом посмтрел и пересобрал пересобранное, а потом при детальной проработке сделал это в третий раз. Сейчас результат меня устраивает, жду согласования и готовлю шаблоны файлов для тимлидов. Впереди решение проблем со сбором данных, есть несколько идей, но пока думаю, как сделать это проще.
Еще в отделе еще -1 человек. Не драма конечно, но оглядываясь назад моя субъективная картина имеет название «Так себе». Что ж, буду смотреть, что из этого получится.
Встречи. Их было очень много. Обсуждали опыт работы с ИИ: послушал и сам поделился опытом. Встречались про выгорание с Женей Идзиковским. Обсуждали качество с Виталием Шароватовым. Был на мок-собесе с тимлидом. Ну и конечно обсудили книжку «Легко не будет» Хоровитца. Прямо сейчас слушаю Илью Прахта про набор знаний, навыков и умений для мидл-менеджера. Осталось успеть все это осознать.
А еще успел починить кофемашину в офисе. Дважды :)
Если появятся силы и время, попробую раскрыть какую-нибудь интересную тему. Расскажу про опыт и отношение к ИИ или, например, почему я приезжаю в офис за 30-40 минут до начала рабочего дня. Stay tuned!
На фото моя кошка Дымка
Я добил обе книги из предыдущего поста и успел послушать еще одну: «Управление в условиях кризиса: Как выжить и стать сильнее» Ицхака Адизеса. Небольшая книжка, в которой доступно рассказано о том, почему кризис это все же про возможности. Часто этой фразой прикрываются и прикрывают всякое, но если хотите понять смысл — не пожалейте два часа. Сейчас взял паузу с книгами, кажется, что надо немного передохнуть, слишком много профессионального в моей жизни. Но следующие я наметил — «Выбор. Правила Голдратта», скорее всего еще будет «Цель 2», посмотрим.
В рабочих делах было много всего. Ключевой задачей выберу новые показатели перформанса разработчиков, которые я пересобрал, потом посмтрел и пересобрал пересобранное, а потом при детальной проработке сделал это в третий раз. Сейчас результат меня устраивает, жду согласования и готовлю шаблоны файлов для тимлидов. Впереди решение проблем со сбором данных, есть несколько идей, но пока думаю, как сделать это проще.
Еще в отделе еще -1 человек. Не драма конечно, но оглядываясь назад моя субъективная картина имеет название «Так себе». Что ж, буду смотреть, что из этого получится.
Встречи. Их было очень много. Обсуждали опыт работы с ИИ: послушал и сам поделился опытом. Встречались про выгорание с Женей Идзиковским. Обсуждали качество с Виталием Шароватовым. Был на мок-собесе с тимлидом. Ну и конечно обсудили книжку «Легко не будет» Хоровитца. Прямо сейчас слушаю Илью Прахта про набор знаний, навыков и умений для мидл-менеджера. Осталось успеть все это осознать.
А еще успел починить кофемашину в офисе. Дважды :)
Если появятся силы и время, попробую раскрыть какую-нибудь интересную тему. Расскажу про опыт и отношение к ИИ или, например, почему я приезжаю в офис за 30-40 минут до начала рабочего дня. Stay tuned!
На фото моя кошка Дымка
🔥7👍2🏆2
ИИ-агент Cursor на базе Opus 4.6 «самовольно» удалил основную базу данных и все резервные копии стартапа PocketOS
Свежайшая новость последних часов о том, как очередной продукт потерял всё, доверив разработку ИИ. И наверное первая реакция рандомного мимокродкодила будет такой: «Ахахаха! Опять ИИ налажал! Так и знал, что это бредогенератор. Когда уже этот пузырь лопнет?!» Но я хочу подсветить кое-что другое.
Итак, что мы имеем: ИИ-агент Claude Opus 4.6 от Anthropic в Cursor во время работы обнаружил по его мнению проблемы в учётных данных и решил их исправить, но удалил продовую базу и все резервные копии. Ничего себе сеттинг. Помимо этого уточняется, что:
Агент сам нашёл нужный API-токен в файле, не относящемся к его первоначальной задаче. Токен сделали, чтобы добавлять пользовательские домены, но он давал неограниченные права и на другие действия.
Ситуация становится еще неоднозначнее, сразу возникает ряд очевидных вопросов.
1. Почему агент работает в режиме, когда он не запрашивает подтверждения своим действиям, особенно таким деструктивным?
Уточняется, что в системном промпте агента было указано: «НИКОГДА не выполняй вредоносные и необратимые git-команды, если пользователь явно не попросил об этом». Тем не менее промпт, пусть и системный это все же инструкции на вход, которые могут быть проигнорированы ИИ. Если вы не знаете, по дефолту агенты работают в режиме, когда они не выполняют никаких действий и команд без подтверждения пользователя. Я знаю, что очень скоро эта настройка начинает утомлять и ты переходишь в режим, когда подтверждение не требуется. Но стоит задуматься, если в доступе агента находится файл с ключами от продакшн-среды? Вопрос риторический.
2. Почему права доступа настроены без учета принципа минимальных привелегий?
Как это возможно, что для выполнения рядовой операции в принципе существует ключ с таким уровнем доступа, при котором вы не просто можете получать управление продовой средой за пределами задачи, но и имеете доступ к резервным копиям?! Кажется, что здесь что-то не так и кто-то банально забил на базовые требования безопасности
3. Почему так настроено резервное копирование?
Я не знаю деталей, но резервные копии, которые лежат настолько близко к продовой среде, что их можно удалить используя один API-ключ, расположены ненадежно. Все, кто сталкивался с DRP и настройкой резервного копирования знают, что эти «яйца» точно не стоит складывать в одну корзину вместе с продом.
Надеюсь у ребят всё получится и они смогут найти у кого-то из разрабов завалявшийся бэкап трехмесячной давности, пожелаем им удачи.
Что хочется сказать. Помимо очевидных проблем, которые видны в организации работы, я бы выделил главную — контроль за действиями ИИ. Знаете, мы получили крутой инструмент, как в свое время трактор или ткацкий станок. Но кажется, водитель этого трактора по прежнему должен приходить на работу трезвым и уметь им управлять 🙂
🔥4🤔3👍2
Несколько месяцев назад мы с коллегами составили майндмэп онбординга сотрудника с множеством аспектов этого процесса. Состав у нас очень разнообразный, поэтому мы смогли посмотреть на это достаточно широко. Подробнее можно ознакомиться ✈️ по ссылке.
Онбординг. Ценность для руководителя.
Сегодня я затрону тему онбординга сотрудников и преимуществ качественной организации этого процесса для руководителей. Пойдем от самых очевидных бенефитов к менее популярным, но не менее важным.
✅ Меньше однообразных вопросов. Разумеется при качественно выстроенном онбординге вопросов, на которые нужно отвечать руководителю гораздо меньше. Это существенно экономит время и позволяет руководителю заниматься текущими вопросами и параллельно проводить онбординг без вреда для текущей работы. Можно говорить в целом о снижении трудозатрат на адаптацию нового сотрудника.
✅ Ускорение выхода сотрудника на требуемый уровень качества и результата. Очевидно, что чем раньше сотрудник выйдет на ожидаемый уровень выполнения задач, тем лучше для компании и руководителя. Качественный онбординг значительно ускорит этот процесс.
✅ Появление возможности делегирования. Когда процесс онбординга формализован, его можно полностью или частично делегировать. А еще его можно делегировать нескольким людям. Это могут быть менторы из числа разработчиков (так можно прокачать и их навыки управления людьми), HR, руководителям нижестоящих звеньев.
✅ Альтернативное мнение. Новый сотрудник в процессе знакомства с компанией и процессами это всегда свежий взгляд. Руководителю не стоит упускать такую возможность найти проблемы и получить предложения по их исправлению.
✅ Снижение риска «взять не того». Когда все выстроено и «по полочкам», шансы оставить неподходящего человека значительно сокращаются. Все руководители знеают, насколько это дорого нанять не того сотрудника и понять это с запозданием: новый найм, поиски, потраченное время и бюджеты, а проекты и дедлайны никто не отменял.
✅ Бесплатное обновление документации по проектам. В качестве неочевидного преимущества в рамках адаптации можно сразу проверить и организовать обновление документации к вашим проектам и процессам.
✅ Снижение вероятности потери сотрудника. Адаптация в новой компании это очень большой стресс для новичка. Понятные процессы и правила, четкий план, сокращают неопределенность и страх. Для руководителя важно нанять и сохранить качественного сотрудника, чтобы он не сошел с ума еще на этапе адаптации. Дополнительно это может быть и вклад в его вовлеченность: хороший онбординг зачастую — более лояльное отношение к компании в будущем.
✅ Снижение количества потенциальных конфликтов. Задача руководителя не просто организовать сольную работу сотрудника, но и интеграцию его в командную деятельность. Чем быстрее сотрудник освоится и узнает правила игры, тем меньше трений с коллегами в процессе, тем меньше потенциальных конфликтов.
✅ Дебют в «догфудинге» продукта. Догфудинг — это практика использования сотрудниками компании собственных продуктов. Новый человек — отличная возможность подтюнить не только внутренние процессы, но и свой продукт. Хорошая практика — дать поревьюить продукт, собрать обратную связь и вынести из этого максимум пользы.
Эта была часть про ценность онбординга для руководителя. Полную версию статьи про онбординг можно найти✈️ по ссылке
Онбординг. Ценность для руководителя.
Сегодня я затрону тему онбординга сотрудников и преимуществ качественной организации этого процесса для руководителей. Пойдем от самых очевидных бенефитов к менее популярным, но не менее важным.
Эта была часть про ценность онбординга для руководителя. Полную версию статьи про онбординг можно найти
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍5🔥5