Project Manager в IT: как запустить IT-проект с нуля – полный цикл от идеи до MVP

По статистике, около 70% IT-проектов заканчиваются срывом сроков или выходят за бюджет. И главная причина этого – не «плохие программисты», а размытые ожидания на старте. Самый частый сценарий провала выглядит так: заказчик говорит «сделайте как там, ну вы поняли», PM кивает, разработчики пишут код полгода, а в итоге получают систему, которой никто не пользуется.

Как этого избежать? Ответ прост: не бежать в код, пока не готов проект. В этой статье я на реальном примере разработки CRM для сети фитнес-клубов разберу полный цикл запуска IT-проекта. Вы узнаете, какие документы нужно подготовить до старта разработки, как отстоять MVP перед заказчиком и почему хороший PM – это в первую очередь детектив и переговорщик, а не просто «человек с диаграммой Ганта».

Project Vision – цель, а не просто слова

Представьте ситуацию: к вам приходит владелец сети фитнес-клубов «FlexFit». У него бардак: администраторы сидят в Excel, теряют заявки, тренеры не видят расписания, руководство не понимает финансовую картину. Он говорит: «Сделайте CRM».

Ошибка новичка: записать эту фразу в Jira как задачу и начать искать разработчиков.

Правильное действие: открыть Notion и написать Project Vision. Это не просто «хотелка», а ваш «северный полюс». К нему вы будете возвращаться, когда заказчик попросит «добавить онлайн-оплату прямо сейчас» или «сделать приложение для телефона».

Я всегда оформляю Vision так, чтобы он отвечал на три вопроса:

• Зачем? (Бизнес-цель).
• Кто? (Целевые пользователи).
• Как поймём успех? (Измеримые метрики).

Для FlexFit я написал следующее:

• Цель: автоматизировать работу администраторов и тренеров, исключить потерю данных о клиентах.
• Пользователи: администраторы (основные), тренеры, руководство.
• Критерии успеха: время записи клиента сокращается с 5 до 1 минуты; количество потерянных заявок падает до нуля; руководство видит статистику по клубам за 5 секунд вместо 2 часов в Excel.

Анти-пример (как делать НЕ надо): «Мы разработаем современную CRM с кучей фич и красивым дизайном». Такая формулировка ни о чём. Если кто-то из команды предложит добавить модуль для массажного кабинета, вы не сможете сказать «нет», потому что в Vision этого нет. А если критерий успеха – «скорость записи», вы легко отклоните лишние запросы.

Сбор требований – техника «5 Почему» в деле

Следующий шаг – погрузиться в боли бизнеса. Тут важно запомнить правило: заказчик всегда предлагает решение, но плохо объясняет проблему. Он скажет: «Сделайте поиск по имени». А вы спросите: «Зачем?» – «Чтобы быстрее находить». – «Почему сейчас долго?» – «Потому что открываем файл и скроллим 500 строк».

Ваша задача – спуститься на уровень ниже. Я использую простую таблицу из трех столбцов: Что болит -> Желаемый результат -> Почему важно.

Для «FlexFit» мы собрали такой срез:

Фишка PM: Записывая «Что хотим получить», мы пока не говорим про кнопки и базы данных. Мы говорим про бизнес-результаты. Только когда таблица согласована с владельцем, мы задаём последний вопрос: «Какая функция решит эту проблему технически?». Из строки про Excel рождается форма добавления клиента и поисковик. Из строки про историю – карточка клиента.

User Stories – формула, которая спасает от недопонимания

Теперь переходим к главному документу, который поймут и бизнес, и разработчики. Техническое задание в стиле «реализовать CRUD для таблицы «users» – это провал для коммуникации. Используйте User Story. Формула:

Как [роль], я хочу [действие], чтобы [ценность].

