Принимаешь ли инициативу от подчиненных

Отношение к инициативе подчиненных

Это критически важный вопрос о стиле управления и культуре команды. Мой ответ ясен: не просто принимаю инициативу, а активно поощряю и создаю условия для её проявления. Это один из ключевых факторов успеха в IT-продакте.

Почему инициатива важна

Люди, которые работают с продуктом каждый день — разработчики, дизайнеры, тестировщики, аналитики — часто видят проблемы раньше меня. Они ближе к коду, к пользовательским сценариям, к реальным болевым точкам. Если я буду диктовать всё сверху, я упущу огромное количество улучшений.

Как я создаю культуру инициативы

1. Открытое приглашение к идеям На регулярных встречах (планерках, ретроспективах) я явно создаю безопасное пространство: "Какие идеи улучшения у вас есть? Что вас раздражает? Что мы упускаем?" Главное — не давить оценками, а слушать.

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

3. Ясные критерии оценки Не все идеи подходят. Но я объясняю, почему: "Это не соответствует нашим приоритетам сейчас, но хорошая идея. Давай вернёмся к ней через квартал", или "Это требует много ресурсов, но есть более неотложные задачи".

4. Эксперименты и small bets Даже если идея не вписывается в главную дорожную карту, я предлагаю: "Давай сделаем это как эксперимент на 5% времени" или "Реализуй это как MVP, если будет результат, масштабируем". Риск минимален, но инициатива получает зелёный свет.

Примеры из практики

Случай 1: Инженер предложил оптимизировать процесс деплоя Это была инициатива снизу. Я не просил, но инженер видел, что деплой занимает 2 часа и часто ломается. Результат: вместе мы сократили время до 15 минут. Экономия: 2-3 часа в неделю на всю команду.

Случай 2: Дизайнер предложил переработать onboarding Я сам не заметил проблему, но дизайнер видел метрики drop-off в первые 5 минут. Мы сделали A/B тест, и новый onboarding повысил Activation на 25%.

Случай 3: QA инженер предложил автоматизировать регрессионное тестирование Это заняло 2 недели, но потом экономило 6 часов в неделю. Я одобрил проект, потому что видел долгосрочный выигрыш.

Границы и баланс

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

Правило баланса:

• 80% времени я двигаю заранее спланированные приоритеты
• 20% времени оставляю для инициативы и экспериментов
• Результаты эксперимента определяют, станут ли они приоритетом

Как я обрабатываю отклонённые идеи

Если отвергаю идею, я объясняю причину и предлагаю альтернативу:

• "Это хорошая идея, но у нас нет ёмкости в спринте. Давай добавим в backlog на следующий квартал"
• "Это не соответствует нашей текущей стратегии, но если результаты покажут спрос — вернёмся"

Главное — не убивать мотивацию человека. Он должен чувствовать, что его идея важна, даже если не была реализована.

Результат такого подхода

Плюсы:

• Команда более вовлечена и мотивирована
• Лучше видимость проблем на ранней стадии
• Часто лучшие идеи приходят не от PM, а от людей в траншеях
• Retention и удовлетворённость команды выше

Минусы:

• Нужна дисциплина, чтобы не потеряться в инициативах
• Требует больше времени на обсуждение и фасилитацию
• Нужен чёткий фреймворк приоритизации

Но минусы легко управляемы, а плюсы стоят того. Лучшие продукты создаются командой, которая активно участвует в их улучшении, а не просто следует приказам.