Бесплатный фрагмент - Начинающему руководителю проекта в IT

Введение

Зачем эта книга

Вы стали руководителем проекта. Возможно, вчера вы были разработчиком, тестировщиком, аналитиком или вообще пришли из смежной области. А сегодня вам поручили вести проект, и внутри крутится вопрос: «А я справлюсь?»

Эта книга не сделает вас идеальным 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 пунктов.

— Что НЕ входит — отдельный список, чтобы избежать иллюзий.

— Ключевые ограничения — сроки, бюджет, платформы.

— Следующие шаги — что и когда делаете вы, что нужно от заказчика.

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

Пример: расшифровка расплывчатой задачи

Заказчик говорит: «Нам нужно мобильное приложение для доставки еды. Как у X, но удобнее».

PM уточняет:

— Что значит «удобнее»? Что именно в приложении конкурента вам не нравится?

— Какие платформы нужны? iOS, Android или обе?

— Доставка только по городу или по всей стране?

— Оплата внутри приложения или при получении?

— Нужна ли система лояльности, промокоды, push-уведомления?

— Есть ли готовый бэкенд или его тоже нужно делать?

— Кто будет наполнять каталог блюд? Нужна ли админка?

— Какой бюджет и к какому сроку нужен MVP?

После встречи PM формулирует

— Проект: мобильное приложение для доставки еды, MVP.

— Платформы: iOS и Android (Flutter/React Native — техническое решение команды).

— В первой версии: каталог блюд, корзина, оплата картой внутри приложения, отслеживание статуса заказа, push-уведомления.

— НЕ входит в первую версию: система лояльности, отзывы, мультиязычность, веб-версия заказа.

— Срок MVP: 3 месяца.

— Ограничения: нужен готовый бэкенд или его разработка; нет дизайн-макетов — нужен дизайнер.

Разница между «как у X, но удобнее» и этим списком — это разница между провалом и управляемым проектом.

Глава 2. Команда и роли: кто за что отвечает и как договариваться

Кто в команде

Веб- и мобильные проекты обычно собираются из следующих ролей. В небольших командах один человек может совмещать несколько, но функции остаются теми же.

Продуктовый дизайнер (UI/UX) — отвечает за то, как продукт выглядит и как им пользоваться. В веб-проектах готовит макеты экранов, прототипы, адаптации под мобильные устройства. В мобильных — учитывает нативные гайдлайны (Human Interface Guidelines для iOS, Material Design для Android).

Фронтенд-разработчик — превращает макеты в работающие веб-страницы. Веб: HTML, CSS, JavaScript, фреймворки (React, Vue и т. д.). В мобильных проектах фронтендом часто называют клиентскую часть приложения.

Бэкенд-разработчик — пишет серверную логику, API, работает с базой данных. Отвечает за то, что данные приходят и уходят правильно.

Мобильный разработчик — пишет нативное (Swift/Kotlin) или кроссплатформенное (Flutter, React Native) приложение. Часто два разработчика — по одному на платформу, или один кроссплатформенный.

Тестировщик (QA) — проверяет, что всё работает. В веб-проектах тестирует разные браузеры и устройства. В мобильных — разные версии OS, размеры экранов, сценарии прерываний (звонок во время оформления заказа).

DevOps-инженер — настраивает инфраструктуру: серверы, CI/CD, деплой, мониторинг. В небольших проектах эту роль часто берёт на себя бэкенд-разработчик.

Аналитик — собирает и формализует требования, описывает пользовательские сценарии, составляет документацию. В небольших командах эту работу часто делает PM.

Как выстроить первые договорённости

На первой встрече с командой не нужно сразу загружать задачами. Нужно договориться о правилах игры. Вот минимум:

Каналы коммуникации:

— Где обсуждаются задачи? (Таск-трекер, чат, встречи.)

— Где принимаются решения? (Важно: «мы обсудили в курилке» — это не решение. Решение зафиксировано там, где все видят.)

— Как сообщать о проблемах? (Разработчик застрял на задаче два дня — это норма или повод для эскалации?)

Встречи:

— Какие встречи нужны и как часто? (Дейли, планирование, ретроспектива.)

— Кто готовит повестку? Кто фасилитирует?

— Что делать, если встреча не нужна? (Отменить. Без сожалений.)

Эскалация:

— Кто принимает решения, если PM и команда не согласны?

— Как и когда поднимать проблему к руководству заказчика?

— Что считать «красным флагом», требующим немедленного внимания?

Правило обратной связи:

— О проблемах сообщают сразу, а не в день дедлайна.

— PM не наказывает за честность — наоборот, благодарит за ранний сигнал.

— Обратная связь по работе даётся команде регулярно, а не только на ретроспективе.

Пример: сценарий встречи «знакомство с командой»

PM открывает встречу:

«Привет! Я — ваш PM на проекте доставки еды. Моя задача — чтобы вы могли работать без хаоса и перегруза, а заказчик получал то, что ожидает. Расскажите, как вам удобнее: какие инструменты, какие встречи, как сообщать о проблемах. Я не буду микроменеджить, но мне важно знать статус, чтобы защищать вас перед заказчиком».

Вопросы команде:

— С какими инструментами вам комфортно работать? (Jira, Trello, GitHub Projects — что угодно, главное, чтобы все согласились.)

— Как часто нужен дейли? Каждый день или через день?

— Есть ли что-то, что вас раздражало в прошлых проектах? (PM, который обещал заказчику без согласования с командой — частый ответ.)

— Кто будет оценивать задачи — вы сами, или мне нужно организовать отдельную встреку с оценкой?

PM фиксирует договорённости и отправляет в общий чат:

«Итак, договорились: задачи в Jira, дейли в 11:00, оценки дает разработчик, я согласовываю сроки с заказчиком только после вашей оценки. Проблемы пишем в чат сразу. Если что-то блокирует — тегаете меня».

Культура обратной связи

Обратная связь — это не критика, это калибровка. Правило простое: говорите о работе, а не о человеке. Не «ты медленный», а «задача, которую мы оценили в два дня, идёт четвёртый. Что мешает? Как помочь?».

Три правила, которые работают:

— Регулярность важнее формы. Лучше пять минут каждый день, чем час раз в месяц.

— Благодарите за честность. Разработчик сообщил, что не успевает — спасибо, что сказал сразу, давайте подумаем, что делать.

— Не копите претензии. Если что-то не нравится — скажите в течение недели, не ждите ретроспективы.

Глава 3. Планирование без перегруза: от идеи к плану

Минимальный набор артефактов

Для начала не нужны тяжёлые процессы. Нужны четыре вещи:

1. Цель проекта — одним предложением, понятным всем. Не «разработка веб-портала», а «интернет-магазин, который позволит оформлять заказы за 3 клика и увеличит конверсию на 20%».

2. Границы (scope) — список того, что входит в проект, и список того, что не входит. Без второго списка первый бесполезен.

3. Критерии приёмки — как мы поймём, что готово. Не «сайт работает», а «пользователь может зарегистрироваться, выбрать товар, оплатить картой и получить подтверждение на email. Время загрузки страницы — до 3 секунд. Работает в Chrome, Safari, Firefox, на мобильных — iOS Safari и Chrome Android».

4. План по вехам (milestones) — ключевые точки проекта, когда можно показать результат. Не план на каждый день, а 4–6 вех: «дизайн готов», «бэкенд API готов», «первая тестируемая версия», «релиз».

Как декомпозировать задачу

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

Пример декомпозиции для веб-проекта — интернет-магазин:

Большая задача: «Каталог товаров».

Разбиваем:

— Дизайн страницы категории (макет, адаптация под мобильные).

— Верстка страницы категории.

— Бэкенд: API для получения списка товаров по категории.

— Фронтенд: подключение API к странице категории.

— Фильтры и сортировка (отдельная задача, потому что сложная).

— Карточка товара — дизайн.

— Карточка товара — верстка.

— Карточка товара — бэкенд API.

— Поиск по каталогу — отдельная подзадача.

Каждую из этих задач можно оценить отдельно, и если что-то пойдёт не так, вы увидите, где именно, а не «каталог задерживается».

Для мобильного приложения — доставка еды:

Большая задача: «Оформление заказа».

Разбиваем:

— Экран корзины — дизайн.

— Экран корзины — реализация (Flutter/React Native).

— Экран выбора адреса доставки — дизайн.

— Экран выбора адреса — интеграция с картами.

— Экран оплаты — дизайн.

— Экран оплаты — интеграция с платёжным шлюзом.

— Обработка статусов заказа — бэкенд.

— Push-уведомления о статусе — настройка.

— Тестирование сценария «от корзины до подтверждения» на iOS.

— То же на Android.

Как оценивать сроки

Главная ошибка новичка — взять оценку разработки и прибавить немного «на всякий случай». Этого «всякого случая» всегда больше, чем кажется.

Правильный подход к оценке срока задачи: