Глава 5: Работа с командой
Предыдущие статьи:
Лидерство
Как влиять без прямого подчинения?
1. Управление через влияние
Напомню, что PM — это, прежде всего, роль влияния, а не контроля. Ты влияешь через контекст, смысл и коммуникацию.
Научись «продавать» идею. Продукт — это всегда про «зачем». Когда ты презентуешь фичу или roadmap, не говори только про сроки и задачи. Объясни, почему это важно, какой пользовательской или бизнес-проблемой мы занимаемся, почему именно сейчас и какой цели хотим достичь. Когда твоя позиция прозрачна, за тобой проще идти и доверять твоим решениям.
Контекст вместо указаний. Вместо «сделай вот так», задай рамку: «Проблема вот такая, гипотеза вот такая, цель — такая-то метрика». Люди сами примут правильные решения, если понимают контекст. Хорошая практика — описывать в задачах вводные данные с объяснением, по какой причине задача появилась, и указанием цели.
Совместное принятие решений. Вовлекай команду в обсуждение решений. Делай product discovery открытым. Когда люди участвуют в принятии решений, они чувствуют ответственность за результат.
2. Построение доверия
Доверие — это валюта. Она очень сложно зарабатывается делом и невероятно быстро тратится.
Будь надёжен: выполняй обещания, держи слово, признавай ошибки.
Защищай команду: бери на себя ответственность, «разруливай» блокеры и конфликты, не перекладывай вину.
Проявляй эмпатию: слушай, интересуйся задачами и болями коллег.
3. Развитие soft skills
Самые важные навыки для продакта:
Коммуникация: умение доносить мысль ясно, кратко, по делу. Важно уметь говорить с разными ролями на их языке.
Активное слушание: не просто «слышать», а понимать мотивы, потребности, опасения.
Эмоциональный интеллект: считывать настроение, реагировать адекватно, управлять своими эмоциями в стрессовых ситуациях.
Как развивать лидерство?
Ключевые навыки
Навыки, необходимые для зарабатывания очков профессионального авторитета. Без них ты не будешь экспертом в глазах коллег, а это породит недоверие. Без доверия лидерство невозможно.
Стратегическое мышление — видеть продукт в контексте бизнеса. Навык не только видеть цель, но и умение формировать её и влиять на неё.
Критическое мышление — уметь задавать правильные вопросы. Коллегам, руководству, себе. Правильно заданный вовремя вопрос поможет избежать многих ошибок.
Системность — строить процессы, а не тушить пожары. Включи педанта, будь аккуратен. Сначала обустрой свои процессы и придерживайся их. Потом начни работать вместе с коллегами над общими процессами команды. Системность = порядок.
Инициативность — поднимать сложные темы, предлагать решения, быть “впереди”. Умей решать сложные вопросы. Не бросай коллег один на один с проблемами. В идеале — часть проблем решать задолго до того, как задача пойдёт в работу.
Полезные привычки
Вести рефлексию после каждого спринта/запуска: что сработало, что — нет. Ошибки — это нормально. Их не нужно прятать, потому что иначе они повторятся вновь.
Читать и пересказывать сложные идеи в простом виде. Сложные конструкции сложно понять. Хочешь, чтобы твои идеи лучше доходили до других? Научись рассказывать их в 1–2 предложения.
Искать фидбек: от команды, от пользователей, от менторов. Ты необъективен, и сам себя или свою команду оценить не сможешь. А взгляд со стороны может помочь увидеть зоны роста.
Помогать другим — учить, менторить, делиться знаниями. Не чахни над златом. Знаешь — поделись.
Для любителей читать
Книги расположены от лучшей к худшей, на мой взгляд:
«Пять пороков команды» — Патрик Ленсиони. Роман о построении процессов будучи руководителем. В художественной форме рассказывается о важных принципах управления;
«От хорошего к великому» — Джим Коллинз. Книга не совсем о лидерстве, но там есть важный и интересный вывод, ради которого и стоит прочесть. Книга объясняет, почему некоторые компании становятся великими;
«Бирюзовое управление на практике» — Валера Разгуляев. Что делает компании «бирюзовыми»? Рекомендую послушать в аудиоформате — читать довольно тяжело;
«Радикальная прямота» — Ким Скотт. О подходе «кнут и пряник» в управлении. Перевод кривой, поэтому лучше прочесть в оригинале. Но там много терминов. Основная идея будет понятна и в переводе;
«Лидеры едят последними» — Симон Синек. В несколько топорной форме рассказываются интересные вещи. Не все рекомендации, на мой взгляд, хорошие, но прочесть стоит;
«45 татуировок менеджера» — Максим Батырев. Вообще, это книга про управление в продажах, и там много соответствующего контекста. Часть «татуировок» повторяется или противоречит друг другу, но общий посыл книги верен. Несмотря на то, что я считаю эту книгу плохой, я всё равно советую вам её прочесть, чтобы вы понимали, как надо и как не надо. Будьте с книгой осторожны — там есть в том числе и вредные советы.
Применение на практике
Проводить продуктовые демо — это хорошая площадка для развития уверенного публичного выступления и выстраивания доверия. Рассказывай коллегам из разных команд об успехах и провалах в продукте: какие фичи появились и почему, какие эксперименты проводили и какие итоги.
Модерируй встречи и воркшопы — учись направлять дискуссию, а не управлять ею.
Заводи менторские отношения — как ученик и как ментор. Учись и учи. Так ты не будешь стоять на месте и будешь постоянно находить и закрывать белые пятна в своих знаниях.
Что такое микроменеджмент и как его избежать?
Микроменеджмент — это контролирование каждой мелочи: каждый тикет, каждый час работы, каждое решение. Это путь к выгоранию и вашему, и команды. Да и прекрасный источник для конфликтов.
Как выглядит микроменеджмент
Постоянные проверки, отчёты, «где это?»;
Комментарии на каждую мелочь в дизайне, копирайтинге, коде;
Желание всё делать самому, «потому что быстрее».
Почему это вредно
Убивает инициативу: команда ждёт инструкций, а не предлагает решения;
Замедляет работу: каждый шаг требует подтверждения;
Вызывает выгорание у PM и недоверие у команды.
Как не скатиться в микроменеджмент
Доверяй профессионализму команды. Дизайнер знает, как построить UX. Разработчик — как реализовать. Твоя задача — задать цели, а не указывать путь.
Фокус на outcome, а не output. Обсуждай цели, метрики, пользовательскую ценность — а не количество тасок.
Делегируй и отпускай. Да, не всё будет идеально. Но если не давать людям пробовать и ошибаться — рост невозможен.
Уточняй зоны ответственности. Кто за что отвечает. Кто принимает финальные решения. Это создаёт ясность и снижает «вмешательство».
Из личного опыта
Я очень падок на микроменеджмент и за три года так и не избавился полностью от желания за всем проследить. Периодически ловлю себя за этим и бью по рукам. Стараюсь найти сам для себя причину такого поведения и отрефлексировать ситуацию. Если ты тоже подвержен полному контролю, постарайся разобраться, почему это происходит. Проблема наверняка в тебе, а не в окружающих.
Командная динамика и роли
Как выстраивать рабочий процесс?
Начнём с простого: эффективность — это не про количество встреч или строгость процессов. Это про предсказуемость результата, быструю обратную связь и ясность целей. То есть цель — построить прозрачную систему с понятной обратной связью.
1. Один бэклог — одна команда
Если у тебя дизайнеры живут по своей доске, а разработчики — по своей, то ты не управляешь продуктом — ты наблюдаешь за хаосом. Общий бэклог с единым приоритетом и видимостью для всех участников — это не просто трекер, это средство синхронизации.
2. Регулярные синки и демо — не для галочки
Синк-встреча — это не отчёт для PM. Это место, где команда синхронизирует ожидания друг с другом. Минимум раз в неделю — синк всей команды. Каждые две недели — демо. Показывай не только фичи, но и инсайты, исследования, гипотезы.
3. Пиши и визуализируй
Документы спасают от домыслов. Пиши документацию, описывай результат в задачах. Не нужно на 30 страниц расписывать каждую мелочь, но нужно указать контекст, цели, метрики успеха и рамки. И доска с визуализацией прогресса — важная часть порядка и прозрачности.
4. Создавай культуру ответственности, а не контроля
Люди не обязаны выполнять твои задачи — они обязаны достигать целей продукта. Делегируй ответственность, а не задачи. Это отличает зрелую команду от команды фрилансеров на зарплате. Хочешь, чтобы вокруг тебя были профессионалы? Относись к окружающим как к профессионалам.
Как распределяются роли и зоны ответственности в продуктовой команде?
Важно понимать, что "все делают всё" — путь в никуда. При таком подходе в действительности никто ни за что не отвечает. Даже в гибкой среде нужны чёткие роли. И они не мешают кросс-функциональности, а наоборот, усиливают её.
PM (продакт-менеджер)
Отвечает за: ценность, приоритеты, пользовательские и бизнес-результаты.
Не делает: UI-дизайн, код, сложные SQL-запросы (если только ты не в стартапе из трёх человек) и дашборды.
Совет: будь тем, кто принимает решения, а не единственным источником правды (пиши документацию).
Дизайнер
Отвечает за: пользовательский опыт, визуальные решения, исследование поведения.
Зона риска: дизайнер без данных — это художник. Всегда дай доступ к метрикам. Если дизайнер не знает и не интересуется показателями продукта, стоит задуматься.
Совет: вовлекай дизайнера в обсуждение фичей с самого начала. Не кидай ему таск после синка. Приходи с идеями, а не решениями.
Разработчики
Отвечают за: техническую реализацию, архитектуру, качество кода.
Совет: обсуждай с ними не «что сделать», а «зачем мы это делаем». Тогда решения будут лучше.
Аналитик (если есть)
Отвечает за: метрики, валидацию гипотез, сегментацию, причинно-следственные связи.
Совет: подключай его на этапе формулировки проблемы, а не постфактум. Аналитик — не просто исполнитель твоих желаний, он соратник.
Тестировщик (QA)
Отвечает за: качество, стабильность, автоматизацию тестирования.
Совет: QA — самый важный член команды. Именно от качества его работы зависит то, как пользователи будут воспринимать продукт.
Чем вреден водопадный подход в гибких командах?
Если совсем просто, водопадный подход — это когда фича делается до готовности и только потом выпускается. Подход не считается гибким.
Слишком часто я видел, как даже «гибкие» команды на деле работают по водопаду: сначала дизайнер рисует без обсуждения с разработкой, потом разраб делает, потом тестировщик без контекста тестит, а в конце — продакт всё презентует. В таком подходе нет итеративности.
Почему водопад не работает:
Поздняя обратная связь. Если гипотеза не сработала, мы узнаем это через месяц;
Теряется контекст. Чем больше этапов между идеей и реализацией, тем хуже результат;
Изолирование ролей. Люди перестают понимать бизнес-контекст и общие цели.
Как быть:
Вовлекай всю команду в обсуждение задачи. Например, гипотезу по онбордингу обсуждают вместе дизайнер, аналитик, разработчик и ты. Все на одном уровне. Это снижает риск «функционального переложения ответственности». Каждый принял участие и согласовал результат.
«Бутылочное горлышко» и «фактор автобуса»: что это и как их избегать?
Если ты не можешь уйти в отпуск, потому что «а как команда без меня», значит, где-то ты свернул не туда. Команда не должна терять эффективность без твоего присутствия и контроля.
Бутылочное горлышко (bottleneck)
Это когда один человек тормозит весь процесс. Не обязательно потому, что он злодей. Обычно это выливается из-за дисбаланса в процессах или ресурсах.
Примеры:
Только один аналитик умеет выгружать метрики.
Только один разработчик понимает, как работает платёжная система.
В команде 8 разработчиков и 1 тестировщик.
Как решать:
Внедряй практику менторства и шеринга знаний.
Делай парное программирование и совместную аналитику.
Документируй процессы и знания — Confluence и Notion в помощь.
С ростом команды следи за балансом ресурсов.
Фактор автобуса (bus factor)
Сколько человек должно уехать в отпуск или «быть сбитыми автобусом», чтобы проект встал? Если ответ — один, у тебя проблемы. Если ответ — “я”, у тебя огромные проблемы.
Как решать:
Дублируй ключевые компетенции. Не замыкай ключевые процессы на одном человеке.
Поощряй ротацию внутри команды. Не допускай появления специализации в команде, особенно среди разработчиков.
Делай «шадоуинг»: когда кто-то временно выполняет работу коллеги под его контролем, чтобы понять суть.
Создание доверия
Почему доверие — основа хорошей команды?
Доверие — это не про хорошее отношение между людьми. Это конкретная основа, на которой строится способность команды быстро принимать решения, брать ответственность и не бояться ошибок. Без неё любая попытка масштабировать продукт, улучшить time-to-market (время доведения задачи до релиза) или внедрить культуру экспериментов становится похожей на попытку строить небоскрёб на зыбучих песках.
Доверие снижает издержки
Когда в команде есть доверие, каждый член знает: его вклад важен, его не подставят, и можно сосредоточиться на работе, а не на самозащите. Это убирает десятки микроперепроверок, «страховочных» действий и многочасовых совещаний «на всякий случай».
Но не нужно путать доверие с наивностью. Если ты видишь, что кто-то не оправдывает доверие или злоупотребляет им, на это нужно обращать внимание и с этим нужно разбираться. Но не через дополнительный надзор, а через построение процессов взаимодействия. Ну и, конечно же, диалог. Вполне может быть, что человек просто устал и таким образом пытается обратить внимание на проблему.
Доверие позволяет открыто обсуждать проблемы и конфликты
Конструктивная обратная связь невозможна, если люди боятся друг друга. Команда без доверия либо избегает острых тем, либо скатывается в пассивную агрессию. Там, где есть доверие, можно спорить, не боясь потерять лицо, и вместе искать лучшее решение, а не «победителя».
Доверие даёт командный иммунитет
Сильные команды не разваливаются от первой неудачи или внешнего давления. Они могут пережить провал спринта, токсичного клиента, смену фокуса. Потому что знают: мы — не просто набор специалистов, а мы — команда. Хоть эта фраза и абсолютно клишированная, но как ещё донести мысль, что мы тут не просто задачки собрались позакрывать, я не знаю.
Как строить доверие?
Как продакт, ты находишься в уникальной позиции: ты не начальник, но от тебя ждут лидерские и стратегические решения. Поэтому создание доверия — это единственный вариант делать свою работу эффективно.
Будь предсказуемым
Доверие начинается с ощущения стабильности. Если ты сегодня поддерживаешь одно решение, а завтра полностью меняешь курс без объяснений — команда перестаёт тебе верить. Предсказуемость не означает «никогда не менять мнение», но означает, что у твоих решений должна быть логика, которую ты доносишь. Ключевое — доносишь.
Проговаривай причины своих решений и изменений.
Публично признавай ошибки — это не слабость, а сила.
Выполняй обещания.
Рассказывай о целях и контексте
Когда ты вовлекаешь команду в цели продукта и даёшь широкий контекст, ты не просто информируешь — ты приглашаешь к соучастию. Люди начинают понимать, зачем они делают задачу, как она влияет на пользователя и какое решение будет «правильным».
Рассказывай команде о квартальных и годовых планах.
Начинай описание задач не с «надо сделать», а с проблем, которые мы решаем и почему мы их решаем.
Рассказывай команде о метриках продукта и о том, как они меняются со временем.
Демонстрируй эмпатию и уважение к разным ролям
Кросс-функциональная команда состоит из дизайнера, разработчиков, аналитика, тестировщика и т. д. У каждого свои боли, приоритеты, язык. Умение понимать и признавать это создаёт ощущение того, что «нас слышат».
Задавай открытые вопросы: «Как ты видишь эту фичу с точки зрения UX?», «Что тебя смущает в этом решении как разработчика?», «Думаю о таком решении. Как оно тебе?».
Благодари не только за результат, но и за усилия, особенно если они не всегда заметны. «Спасибо» — это бесплатно.
Слушай. По-настоящему.
Создавай ритуалы открытости и взаимодействия
Командная ретроспектива, демо, встречи 1:1 — это не просто календарные события, а точки роста доверия. Главное — не превращать их в формальность.
На ретроспективах у каждого должна быть возможность высказаться — публично или анонимно.
Делай демо не ради «отчётности», а как площадку для гордости и обратной связи. На демо стоит подсвечивать только плюсы и сообщать об успехах конкретных людей.
Вводи практику «вопрос недели» в Slack — пусть команда делится не только о работе, но и о себе. Разговоры только по работе никак не улучшают атмосферу в коллективе.
Защищай команду, но не скрывай от реальности
Хороший продакт не превращается в «переводчика боли» между бизнесом и командой. Он умеет честно доносить требования рынка, но при этом не даёт менеджменту обесценивать труд разработчиков и защищает командные интересы. Например, если в руководстве самодуры, которые распыляются в целях и фонтанируют идеями, нужно работать так, чтобы команда никогда этого не узнала, и приносить им стоит только то, что они реально будут делать. Это тоже про защиту.
Аргументируй приоритизацию с опорой на данные, а не «потому что сказал инвестор». Помни про важность контекста.
Отстаивай реалистичные сроки и ресурсы. Конечными исполнителями выступают члены команды, и нужно следить за разумной нагрузкой на них. Выгорание — это отстой.
Показывай бизнесу, что твоя команда — это партнёры, а не исполнители. Говори и показывай, как команда участвует в развитии продукта и насколько они важны.
Прозрачность и синхронизация
Что такое синхронные и асинхронные процессы?
Синхронные процессы — это взаимодействие команды в реальном времени. Совещания, звонки, живые обсуждения, стендапы, демо, ретроспективы — всё, где люди должны быть "в онлайне" одновременно.
Асинхронные процессы — это работа, где каждый взаимодействует в своём темпе. Это задачи в таск-трекере, документация, записи встреч, апдейты в Slack, комментарии в Figma и Notion. Они не требуют немедленного ответа.
Придерживаться какого-то одного типа абсолютно неэффективно, и нужно искать между ними баланс, потому что излишняя синхронность сжигает ресурсы, а асинхронность требует зрелости от каждого участника команды и других команд. Игра в одну из сторон приведёт либо к выгоранию от бесконечных митингов, либо к тормозам и недопониманию. Баланс даёт гибкость и масштабируемость.
Какие регулярные ритуалы приносят пользу?
Почти всё описанное ниже — это активности, которые предлагает вводить методология Scrum. Подробнее об этой методологии мы поговорим позднее.
Ежедневные митинги (стендапы)
Не для отчёта, а для фокуса и взаимопомощи. Про них подробнее — ниже.
Ключевые идеи: движемся от задач, а не от людей; говорим только по сути; не затягиваем встречу дольше, чем на 15 минут.
Груминг
Встреча для обсуждения и оценки задач. Продакт рассказывает команде контекст, проблему и ожидаемый результат, а команда ищет возможное решение и даёт оценку.
Активность может делиться на продуктовый груминг и технический. На продуктовом груминге продакт в формате монолога рассказывает о задачах и отвечает на вопросы, а на техническом груминге команда, как правило, уже без продакта, обсуждает техническую сторону этих же задач, намечает примерный план реализации задачи, дробит задачу на таски поменьше и т. д. Обычно технический груминг проводят на следующий день после продуктового, чтобы помнить максимум деталей по задачам.
Планинг (раз в неделю / раз в спринт)
Суть — договориться о целях, приоритетах и ожиданиях всех участников команды. Хорошее планирование — это когда команда сама предлагает решения, а не просто получает задачи сверху. По итогу планирования получается список задач, которые команда будет выполнять в следующий спринт, и с этим списком все согласны.
Ретроспектива (раз в 2 недели / месяц)
Пространство, где можно говорить честно. Что пошло хорошо? Что тормозило? Что пробуем улучшить? Главное — внедрять реальные изменения по итогам, а не ограничиваться только разговорами. У команды обязана быть встреча, где они могут высказаться. Хвалите, ругайте и ищите решения совместно.
Демо (раз в спринт / по готовности)
Позволяет показать результат другим командам, собрать обратную связь и напомнить себе, зачем мы всё это делаем. У команды появляется чувство завершения и гордости. Встреча помогает похвастаться успехами внутри компании (или даже за её пределами, но такой формат демо проводят редко).
Async апдейты по ключевым метрикам / инициативам
Например, раз в неделю продакт пишет в Slack/Mattermost или Confluence/Notion: что сделано, какие инсайты обнаружены, на чём фокус. Это помогает держать контекст и устраняет «непрозрачность» работы продакта.
Как организовать эффективные стендапы?
Эта активность имеет несколько имён: стендап, митинг, дейлик. Вне зависимости от названия, это всё одно и то же.
Может показаться, что стендап — простая штука: каждый всего лишь должен ответить на 3 вопроса — что делал, что будешь, что мешает. Но дьявол в деталях. Да, действительно, дейлик можно проводить в формате вопрос-ответ, но важно держать фокус на результатах. Не важно, что разработчик делал весь рабочий день. Важно, что он сделал.
Как сделать дейлик идеальным:
Ограничь по времени. 15 минут — потолок. Время истекло, а ещё не всё обсудили? Увы, надо расходиться. Такая строгость приучит соблюдать тайминг.
Фокус на ценности, а не на активности. Движемся от задач, а не от людей. Вот есть задача А. Что по ней сделано? Когда будет результат? Какие есть сложности? И так по каждой задаче из списка запланированных. Кроме уже готовых, естественно.
Нет статусам ради статуса. Учитесь говорить «по этой задаче пока ничего». Но нужно разобраться, почему задача застряла и когда она статус изменит
Формат — по ситуации. В офисе — у доски. Удалёнка — в Zoom или async в Slack (текст, видео, аудио). Но лучше всего работает голосовой формат дейлика. Созвонитесь и быстренько обсудите задачи.
Подключай дизайн, аналитику, тестировщиков. Стендап — не только для разработчиков. Это ваша общая миссия. Каждый причастный должен быть в курсе, что происходит в команде и с какими трудностями мы сталкиваемся. Но тут нужно быть аккуратным. Если, условно, аналитику точно будет не полезно на дейлике, то звать его не нужно. Только полезные встречи.
Смело говорите о блокерах. Если кто-то говорит «всё нормально», но буксует третий день с одной и той же задачей — это сигнал, что доверия и безопасности не хватает. Говорить о проблемах важно и нужно. Иногда достаточно людям напомнить, что они могут высказаться, чтобы они начали это делать.
Как давать и принимать обратную связь?
Без обратной связи команда топчется на месте. Без культуры принятия — ломается мотивация и рождается токсичность. Обратная связь — не бонус и не критика. Это топливо для роста. И как продакт, ты — один из главных носителей этой культуры.
✍️ Как давать обратную связь:
Обсуждай факты, а не людей
Не следует искать виноватых. Вместо "ты всё время тормозишь" — "последние два таска заняли дольше, чем мы планировали. Давай разберём, почему так, и как улучшить". Лучше начинать такую коммуникацию сначала в личных сообщениях или звонке на двоих. Выносить проблему на команду стоит только в том случае, если обсуждение один на один не помогло.
Регулярно
Не жди ретро, чтобы высказаться. Чем быстрее даёшь фидбек после события — тем выше шанс, что он будет услышан и принят.
Пытайся помочь
Подсвети проблему и уточни, как ты можешь помочь её решить или не допускать. Помни, что фидбек ты даёшь с целью усиления команды, а не для самоутверждения. Вот и будь готов её усилить своими руками/поступками, будь готов решать проблемы. Но не перебарщивай — ты не нянька. Ищи решение только для тех проблем, что мешают команде эффективно достигать результата.
«Плюс — дельта» вместо «сэндвича»
Старый трюк «похвала — критика — похвала» часто звучит фальшиво. Многие об этом подходе знают и замечают его применение. Лучше: "что получилось хорошо" и "что можно улучшить и как". То есть — похвали, обозначь проблему и предложи решение.
Формат — под человека
Будь гибким в общении. Не нужно решать за людей, как им удобнее вести диалог. Кому-то комфортно в личке, кому-то — голосом один на один. Спроси, как им удобнее. Вроде и мелочь, а это сильно добавляет к комфорту в общении.
✍️ Как принимать обратную связь:
Не обороняйся
Даже если что-то звучит резко — попробуй услышать суть. Фраза «спасибо, подумаю об этом» — отличный старт к рефлексии. Только реально подумай.
Уточняй
«Можешь привести пример?» — помогает понять контекст и избежать догадок. Но тут важно: уточнять нужно не для того, чтобы найти удачное оправдание, а чтобы реально разобраться в ситуации и себе.
Отделяй мнение от факта
Фидбек — это взгляд со стороны, не истина в последней инстанции. Но если сигнал повторяется — стоит задуматься.
Проси сам. Регулярно
Один из сильнейших вопросов, который ты можешь задать: «Что мне стоит начать, прекратить или продолжить делать, чтобы тебе было проще со мной работать?»
Люди охотнее дают обратную связь анонимно. Создай форму с тремя вопросами: какие положительные стороны, что можно улучшить, комментарий в свободной форме. Закинь форму команде и запроси фидбек. Ты можешь быть удивлён. И не всегда приятно.
Важно, чтобы обратная связь была добровольной. Ты запроси, но если никто не откликнулся — не настаивай.
Делай выводы видимыми
Если ты получил фидбек и что-то поменял — проговори это. Так рождается доверие: команда видит, что к её мнению прислушиваются, а ты готов к реальным изменениям.
Конфликты и решения
Как реагировать на напряжение и превращать его в продуктивный результат?
В конфликтах в команде, а они будут происходить как ни крути, не ищи виноватого. Кто виноват — не важно. Важно, как не допустить повторения ситуации, которая привела к конфликту. Направь все силы именно на поиск ответа: «как нам тут больше не оказаться».
1. Прими напряжение как сигнал, а не угрозу
Первый шаг — не пугаться напряжения. Чаще всего за ним скрываются не "плохие люди", а несовпавшие ожидания, непроговорённые роли или реальные риски, которые кому-то видны раньше остальных.
Сначала — сними эмоциональное напряжение. Переведи разговор в плоскость интересов, а не позиций. Не «ты против меня», а «давай поймём, что на самом деле важно». На удивление, люди совсем не против поделиться переживаниями, если их об этом попросить. И лучше это делать один на один.
2. Замени обвинение на любопытство
Вместо "Почему ты не сделал задачу в срок?" используй: "Что повлияло на тайминг? Есть ли системная причина?". Вместо "Ты не слушаешь команду" лучше сказать: "Как ты воспринимаешь обратную связь от команды? Что тебе помогает/мешает её учитывать?"
Когда начинается трение — не ищи виноватого, ищи контекст и смысл. Попробуй понять мотивацию поступков людей. Ситуация в действительности может оказаться не такой, как она выглядит со стороны.
3. Превращай конфликты в точки роста
Любой серьёзный конфликт — повод сделать ретроспективу, переосмыслить процессы и укрепить культуру. Конфликты подсвечивают точки роста для команды и тебя самого.
Конфликт — это не сбой, это возможность обновить систему координат. Но только если ты осознанно его отрефлексируешь. Старайся сделать из любого конфликта выводы.
Как говорить «нет» конструктивно?
Один из главных навыков продакта — говорить «нет» так, чтобы все продолжали с тобой работать. И это непросто. Особенно, если перед тобой фаундер, инвестор, топ-дизайнер или клиент с «срочным багом» в фиче, которая вообще не в приоритете.
1. «Нет» через причину, а не авторитет
Просто сказать: «Мы этого делать не будем» — это путь к вражде. А вот сказать: «Сейчас у нас цель — улучшить retention. Эта идея может мешать фокусу. Давай поставим её в backlog и вернёмся после релиза» — путь к сотрудничеству.
Люди готовы принять «нет», если ты объясняешь его через интересы продукта, а не через свою власть. Просто «нет» звучит грубо, а вот «нет» с аргументацией — уже нет. Тебе ничего не стоит объяснить свою мотивацию и дать контекст тому человеку, которому ты вынужден отказать.
2. Замени «нет» на «да, если»
Иногда конструктивное «нет» — это «да», но с условием.
Людям важно быть услышанными. Даже если ты говоришь «нет», оставь мостик для обсуждения в будущем.
3. Убери личное из отказа
Твоя задача — сделать так, чтобы «нет» не звучало для собеседника как «ты плохой». Ведь отказываешь ты не человеку, а тому решению, что он принёс.
Не «Ты опять предлагаешь что-то невпопад», а «На данном этапе фокус — другой. Давай сверим приоритеты».
Никогда не убивай инициативу. Даже если идея не подходит — поблагодари за вклад. С каждым отказом ты или строишь репутацию, или разрушаешь её.
Итог пятой главы
«Продавай» идеи команде — объясняй, зачем фича важна, а не просто что и когда делать. Объясняй проблемы и рассказывай о целях.
Вовлекай команду в решения — это повышает ответственность и мотивацию.
Доверие — основа работы — держи слово, признавай ошибки, защищай команду.
Строй процессы, а не туши пожары — системность важнее хаотичной многозадачности.
Проявляй инициативу — поднимай сложные темы до того, как они станут проблемами.
Микроменеджмент вреден — он убивает инициативу и снижает доверие.
Фокус на результат, а не на таски — оценивайте ценность, а не активность.
Создавай культуру ответственности — делегируй цели, а не задачи.
Документируй и визуализируй — письменный контекст снижает недопонимание.
Избегай "бутылочных горлышек" — распространяй знания и дублируй критичные роли.
Доверие снижает издержки — меньше контроля — больше скорости.
Поясняй решения и изменения — предсказуемость рождает доверие.
Встречи не для галочки — синки, ретро, демо — это точки роста, а не формальности.
Умей говорить «нет» правильно — аргументируй через цели продукта, а не авторитет.
То же самое в формате тг-канала. Сначала будет выходить там отдельным постами по чуть-чуть, потом здесь большой статьей.