Я — Егор Северинов, Product Manager в VK Знакомствах ❤️‍🔥

7+ лет руковожу IT-командами — от геймдева до финтеха.
Здесь делюсь опытом, продуктовыми и проектными кейсами, рассказываю, как вытаскивать команды из хаоса, строить процессы и запускать рост.
Немного про меня:
🔹 По диплому — программист, по жизни – менеджер
🔹 Начинал в продажах крупного банка, потом пришёл в IT как проджект — и понеслось.
🔹 Работал в стартапах и гигантах, в геймдеве и банках.
🔹 Специализация — команды с бардаком в процессах. Люблю наводить порядок, выстраивать ритм и видеть, как продукт оживает.

А если интересно, как я шучу, работаю, живу и периодически страдаю в офисе — заглядывай в Instagram @severegor

ТОП посты:
1) Как я строил карьеру: от Сбера в топы IT
2) Сколько стоит подписаться на любовь
3) Как я начал успевать больше
4) Нарисуй мне фичу: почему визуальные баги опаснее логических
5) Перестаньте спрашивать у пользователей чего они хотят
6) Как стать уверенным, если ты всегда был «тем самым тихим парнем»

Что важнее, коммуникация или автократия в команде?

Когда я начинал, я недооценивал значение коммуникации в команде. После банка казалось, что я — босс, и остальные должны меня слушаться! И вот, работаю я в команде классных ребят, но они не хотят со мной нормально общаться, валят сроки и вообще игнорируют меня как «руководителя».

Как же мне повезло, что тимлид разработчиков, который как мне в тот момент казалось вообще меня ненавидел, назначил мне встречу 1-1 и высказал в подробностях мои проблемы и что главное варианты их решений! Ох, как я попотел, было так страшно, ведь после банка, в котором постоянно говорили об открытой обратной связи, но никогда фактически ее не использовали, я был не готов к такому. НО, это дало мне колоссальный буст, и за эти 20 минут встречи мой мозг поменял мышление. Как было круто, что этот же тимлид буквально через месяц сказал мне: «Блин, Егор, ты так круто поменялся. Я не думал, что это получится. Не останавливайся». А через пару лет, когда я покидал команду, ребята уже не хотели меня отпускать (пишу это и мурашки по коже).

Так вот к чему я. Руководитель — это не тиран и бог, а такой же член команды и лидер процесса! Просто кто-то работает «ручками», а вы помогаете им, даете ресурсы, ответы на вопросы, сохраняете здоровую атмосферу и поддерживаете!

Проводите встречи 1-1, узнавайте, как зовут жену и собаку сотрудника, чем он живет, что ему нравится и, конечно же, как дела на работе. И вам будут доверять. А когда с вами поделятся — решите проблему любым способом. Будьте другом и наставником! Будьте тем, кому можно довериться и на кого положиться!

Коммуникация — это не просто обмен информацией. Это основа, на которой строится успешная работа команды. Поэтому я всегда стараюсь уделять ей особое внимание и рекомендую это всем, кто хочет добиться успеха в управлении проектами.

ПС Никита, тебе привет 🫶🏼

Разработчики говорят, что stand-up (дейлик) — глупая трата времени. А так ли это? 🤔

Когда я впервые предложил своей команде ежедневные встречи, все возмущались и восприняли это как инструмент контроля, а не помощи. Ребята считали, что это пустая трата времени и лучше сразу приступить к работе. Но я был уверен, что это должно нам помочь. (У нас была проблема, что информация медленно перемещалась по команде)

И вот мы начали собираться по утрам, да, в начале пришлось немного надавить. Главное, чтобы все реально участвовали. Можно добавить элементы игры, но самое важное — вести эту встречу так, чтобы это была дискуссия, а не монолог. Когда команда чувствует заинтересованность, участники лучше делятся и помогают друг другу.

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

Вот еще регулярная история. Один разработчик работает над фичей, а другой, когда услышав это на дейлике, вспоминает, что уже копался в том коде и видел неявный «подводный камень», конечно это ускорит работу в будущем.

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

Если вам кажется, что дейлики — это глупая трата времени, значит вы не с тем их едите. Попробуйте по-другому!

🍕 Принцип двух пицц от Amazon:

Слышали про "принцип двух пицц" от Amazon? Это когда команда должна быть настолько маленькой, чтобы её можно было накормить двумя пиццами. Чуть поделюсь на эту тему из своего опыта.

