Когда застройщик создает план будущего здания, он должен прописать все его спецификации до того, как заложен фундамент, — регламент, от которого нельзя отступать. Невозможно построить фундамент, а уже потом решать, сколько этажей оптимально сделать, пять или двенадцать. В противном случае вся затея может рухнуть, причем в прямом смысле.
В IT все обстоит наоборот. Да, в начале проекта пишется ТЗ и создаются прототипы, но в процессе работы все может поменяться — например, если у клиента появилась новая услуга, под которую нужно создавать новый раздел на сайте. Управление проектами в IT — это работа в ситуации неопределенности почти по умолчанию.
Менеджер проекта — это человек, который отвечает за него с момента встречи с клиентом до сдачи результата:
- общается с заказчиком
- планирует ход проекта и бюджет
- ставит задачи команде
- контролирует их выполнение
- принимает результаты работы и презентует проект заказчику
Все эти процессы во многом зависят от выбора метода управления проектом. И неопределенность начинается уже на этом этапе, и предугадать, какой способ подойдёт лучше, здесь непросто уже на старте.
Выбор методологии
Способов управления проектами существует очень много, но среди основных выделяют водопад (waterfall) и Agile. Хотя изначально agile — самостоятельная методика, этим термином часто обозначают все гибкие модели: скрам, канбан, скрамбан и другие, отличные от классического «водопадного» типа.
Водопад — это классическая модель управления с линейной последовательностью этапов, когда один следует за другим каскадом (отсюда и название методики). В этой модели есть фиксированный список задач, который не должен существенно меняться в процессе выполнения. Иначе говоря, все идет по плану.
Мы в Toimi используем водопад для стандартных проектов, где изначально понятен список задач, примерные сроки и есть фиксированный бюджет — такие, как онлайн-магазин или каталог услуг.
Но большие нестандартные проекты сложно спрогнозировать целиком на старте — для них лучше подходят гибкие методы, когда содержание каждого этапа может меняться от месяца к месяцу. То есть пока идет работа над одним пулом задач (в скраме это называется спринт), мы одновременно согласовываем сроки и содержание следующего спринта. В классическом скрам-подходе каждый спринт длится две недели, но в реальности компании часто формируют сроки исходя из объема задач.
Такой подход дает большую гибкость в работе и позволяет подстраиваться под внешние обстоятельства. Например, если в процессе доработки сайта клиент хочет запустить доставку, ему достаточно обозначить приоритет этой задачи. Тогда подрядчик запланирует ее на следующий спринт — а не через условные полгода после завершения остальных этапов.
Кроме того, гибкие методики управления проектами подходят для проектов с долгим процессом согласования. Это актуально для крупных корпораций, где каждое изменение требует подтверждения целого круга руководителей. В классической модели такая работа растягивается надолго, зато гибкий подход позволяет согласовывать один этап одновременно с работой над следующим.
Проблема переговоров
Во многих случаях выбор методологии управления проектами зависит от заказчика. Если клиент разбирается в ИТ и глубоко погружен в проект, он может участвовать в управлении процессами и приоритизации задач — то есть работать по гибкой модели. Но часто компании приходят с запросом на фиксированную оплату, которая предполагает классический подход. У этого требования есть веские основания: руководителю нужно отчитаться перед акционером или гендиректором и запланировать бюджет. И так как подрядчик не может настаивать на выборе другой методологии, приходится вместе искать правильные решения.
Как выбрать методологию под конкретный проект
Единого правильного ответа нет — методология подбирается под три параметра.
- Определённость требований. Если техзадание фиксировано и вряд ли изменится — например, для лендинга или каталога — водопад экономит время на координации: команда просто идёт по плану.
- Скорость обратной связи от рынка. Если продукт нужно проверять на живых пользователях и часто дорабатывать — например, MVP нового сервиса — Agile-подход даёт возможность менять приоритеты каждый спринт, не дожидаясь конца проекта.
- Вовлечённость заказчика. Гибкие методики требуют регулярного участия клиента в приоритизации задач. Если у заказчика нет ресурса включаться каждые две недели, водопад с чётким ТЗ подойдёт лучше — даже для крупного проекта.
На практике многие проекты используют гибрид: фиксированный бюджет и укрупнённый план по водопадной модели, а внутри — короткие спринты для контроля хода работ. Это сохраняет предсказуемость для заказчика и гибкость для команды разработки.
Ошибка, которая одинаково дорого обходится в обеих моделях, — сменить методологию посреди проекта без пересмотра бюджета и сроков. Если водопад буксует из-за меняющихся требований, разумнее формально пересобрать план: заново декомпозировать задачи и пересчитать сроки.
В целом коммуникация с заказчиком в управлении проектами требует от менеджера хороших навыков ведения переговоров. Как правило, представление клиента о проекте сильно отличается от того, как видит это техническая команда. Для заказчика это результат, бюджет, продажи и лиды, которые он получит, а для разработчиков — конкретный пул задач по реализации. И объединить эти два видения должен именно проджект-менеджер. Его цель — найти точки соприкосновения и понять ценность проекта, чтобы совместно находить оптимальные решения. Выбор методологии во многом определяет, как выстраивается весь процесс разработки программного обеспечения — от планирования спринтов до финальной сдачи результата.