Обратите внимание: в этой формуле нет технических терминов (API, БД, фронтенд). Это обещание обсудить детали позже. Для нашей CRM мы написали ровно 8 историй. Вот главный лайфхак: пишите истории только для основных ролей. Если у вас 10 администраторов и 2 тренера – не пишите истории для «старшего администратора», если он делает то же самое.

Примеры из нашего бэклога:

• Как администратор, я хочу добавить нового клиента, чтобы хранить данные о нём в системе.
• Как администратор, я хочу отметить посещение, чтобы счётчик занятий уменьшался автоматически.
• Как руководитель, я хочу видеть отчёт по активности за месяц, чтобы оценить работу клубов.

Один из важнейших шагов, который новички пропускают – Критерии приемки (Acceptance Criteria). Прямо в заметках к истории напишите конкретные условия. Для истории «Добавить клиента» критерии будут: форма содержит поля Имя, Телефон, Абонемент; после сохранения клиент появляется в списке; если телефон уже есть – система выдаёт предупреждение. Это снимает 90% вопросов на тестировании.

Бэклог и магия MoSCoW (или как сказать «нет» заказчику)

Когда 8 историй готовы, вы переносите их в Product Backlog. Это просто список всего, что нужно сделать. Но самое сложное – расставить приоритеты. Заказчик будет говорить, что «всё Must Have». Если вы согласитесь, разработка растянется на год, а выйдет сырой продукт.

Здесь я использую метод MoSCoW. Но я добавляю к нему жесткое правило: Must Have – не больше 60% от общего объёма.

• Must Have (Без этого – смерть): Добавление клиента, поиск, карточка с остатком, отметка посещения, авторизация (чтобы данные не воровали).
• Should Have (Важно, но можно через неделю после релиза): Расписание для тренеров, отчёт для руководства.
• Could Have (Приятный бонус): Экспорт в Excel, история посещений в карточке.
• Won't Have (Точно не сейчас): Мобильное приложение, интеграция с оплатой, массажный кабинет.

Как продать это заказчику? Я всегда говорю так: «Мы можем сделать всё, но, если мы сделаем оплату, мобильное приложение и массажный кабинет, вы увидите результат только через 6 месяцев. Если мы сделаем только Must Have – вы увидите работающую систему через 3 недели. Соберём обратную связь и доделаем остальное за следующие 2 недели. Выбирайте: деньги сейчас или фантазии через полгода». 99% заказчиков выбирают деньги сейчас.

Режем MVP без сожаления

MVP (Minimum Viable Product) – это не «сырая поделка». Это продукт, который решает главную боль заказчика и готов к эксплуатации. Для «FlexFit» мы оставили только 5 историй из 8. Мы убрали расписание и отчёты.

Почему? Потому что MVP должен проверять гипотезу. Наша гипотеза: «Если мы дадим администраторам быстрый поиск и учёт посещений, они перестанут терять клиентов и ускорят работу». Для проверки этой гипотезы отчёты не нужны. Их можно сделать через месяц. Тренеры пока могут смотреть расписание на доске, это терпимо.

Главный критерий выбора фич в MVP: фича должна закрывать одну конкретную бизнес-боль. Если фича просто «улучшает интерфейс» – она в MVP не попадает. Режем без сожаления. Помните: вы запускаетесь, чтобы быстро получить обратную связь и исправить ошибки, а не чтобы построить идеальный космический корабль.

Roadmap, который не врет

Roadmap – это дорожная карта. Я не люблю рисовать её с точными датами (например, «15 мая делаем релиз»), потому что разработка – это не стройка. Я использую подход Now / Next / Later.

• Now (Ближайшие 4 недели): Проектирование БД, написание бэкенда для 5 MVP-фич.
• Next (Следующие 4 недели): Подключение расписания, первые отчёты, тестирование.
• Later (Потом): Экспорты, улучшение дизайна, мобильная адаптация.

Этот подход спасает от стресса: если спринт задерживается на 2 дня, вам не нужно перерисовывать календарь и паниковать. Вы просто смещаете «Next» на чуть позже.

Планируем спринт – фокус на Sprint Goal

