Как продакту работать с разработчиками

Принцип нулевой: уважение к работе

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

Боль без хороших отношений выглядит так: продакт приходит со срочной фичей, разработчик молча оценивает в три недели, продакт давит, разработчик молча халтурит, фича катится с багами, продакт винит команду. Через пару циклов у вас в команде партизанская война, ретеншен сотрудников падает, и всем плохо.

Главное, что нужно понять: разработчики — это не «руки», а соавторы продукта. У них больше контекста про код, ограничения и риски, чем у вас. Их роль — не выполнять ТЗ, а вместе с вами делать продукт.

Как писать ТЗ, которые не возвращают

Хорошее ТЗ отвечает на три вопроса:

1. Зачем мы это делаем. Какая боль, какая метрика. Без этого разработчик не сможет принять разумное решение, когда упрётся в развилку.
2. Что должно получиться. Юзер-стори, экраны, состояния, поведение в крайних случаях.
3. Как поймём, что готово. Критерии приёмки, метрика успеха, события для аналитики.

Плохое ТЗ выглядит так: «Сделать кнопку „Купить“ зелёной». Хорошее: «Юзеры не находят кнопку покупки на странице товара (CTR 1.2% против 4% в рынке). Гипотеза: цвет сливается с фоном. Меняем на зелёный из дизайн-системы. Метрика успеха — CTR кнопки. Критерий — кнопка отправляет событие buy_click со старыми параметрами».

Что обязательно проговорить ДО передачи в разработку:

• Все состояния: дефолт, error, empty, loading.
• Поведение оффлайн.
• Аналитика: какие события и параметры.
• Граничные случаи: что если строка пустая, что если число отрицательное.
• Локализация и дизайн на маленьких экранах.

Если разработчик возвращает ТЗ десять раз с уточнениями — это не он плохой, это вы недодумали.

Оценки и сроки: что с ними не так

Оценки в разработке всегда плывут, и это не баг, а фича. Сложно знать заранее, на что наткнётся разработчик в коде десятилетней давности.

Что работает:

• Делите крупные задачи на куски по 1–3 дня. Чем мельче, тем точнее оценка.
• Спрашивайте «что может пойти не так» — это вытаскивает риски.
• Закладывайте буфер 30–50% на оценку команды. Это не подушка для лени, это здравый смысл.
• Договаривайтесь не на дату «к 15 числу», а на «спринт N» или «в течение двух спринтов».

Что не работает:

• Давить на сроки. «Можно к пятнице?» работает один раз — потом разработчик начинает занижать качество, чтобы успеть.
• Оценивать самому. Оценка — работа того, кто пишет код. Ваше дело — приоритизация.
• Считать оценку обязательством. Оценка — это прогноз, не контракт. Если оценили в 3 дня, а заняло 5 — это норма, а не повод для разноса.

Если фича критична по дате — урезайте скоуп, а не сроки. Это всегда работает лучше, чем «сделайте быстрее».

Технический долг

Технический долг — это компромиссы в коде, которые ускорили релиз вчера и тормозят разработку сегодня. Хардкоды, костыли, отложенный рефакторинг, тесты, которые не написали. Долг — это нормально, без него продукт никуда не уедет. Но если его не отдавать — рано или поздно команда упрётся, и любая мелкая задача начнёт занимать неделю.

Как продакту относиться к техдолгу:

• Закладывайте 15–25% времени команды на техдолг постоянно. Это не «потом, когда будет время», это часть бэклога.
• Спрашивайте у тимлида и разработчиков, какие куски их больше всего беспокоят. У них есть список, поверьте.
• Не пытайтесь оценивать ROI каждой техзадачи. Часть техдолга — про предотвращение будущих проблем, ROI там сложно посчитать.
• Если разработчик просит две недели на рефакторинг — выслушайте обоснование. В 8 случаях из 10 это окупится через месяц.

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

Когда и как спорить

Споры с командой — норма. Плохо, если их нет: значит, никто не думает. Главное — спорить правильно.

Что работает:

• Аргументы, а не статус. «Я продакт, поэтому делаем так» — самое плохое, что можно сказать.
• Данные. Если есть метрика, исследование, результаты A/B — приносите. Без данных это просто чьё-то мнение против чьего-то мнения.
• «Не согласен, но делаем» — иногда так. У продакта final call по продуктовым решениям, у тимлида — по техническим. После обсуждения кто-то должен принять решение, и команда идёт делать.
• Возвращаться к решениям. Если через месяц видно, что было неправильно — признавайте и меняйте.

Что не работает:

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

Частые ошибки

• Микроменеджить. Спрашивать «как там задача?» три раза в день — путь убить мотивацию.
• Менять скоуп в середине спринта. Если фича уже в работе — не лезьте, кроме критических случаев.
• Игнорировать оценки и обещать заказчикам «сделаем за неделю». Через спринт это выльется в скандал.
• Не давать контекст. Без понимания «зачем» разработчик принимает решения, которые ломают продукт.
• Не приходить на демо и ретро. Это выглядит как «мне неинтересно, что вы делаете».
• Винить команду перед стейкхолдерами. Если фича не зашла — это решение продакта, а не команды. Берите ответственность.
• Не отмечать успехи. Релиз прошёл, метрика выросла — скажите спасибо публично. Это копится.

Связанные темы

• Как продакту работать с дизайнером
• Как продакту работать с QA
• Как продакту ставить задачи команде
• Как продакту разрешать конфликты в команде

FAQ

Нужно ли продакту уметь программировать?

Не обязательно, но полезно понимать базовые концепции: API, базы данных, фронт vs бэк. Это сильно улучшает общение и качество ТЗ.

Кто принимает финальное решение по техническим вопросам?

Тимлид или ведущий разработчик. Продакт принимает по продуктовым. Если границы пересекаются — обсуждаете и решаете вместе.

Что делать, если команда саботирует задачу?

Сначала разобраться, почему. Обычно это сигнал, что задача либо плохо обоснована, либо технически бессмысленна. Поговорите 1:1 с тимлидом.

Как часто проводить 1:1 с разработчиками?

1:1 с тимлидом — раз в неделю или две. С отдельными разработчиками — по необходимости, но регулярно стоит общаться, особенно с теми, кто делает ключевые куски.

Можно ли давить на сроки?

Один раз в год по реально критичной фиче — да. Постоянно — нет, это убивает доверие.

Как объяснить команде ценность продуктового решения?

Через данные и боль пользователя. «У нас 60% отваливаются на этом шаге, юзер-тесты показали, что причина X, мы хотим попробовать Y и измерить Z». Без чисел и контекста любая фича выглядит как каприз.

---

Готовьтесь к собесу на продакта — откройте тренажёр с 1500+ вопросами по аналитике и продукту.