Руководитель проекта без иллюзий. Как начать, не утонуть в хаосе и довести проект до результата

1.6.2. КАК ВЫБРАТЬ?

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

— Присмотритесь к Scrum, если в проекте много неопределённости, заказчик готов регулярно смотреть результат и давать обратную связь, а продукт нужно быстро вывести на рынок хотя бы с минимальным функционалом.

Запомните:

— Нет одной «правильной» методологии. Есть методология, подходящая под конкретный проект, команду, заказчика и ограничения бизнеса.

— Методология нужна не ради красивого названия и не ради модного слова в презентации, а ради управляемости проекта.

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

1.6.3. ГИБРИДНЫЕ ПОДХОДЫ: WATERFALL + AGILE

На практике чистый Waterfall или чистый Scrum встречаются редко. Чаще используется гибридный подход. Например:

— Инициацию и высокоуровневое планирование проводят по классическому подходу: фиксируют бюджет, сроки, ключевые требования и Устав проекта.

— Исполнение разбивают на Agile-спринты по 2—4 недели, внутри которых команда работает гибко и регулярно показывает инкремент продукта.

— Сдачу результата и закрытие проекта снова формализуют: подписывают документы, закрывают договорённости, фиксируют итоги и уроки.

Гибридный подход даёт лучшее из двух миров: предсказуемость для бизнеса и гибкость для команды. Руководителю проекта важно одинаково уверенно работать и с формальными документами, и с гибкими командами.

1.6.4. ИСТОРИИ УСПЕХА РЕАЛЬНЫХ ПРОЕКТОВ

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

1. Проект: стартап по доставке еды (Agile/Scrum)

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

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

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

Ключевой фактор успеха: быстрый вывод MVP и регулярная обратная связь с рынком.

2. Проект: создание серверной на стороне клиента (Waterfall)

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

Здесь было мало места для импровизации. Требования к помещению, оборудованию, доступам, безопасности, срокам, поставщикам и ответственности нужно было определить заранее. Ошибка в планировании могла привести не к фразе «подумаем в следующем спринте», а к простою, лишним расходам и рискам для бизнеса.

Поэтому классический каскадный подход был уместен: заранее описать требования, согласовать план, проработать риски, синхронизировать подразделения и последовательно пройти этапы проекта.

Ключевой фактор успеха: чёткое планирование, контроль рисков и фиксированные требования.

3. Проект: оптимизация логистических маршрутов международной торговой сети (Scrum + Kanban)

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

Scrum помог двигаться итерациями и регулярно проверять результат, а Kanban дал прозрачность по потоку задач и узким местам. Команда могла быстро видеть, что застряло, где нужна помощь и какие изменения стоит вносить в первую очередь.

Такой подход помог сократить издержки, улучшить качество обслуживания клиентов и быстрее адаптироваться к рыночным условиям.

Ключевой фактор успеха: итеративность, прозрачность и визуализация потока работ.

Главный вывод: методология — это инструмент управления, а не самоцель. Хороший руководитель проекта выбирает подход под реальность проекта, а не пытается любой проект загнать в любимую схему.

1.7. ЧТО ДЕЛАЕТ ПРОЕКТ УСПЕШНЫМ?

Выше мы уже несколько раз говорили об успешном проекте. Но что вообще значит «успех» в управлении проектами?

В широком смысле успешный проект — это проект, который дал качественный результат, был принят заказчиком и не развалился по срокам, бюджету, объёму и ожиданиям.

Качество и одобрение клиента всегда завязаны на три вещи: объём, время и стоимость. Руководитель проекта не может волшебно угадать точный срок и бюджет с первого разговора, особенно если у клиента пока только «хотелки». Но он может начать с главного — определить объём.