Мы используем Scrum. В начале спринта мы собираем команду и выбираем задачи. Но важнее задач – Sprint Goal (Цель спринта). Это то, ради чего мы просыпаемся на две недели.

Для первого спринта нашей CRM я поставил такую цель: «Сделать так, чтобы администратор мог авторизоваться, найти любого клиента и отметить его приход, а счётчик посещений уменьшался».

В спринт мы взяли:

1. Авторизация.
2. Добавление клиента (с проверкой дублей).
3. Поиск + карточка.
4. Отметка посещения.

Я всегда добавляю задачу «Подготовка среды» (сервер, репозиторий, БД). И никогда не забиваю спринт под завязку – оставляю 15-20% времени на форс-мажоры (баги, внезапные вопросы заказчика). Если разработчик говорит «я сделаю это за 3 дня», прибавляю ещё 1 день про запас.

Риски – о чём молчат джуниоры

Зеленые PM часто игнорируют риски, думая: «Зачем каркать? Всё и так хорошо». Профессионал же всегда моделирует сценарий «Что, если…».

Вот мой топ-3 рисков для такого стартапа (и стратегии их обхода):

1. Болезнь ключевого разработчика.
   Реакция: сразу договариваюсь с фрилансером, который готов подхватить. И требую, чтобы вся документация велась в актуальном состоянии. Bus Factor должен быть низким.
2. Заказчик звонит и просит «вот тут переделать» в середине спринта.
   Реакция: соглашаюсь, но говорю: «Мы это запишем. Но сейчас мы закончим спринт, а на следующем планировании поставим вашу задачу первой. Если она настолько критична, что ломает бизнес, мы остановим текущий спринт, но потраченное время уйдет в убыток. Вы готовы к такому сдвигу?».
3. Заниженная оценка сложности.
   Реакция: в оценку всегда закладываю +20% (коэффициент неопределенности). После каждого спринта мы на ретроспективе смотрим, насколько ошиблись, и корректируем следующие оценки. Это учит команду более точно прогнозировать.

Коммуникации – ваша валюта

PM тратит на встречи и отчёты примерно 50% времени. Это нормально. Важно – делать это правильно. Заказчик не хочет знать, какой фреймворк вы используете. Он хочет знать, вылетит ли он в трубу или его бизнес растёт.

Я готовлю статус-отчёт по формуле: «Сделано – Планы – Проблемы – Решения (нужны от вас)».

Плохой отчет (вода):
Мы пишем код, всё хорошо, скоро покажем.

Хороший отчет (факты):
За 2 недели: готов поиск и добавление. На следующей неделе стартуем карточку клиента. Заметили, что заказчик не отвечает на вопросы по полям абонемента – это стоп-фактор. Прошу утвердить список полей до завтра.

Такой отчёт занимает 15 минут, но создает впечатление абсолютного контроля. Заказчик видит, что вы управляете ситуацией, и доверяет вам.

Частые ошибки новичков (Q&A)

«Мы начали делать, а потом поняли, что архитектура не тянет нагрузку. Что делать?»
Ответ: значит, вы пропустили этап проектирования. Перед спринтом всегда проводите митинг с архитектором. Даже 2 часа разговора о том, как устроены таблицы, сэкономят неделю переписывания кода.

«Заказчик говорит, что наша CRM неудобная. Мы провалились?»
Ответ: это победа! Вы быстро запустили MVP и получили обратную связь. Если бы вы делали идеальный продукт год, вы бы узнали об этом через год. Теперь вы знаете, что править, и потратите на это 2 недели.

«Мне кажется, я трачу больше времени на таблички, чем на реальную работу».
Ответ: таблички – и есть ваша реальная работа. Документация – это единственный способ избежать хаоса. Если ваша команда из 5 человек может работать без документации – вы исключение. В 95% случаев без «табличек» через месяц начнется бардак.

Итог: ваш стартовый пакет – не архив, а оружие

