← Назад к вопросам

Передача проекта от другого менеджера

3.0 Senior🔥 151 комментариев
#Жизненный цикл проекта#Ожидания и мотивация#Работа с заказчиком#Требования и документация#Управление командой

Условие

Вас переводят на проект, который запустили месяц назад. Предыдущий менеджер уволился, оставив минимум документации.

Команда демотивирована, клиент недоволен текущим прогрессом. Вам нужно быстро войти в контекст и наладить работу.

Задание

  1. Какую информацию вы соберёте в первую неделю?
  2. С кем и о чём поговорите?
  3. Какие quick wins можете реализовать для улучшения ситуации?

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI23 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

План входа в контекст проекта за неделю

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

Информация для сбора в первую неделю

1. Техническое состояние проекта (День 1-2)

Артефакты:

  • Последние спринты (backlog, done, in progress) — что реально закрывается
  • Velocity: скорость разработки за последние 4 недели
  • Technical debt: есть ли список известных проблем в коде
  • Architecture overview: диаграмма компонентов, технический стек
  • Production issues: лог багов, ошибок, uptime
  • CI/CD pipeline: как часто падают деплои

Вопросы техлиду:

  • Какие задачи в в прогрессе блокированы и почему
  • Есть ли известные risks на следующие 2 недели
  • Какие инструменты используются (Jira, Slack, GitHub и т.д.)

2. Состояние требований (День 1-2)

  • Requirements document (или его отсутствие) — главный причина проблем
  • User stories: написаны ли acceptance criteria
  • Figma/Mockups: есть ли дизайн
  • Product roadmap: что планировалось на 3/6/12 месяцев
  • Bugs/Issues: невыясненные требования

Вывод: Часто демотивация команды — не в лени, а в том, что требования меняются каждый день, и никто не знает, что именно делать.

3. Клиентская ситуация (День 2-3)

Встреча с клиентом/PO:

  • Какие ожидания были изначально
  • Какие сроки обещаны
  • Что не устраивает в текущем прогрессе (конкретно!)
  • Какие вещи из scope самые критичные
  • Есть ли отзывы пользователей / метрики

Встреча с командой — отдельно (без клиента):

  • Что там реально происходит по их мнению
  • Какие blockers
  • Уходит ли на что-то много времени кроме разработки

4. Организационная информация (День 3-4)

  • Кто за что отвечает (Architect, Tech Lead, QA Lead)
  • Какой процесс планирования спринтов
  • Как часто стендапы, планирование, ретро
  • Есть ли document о процессе/best practices
  • Контакты всех ключевых людей

С кем поговорить и о чём

Встреча 1: Tech Lead (1-1, 1 час)

Цель: Понять техническое состояние и проблемы

Вопросы:

  • Какой текущий state системы на 10 баллов?
  • Какие компоненты самые нестабильные?
  • Сколько времени в неделю уходит на фиксинг production bugs?
  • Что можно улучшить в процессе разработки?
  • Есть ли areas, где нужна помощь? (Code review bottleneck, knowledge sharing)

Итог: Получить техническую дорожную карту на месяц.

Встреча 2: PO / Business Analyst (1-1, 45 мин)

Цель: Понять бизнес-требования и expectation-setting

Вопросы:

  • Какая главная боль клиента? (быстрота, качество, функции)
  • Что мы можем доставить в следующие 2 недели?
  • Есть ли блокирующие вопросы, на которые нужны ответы клиента?
  • Каков критерий успеха проекта?

Итог: Список из 3-5 quick wins, которые видимо улучшат ситуацию.

Встреча 3: Клиент (видеоколл, 30 мин)

Контекст: Представиться, показать, что вы берёте на себя ownership

Сказать:

  • "Я проанализировал проект. Я вижу, где проблемы. Вот что я планирую сделать в ближайшие 2 недели [quick wins]. Это поможет нам выправить ситуацию"
  • "Мне нужны уточнения по [2-3 вопроса]. Когда мы можем встретиться?"
  • "Я буду еженедельно отправлять вам status. Если что-то не нравится, скажите мне сразу"

НЕ говорить: "Предыдущий менеджер был плохой", обещания, которые не можешь выполнить.

Встреча 4: Team Sync (1 час)

Цель: Завоевать доверие, показать направление

Ты говоришь:

  • "Я хочу вас поблагодарить за то, что вы держали проект на плаву без менеджера"
  • "Я вижу, что есть проблемы [назови конкретные]. Это не про вашу производительность, это про процесс"
  • "Вот план, как мы выправим ситуацию [quick wins]"
  • "Я здесь, чтобы помочь убрать blockers. Если что-то вас тормозит — скажите мне"
  • "Следующая неделя будет жесткой, но я вижу свет в конце туннеля"

Важно: Будь честен. Команда чувствует фальшь.

Quick Wins для первых 2 недель

Это видимые улучшения, которые докажут команде и клиенту, что ты знаешь, что делаешь.

Win 1: Ясность в требованиях (3-5 дней)

Проблема: Часто люди пишут код в неправильном направлении

Решение:

  • Провести requirements review workshop (2 часа)
  • Выписать 5-10 самых неясных моментов
  • Получить ответы от клиента за день
  • Обновить acceptance criteria в Jira

Результат: Команда точно знает, что писать. Баги от неправильного понимания исчезают.

Win 2: Fix obvious bugs (2-3 дня)

Проблема: Есть известные баги, которые висят месяц

Решение:

  • Выписать всех известных bugs из production
  • Расставить priority: что влияет на UX больше всего
  • Дать разработчикам clear acceptance criteria
  • Закрыть топ-3 buga за неделю

Результат: Клиент видит, что мы фиксим его боли. Команда чувствует себя продуктивнее.

Win 3: Наладить процесс (День 1)

Проблема: Нет четкого flow: как задача попадает в backlog, как она вдвигается, как закрывается

Решение:

  • Установить Definition of Done: PR review, test, deployment
  • Сделать спринт-планирование ритуалом (вт/ср, 1.5 часа)
  • Включить daily standup (10 мин, но четко: что сделал, что делаю, что мешает)
  • Добавить демо (пт, 30 мин) — показать клиенту, что готово

Результат: Предсказуемость. Клиент видит progress еженедельно.

Win 4: Communicate progress (День 1 + еженедельно)

Проблема: Клиент не видит, что происходит. Строит worst-case сценарии

Решение:

  • Скопировать код из Jira в краткий еженедельный отчет
  • Каждую пятницу отправлять: что закрыли, что осталось, что планируем
  • Включить скриншот / видео работающего функционала

Результат: Клиент видит transparency. Растет trust.

Win 5: Персональные разговоры (День 2-5)

Проблема: Разработчики демотивированы неясностью

Решение:

  • Провести 1-1 с каждым разработчиком (30 мин)
  • Спросить: Что тебя раздражает? Чем я могу помочь? Какие навыки ты хочешь развивать?
  • Показать, что ты слышишь

Результат: Люди чувствуют, что менеджер не враг, а союзник. Моrale растет.

Метрики успеха за неделю

  1. ✓ Все ключевые люди проинтервьюены
  2. ✓ Клиент получил план улучшений
  3. ✓ Команда знает требования на следующие 2 недели
  4. ✓ Процесс (daily, planning, demo) работает
  5. ✓ Velocity не упала (даже с моральными днями)
  6. ✓ 1-2 quick win закрыты

Это не волшебство. Это simple management: communication, clarity, respect.

Передача проекта от другого менеджера | PrepBro