Почему это работает?🤔
1. Меньше бюрократии: В маленьких командах решения принимаются быстрее. Вы помещаетесь в небольшом кабинете и можете подойти к любому сотруднику и ущипнуть его со словами «Спринт в огне».
2. Лучшая коммуникация: С небольшим количеством людей проще общаться. Мы часто устраиваем быстрые созвоны, всё понятно без лишних слов. И в целом это «дешево» в отличии от большой команды.
3. Больше ответственности: Каждый чувствует свою значимость. Когда у нас было всего пять человек на проекте, каждый знал, что его вклад действительно важен. Да и видел разумеется.

Как это работает у меня?
Сразу скажу, что не работал в таких маленьких командах изначально. Но приходя в крупную команду, всегда делю её на несколько проектных групп:
1. Выделил основные независимые направления разработки
Как правило даже если команда большая, разработчики специализируются на каких-то направлениях: одни пилят продуктовое решение, вторые админку, а третьи эксперименты ставят.
2. Разбил на три команды:
Под разбил понимаю, что у команд отдельные спринты, дейлики, ретро и все возможные стандартные встречи.
3. Нанял новых ПМов на каждую команду
Этот пункт не обязателен, если работы не много. Но часто бывает, что один ПМ не справится.

Минусы:
- Разработчики не погружены в детали проекта, с которым не работают (Одно из решений: иногда перемешивать команды)
- Меньше ресурсов для крупных задач: Маленьким командам может не хватать людей для выполнения больших и сложных задач.
- Проблемы с масштабированием: Увеличение числа маленьких команд может привести к сложностям в координации и интеграции их работы.
- Повышенная нагрузка на ПМов: Если нанимать дополнительных ПМов нет возможности, то оставшиеся могут быть перегружены.

🚀 Что такое Agile и почему он важен?

Когда я начинал свой путь в банке, об Agile там только говорили, но даже не пытались применять. Столкнулся я впервые с методологией "вживую" только в своей первой IT. И осознал, что это не просто модное слово, которое вставляют в тренинги, а рабочий инструмент в "здоровых" компаниях.

Agile — это методология, которая помогает командам быть гибкими и быстро адаптироваться к изменениям.

Почему Agile круто? 😎

Гибкость: Самый банальный пример. Заказчик приходит через месяц после запуска и меняет половину концепции продукта. Конечно, это всегда больно, но с Agile это можно пережить малыми потерями.
Коммуникация: Мы проводим регулярные дейлики, а еще планнинги, грумминги, ретро, 1-1 и т.д. О них тоже расскажу позже.
Продуктивность: Работая итеративно, мы быстро выпускаем новые апдейты, и продуктом можно начать пользоваться быстрее и получить аналитику. Это значит, что мы не тратим месяцы на что-то, что в итоге никому не нужно.
Клиентоориентированность: Agile помогает лучше понимать потребности заказчика. Заказчик каждый день получает новые данные и пару раз в неделю очередной релиз. Разумеется, это помогает ему быстро принимать решения и, если нужно, менять направление развития максимально оперативно.

В следующих постах расскажу про три популярные методологии, основанные на Agile: Scrum, Kanban и Waterfall. 📈

📈 Scrum: Самый популярный! А почему?

Простыми словами: Scrum — это методология со спринтами, Scrum-мастером и ретроспективами. По сути, большинство, когда слышат слово Agile, на самом деле представляют в голове Scrum.

Основные элементы Scrum:

1) Роли:

• Scrum-мастер: Помогает команде следовать Scrum процессам и устраняет препятствия. (На деле мало компаний выделяют эту должность, и всё это просто PM)
• Владелец продукта: Управляет бэклогом продукта и максимизирует его ценность.
• Команда разработки: Работает над созданием инкремента продукта.

2) Артефакты:

• Бэклог продукта: Список всех желаемых фич, доработок, багов.
• Бэклог спринта: Задачи для текущего спринта.
• Инкремент: Готовый результат работы за спринт.

3) События:

• Спринт: Короткий цикл (2-4 недели) для создания инкремента. (Хотя я сейчас работаю в команде, где спринт = 1 неделя)
• Планирование спринта: Планирование задач на спринт.
• Дейли: Короткие ежедневные встречи для синхронизации.
• Обзор спринта: Демонстрация результатов спринта. (Иногда делают в узком круге, чисто менеджеры рассказывают СЕО, а обычно не делают)
• Ретроспектива: Обсуждение проблем и успехов, а также улучшений. (По хорошему проводят раз в спринт, по факту в лучшем случае раз в месяц)