Объём показывает, за что проектная команда отвечает, а за что не отвечает. Пока объём не зафиксирован, сроки и стоимость будут гаданием. Сначала нужно понять, какой результат нужен заказчику, какие функциональные блоки входят в проект, какие ограничения есть и что точно не входит в работу. После этого проект можно разложить на задачи, оценить ресурсы, заложить риски, учесть тестирование, согласования, отпуска, занятость людей на других проектах и только потом говорить о реалистичных сроках.

Проще говоря: сначала границы, потом задачи, потом оценка, потом график. Не наоборот.

Но есть важный момент: сроки можно нормально оценивать только тогда, когда задачи действительно поставлены. Не названы, не брошены в чат, не сформулированы на уровне «сделайте нормально», а именно поставлены.

Для руководителя проекта качество постановки задачи — это не мелочь и не бюрократия. Это основа управляемости. Плохо поставленная задача ломает оценку сроков, создаёт переделки, провоцирует конфликты и делает приёмку результата субъективной.

Поэтому перед передачей задачи в работу её стоит быстро проверить: достаточно ли она понятна, обеспечена ресурсами, связана с целью проекта, достижима и проверяема на выходе. Для такой проверки я использую собственный чек-лист — КРЕДО.

Авторский чек-лист КРЕДО

На практике проблема часто возникает не потому, что команда плохо работает, а потому, что задача изначально поставлена не как задача, а как пожелание, эмоция или общее направление мысли.

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

Для проверки качества постановки задачи я использую авторский чек-лист КРЕДО. Я разработал его как практическую доработку логики SMART/SMARTER, но адаптировал не под постановку личных целей, а под проектные, продуктовые и ИТ-задачи.

SMART и SMARTER помогают думать о цели: конкретна ли она, измерима ли, достижима ли, релевантна ли и ограничена ли по времени. Но в проектной работе одной цели мало. Задача должна быть не только понятной, но и обеспеченной ресурсами, связанной с причиной, достижимой в текущих ограничениях и проверяемой на выходе.

КРЕДО помогает быстро проверить, можно ли такую задачу отдавать в работу:

К — конкретная. Понятно, что именно нужно сделать и в каком контексте.

Р — ресурсно обеспеченная. Понятно, кто исполнитель, какие сроки, какие доступы, данные, материалы или другие ресурсы нужны для выполнения.

Е — единая. Задача связана с целью проекта, запросом бизнеса, изменением, требованием или другой понятной причиной. Она не висит в воздухе.

Д — достижимая. Понятны ограничения, риски, зависимости, блокеры и примерная оценка трудозатрат.

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

Плюс такого подхода простой: он снижает двусмысленность. Чем лучше поставлена задача, тем меньше переделок, споров, скрытых ожиданий и фраз вроде: «Я думал, нужно было сделать не так».

КРЕДО не является международным стандартом и не заменяет профессиональное мышление руководителя проекта. Это мой авторский рабочий инструмент, который помогает быстро проверить качество постановки задачи перед тем, как отдавать её в работу.

Полную рабочую версию инструмента я вынес в приложение А.12. «Чек-лист КРЕДО для постановки задачи». Используйте его при постановке задач команде, подрядчику, аналитику, разработчику или себе — особенно когда задача кажется «и так понятной».

Хочу вернуться к важному параметру, который упомянул выше — «Область применения», обычно она определяется на первом этапе. Наиболее важной целью области применения является то, что она устанавливает ограничения на функционал в проекте (а иногда и больше). Замечу, что всё, что находится за пределами области применения и допустимого объёма работ, может оказать негативное влияние на результат проекта.

Давайте опишу ещё одну проблему — появление новой и незапланированной работы в середине итерации или проекта. Подобное явление называют — «ползучесть области».

В гибких методологиях ползучесть области — действительно проблема: новые или незапланированные задачи добавляют прямо в середине итерации, вместо того чтобы сначала внести их в общий список задач проекта. Все гибкие методологии решают это посредством формальных процессов и церемоний. В методологии Скрам (Scrum), например:

1. Новая задача обычно должна вводиться только во время планирования Спринта (Sprint).

