Read the book: «Начинающему руководителю проекта в IT»
© Дмитрий Болесов, 2026
ISBN 978-5-0071-3510-8
Создано в интеллектуальной издательской системе Ridero
Введение
Зачем эта книга
Вы стали руководителем проекта. Возможно, вчера вы были разработчиком, тестировщиком, аналитиком или вообще пришли из смежной области. А сегодня вам поручили вести проект, и внутри крутится вопрос: «А я справлюсь?»
Эта книга не сделает вас идеальным PM за один вечер. Но она даст набор практических инструментов, которые можно применять с первого дня: как понять, чего хочет заказчик, как спланировать веб- или мобильный проект, чтобы он не развалился к релизу, как говорить с командой и стейкхолдерами, как замечать риски до того, как они станут катастрофой.
Здесь нет абстрактных теорий менеджмента. Есть конкретные сценарии, шаблоны, чек-листы и разборы реальных ситуаций из веб- и мобильной разработки. Всё — без таблиц, простым языком, с примерами, которые можно сразу использовать.
Что на самом деле делает PM в IT
Представьте себе мост. С одной стороны — бизнес, которому нужен результат: новый сайт, мобильное приложение, доработка существующего продукта. С другой — команда, которая этот результат создаёт: разработчики, дизайнеры, тестировщики, DevOps. PM — это и есть мост. Без него бизнес не понимает, почему «простая кнопка» занимает две недели, а команда не понимает, зачем вообще нужна эта кнопка.
PM не пишет код, не рисует дизайн, не тестит баги. PM делает так, чтобы все остальные могли делать свою работу эффективно. Это значит:
— Понимать цель проекта и уметь объяснить её команде так, чтобы все тянули в одну сторону.
— Согласовывать ожидания между заказчиком и командой, чтобы в конце не оказалось, что все понимали по-разному.
— Управлять сроками и ресурсами, не обещая невозможного и не впадая в микроменеджмент.
— Замечать риски раньше, чем они станут проблемами.
— Фасилитировать коммуникацию, чтобы важное не терялось в переписках и встречах.
Мифы и страхи начинающего PM
«Я недостаточно техничен» — самый частый страх. Вам не нужно уметь писать код. Вам нужно понимать, как устроен процесс разработки, уметь задавать правильные вопросы и доверять команде в технических деталях. В веб-проектах достаточно понимать разницу между фронтендом и бэкендом, знать, что такое API и зачем нужен деплой. В мобильных — понимать, что iOS и Android требуют разных подходов, и почему релиз в App Store занимает больше времени, чем в Google Play.
«Меня не будут слушать, потому что я не разработчик» — вас будут слушать, если вы прозрачны, честны и защищаете команду от хаоса. Разработчики ценят PM, который не обещает заказчику невыполнимого и не заставляет делать бессмысленную работу.
«Всё сломается в последний день» — и это случится. Но если вы планировали риски, у вас будет план Б. Если нет — будет паника. Эта книга как раз про то, чтобы план Б был.
Как устроена книга
Каждая глава — это самостоятельный блок, который можно читать отдельно, но лучше по порядку. Внутри глав вы найдёте:
— Примеры — разборы реальных ситуаций из веб- и мобильной разработки.
— Сценарии разговоров — что сказать и как, чтобы не обидеть и добиться результата.
— Чек-листы — что проверить перед важными этапами.
— Шаги — конкретные действия, которые можно сделать сегодня.
Начнём.
Глава 1. С чего начинается проект: первый разговор со стейкхолдером
Заказчик не знает, чего хочет, и это нормально
Веб- и мобильные проекты редко начинаются с чёткого технического задания. Чаще звучит что-то вроде:
— «Нам нужен новый сайт, современный, чтобы продавал».
— «Хотим приложение, как у конкурентов, только лучше».
— «Нужно переделать админку, текущая — кошмар».
Это не плохо. Это нормально. Задача PM на старте — не получить идеальное ТЗ, а помочь заказчику превратить расплывчатое желание в конкретные, измеримые цели. Для этого нужен разговор.
Вопросы, которые спасают проект до старта
На первой встрече со стейкхолдером задайте эти вопросы. Запишите ответы. Отправьте их заказчику после встречи с просьбой подтвердить — это ваша первая страховка от «я имел в виду другое».
О цели:
— Какую бизнес-задачу должен решить проект? (Не «нужен сайт», а «увеличить количество заявок с сайта на 30% за полгода». )
— Что произойдёт, если проект не запустится? (Помогает понять реальную значимость и приоритет.)
— Как вы поймёте, что проект успешен? Какие метрики?
О границах:
— Что обязательно должно войти в первую версию, а что можно отложить?
— Что точно НЕ должно быть в проекте? (Иногда это важнее, чем список «хотелок». )
— Есть ли существующие системы, с которыми нужно интегрироваться? (CRM, платёжные шлюзы, аналитика — частый источник сюрпризов в веб-проектах.)
О пользователях:
— Кто будет пользоваться сайтом или приложением? Возраст, устройство, контекст.
— Для мобильных проектов: какие платформы нужны — iOS, Android? Какие версии? Только телефон или планшет тоже?
— Для веб-проектов: какие браузеры и устройства нужно поддерживать? (Если заказчик скажет «все» — это красный флаг, нужно уточнять.)
Об ограничениях:
— Какой бюджет? Хотя бы вилкой — «до X» или «от X до Y».
— Какие сроки жёсткие, а какие гибкие? Есть ли внешняя дата (конференция, запуск сезона, договор)?
— Кто будет принимать результат и подписывать этапы?
О рисках и зависимостях:
— От чего зависит запуск, что вне вашего контроля? (Релиз в App Store, доступы к серверам, согласование дизайна у руководства.)
— Были ли раньше попытки сделать этот проект? Если да — что не получилось и почему?
Как зафиксировать ожидания
После первой встречи отправьте заказчику короткое резюме — одну страницу, не больше. Структура:
— Цель проекта — одним предложением.
— Что входит в первую версию — нумерованный список, 5—10 пунктов.
— Что НЕ входит — отдельный список, чтобы избежать иллюзий.
— Ключевые ограничения — сроки, бюджет, платформы.
— Следующие шаги — что и когда делаете вы, что нужно от заказчика.
Попросите подтвердить письменно. Это не формальность — это ваш щит на будущее, когда через два месяца заказчик скажет: «А мы думали, сюда ещё и личный кабинет войдёт».
