Что такое управление проектами по веб-разработке
📌 Управление проектами по веб-разработке — это контроль процесса разработки ПО, веб-сайтов и веб-приложений от идеи до релиза. Также сюда входит постпроектное управление — обслуживание цифрового продукта после выпуска.
Цифровые продукты окружили нас: это онлайн-магазины, видеохостинги, соцсети, программы для созвонов, мессенджеры, любой сайт, сервисы — и наш WEEEK тоже.
В веб-продукте есть переменные:
- цели
- задачи — текущие и будущие
- команда
- ресурсы
- проблемы
Управление этими переменными — и есть управление веб-разработкой. Причём они актуальны и для разовых проектов, и для продуктовой разработки, когда развитие продукта продолжается постоянно.
В одиночных проектах важно выстроить систему мониторинга переменных, которая поможет прийти к заданному результату. С продуктовой разработкой сложнее — система должна быть долгосрочной и надёжной, учитывать множество внешних и внутренних факторов.
В гайде рассмотрим оба сегмента веб-разработки: проектный и продуктовый. Работа над каждым из них зависит от выбранной методологии — с них и начнём.
Методологии управления проектами в веб-разработке
Agile
Эта система ценностей считается основным для управления проектами по веб-разработке.
Главный принцип Agile — гибкость, которая помогает быстро реагировать на новые вводные, адаптироваться и перестраиваться. Ещё Agile культивирует постоянное взаимодействие команды с заказчиками, отказ от следования чёткому плану и снижение бюрократии.
Разработка сайта по Agile похожа на живой организм — во время работы происходят непредвиденные ситуации, приходят новые идеи, перекраиваются изначальные представления о продукте.
Все эти активности подхватываются командой, обсуждаются и берутся в работу. В непосредственной реализации помогают прикладные инструменты (или методологии) Agile — Канбан и Scrum.
Методология Канбан
Помогает превратить управление веб-разработкой в поток, где все задачи двигаются от формулирования до завершения.
В этом помогают Канбан-доски, где в колонках фиксируются этапы работы. Они могут быть такими:
- Бэклог — приоритизированный список всех задач
- К работе — здесь задача получает сроки и исполнителя
- В работе — всё, что активно разрабатывается прямо сейчас
- Развёртывание и запуск — означает, что сайт или фича готовы к выгрузке на сервер или хостинг
- Тестирование — в этой колонке задачу подхватывают тестировщики, ищут баги и ошибки
- PO/PM согласование — тут включаются владелец продукта и проджект-менеджер, чтобы принять финальное решение о готовности
- Готово — в этой колонке хранятся завершённые и согласованные задачи
✅ Канбан подойдёт для небольших проектов веб-разработки с неопределёнными сроками и объёмами работы и высокой динамикой изменений — когда часто меняются вводные и приоритеты.
Методология Scrum
Или фреймворк. Это чёткий подход к созданию цифровых продуктов, основанный на наборе артефактов и ритуалов. Scrum помогает структурировать работу кросс-функциональной команды.
Как и в Канбане, в Scrum принят итеративный подход. Но тут более строгая структура:
- Управление проектом разбивается на отрезки длиной в 1–4 недели — спринты
- Команда ежедневно собирается на встречи-дейлики, обозначает план работы на день и делится статусами о проделанном
- В конце спринта команда собирается ещё на две встречи — на демо продукта и ретроспективу
Процесс разработки по Scrum тоже раскладывается на Канбан-доске. Работа при этом делится поквартально. Проджект-менеджер распределяет фронт работ по колонкам: Q1, Q2, Q3, Q4, после чего начинается работа по спринтам.
Рабочий процесс распределяется на три колонки: К работе, В работе и Готово. Сначала команда принимается за задачи из первого квартала. Они уже приоритизированы и декомпозированы, внутри обозначены исполнители и дедлайны.
✅ Scrum подойдёт для проектов веб-разработки любого масштаба, где есть доля неопределённости в технологиях и требованиях к продукту.
Водопадная модель Waterfall
Полная противоположность Agile — планирование проекта происходит в самом начале и не подразумевает гибкости.
Для визуализации проекта по веб-разработки удобнее использовать диаграмму Ганта. На ней обозначаются ключевые этапы работы, которые при необходимости можно разделить на мелкие. Главное — строго сохранять последовательность выполнения задач!
Перечислим примерный алгоритм управления проектом по Waterfall:
- Разработка техзадания и определение требований
- Разработка дизайна сайта
- Вёрстка
- Разработка функциональной части сайта
- Тестирование сайта
- Релиз сайта
✅ Waterfall подойдёт для крупных проектов веб-разработки со сложной архитектурой, чёткими требованиями и сроками, понятным результатом, где можно прописать последовательность действий.
Critical Path Method (CPM)
Метод критического пути (CPM) — это последовательное выполнение ключевых задач. На каждую задачу запланировано конкретное количество времени — если суммировать её, можно высчитать точную продолжительность проекта.
В веб-разработке CPM помогает грамотно планировать сроки и приоритизировать задачи. Этот метод — антипод Agile, потому что приветствует чётко сформулированный план действий.
CPM удобнее визуализировать на диаграмме Ганта. Важно заранее сформулировать список ключевых задач и подзадач, определить продолжительность времени работы над ними и строго соблюдать дедлайны.
Такой подход сделает процесс работы прозрачным, а проджект-менеджер или руководитель смогут легко планировать сдачу проекта.
✅ CPM подойдёт для крупных проектов веб-разработки, где нужен чёткий прогноз по срокам. А вот стартапам или творческим проектам с высокой неопределённостью лучше выбрать что-то другое.
📎 Подробнее про Critical Path Method
5 шагов по управлению веб-разработкой
Шаг 1. Планирование: брифинг и разработка технического задания
Если речь о планировании отдельного проекта по веб-разработке, то работа начинается с построения плана реализации. Здесь для плана нужно собрать требования заказчика — провести брифинг.
Бриф позволит исполнителю оценить объём проекта, сроки и каким должен быть результат. А заказчик оценит скиллы исполнителя и сможет принять взвешенное решение о сотрудничестве.
Вот примерный список того, что можно уточнить в брифе:
- Цель проекта
- Целевая аудитория проекта
- Функциональность разрабатываемого продукта
- Сроки и бюджет
По итогам брифа формируется техническое задание, которое содержит формальные требования к цифровому проекту. ТЗ — залог того, что проект будет соответствовать ожиданиям заказчика.
ТЗ лучше хранить в общем доступе — например, в корпоративной базе знаний.
📎 Подробнее о техническом задании
В продуктовой разработке планирование лучше организовать с помощью дорожной карты.
Дорожная карта должна отвечать на вопросы — «Кто?», «Что?» и «Когда?». Чтобы ответить на них, нужно учесть запросы целевой аудитории, тренды рынка, имеющиеся ресурсы, сроки и так далее.
Глобально есть два вида дорожных карт:
- Каскадная дорожная карта (Waterfall), где информация по проекту отображается последовательно. Пока команда работает над одной задачей, нельзя приступать к следующей и откатываться на шаг назад
- Гибкая дорожная карта (Agile), где работу можно делить на циклы. То есть декомпозировать большие этапы на задачи — и каждой задавать цели, сроки и исполнителей. Работа ведётся параллельно, можно адаптироваться под обстоятельства и новые вводные от заказчика
Шаг 2. Организация рабочего пространства
Не будем фокусироваться на подробном описании этапов веб-разработки — лучше покажем, как её контролировать.
Организовать рабочее пространство удобнее на Канбан-доске либо диаграмме Ганта — зависит от методологии управления проектом.
Agile
Работая по Agile, можно организовать процесс в формате спринтов и визуализировать их на Канбан-доске.
Проджект и другие участники команды смогут ставить задачи, декомпозировать их, определять дедлайны, добавлять подробные описания и переписываться в комментариях. Для этого на Канбан-доске необходимо создать две доски — Бэклог продукта и Бэклог спринта.
На доске Бэклог продукта задачи распределяются поквартально — Q1, Q2, Q3, Q4. Для каждого квартала должна быть отдельная колонка.
Задачи в этих колонках — большие этапы, которые нужно разбить на мелкие части. Чтобы не запутаться, к каким этапам относятся задачи, можно добавить соответствующие теги.
Дальше работа будет выстраиваться на второй доске — Бэклог спринта. Сюда переносятся все большие задачи из Бэклога продукта. Названия колонок будут такими: К работе, В работе и Готово.
В первой колонке будут лежать все задачи из первой доски, которые нужно приоритизировать. В этом поможет разделение по кварталам.
Теперь большие задачи в колонке К работе нужно декомпозировать и начать работу над ними. Например, для сбора информации нужно определить цели и целевую аудиторию. Эти две подзадачи будут иметь свой срок, время на выполнение, приоритет и исполнителя.
Когда все данные в подзадачах обозначены, можно переносить их в колонку В работе. Далее по мере выполнения они переместятся в колонку Готово.
Waterfall или Critical Path Method (CPM)
Если команда разрабатывает сайт по Waterfall или Critical Path Method, удобнее организовать процессы на диаграмме Ганта.
Здесь, как и в Agile, необходимо определить ключевые этапы веб-разработки и разбить их на мелкие задачи. Внутри них нужно определить всё то же самое — исполнителя, дедлайн, приоритет, время на работу.
Главное отличие Waterfall и CPM от Agile в том, что задачи должны выполняться в строгом порядке. Для этого можно настроить блокирующую связь между задачами. Так работа будет выстраиваться последовательно — сделали первый шаг, только теперь приступаем ко второму.
Шаг 3. Детализация задач
Чтобы работа шла ровно и результат соответствовал ожиданиям, необходимо детализировать задачи. А именно:
- назначить исполнителя и сроки
- дать ссылку на ТЗ (или написать его прямо в задаче)
- собрать все артефакты и референсы
- поставить теги
- определить приоритет и время на выполнение
Для этого можно использовать готовые поля в задачах или добавлять собственные. А теги понадобятся, чтобы быстро находить задачи, соответствующие определённым этапам.
Важно, чтобы эти данные не потерялись и любой участник команды смог быстро найти всё по конкретной задаче.
Для встреч команды и других мероприятий, привязанных ко времени, можно настроить напоминания. Например, за 15 минут до дейлика, чтобы все вспомнили о встрече и отложили другие дела.
Шаг 4. Отслеживание процесса работы
Фильтры помогут верхнеуровнево отслеживать статусы и сроки всех задач. Можно настроить фильтр:
- По статусу — выполненные и невыполненные
- По исполнителям или авторам
- По приоритету
- По нужным тегам
- По значениям кастомных полей
В комментариях удобно обсуждать детали выполнения задач и фиксировать договорённости. Если произойдут отклонения, то участники команды смогут быстро сориентироваться, как и с чего начиналась работа.
Шаг 5. Анализ результатов
Этот шаг будет отличаться для разовых проектов и продуктовой разработки.
В проектной веб-разработке заказчик разово приходит с запросом собрать сайт или приложение. Нужны три вида отчётов:
- регулярный, по итогам недельного спринта
- по непредвиденным затратам, если вдруг что-то пошло не так
- финальный, когда продукт готов к релизу
По ним команда анализирует результаты — уложились ли в сроки и бюджет, где были проблемы, как их решили и достигли ли поставленной цели. Эти отчёты можно хранить в Базе знаний WEEEK.
В продуктовой разработке заказчик сотрудничает с командой вдолгую, не ограничиваясь одним продуктом. Каждый результат нужно оценивать с заделом на будущее, чтобы улучшать достигнутые показатели.
Рассмотрим две распространённых проблемы.
Проблема 1: команда не уложилась в сроки. К примеру, команда декомпозировала большую задачу на пять шагов, но этого оказалось недостаточно, и в спринт пришлось добавить ещё несколько подзадач. Команда потеряла время и не уложилась в сроки.
- Первое решение. В WEEEK есть WIP-лимиты, которые контролируют количество задач в колонке на Канбан-доске. Их можно выставить, опираясь на прошлый опыт в подобных проектах. Скажем, вместо семи задач можно было бы уложиться в пять или даже четыре.
- Второе решение. В WEEEK есть трекер времени, чтобы определять, сколько времени уходит на решение конкретных задач. Если для исполнителя был обозначен срок в 2 часа, а он уложился в 6, то трекер покажет это.
Проанализировать результаты проектов можно в сервисе Аналитика.
Здесь фиксируются показатели эффективности по проектам и отдельным сотрудникам — например, сколько задач выполнил дизайнер в определённый день. Ещё можно посмотреть количество завершённых задач внутри проекта и сколько времени ушло на работу над ними.
Проблема 2: расхождение в ожиданиях. Команда составила и согласовала бриф и ТЗ, ни разу не созвонившись с заказчиком. В результате он остался недоволен результатом. У него на руках была старая версия ТЗ, в которую он вносил правки, пока команда работала по другому документу.
Решение. Хранить бриф, ТЗ и другие важные для проекта документы можно в Базе знаний WEEEK. Заказчика можно пригласить в пространство как гостя и выдать ему нужные доступы — так он сможет просматривать документы и оставлять комментарии.
Управляем главным в тексте
- Управлять проектом по веб-разработке — значит организовывать и контролировать ход работы над проектом так, чтобы конечный продукт соответствовал поставленным целям
- Для успешной разработки продукта важно поставить чёткие цели и задачи, сформулировать и определить объём работ, наладить коммуникацию и взаимодействие, мониторить выполнение задач, управлять рисками и проводить промежуточные итоги
- Управлять проектами по веб-разработке можно с помощью методолгий Agile (Канбан и Scrum), водопадной модели Waterfall и Метода критического пути (Critical Path Method)
- Управление веб-разработкой укладывается в пять шагов: планирование, организация рабочего пространства, декомпозиция и детализация задач, контроль хода работы, анализ результатов
Подписаться 
