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