2. Новая задача, которая имеет приоритет над текущей задачей, требует раннего завершения текущего Спринта и возврата к планированию нового Спринта.

3. Новая задача в проекте должна быть приоритетной для Владельца Продукта в сотрудничестве с заинтересованными сторонами, так что ползучесть области на уровне проекта управляется договорённостями и соглашениями.

Немного поясню термины. В Скраме итерации называют «спринтами», они представляют собой фиксированные блоки работ (задач).

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

Можно смело сказать: лишние работы с высокой вероятностью ведут к провалу или, как минимум, к незапланированным расходам бюджета проекта. Но есть потребности бизнеса, которые игнорировать нельзя. В связи с этим предлагаю модификацию 1 и 2 пунктов из списка выше.

Если новая задача срочная и её нужно реализовать прямо сейчас, стоит оценить её и посмотреть, хватает ли запаса времени, чтобы добавить задачу в спринт и не сломать текущий план. Если запаса времени не хватает, нужно понять, какую задачу можно убрать и на её место поставить новую. Главное — чтобы продолжительность была сопоставимой и клиент согласовал замену. Более подробно Скрам (Scrum) стоит рассматривать отдельно.

Главное — не делать вид, что новые задачи сами аккуратно встроятся в проект. Так почти никогда не бывает. Любое изменение нужно честно оценить, обсудить и понять, что оно двигает: сроки, бюджет, объём работ или нагрузку команды. Тогда даже нестандартный подход будет работать лучше, чем формальная методология, которую все красиво называют, но никто по-настоящему не использует.

По поводу управления изменениями подробно поговорим в главе 7, а об успешности проекта — в главе 3.

1.8. РАБОТА БЕЗ УПРАВЛЕНИЯ ПРОЕКТАМИ. ПОУЧИТЕЛЬНАЯ ИСТОРИЯ

Давайте посмотрим, что происходит, когда у проекта вроде бы всё есть: договор, срок, бюджет, исполнитель и заказчик. Не хватает только нормального управления объёмом, требованиями и изменениями.

Нужно было разработать большую CRM-систему. По договору был зафиксирован год работ и фиксированный бюджет. Роль руководителя проекта отдали непрофильному специалисту. Требования заказчика почти напрямую превращались в задачи для разработки: без нормальной проверки, описания, декомпозиции, критериев приёмки и оценки влияния на сроки.

Разработчики реализовывали так, как понимали. Заказчик периодически смотрел сборки, выдавал новые пожелания и говорил: «Нет, мы хотели не это». Всё это ставилось в работу без оценки влияния на сроки, бюджет и объём.

Проблема стала очевидной только к концу срока. Бюджет закончился, заказчик отказывался принимать результат, команда была вынуждена переделывать уже сделанное, а стоимость проекта для исполнителя выросла примерно в три раза. И самое неприятное — пока команда спасала этот проект, она не могла нормально работать над новыми.

Этот проект не провалился в один день. Он проваливался постепенно: каждый раз, когда новое пожелание превращалось в задачу без оценки; каждый раз, когда результат принимался «на глаз»; каждый раз, когда никто не задавал неудобный вопрос: «Что это меняет в сроках, бюджете и объёме?»

Этот проект мог закончиться иначе, если бы с самого начала были понятны область работ, требования, сроки, правила изменения объёма и ответственный за управление.

Управление проектами не гарантирует идеальный результат. Но оно не даёт проекту тихо превратиться в бесконечные переделки, споры с заказчиком и сжигание бюджета. Когда в проекте есть понятные роли, планирование, контроль изменений и нормальная коммуникация, довести работу до результата намного проще.

Теперь перейдём к планированию — этапу, где хаос впервые начинают превращать в управляемый проект.

ГЛАВА 2. ПЛАНИРОВАНИЕ БЕЗ ИЛЛЮЗИЙ: КАК ПРЕВРАТИТЬ ИДЕЮ В УПРАВЛЯЕМЫЙ ПРОЕКТ