Почему Scrum работает?

• Фокус на результат: Конкретные цели на каждый спринт.
• Прозрачность: Регулярные встречи и артефакты для всех участников.
• Быстрая адаптация: Возможность быстро реагировать на изменения.

Когда я внедрял Scrum в команду, которая была без процессов, уже через месяц заметили улучшения в плане прозрачности и продуктивности. Ежедневные встречи помогали быстро выявлять проблемы и находить решения.

Кстати, часто на собесах меня просили описать основные артефакты Scrum. А вот вам ответы 😄

В следующем посте поговорим о Kanban — ещё одной популярной методологии. 📝

А вот реальная история из жизни 😀

📋 Kanban: Визуальное управление задачами

Kanban — максимально простая методология. Подходит для малых проектов, где релизы не регулярные, но есть какой-то приоритизированный список задач.

Основные элементы Kanban:

1. Визуализация работы: Все задачи отображаются на доске, разделённой на колонки (например, “To Do”, “In Progress”, “Done”).
2. Ограничение незавершённой работы (WIP): Ограниченное количество задач в каждой колонке помогает контролировать нагрузку на команду.
3. Управление потоком: Цель — обеспечить плавное движение задач по доске, минимизируя задержки и узкие места.

Отличия Kanban от Scrum:

1. Гибкость против структуры:
• Scrum: Работает по фиксированным спринтам.
• Kanban: Нет спринтов. Работа выполняется непрерывно, и новые задачи могут быть добавлены в любой момент.
2. Роли:
• Scrum: Включает три ключевые роли — Scrum-мастер, владелец продукта и команда разработки.
• Kanban: Не требует определённых ролей, хотя часто используются менеджеры задач и владельцы продуктов.
3. Артефакты и события:
• Scrum: Включает бэклог продукта, бэклог спринта, инкременты, а также события, такие как планирование спринта, ежедневные встречи, обзоры спринта и ретроспективы.
• Kanban: Включает только доску и задачи. Нет формальных событий, но можно проводить регулярные встречи по необходимости. Кажется, мечта любого разраба🤣 — никаких встреч.
4. Изменения в процессе:
• Scrum: Изменения могут быть внесены только в начале нового спринта.
• Kanban: Изменения могут вноситься в любой момент.

Мой опыт:
Я использовал Kanban в рамках довольно большой компании. У меня было 4 команды, и одна из них занималась проектом «Система управления и дашборды». В ней было куча задач, были приоритеты, но не было жестких релизов. Разработчики просто постепенно всё пилили и сразу выкатывали, и админка тихонько обновлялась. Встречались мы раз в неделю, чтобы актуализировать приоритеты и просто «сверить часы».

В следующем посте расскажу о Waterfall — ещё одной методологии управления проектами. 📝

🌊 Waterfall: Традиционная методология управления проектами

В отличие от Agile методологий, таких как Scrum и Kanban, Waterfall (иногда называют "водопад") — это более традиционный и линейный подход к управлению проектами. Сам я никогда не работал с этой методологией, считается, что она устарела для современного управления. В современных реалях гибкость слишком важна. Но расскажу про её особенности:

Основные элементы Waterfall:

1. Линейная последовательность: Есть несколько фаз, и каждая из них выполняется только после предыдущей.
2. Фазы проекта:
- Сбор требований: Все требования полностью описываются на старте.
- Проектирование системы: UX/UI готовится для будущего продукта.
- Реализация: Техническая разработка.
- Интеграция и тестирование: Тестирование на соответствие требованиям.
- Внедрение: Выход продукта/решения в лайв.
- Поддержка: Обслуживание и улучшение продукта после его релиза.

Преимущества Waterfall:

1. Четкая структура: Каждый этап проекта чётко определён и легко отслеживается.
2. Документирование: Всё качественно документируется. Легко найти любую информацию и влиться в проект.
3. Контроль: Просто контролировать проект, так как есть чёткая структура.

Недостатки Waterfall:

1. Гибкость: Любые изменения, особенно на поздних стадиях, могут быть критичны.
2. Риски: Заказчик увидит продукт только в конце, реализация может быть неудачной.
3. Время: Проект займет больше времени, так как нет параллельности этапов.

В следующем посте расскажу, как выбрать подходящую методологию для вашего проекта. 📝

Немного юмора в связи с новостями о налогах)