Как вы работаете с инженерами? Опишите ваш подход.?

Как вы работаете с инженерами? Опишите ваш подход

Взаимодействие PM с инженерами это центр разработки продукта. Плохое взаимодействие = срывы deadline, низкое качество, текучка.

Ключевой принцип: Уважение

Я уважаю инженеров потому что:

• Они делают логику реального
• Они видят technical constraints которые я не вижу
• Они знают code quality, performance, scalability
• Без них я просто человек с идеями

Самая большая ошибка PM: думать что они главнее инженеров. Неправда. Мы партнёры.

Мой подход по фазам

Фаза 1: До разработки (Research & Design)

Что я делаю:

1. Customer research (интервью с пользователями)
2. Формулирую гипотезу и требования
3. Пишу PRD (Product Requirements Document)
4. Делаю дизайн с дизайнерами

Что я НЕ делаю:

• Не пишу код
• Не диктую архитектуру
• Не говорю "это должно быть done за 3 дня" без обсуждения

Как вовлекаю инженеров:

• На ранней стадии (day 1, не день 14)
• Спрашиваю: "Это feasible? Сколько это займет? Какие risks?"
• Слушаю их feedback
• Меняю требования если инженеры скажут "нет"

Пример: Я: "Хотим добавить AI-powered recommendations" Инженер: "Это займет 6 недель, нужен отдельный ML team, надо train модель на данных" Я: "Шесть недель это много. Давайте пойдем меньшей дорогой: просто рекомендуем based on popularity (1 неделя). Потом улучшим ML". Инженер: "Отлично, это feasible в 1 неделю."

Фаза 2: Во время разработки (Execution)

Мой роль:

1. Clarity: убедиться что инженеры понимают что строить
2. Support: помочь remove блокеры
3. Visibility: знать progress
4. Communication: информировать stakeholders

Что я делаю:

• Еженедельные синки: знаю что на треке
• Daily standups: слушаю (не говорю, слушаю)
• Remove blockers: если инженер говорит "мне нужен дизайн approval" → я делаю это
• Не микроменеджмент: я не говорю "используй pattern X вместо pattern Y"

Как я НЕ работаю:

• ❌ Не требую обновлений каждый день
• ❌ Не жаловаюсь что медленно
• ❌ Не меняю требования каждый день
• ❌ Не говорю инженеру как писать код

Что я ценю:

• ✅ Инженеры которые говорят "это займет дольше чем планировали" рано
• ✅ Инженеры которые предлагают лучшие решения
• ✅ Инженеры которые thinking о performance
• ✅ Инженеры которые думают о future (scalability)

Фаза 3: После разработки (Launch & Learning)

Что я делаю:

1. Благодарю инженеров за работу (important!)
2. Анализирую метрики: работал ли фича?
3. Собираю feedback: что можно улучшить?
4. Делюсь learnings: "Вот что пользователи сказали"
5. Меню улучшений: вот что нужно фиксить

Важно: Если фича не сработала = это не вина инженеров, это вина моей гипотезы. Я говорю: "Мои плохой research, давайте улучшим вместе."

Как я строю доверие с инженерами

1. Слушаю их идеи

• Инженер говорит: "А может мы вместо X сделаем Y?"
• Я слушаю (не защищаю мою идею)
• Часто инженер прав

2. Признаю когда я неправ

• Я допускаю ошибки в анализе
• Я говорю: "Мне нужно это пересмотреть"
• Не боюсь выглядеть глупо

3. Защищаю их от руководства

• CEO: "Почему еще не done?"
• Я: "Это займет 6 недель, вот почему. Инженеры знают что делают."
• Я не кидаю инженеров, я их защищаю

4. Даю credit

• "Это была идея Миши из инженеров"
• Я не беру credit за все
• Инженеры видят что я честный

5. Уважаю их время

• Не приглашаю на лишние встречи
• Не задаю вопросы которые я могу answer сам
• Respect их deep work time

Как я коммуницирую

Документация:

• PRD должна быть ясна
• Не 50 страниц, а 5-10 страниц с мясом
• Acceptance criteria должны быть ясны
• "Done" должна быть defined заранее

Встречи:

• Еженедельный sync: 30 минут, планирование + blockers
• Daily standup: 15 минут, кто что делает
• Retro: 30 минут, что хорошо, что плохо
• Не more meetings!

Slack/Email:

• Я вопросы важные в синхронных встречах, не в Slack
• Slack для quick updates
• Не пинг инженеров в выходные

Как я работаю с инженерами которые сопротивляются

Сценарий 1: Инженер говорит "это невозможно"

• Я: "OK, почему невозможно? Давайте разберемся."
• Обычно есть способ, просто инженер не видит
• Или он действительно невозможно (тогда уважаю)

Сценарий 2: Инженер говорит "это займет месяц"

• Я: "Месяц это много. Давайте сделаем меньшую версию (MVP) за неделю, потом улучшим."
• MVP thinking это ключ
• Не все features нужны в день 1

Сценарий 3: Инженер говорит "это плохой дизайн"

• Я слушаю внимательно
• Часто инженер видит problems которые дизайнер не видит
• Я это комм в design team
• Мы находим компромисс

Ошибки которых я избегаю

❌ Ошибка 1: "Я знаю лучше"

• Я слушаю инженеров
• Я не диктую решения

❌ Ошибка 2: "Это срочно, нужна за 2 дня"

• Всё срочно не может быть
• Приоритизация это моя работа

❌ Ошибка 3: Менять требования во время разработки

• Это убивает моральу
• Если нужно менять → explicit conversation

❌ Ошибка 4: Не знать tech constraints

• Я не эксперт в code
• Но я знаю databases, APIs, scaling
• Я могу говорить на языке инженеров

❌ Ошибка 5: Не признавать hard work

• Спасибо это важно
• Публичное recognition еще важнее

Как я развиваю отношения

1. Lunch с инженерами: узнаю их как людей, не как resource
2. Спрашиваю их мнения: "Что ты думаешь о этом направлении?"
3. Даю им ownership: "Ты лид этого проекта"
4. Расту вместе с ними: если они grows, они остаются
5. Honesty: я честный о challenges и планах

Пример хорошей PM-Engineer relationship

День 1: ПМ: "Вот customer problem. Вот гипотеза. Вот PRD." Инженер: "Это хорошо, но я предлагаю другой approach." ПМ: "Покажи. Мне нравится твой approach, он лучше."

День 2-4: Синк каждый день. ПМ помогает remove blockers. Инженер work на high-quality. ПМ не микроменеджмент.

День 5: Ланч! Инженер горд, ПМ горд.

День 6: Результаты: +15% conversion. ПМ: "Спасибо Вася за отличную работу. Это была твоя идея что лучше." Вася: "Спасибо за ясные требования и поддержку."

Вывод

Хороший PM это не тот кто диктует. Это тот кто:

• Слушает инженеров
• Уважает их
• Защищает их от politics
• Дает им ownership
• Благодарит их
• Растет вместе с ними

Если инженеры тебя уважают → everything else работает. Если нет → ничего не работает.