2.3. ОБЪЁМ ПРОЕКТА

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

— Какой продукт должен быть передан заказчику по окончании проекта.

— Обоснование проекта.

— Стандарты (могут быть стандарты оформления документации и/или стандарты реализации проекта).

— Цели, исключения, ограничения и прогнозы.

— Описание частей проекта (с указанием ответственных и сроков реализации).

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

Замечу:

Информация в документе актуальна на момент его создания. По мере развития проекта данные могут уточняться, поэтому документ не стоит считать раз и навсегда финальной версией. Корректировки можно вносить на любой стадии проекта через запрос на изменение документации с согласованием заинтересованных сторон.

Из написанного выше можно сделать вывод, что объём проекта — это основа, на которой будут построены все части плана реализации проекта. Чтобы получить полный и правильный документ, нужно собрать ключевую информацию.

Далее рассмотрим подробнее, что нужно собрать и какой должна быть последовательность сбора этой информации:

— Основная цель. Делается краткое описание цели проекта, описывается, почему проект является необходимым для заказчика и какие проблемы будет решать продукт (полностью или частично), который получится на выходе проекта. В уставе проекта должно быть предоставлено более подробное описание.

— Список задач. Перечень задач верхнего уровня, выполнение задач из этого списка будет происходить на протяжении всего проекта. В этот список также должны войти следующие задачи: составление перечня спецификаций, реализация проекта, тестирование продукта, полученного на выходе проекта.

— Вехи проекта. Контрольные или ключевые точки, важные для проекта события, которые будут происходить в определённые моменты времени. Представляются в виде план-графиков. План-график контрольных точек строится на основе списка задач, получаемых во втором пункте. План-график должен дать представление о первичной (приблизительной) оценке затрат всех существующих видов ресурсов, таких как финансовые и человеческие. Например, тестирование и приём функционала формы обратной связи должны быть окончены до 15 августа текущего года.

— Технические требования. Набор определённых требований, которым должен отвечать конечный продукт, чтобы быть качественным. Например, продукт должен быть кроссплатформенным и адаптивным (планшет, смартфон и тому подобное).

— Исключения. Определить, что из предполагаемых требований делать не будут, чтобы они не появились потом как новые требования. В любом проекте всегда будет много задач, которые заказчик или его представители захотят добавить в реализацию, но среди них могут быть те, что особо не влияют на продукт и те, что выходят за рамки проекта.

— Ограничения. Это важнейшие условия управления проектом, которые находятся в постоянном балансе между собой. К основным ограничениям относятся стоимость, объём и время. В результате их баланса формируется качество.

Такой подход называют «тройным ограничением», «треугольником ограничений проекта» или «треугольником управления проектом» (см. рисунок 2). В вершинах треугольника находятся ключевые ограничения: стоимость, объём и время. В центре находится качество как результат их баланса.

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

Далее хочу дать пояснения к условиям (ограничениям) и результату их баланса:

1. Стоимость — это бюджет, выделенный для реализации проекта. Он включает общую стоимость ресурсов и возможных затрат.

2. Объём — это границы проекта, то есть содержание работ и результатов: что должно быть получено в ходе проекта и что не входит в его рамки.

3. Время — это количество доступного времени для завершения проекта, то есть сроки реализации.

4. Качество — это совокупность характеристик результата, которые позволяют ему удовлетворять установленные или предполагаемые потребности. В контексте управления проектом таким объектом могут быть результат проекта, отдельные поставляемые материалы, ресурсы проекта или проект в целом.

Указанные ограничения часто соперничают между собой. Изменение одного из них приводит к изменению других. Например, сокращение сроков может потребовать уменьшения объёма или увеличения стоимости. А уменьшение бюджета может привести к увеличению сроков, сокращению объёма или снижению качества. Эта связь ограничений показана на рисунке 2.

Рисунок 2 — Треугольник управления проектом