Последнее время много задумываюсь о целях организации и своих личных целях. Не в разрезе эффективности или роста, а скорее экзистенциальных. Зачем существует организация, какова её миссия, и как она приносит пользу людям? Какая моя роль в этом, и как мои ежедневные дела помогают в достижении жизненных целей, дополняют или противоречат принципам?
Литература, которую читаю последнее время, тоже смещает фокус с практики в сторону конфигурации компании, формирования её целей и принципов.
И вот недавно наткнулся на интересный подкаст с заголовком «Как остаться собой на пути к вершинам», в котором затрагиваются вопросы успеха, самопознания, баланса в жизни, психологии и многого другого.
С Глебом (автором подкаста) и Максимом (гостем) мне посчастливилось быть знакомым лично. Оба с первой встречи произвели впечатление думающих и глубоких людей, поэтому я был просто обязан посмотреть выпуск 🙂
Если вам тоже интересны вопросы выше, крайне рекомендую посмотреть.
#размышления #сергей_чернобровкин👨
Литература, которую читаю последнее время, тоже смещает фокус с практики в сторону конфигурации компании, формирования её целей и принципов.
И вот недавно наткнулся на интересный подкаст с заголовком «Как остаться собой на пути к вершинам», в котором затрагиваются вопросы успеха, самопознания, баланса в жизни, психологии и многого другого.
С Глебом (автором подкаста) и Максимом (гостем) мне посчастливилось быть знакомым лично. Оба с первой встречи произвели впечатление думающих и глубоких людей, поэтому я был просто обязан посмотреть выпуск 🙂
Если вам тоже интересны вопросы выше, крайне рекомендую посмотреть.
#размышления #сергей_чернобровкин
Please open Telegram to view this post
VIEW IN TELEGRAM
Есть всего одно правило в дизайне: его надо презентовать, а не отправлять
Я считаю, что дизайн должен заходить с первого раза и с одного варианта.
Конечно, бывают правки, и доработка макетов — один из базовых шагов процесса, но фразу: «Мне не нравится, нарисуйте ещё один вариант» допускать нельзя.
Как этого достигнуть:
1. Чётко поставленная задача: цель, аудитория, контент с понятной структурой, акценты, требования корпоративного стиля, если есть
2. Профессиональные дизайнеры. От результата работы дизайнера не должно оставаться впечатления, что с ним что-то не так. Такого рода возражения заказчику трудно сформулировать, поэтому обычно заводят в тупик
3. Продуманные детали: нужно понимать, как пользователь будет использовать интерфейс во всех ситуациях и понимать, почему блок был реализован так, а не иначе. «Так, а не иначе» значит: Как этот блок, эта компоновка, решают поставленную задачу?
4. Подготовленный питч. При презентации разработанного дизайна важно подготовить структурированное повествование по деталям из первого пункта. Заказчик должен видеть в дизайнере не художника, который «так видит», а человека, который с помощью продуманного визуала решает задачу бизнеса
5. Референсы. Если задача совсем не типовая или заказчику сложно сформулировать образ результата, то лучше перед дизайном собрать референсы, чтобы понять, что нравится, а что «сразу нет»
И напоследок. Все эти правила хороши для дизайна чего-то конкретного и решающего конкретную задачу. Для креативного дизайна, скорее всего, надо двигаться по-другому.
#максим_павлов😀
Я считаю, что дизайн должен заходить с первого раза и с одного варианта.
Конечно, бывают правки, и доработка макетов — один из базовых шагов процесса, но фразу: «Мне не нравится, нарисуйте ещё один вариант» допускать нельзя.
Как этого достигнуть:
1. Чётко поставленная задача: цель, аудитория, контент с понятной структурой, акценты, требования корпоративного стиля, если есть
2. Профессиональные дизайнеры. От результата работы дизайнера не должно оставаться впечатления, что с ним что-то не так. Такого рода возражения заказчику трудно сформулировать, поэтому обычно заводят в тупик
3. Продуманные детали: нужно понимать, как пользователь будет использовать интерфейс во всех ситуациях и понимать, почему блок был реализован так, а не иначе. «Так, а не иначе» значит: Как этот блок, эта компоновка, решают поставленную задачу?
4. Подготовленный питч. При презентации разработанного дизайна важно подготовить структурированное повествование по деталям из первого пункта. Заказчик должен видеть в дизайнере не художника, который «так видит», а человека, который с помощью продуманного визуала решает задачу бизнеса
5. Референсы. Если задача совсем не типовая или заказчику сложно сформулировать образ результата, то лучше перед дизайном собрать референсы, чтобы понять, что нравится, а что «сразу нет»
И напоследок. Все эти правила хороши для дизайна чего-то конкретного и решающего конкретную задачу. Для креативного дизайна, скорее всего, надо двигаться по-другому.
#максим_павлов
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда KMP переигрывает Flutter
Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах.
При выборе технологии для кроссплатформенной мобильной разработки многие отдают предпочтение Flutter. Мы выбрали KMP. Я поспрашивал у нашего руководителя мобильной разработки Максима Мялкина, почему мы выбрали его, а не попсовый Flutter — делюсь результатами в статье на VC.
👉 Ссылка на статью
#максим_павлов😀 #максим_мялкин📱
Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах.
При выборе технологии для кроссплатформенной мобильной разработки многие отдают предпочтение Flutter. Мы выбрали KMP. Я поспрашивал у нашего руководителя мобильной разработки Максима Мялкина, почему мы выбрали его, а не попсовый Flutter — делюсь результатами в статье на VC.
👉 Ссылка на статью
#максим_павлов
Please open Telegram to view this post
VIEW IN TELEGRAM
Самый сложный скилл в IT
Как вы думаете, что самое сложное в IT? DevOps наверно, или iOS за 300k/сек? Не думаю.
Недавно я общался с одним клиентом, и мы вырулили на проблему отсутствия у многих специалистов комбинации двух ключевых экспертиз:
1. Системный дизайн
2. Продуктовое мышление
Это, как мне кажется, секретный соус Крабсбургера или два камня бесконечности из перчатки Таноса.
Давайте разберём.
1 — Системный дизайн. Это не глубокое понимание технологий бэкенда или инфраструктуры, а умение быстро, в уме, запроектировать систему крупными мазками и сходу понимать, какие решения будут правильными с точки зрения нефункциональных требований: нагрузки, безопасности и тд. Причём в идеале нужно обладать таким скилом по всем ключевым направлениям разработки: и на бэке, и на фронте, и в инфраструктуре. Любой опытный сеньор-бэкендер должен обладать таким скилом.
Но этого недостаточно.
2 — Продуктовое мышление: умение понимать потребность пользователей/бизнеса и также быстро, в уме, вывести крупными мазками варианты реализации, исходя из имеющихся ресурсов (бюджет, команда) и ограничений (сроки, нефункциональные требования).
Скомбинировать эти скилы оказывается очень тяжело, но крайне эффективно. Докажем от обратного.
Если специалист не обладает навыком продуктового мышления, то он, скорее всего, будет «упарываться» в технику там, где это вообще не нужно. Нефункциональные требования и «красота кода» возьмут верх над скоростью реализации, time to market и периодом тестирования гипотезы. При этом гипотеза может вообще не выстрелить, и функционал нужно будет просто убрать. Либо, если специалист более низкого грейда, он будет просто делать свои задачи, не думая о том, что где-то можно что-то и улучшить, исходя из продуктовых целей конкретной фичи.
С другой стороны, если проджект/продакт-менеджер не обладает навыком системного дизайна и насмотренностью (в том числе инструментов nocode, которые позволяют проверить кучу гипотез быстро), он не сможет грамотно рулить проектом. Снова будут страдать скорость и качество. Такой менеджер будет полностью полагаться на решения и сроки технарей, которые упарываются в технику, и в худшем случае будет просто протоколировать передвижения задачек в таск-трекере.
Конечно, в IT есть куча ролей, сфокусированных на разных этапах создания продукта: продакты делают исследования, аналитики и архитекторы проектируют, разработчики кодят, а проектные менеджеры управляют ресурсами и ограничениями. Сейчас, кстати, появляются роли «технических менеджеров» — возможно, они-то и решат описанную проблему.
Но я убеждён, что каждый член команды должен прокачивать оба вектора. Только тогда вся команда будет генерировать лучшие решения, оптимизировать их в процессе разработки, и делать это быстро, выпуская новые релизы и тестируя новые гипотезы.
#бизнес #сергей_чернобровкин👨
Как вы думаете, что самое сложное в IT? DevOps наверно, или iOS за 300k/сек? Не думаю.
Недавно я общался с одним клиентом, и мы вырулили на проблему отсутствия у многих специалистов комбинации двух ключевых экспертиз:
1. Системный дизайн
2. Продуктовое мышление
Это, как мне кажется, секретный соус Крабсбургера или два камня бесконечности из перчатки Таноса.
Давайте разберём.
1 — Системный дизайн. Это не глубокое понимание технологий бэкенда или инфраструктуры, а умение быстро, в уме, запроектировать систему крупными мазками и сходу понимать, какие решения будут правильными с точки зрения нефункциональных требований: нагрузки, безопасности и тд. Причём в идеале нужно обладать таким скилом по всем ключевым направлениям разработки: и на бэке, и на фронте, и в инфраструктуре. Любой опытный сеньор-бэкендер должен обладать таким скилом.
Но этого недостаточно.
2 — Продуктовое мышление: умение понимать потребность пользователей/бизнеса и также быстро, в уме, вывести крупными мазками варианты реализации, исходя из имеющихся ресурсов (бюджет, команда) и ограничений (сроки, нефункциональные требования).
Скомбинировать эти скилы оказывается очень тяжело, но крайне эффективно. Докажем от обратного.
Если специалист не обладает навыком продуктового мышления, то он, скорее всего, будет «упарываться» в технику там, где это вообще не нужно. Нефункциональные требования и «красота кода» возьмут верх над скоростью реализации, time to market и периодом тестирования гипотезы. При этом гипотеза может вообще не выстрелить, и функционал нужно будет просто убрать. Либо, если специалист более низкого грейда, он будет просто делать свои задачи, не думая о том, что где-то можно что-то и улучшить, исходя из продуктовых целей конкретной фичи.
С другой стороны, если проджект/продакт-менеджер не обладает навыком системного дизайна и насмотренностью (в том числе инструментов nocode, которые позволяют проверить кучу гипотез быстро), он не сможет грамотно рулить проектом. Снова будут страдать скорость и качество. Такой менеджер будет полностью полагаться на решения и сроки технарей, которые упарываются в технику, и в худшем случае будет просто протоколировать передвижения задачек в таск-трекере.
Конечно, в IT есть куча ролей, сфокусированных на разных этапах создания продукта: продакты делают исследования, аналитики и архитекторы проектируют, разработчики кодят, а проектные менеджеры управляют ресурсами и ограничениями. Сейчас, кстати, появляются роли «технических менеджеров» — возможно, они-то и решат описанную проблему.
Но я убеждён, что каждый член команды должен прокачивать оба вектора. Только тогда вся команда будет генерировать лучшие решения, оптимизировать их в процессе разработки, и делать это быстро, выпуская новые релизы и тестируя новые гипотезы.
#бизнес #сергей_чернобровкин
Please open Telegram to view this post
VIEW IN TELEGRAM
Как прокачивать продуктовое мышление у команды
Так как же развивать продуктовое мышление у команды?
Радикально, и для кого-то, возможно, утопически — меньше разделять процесс создания продукта на этапы и роли в команде.
Каждый член команды должен обладать максимально возможным контекстом, чтобы принимать лучшие решения в своём деле. То есть роли должны быть фокусом, но не ограничением зоны ответственности.
Можно использовать следующие практики:
1. Общие брейнштормы / стратсессии.
На таких сессиях обычно поднимаются глобальные цели и проблемы, и все члены команды могут подняться с уровня своего производственного процесса на уровень всего продукта. Тогда у людей обычно открываются глаза: «Ах вот почему мы это все делаем», и начинают появляться правильные вопросы.
2. Общение с клиентами / пользователями.
Мы делаем продукты для пользования кем-то. И странно, если мы просто «кодим» и совсем не интересуемся проблемами и задачами пользователей. Нет ничего зазорного в том, чтобы, например, посидеть в чате техподдержки и посмотреть, что вообще спрашивают пользователи. Или если менеджер возьмёт разработчика на встречу по продукту со своим руководством/заказчиком.
3. Закрытие белых пятен в технике / продукте хотя бы с помощью базовых курсов/видео. Сюда же можно записать изучение nocode-инструментов и тд.
4. Выполнение неспецифичных для своей специальности задач. Например, разработчику сходить на кастдев, или продакту настроить рекламу вместе с маркетологом.
5. Любые другие совместные активности и участие в «чужих» производственных процессах.
6. «Командировки» в другие отделы для обмена опытом.
7. Прокачка насмотренности через изучение конкурентов.
И конечно, для максимальной эффективности в команде должна сложиться определённая культура. В экспертизе не будет смысла, если её нельзя реализовать. Если «за продукт отвечают менеджеры», а «я просто делаю задачи, как описано». Любой член команды должен иметь возможность поучаствовать или повлиять на разные процессы при желании. И чувствовать в этом поддержку от команды, а не ограничение своей ролью.
#бизнес #сергей_чернобровкин👨
Так как же развивать продуктовое мышление у команды?
Радикально, и для кого-то, возможно, утопически — меньше разделять процесс создания продукта на этапы и роли в команде.
Каждый член команды должен обладать максимально возможным контекстом, чтобы принимать лучшие решения в своём деле. То есть роли должны быть фокусом, но не ограничением зоны ответственности.
Можно использовать следующие практики:
1. Общие брейнштормы / стратсессии.
На таких сессиях обычно поднимаются глобальные цели и проблемы, и все члены команды могут подняться с уровня своего производственного процесса на уровень всего продукта. Тогда у людей обычно открываются глаза: «Ах вот почему мы это все делаем», и начинают появляться правильные вопросы.
2. Общение с клиентами / пользователями.
Мы делаем продукты для пользования кем-то. И странно, если мы просто «кодим» и совсем не интересуемся проблемами и задачами пользователей. Нет ничего зазорного в том, чтобы, например, посидеть в чате техподдержки и посмотреть, что вообще спрашивают пользователи. Или если менеджер возьмёт разработчика на встречу по продукту со своим руководством/заказчиком.
3. Закрытие белых пятен в технике / продукте хотя бы с помощью базовых курсов/видео. Сюда же можно записать изучение nocode-инструментов и тд.
4. Выполнение неспецифичных для своей специальности задач. Например, разработчику сходить на кастдев, или продакту настроить рекламу вместе с маркетологом.
5. Любые другие совместные активности и участие в «чужих» производственных процессах.
6. «Командировки» в другие отделы для обмена опытом.
7. Прокачка насмотренности через изучение конкурентов.
И конечно, для максимальной эффективности в команде должна сложиться определённая культура. В экспертизе не будет смысла, если её нельзя реализовать. Если «за продукт отвечают менеджеры», а «я просто делаю задачи, как описано». Любой член команды должен иметь возможность поучаствовать или повлиять на разные процессы при желании. И чувствовать в этом поддержку от команды, а не ограничение своей ролью.
#бизнес #сергей_чернобровкин
Please open Telegram to view this post
VIEW IN TELEGRAM
Существуют ли джуниор-DevOps-инженеры и почему их ищут
DevOps находится на стыке Development и Operations.
Команда Development прежде всего фокусируется на создании программного обеспечения, а команда Operations — на том, чтобы это ПО надёжно и эффективно работало в реальных условиях. DevOps же старается сделать эти процессы более связанными и гармоничными.
Чтобы продуктивно работать и понимать и тех и других, нужен достаточно широкий кругозор. И здесь мы приходим к вопросу: может ли существовать DevOps-специалист уровня джуниор? Разбираемся в этом вопросе в статье на Хабре:
👉 Ссылка на статью
#бизнес #devops #сергей_маленко🙂
DevOps находится на стыке Development и Operations.
Команда Development прежде всего фокусируется на создании программного обеспечения, а команда Operations — на том, чтобы это ПО надёжно и эффективно работало в реальных условиях. DevOps же старается сделать эти процессы более связанными и гармоничными.
Чтобы продуктивно работать и понимать и тех и других, нужен достаточно широкий кругозор. И здесь мы приходим к вопросу: может ли существовать DevOps-специалист уровня джуниор? Разбираемся в этом вопросе в статье на Хабре:
👉 Ссылка на статью
#бизнес #devops #сергей_маленко
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Существуют ли джуниор-DevOps-инженеры и почему их ищут
Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS. Сегодня поговорим о том, существуют ли джуниоры в DevOps — и какими они должны быть. Содержание Какое место занимает отдел DevOps...
Вы никогда не сократите Time To Market, если будете тестировать все фичи на одном сервере
Раньше я думал, что тестирование всех фичей на одном сервере — это первое, от чего надо избавляться, если компании важен Time To Market. Однако когда мы начали больше общаться с коллегами по рынку, то поняли, что такое мнение распространено далеко не во всех командах и компаниях.
Люди готовы на любые ухищрения, чтобы не менять привычный процесс. Они создают очерёдность тестирования фичей на едином сервере или по серверу на каждого из разработчиков. Что первый вариант, что второй — сорта известной всем субстанции.
В статье на VC рассказываю подробнее:
— Почему тестировать фичи на едином тестовом сервере — не ок.
— Почему очерёдность тестирования фич и создание по серверу на каждого разработчика также увеличивает TTM.
— Какой из этой ситуации есть выход. Спойлер: динамические окружения.
👉 Ссылка на статью
#максим_павлов😀
Раньше я думал, что тестирование всех фичей на одном сервере — это первое, от чего надо избавляться, если компании важен Time To Market. Однако когда мы начали больше общаться с коллегами по рынку, то поняли, что такое мнение распространено далеко не во всех командах и компаниях.
Люди готовы на любые ухищрения, чтобы не менять привычный процесс. Они создают очерёдность тестирования фичей на едином сервере или по серверу на каждого из разработчиков. Что первый вариант, что второй — сорта известной всем субстанции.
В статье на VC рассказываю подробнее:
— Почему тестировать фичи на едином тестовом сервере — не ок.
— Почему очерёдность тестирования фич и создание по серверу на каждого разработчика также увеличивает TTM.
— Какой из этой ситуации есть выход. Спойлер: динамические окружения.
👉 Ссылка на статью
#максим_павлов
Please open Telegram to view this post
VIEW IN TELEGRAM
Практики HR для бизнеса: менторинг, демо-дни, стратсессии и ретро
Недавно была на вебинаре, где HR разных компаний делились опытом вовлечения и мотивации в распределенных командах. Послушала, кто какие штуки у себя использует, и поняла, что многое из этого мы делаем у себя. Делюсь нашими практиками, буду рада, если поделитесь своими в комментариях.
Менторинг
В KTS у каждого сотрудника есть ментор — более опытный коллега той же специализации. Ментор и подопечный могут работать на разных проектах. Если они на одном проекте, ментор на старте отвечает за онбординг в команду и процессы. Если на разных, то новичка онбордит руководитель проекта или разработчик-лид.
В любом случае ментор отвечает за развитие нового сотрудника — ставит цели на полгода, прописывает параметры оценки достижения целей и каждые полгода участвует в перфоманс-ревью. На ревью ментор собирает фидбеки ключевых людей из команд, с которыми человек успел поработать за полгода, сопоставляет их с целями и презентует результаты на калибровках. Калибровка — это онлайн-митинг, где сравниваются достижения ребят одинаковых грейдов из разных команд между собой. По результатам калибровок ментор ставит оценку достижениям подопечного, подводит итоги на специальном 1-1, они ставят новые цели, и цикл повторяется.
Демо-дни
В среднем раз в месяц (иногда чаще) мы собираемся на демо-день. Это кросс-командная онлайн-встреча для всех желающих, на которой одна из наших команд презентует свои наработки, интересные результаты, рассказывает коллегам, чем занимается. Все это в режиме интерактива, в веселой атмосфере, с мемами и с ответами на вопросы.
Например, за прошедшее лето мы собирались 3 раза. Была встреча, на которой один из основателей #сергей_чернобровкин👨 рассказал, как утроен процесс продаж в компании, и как каждый сотрудник влияет и на этот процесс и на результаты всей компании.
Стратсессии и ретро
Бывают оффлайн и онлайн, объединяют лидов в рамках отдельных юнитов и помогают совместно обсуждать проблемы, брейнштормить решения этих проблем. Выше мы писали отдельные посты про стратсессии и ретро.
#HR #маша_ковылина🔥
Недавно была на вебинаре, где HR разных компаний делились опытом вовлечения и мотивации в распределенных командах. Послушала, кто какие штуки у себя использует, и поняла, что многое из этого мы делаем у себя. Делюсь нашими практиками, буду рада, если поделитесь своими в комментариях.
Менторинг
В KTS у каждого сотрудника есть ментор — более опытный коллега той же специализации. Ментор и подопечный могут работать на разных проектах. Если они на одном проекте, ментор на старте отвечает за онбординг в команду и процессы. Если на разных, то новичка онбордит руководитель проекта или разработчик-лид.
В любом случае ментор отвечает за развитие нового сотрудника — ставит цели на полгода, прописывает параметры оценки достижения целей и каждые полгода участвует в перфоманс-ревью. На ревью ментор собирает фидбеки ключевых людей из команд, с которыми человек успел поработать за полгода, сопоставляет их с целями и презентует результаты на калибровках. Калибровка — это онлайн-митинг, где сравниваются достижения ребят одинаковых грейдов из разных команд между собой. По результатам калибровок ментор ставит оценку достижениям подопечного, подводит итоги на специальном 1-1, они ставят новые цели, и цикл повторяется.
Демо-дни
В среднем раз в месяц (иногда чаще) мы собираемся на демо-день. Это кросс-командная онлайн-встреча для всех желающих, на которой одна из наших команд презентует свои наработки, интересные результаты, рассказывает коллегам, чем занимается. Все это в режиме интерактива, в веселой атмосфере, с мемами и с ответами на вопросы.
Например, за прошедшее лето мы собирались 3 раза. Была встреча, на которой один из основателей #сергей_чернобровкин
Стратсессии и ретро
Бывают оффлайн и онлайн, объединяют лидов в рамках отдельных юнитов и помогают совместно обсуждать проблемы, брейнштормить решения этих проблем. Выше мы писали отдельные посты про стратсессии и ретро.
#HR #маша_ковылина
Please open Telegram to view this post
VIEW IN TELEGRAM
Как мы сделали миниапп с недушными мемами для онлайн-школы Вебиум
Вебиум — онлайн-школа, которая не считает, что подготовка к экзаменам должна быть скучной и похожей на пытку. И я с ними полностью согласен.
На рынке сейчас много онлайн-школ, поэтому ребята решили выделиться необычным проектом — игрой ВКонтакте с мемами для школьников.
За основу игры мы взяли механику «Тиндер» из нашего каталога готовых механик, а ребята из Вебиума наполнили приложение смелыми и некринжовыми мемами, которыми мы еще долго перекидывались в чатах.
Подробнее — в разборе проекта на VC.
#максим_павлов😀
Вебиум — онлайн-школа, которая не считает, что подготовка к экзаменам должна быть скучной и похожей на пытку. И я с ними полностью согласен.
На рынке сейчас много онлайн-школ, поэтому ребята решили выделиться необычным проектом — игрой ВКонтакте с мемами для школьников.
За основу игры мы взяли механику «Тиндер» из нашего каталога готовых механик, а ребята из Вебиума наполнили приложение смелыми и некринжовыми мемами, которыми мы еще долго перекидывались в чатах.
Подробнее — в разборе проекта на VC.
#максим_павлов
Please open Telegram to view this post
VIEW IN TELEGRAM
Практики HR для бизнеса: праздники, активности и внутренние медиа
В прошлом посте я рассказала про менторинг, демо-дни, стратсессии и ретро. Сегодня закончу тему и расскажу про оставшиеся активности и внутренние медиа, которые есть у нас.
Праздники/активности онлайн и оффлайн
В мае мы стабильно открываем сезон встреч и посиделок на крыше офиса, в ноябре празднуем день рождения компании, а в декабре проводим традиционный новогодний корпоратив.
ДР и корпоратив с прошлого года проходят параллельно в оффлайн- и онлайн-формате. Например, на прошлом НГ-корпоративе мы объединили оффлайн и онлайн-сотрудников на совместном квизе, который придумала, организовала и провела HR-команда.
Ещё примерно раз в неделю устраиваем в офисе день какой-то вкусной еды: уже были бельгийские вафли, молочные коктейли, варёная кукуруза и смузи. Во всех таких активностях нам помогает наш офис-менеджер Эля.
Внутренние медиа
Все наши коммуникации происходят в Телеграме. У нас много чатов. Очень много чатов 🙂 Но все они живые, в них поддерживается активность, каждый сотрудник — автор контента.
Основные чаты, которые у нас есть:
— канал с оперативной важной и серьезной рассылкой на всю компанию
— чаты по интересам: про кино, про книги, про компьютерные игры, про настолки, про вкусную еду. В этих чатах ребята обмениваются опытом, интересными наблюдениями, заметками, рекомендациями
— чат-флудилка. Как Твиттер, только в Телеграме: треды с приколами, мемами, несерьезными дискуссиями без политики… для которой есть отдельный чат
— канал-дайджест, который всю активность во всех этих чатах объединяет в еженедельную развлекательную рассылку. Смешные и интересные треды в чатах, важные новости, анонсы материалов, которые выпускаются на наших внешних медиа — все это с любовью собирает каждую неделю наш главный редактор Игорь.
А как вы поддерживаете вовлеченность в распределенных командах?
#HR #маша_ковылина🔥
В прошлом посте я рассказала про менторинг, демо-дни, стратсессии и ретро. Сегодня закончу тему и расскажу про оставшиеся активности и внутренние медиа, которые есть у нас.
Праздники/активности онлайн и оффлайн
В мае мы стабильно открываем сезон встреч и посиделок на крыше офиса, в ноябре празднуем день рождения компании, а в декабре проводим традиционный новогодний корпоратив.
ДР и корпоратив с прошлого года проходят параллельно в оффлайн- и онлайн-формате. Например, на прошлом НГ-корпоративе мы объединили оффлайн и онлайн-сотрудников на совместном квизе, который придумала, организовала и провела HR-команда.
Ещё примерно раз в неделю устраиваем в офисе день какой-то вкусной еды: уже были бельгийские вафли, молочные коктейли, варёная кукуруза и смузи. Во всех таких активностях нам помогает наш офис-менеджер Эля.
Внутренние медиа
Все наши коммуникации происходят в Телеграме. У нас много чатов. Очень много чатов 🙂 Но все они живые, в них поддерживается активность, каждый сотрудник — автор контента.
Основные чаты, которые у нас есть:
— канал с оперативной важной и серьезной рассылкой на всю компанию
— чаты по интересам: про кино, про книги, про компьютерные игры, про настолки, про вкусную еду. В этих чатах ребята обмениваются опытом, интересными наблюдениями, заметками, рекомендациями
— чат-флудилка. Как Твиттер, только в Телеграме: треды с приколами, мемами, несерьезными дискуссиями без политики… для которой есть отдельный чат
— канал-дайджест, который всю активность во всех этих чатах объединяет в еженедельную развлекательную рассылку. Смешные и интересные треды в чатах, важные новости, анонсы материалов, которые выпускаются на наших внешних медиа — все это с любовью собирает каждую неделю наш главный редактор Игорь.
А как вы поддерживаете вовлеченность в распределенных командах?
#HR #маша_ковылина
Please open Telegram to view this post
VIEW IN TELEGRAM
Выступаем на «Подлодке» с iOS-докладом
27 ноября в 19:00 на конференции «Подлодка» наш iOS-эксперт Саша Сычев выступит с докладом «Опыт и точка. Как расти миддлу и сеньору».
Начинающим разработчикам доступно множество ресурсов для роста в IT: школы программирования, образовательные курсы, книги, менторы и конференции. Но если вы уже «крепкий middle» или «опытный senior», то в школах программирования вы сами являетесь преподавателем. Курсы рассчитаны на junior-уровень и не несут новой информации. Основные книги прочитаны, и тезисы из них законспектированы. С менторами скучно: коллег можно увидеть на daily или в профильных чатах. Интерес к конференциям потерян, ведь все доклады уже были, а новые вы сами помогаете готовить.
Как искать точки роста и вдохновение, чтобы идти к новым целям?
На докладе обсудим подходы, которые помогают преодолеть ментальные барьеры и сохранять интерес к профессии.
Почитать о конференции можно по ссылке: https://podlodka.io/ioscrew
Приходите послушать!
#ios #александр_сычев
27 ноября в 19:00 на конференции «Подлодка» наш iOS-эксперт Саша Сычев выступит с докладом «Опыт и точка. Как расти миддлу и сеньору».
Начинающим разработчикам доступно множество ресурсов для роста в IT: школы программирования, образовательные курсы, книги, менторы и конференции. Но если вы уже «крепкий middle» или «опытный senior», то в школах программирования вы сами являетесь преподавателем. Курсы рассчитаны на junior-уровень и не несут новой информации. Основные книги прочитаны, и тезисы из них законспектированы. С менторами скучно: коллег можно увидеть на daily или в профильных чатах. Интерес к конференциям потерян, ведь все доклады уже были, а новые вы сами помогаете готовить.
Как искать точки роста и вдохновение, чтобы идти к новым целям?
На докладе обсудим подходы, которые помогают преодолеть ментальные барьеры и сохранять интерес к профессии.
Почитать о конференции можно по ссылке: https://podlodka.io/ioscrew
Приходите послушать!
#ios #александр_сычев
Удержание через рост: как компания может бороться с выгоранием
Сегодня хочу рассмотреть тему выгорания с точки зрения амбиций человека. По-моему, это очень связанные вещи, хотя, безусловно, причин выгорания много. К тому же выгорание часто становится причиной смены работы (как будто бы существует работа без возможности выгорания), поэтому тем более важно понимать причины выгорания и то, как можно влиять на состояние человека со стороны компании.
Допустим, кто-то уже давно работает в компании, делает плюс-минус одно и то же и думает, что «стоит на месте». Причем доход может на месте не стоять, но внутреннее ощущение все равно будет, а оно куда важнее. Это неизбежно приведет к мыслям вроде: «А тем ли я занимаюсь», «развиваюсь ли я», «зачем я вообще это все делаю». В общем, какие-то экзистенциальные вопросы.
В пору овер-высоких доходов в IT, ставших доступными для очень молодых людей (например, часто вы в свои 20-25 лет можете получать больше родителей, работавших больше этих 25 лет), экзистенциальные вопросы становятся еще актуальнее, люди быстрее до них доходят. Но это отдельная тема. Вернёмся к выгоранию и уходу из компании.
На мой взгляд, ключевое для человека — это чувство наполненности деятельности смыслом, движением и развитием. Если человек ощущает движение, и что направление этого движения верное, он реже выгорает и меньше думает об уходе. Ведь закрываются его нематериальные потребности: познание, развитие, удовлетворение от изменений и результатов.
Конечно, есть разные практики выхода из выгорания, некоторые мы даже описывали, но все они только лечат симптомы и помогают выйти из пика выгорания.
Люди могут закрывать нематериальные потребности разными способами, например, компенсировать отсутствие роста в проф. деятельности какими-нибудь хобби. Иногда хобби может даже перетекать в эту проф. деятельность, когда человек фактически уходит с основной работы и начинает зарабатывать тем, в чем чувствует больше интереса, развития, мотивации и результатов. Это еще раз подтверждает тезис, что человек в целом ищет закрытие этих потребностей.
Значит, задача компании — дать человеку возможности для реализации его амбиций и ощущение постоянного развития. Он должен чувствовать, что не стоит на месте. Для этого должны быть челленджи, новые интересные вызовы, решая которые, человек растет. Это не значит, что нужно постоянно накидывать больше задач и ответственности. Чрезмерное количество таких челленджей может сыграть в обратную сторону. Но человек должен всегда знать, что эти вызовы есть, и есть много путей развития внутри компании.
Причем для сотрудников разного «возраста внутри компании» эти ощущения будут разниться. Например, недавно вышедший сотрудник видит океан возможностей. Его окружают более «старшие» коллеги, а новичок часто даже не знает, чем они занимаются. Очень много путей развития. Здесь компании достаточно просто рассказывать о себе и о том, как можно развиваться по примеру «старших».
А вот сотрудники-старички, находящиеся, как правило, на высоких должностях, смотрят на все с другой стороны «пирамиды». Поэтому для них скорее важно, чтобы рост компании обгонял их собственный рост. То есть здесь компания должна расти и, как следствие, организовывать новые структуры, зоны ответственности, инициативы, чтобы человек видел это и вдохновлялся, чувствовал себя тем, кто может открывать эти новые неизведанные берега.
Поэтому я верю, что единственная стратегия удержания и уменьшения выгорания — это создание ощущения постоянного роста у сотрудников.
#размышления #сергей_чернобровкин👨
Сегодня хочу рассмотреть тему выгорания с точки зрения амбиций человека. По-моему, это очень связанные вещи, хотя, безусловно, причин выгорания много. К тому же выгорание часто становится причиной смены работы (как будто бы существует работа без возможности выгорания), поэтому тем более важно понимать причины выгорания и то, как можно влиять на состояние человека со стороны компании.
Допустим, кто-то уже давно работает в компании, делает плюс-минус одно и то же и думает, что «стоит на месте». Причем доход может на месте не стоять, но внутреннее ощущение все равно будет, а оно куда важнее. Это неизбежно приведет к мыслям вроде: «А тем ли я занимаюсь», «развиваюсь ли я», «зачем я вообще это все делаю». В общем, какие-то экзистенциальные вопросы.
В пору овер-высоких доходов в IT, ставших доступными для очень молодых людей (например, часто вы в свои 20-25 лет можете получать больше родителей, работавших больше этих 25 лет), экзистенциальные вопросы становятся еще актуальнее, люди быстрее до них доходят. Но это отдельная тема. Вернёмся к выгоранию и уходу из компании.
На мой взгляд, ключевое для человека — это чувство наполненности деятельности смыслом, движением и развитием. Если человек ощущает движение, и что направление этого движения верное, он реже выгорает и меньше думает об уходе. Ведь закрываются его нематериальные потребности: познание, развитие, удовлетворение от изменений и результатов.
Конечно, есть разные практики выхода из выгорания, некоторые мы даже описывали, но все они только лечат симптомы и помогают выйти из пика выгорания.
Люди могут закрывать нематериальные потребности разными способами, например, компенсировать отсутствие роста в проф. деятельности какими-нибудь хобби. Иногда хобби может даже перетекать в эту проф. деятельность, когда человек фактически уходит с основной работы и начинает зарабатывать тем, в чем чувствует больше интереса, развития, мотивации и результатов. Это еще раз подтверждает тезис, что человек в целом ищет закрытие этих потребностей.
Значит, задача компании — дать человеку возможности для реализации его амбиций и ощущение постоянного развития. Он должен чувствовать, что не стоит на месте. Для этого должны быть челленджи, новые интересные вызовы, решая которые, человек растет. Это не значит, что нужно постоянно накидывать больше задач и ответственности. Чрезмерное количество таких челленджей может сыграть в обратную сторону. Но человек должен всегда знать, что эти вызовы есть, и есть много путей развития внутри компании.
Причем для сотрудников разного «возраста внутри компании» эти ощущения будут разниться. Например, недавно вышедший сотрудник видит океан возможностей. Его окружают более «старшие» коллеги, а новичок часто даже не знает, чем они занимаются. Очень много путей развития. Здесь компании достаточно просто рассказывать о себе и о том, как можно развиваться по примеру «старших».
А вот сотрудники-старички, находящиеся, как правило, на высоких должностях, смотрят на все с другой стороны «пирамиды». Поэтому для них скорее важно, чтобы рост компании обгонял их собственный рост. То есть здесь компания должна расти и, как следствие, организовывать новые структуры, зоны ответственности, инициативы, чтобы человек видел это и вдохновлялся, чувствовал себя тем, кто может открывать эти новые неизведанные берега.
Поэтому я верю, что единственная стратегия удержания и уменьшения выгорания — это создание ощущения постоянного роста у сотрудников.
#размышления #сергей_чернобровкин
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Запустили новый сайт для DevOps-направления в KTS
Отделу DevOps исполнилось 2 года. В честь дня рождения мы решили избавиться от прежнего кринж-сайта и сделали новый.
Надеемся, что оцените эффект 🔥 от наведения курсора на кота, а также кабанчика 🐗, который всегда готов быстренько метнуться и порешать ваши девопс-вопросики.
На сайте отразили услуги, которые кристаллизовались за 2 года жизни DevOps-направления:
1. Переезд в Yandex Cloud. Мы стали партнерами с Yandex Cloud и даже выпустили совместные курсы.
2. Автоматические фича-стенды. Даже написали статью о том, как эта штука влияет на Time to market.
3. Поддержка инфраструктуры. Разработчики заказчика занимаются разработкой, а наши девопсеры следят за тем, чтобы ничего не падало.
4. Аудиты инфраструктуры. Смотрим, как можно сэкономить на инфраструктуре и выявляем узкие места.
👉 Ссылка на сайт
#devops
Отделу DevOps исполнилось 2 года. В честь дня рождения мы решили избавиться от прежнего кринж-сайта и сделали новый.
Надеемся, что оцените эффект 🔥 от наведения курсора на кота, а также кабанчика 🐗, который всегда готов быстренько метнуться и порешать ваши девопс-вопросики.
На сайте отразили услуги, которые кристаллизовались за 2 года жизни DevOps-направления:
1. Переезд в Yandex Cloud. Мы стали партнерами с Yandex Cloud и даже выпустили совместные курсы.
2. Автоматические фича-стенды. Даже написали статью о том, как эта штука влияет на Time to market.
3. Поддержка инфраструктуры. Разработчики заказчика занимаются разработкой, а наши девопсеры следят за тем, чтобы ничего не падало.
4. Аудиты инфраструктуры. Смотрим, как можно сэкономить на инфраструктуре и выявляем узкие места.
👉 Ссылка на сайт
#devops
Почему рост команды может плохо сказаться на ее производительности
Часто команды расширяются только за счет разработчиков: чем их больше, тем быстрее пишется код, а фичи внедряются в сервис. Звучит логично, но на деле все не так просто.
В новой статье рассказал, почему найм новых разработчиков может не только не улучшить вашу производительность, но и ухудшить ее, и о том, как вовремя сообразить, что что-то идет не так. Спойлер: если вы наняли новых разработчиков, чтобы быстрее работать, а они закопались в багах и согласованиях — текст про вас 🙃
👉 Ссылка на статью
#максим_павлов😀
Часто команды расширяются только за счет разработчиков: чем их больше, тем быстрее пишется код, а фичи внедряются в сервис. Звучит логично, но на деле все не так просто.
В новой статье рассказал, почему найм новых разработчиков может не только не улучшить вашу производительность, но и ухудшить ее, и о том, как вовремя сообразить, что что-то идет не так. Спойлер: если вы наняли новых разработчиков, чтобы быстрее работать, а они закопались в багах и согласованиях — текст про вас 🙃
👉 Ссылка на статью
#максим_павлов
Please open Telegram to view this post
VIEW IN TELEGRAM
Мы участвуем в конкурсе кейсов Tagline Awards, и сейчас там вовсю идет зрительское голосование. От KTS на конкурсе сразу четыре проекта:
1. Мобильное приложение для застройщика «Мангазея»
2. Мини-апп ВКонтакте «СмешАпп» в честь 20-летия «Смешариков»
3. Бот для телевизионного конкурса «Поймай лето за хвост» от СТС
4. Тираж личного кабинета сотрудников «Пятёрочки» на другие бизнес-единицы X5 Group
Нам нужна ваша поддержка, поэтому будет круто, если вы сможете перейти по каждой из ссылок выше и проголосовать за наши кейсы.
P.S. Иногда окошко с голосованием не открывается. Если так случилось — просим попробовать еще раз через полчаса (если вам не лень, конечно 🙂)
1. Мобильное приложение для застройщика «Мангазея»
2. Мини-апп ВКонтакте «СмешАпп» в честь 20-летия «Смешариков»
3. Бот для телевизионного конкурса «Поймай лето за хвост» от СТС
4. Тираж личного кабинета сотрудников «Пятёрочки» на другие бизнес-единицы X5 Group
Нам нужна ваша поддержка, поэтому будет круто, если вы сможете перейти по каждой из ссылок выше и проголосовать за наши кейсы.
P.S. Иногда окошко с голосованием не открывается. Если так случилось — просим попробовать еще раз через полчаса (если вам не лень, конечно 🙂)
Увеличение тайминга встреч
В этом году читал замечательную книгу «Бирюзовое управление на практике». Там был описан интересный контр-интуитивный прием: удлинять временные слоты.
Идея заключается в том, что вместо сокращения встреч (когда вместо часа ставишь 50 минут) и большего их количества, нужно делать наоборот: увеличить время и сократить количество.
Цель, на которую работает такой подход — увеличение продуктивности. Казалось бы, нужно напихать в календарь как можно больше всего, ведь тогда сделаешь больше. Но в этом и заключается заблуждение. Я решил проверить этот совет на практике и теперь рекомендую некоторым ребятам, которые тоже зашиваются.
Следуя этому принципу, я начал бронировать в календаре время заведомо большее, чем по моим оценкам требуется на задачу или встречу. Я почувствовал сразу несколько эффектов:
1. Максимальная концентрация без спешки. Когда встречи короткие и ещё и идут друг за другом, приходится выдавать какие-то идеи и решения чуть ли не на лету, потому что уже пора бежать. В итоге качество таких решений очевидно страдает. А если знаешь, что времени еще много, погружаешься в задачу глубже.
2. Я стал не так сильно уставать от переключений контекстов. Чем длиннее каждая встреча в календаре, тем их меньше за день, следовательно, контекстов тоже меньше. Падает количество контекстов — падает усталость.
3. У меня появилось больше времени! Так как бронь в календаре ставится с запасом, то часто остается свободный кусок, который я могу использовать на что-то другое. В итоге получается, что дел можно сделать почти всегда больше, чем планировал, а это влияет и на удовлетворенность, и на результативность.
Как итог — моя продуктивность в дни, когда я сам инициирую встречи или планирую календарь, выше.
#бизнес #сергей_чернобровкин👨
В этом году читал замечательную книгу «Бирюзовое управление на практике». Там был описан интересный контр-интуитивный прием: удлинять временные слоты.
Идея заключается в том, что вместо сокращения встреч (когда вместо часа ставишь 50 минут) и большего их количества, нужно делать наоборот: увеличить время и сократить количество.
Цель, на которую работает такой подход — увеличение продуктивности. Казалось бы, нужно напихать в календарь как можно больше всего, ведь тогда сделаешь больше. Но в этом и заключается заблуждение. Я решил проверить этот совет на практике и теперь рекомендую некоторым ребятам, которые тоже зашиваются.
Следуя этому принципу, я начал бронировать в календаре время заведомо большее, чем по моим оценкам требуется на задачу или встречу. Я почувствовал сразу несколько эффектов:
1. Максимальная концентрация без спешки. Когда встречи короткие и ещё и идут друг за другом, приходится выдавать какие-то идеи и решения чуть ли не на лету, потому что уже пора бежать. В итоге качество таких решений очевидно страдает. А если знаешь, что времени еще много, погружаешься в задачу глубже.
2. Я стал не так сильно уставать от переключений контекстов. Чем длиннее каждая встреча в календаре, тем их меньше за день, следовательно, контекстов тоже меньше. Падает количество контекстов — падает усталость.
3. У меня появилось больше времени! Так как бронь в календаре ставится с запасом, то часто остается свободный кусок, который я могу использовать на что-то другое. В итоге получается, что дел можно сделать почти всегда больше, чем планировал, а это влияет и на удовлетворенность, и на результативность.
Как итог — моя продуктивность в дни, когда я сам инициирую встречи или планирую календарь, выше.
#бизнес #сергей_чернобровкин
Please open Telegram to view this post
VIEW IN TELEGRAM
Забрали награду в крупнейшем digital-конкурсе Европы в номинации «Лучшая онлайн-игра» 🥉
Миниапп в честь 20-летия сериала «Смешарики» завоевал бронзу. Нашей целью было создать единую платформу для фанатов Смешариков среди пользователей ВКонтакте.
В результате, у пользователей появился быстрый доступ ко всему контенту Смешариков. Вспомнить песни из эпизодов, посмотреть мультфильмы, узнать факт дня от Лосяша и поиграть с Пином можно в одном мини-приложении.
Подробнее о кейсе тут. А еще можете пройти игры сами по ссылке
Миниапп в честь 20-летия сериала «Смешарики» завоевал бронзу. Нашей целью было создать единую платформу для фанатов Смешариков среди пользователей ВКонтакте.
В результате, у пользователей появился быстрый доступ ко всему контенту Смешариков. Вспомнить песни из эпизодов, посмотреть мультфильмы, узнать факт дня от Лосяша и поиграть с Пином можно в одном мини-приложении.
Подробнее о кейсе тут. А еще можете пройти игры сами по ссылке
Программисты делают бизнес
Увеличение тайминга встреч В этом году читал замечательную книгу «Бирюзовое управление на практике». Там был описан интересный контр-интуитивный прием: удлинять временные слоты. Идея заключается в том, что вместо сокращения встреч (когда вместо часа ставишь…
Фокусное событие
Продолжая тему увеличенных таймслотов, хочу поделиться еще одним наблюдением.
Если бронь в календаре становится достаточно большой (например, 3 часа на какой-то блок работы), такое событие становится «фокусным». Фактически, можно сказать, что весь рабочий день посвящен ему, потому что все остальные дела априори будут меньше.
И у этого тоже есть свои эффекты:
1. Фокусное событие мотивирует. Оно становится таким «икигаем на день»: ты думаешь о нем перед сном и хочешь поскорее проснуться, чтоб начать делать.
2. После рабочего дня точно выработается дофамин. Ведь ты закрыл большую задачу, которая была в «центре» всего дня.
3. Приоритет на самом деле всегда один. Не может быть много «самых приоритетных» задач в моменте. И фокусное событие обычно становится таким приоритетом на день.
Наверно, если вы раньше не задумывались об эффектах таких фокусных событий, то самый понятный пример — выездная очная встреча или конференция.
Если вы едете на очную встречу, она становится таким фокусом просто потому, что точно займёт много времени: доехать, провести, уехать, зайти где-нибудь поесть. И как правило, в такие дни вы максимально сконцентрированы только на этом событии, и оно становится запоминающимся.
#бизнес #сергей_чернобровкин👨
Продолжая тему увеличенных таймслотов, хочу поделиться еще одним наблюдением.
Если бронь в календаре становится достаточно большой (например, 3 часа на какой-то блок работы), такое событие становится «фокусным». Фактически, можно сказать, что весь рабочий день посвящен ему, потому что все остальные дела априори будут меньше.
И у этого тоже есть свои эффекты:
1. Фокусное событие мотивирует. Оно становится таким «икигаем на день»: ты думаешь о нем перед сном и хочешь поскорее проснуться, чтоб начать делать.
2. После рабочего дня точно выработается дофамин. Ведь ты закрыл большую задачу, которая была в «центре» всего дня.
3. Приоритет на самом деле всегда один. Не может быть много «самых приоритетных» задач в моменте. И фокусное событие обычно становится таким приоритетом на день.
Наверно, если вы раньше не задумывались об эффектах таких фокусных событий, то самый понятный пример — выездная очная встреча или конференция.
Если вы едете на очную встречу, она становится таким фокусом просто потому, что точно займёт много времени: доехать, провести, уехать, зайти где-нибудь поесть. И как правило, в такие дни вы максимально сконцентрированы только на этом событии, и оно становится запоминающимся.
#бизнес #сергей_чернобровкин
Please open Telegram to view this post
VIEW IN TELEGRAM
Как по нытью разработчиков понять, что нужны фича-сервера
Фича-серверы, или динамические окружения помогают не только с тестированием — они могут быть неочевидным решением многих других проблем. В новой статье рассказал — с чем и как они помогают справиться, а также как не проморгать момент, когда пора их внедрять.
Вот затравочка: если тестовый сервер все время занят или вообще не работает, разработчики постоянно что-то пересобирают а новые члены команды тратят по несколько дней на развертывание проекта — это тот самый момент.
👉 Ссылка на статью
#максим_павлов😀
Фича-серверы, или динамические окружения помогают не только с тестированием — они могут быть неочевидным решением многих других проблем. В новой статье рассказал — с чем и как они помогают справиться, а также как не проморгать момент, когда пора их внедрять.
Вот затравочка: если тестовый сервер все время занят или вообще не работает, разработчики постоянно что-то пересобирают а новые члены команды тратят по несколько дней на развертывание проекта — это тот самый момент.
👉 Ссылка на статью
#максим_павлов
Please open Telegram to view this post
VIEW IN TELEGRAM
«Давайте уже после праздников» — отличный совет для маленьких компаний, когда запускать рекламные проекты
Год назад я написала статью про то, почему среди крупных компаний под Новый год идёт особенно ожесточенная борьба за внимание клиентов, и что можно делать небольшим компаниям, чтобы не затеряться среди новогодней феерии.
Совет для маленьких и средних компаний запускать рекламные активности уже после Нового года не устаревает.
Если пропустили в прошлом году, то велком на новую (старую) статью. Рассказываю там подробнее, почему маленьким компаниям лучше планировать рекламные проекты на январь и февраль, и как это лучше сделать.
#вика_синельникова😎 #спецпроекты
Год назад я написала статью про то, почему среди крупных компаний под Новый год идёт особенно ожесточенная борьба за внимание клиентов, и что можно делать небольшим компаниям, чтобы не затеряться среди новогодней феерии.
Совет для маленьких и средних компаний запускать рекламные активности уже после Нового года не устаревает.
Если пропустили в прошлом году, то велком на новую (старую) статью. Рассказываю там подробнее, почему маленьким компаниям лучше планировать рекламные проекты на январь и февраль, и как это лучше сделать.
#вика_синельникова
Please open Telegram to view this post
VIEW IN TELEGRAM