Посмотрите, что у нас получилось. Два часа назад мы держали в руках одну фразу: «Сделайте CRM». Теперь у нас есть не просто папка с файлами, а система управления проектом, которая работает ещё до того, как написан первый коммит. Вот что я называю настоящим стартовым пакетом PM:

• Vision – наш компас. Если завтра заказчик позвонит с новой идеей, мы не гадаем, брать или нет. Мы сверяем с целью и критериями успеха. Если идея не приближает нас к «время записи 1 минута» – мы вежливо откладываем.
• Бизнес-требования – стенограмма боли заказчика. Это наш главный аргумент в спорах. Когда разработчик говорит: «Зачем нам эта кнопка?», мы открываем таблицу и показываем: «Вот здесь человек терял деньги. Кнопка возвращает эти деньги».
• User Stories и Acceptance Criteria – контракт с командой. Разработчик точно знает, что считать «готово». Тестировщик – что проверять. Никаких «а я думал, надо было по-другому».
• Бэклог с MoSCoW – инструмент торговли с заказчиком. Мы не говорим «нет», мы говорим «сейчас – вот это, остальное – в следующей очереди». И показываем приоритеты прозрачно.
• MVP – наша страховка. Мы не строим космодром, мы запускаем ракету-носитель, чтобы убедиться, что двигатели работают. А доработаем на орбите.
• Roadmap – честный календарь. Без обещаний «всё будет через месяц». Только фазы и вехи, которые мы готовы пересматривать каждые две недели.
• План спринта – не просто список задач, а цель, которая вдохновляет команду. «Администратор может обслужить клиента за минуту» – звучит круче, чем «сделать 5 сторис».
• Реестр рисков – наша подушка безопасности. Мы знаем, что делать, если разработчик заболеет, а сервер упадёт в пятницу вечером. Мы не паникуем – мы действуем по плану.
• План коммуникаций – расписание, которое не даёт проекту развалиться. Мы знаем, когда отчитываться перед заказчиком, когда собирать стендап, а когда – ретроспективу.

Главный секрет: этот пакет работает, только если он живой. Не закапывайте его в Notion и не забывайте. Возвращайтесь к Vision на каждом планировании. Пересматривайте риски на еженедельных синхронизациях. Обновляйте Roadmap, когда меняются приоритеты. PM – не архивариус, а дирижёр. Ваши документы – это партитура. Без неё оркестр сыграет фальшиво.

Что дальше? Kick-off – и вы в роли наставника

Когда все документы собраны, вы проводите Kick-off Meeting. Но не просто читаете слайды. Вы сажаете заказчика, разработчиков, тестировщиков в одну комнату (или Zoom) и делаете три вещи:

1. Показываете «до» и «после». Вот как сейчас работает клуб (Excel, хаос). Вот как будет после MVP (за минуту нашёл, отметил, пошёл дальше). Эмоции важнее цифр.
2. Фиксируете вопросы и сомнения. Разработчики спросят: «А как будем хранить телефоны?», тестировщики: «Что делать с дубликатами?». Записывайте всё – это уточнения к Acceptance Criteria.
3. Запускаете таймер. С этого момента начинается первый спринт. Ваша роль меняется: теперь вы не создаёте документы, а убираете препятствия. Отвечаете на письма заказчика, договариваетесь с дизайнером, находите доступ к тестовому серверу.

Через две недели у вас будет готовая рабочая версия – пусть не идеальная, но реальная. А через месяц вы увидите, как администраторы сами просят добавить «ещё вот эту фичу». Это и есть успех: система жива, ею пользуются, а вы получили обратную связь, которую можно превратить в следующие истории.

Теперь вы знаете, как запустить проект с нуля. Не бойтесь, что в первый раз будет сложно. Берите эту статью как чек-лист, открывайте свой Notion и делайте. Ошибки неизбежны, но каждая ошибка с этим пакетом – это урок, а не катастрофа. Удачи на старте!