Цитаты из книг автора «Сергей Дерцап»

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

Выводы Управление стоимостью проекта дает менеджеру данные, необходимые для принятия решений о невключении лишних работ в проект. Знание типов затрат проекта и базовых законов экономики помогает правильно оценивать его стоимость. Разработка бюджета проекта на основании базового плана по стоимости поможет избежать перебоев с его финансированием, так как можно спрогнозировать, сколько денег необходимо для достижения каждой ключевой точки. Управление освоенным объемом — прекрасный инструмент для оценки состояния проекта. На базе этого метода можно построить много полезных и информативных метрик.

Как правило, заказчик проекта выделяет бюджет не сразу, а поэтапно. Чаще всего следующий транш приходит после достижения заранее определенной ключевой точки — Milestone. До этого момента проект финансирует компания-исполнитель из своих средств. И чем меньше итерация работы (чем больше ключевых точек), тем чаще в компанию поступают деньги (рис. 49). Оценка эффективности расходования средств Понять, насколько эффективно расходуются деньги, можно разными инструментами. Один из них — метод освоенного объема. Метод освоенного объема (Earned value management) — это один из самых распространенных способов контроля при управлении стоимостью проекта. Он помогает руководителю отслеживать отклонения фактического объема выполненных работ и их стоимости от запланированных. Метод работает абсолютно для любых проектов в любой отрасли. Метод использует следующие показатели: PV (Planned value) — запланированная стоимость работ на рассматриваемый период времени; EV (Earned value) — запланированная стоимость фактически выполненных работ на рассматриваемый период времени, то есть освоенный объем; AC (Actual cost) — фактическая стоимость выполненных работ на рассматриваемый период времени. Чтобы подсчитать, насколько мы отстаем от плана или опережаем его, необходимо знать два индекса: SPI и CPI. SPI (Schedule performance index) — индекс выполнения календарного плана, говорящий нам о том, насколько мы вписываемся в запланированный график. Он используется для прогноза сроков завершения проекта. Рассчитывается по формуле: Если вы получили индекс меньше 1, то проект отстает от расписания. Если больше, то опережает. Если индекс равен 1 — значит, все идет по плану. При работе с этим индексом важно в первую очередь анализировать операции, находящиеся на критическом пути, что позволит понять, с опережением или опозданием выполняется проект в целом. CPI (Cost per performance) — индекс стоимости выполненных работ. Рассчитывается по формуле: Этот индекс иллюстрирует эффективность использования бюджета с точки зрения выполненных работ. Если показатель меньше 1, значит, тратится больше, чем было запланировано на этот объем работ. Если больше 1, то уровень затрат меньше, чем планировалось к этому времени. Если 1 — все идет по плану. Также можно сказать, что данный индекс показывает объем результатов на каждый вложенный доллар или рубль. Индексы могут серьезно обмануть менеджера, если использовать их неправильно. Например, если мы таким образом будем считать операции, не находящиеся на критическом пути, то можем получить весьма благостную картину, когда все индексы будут больше 1. В то же время может оказаться, что операции на критическом пути уже отстают от графика и перерасходуют бюджет, — следовательно, выбивается из него и весь проект. Хорошая практика — рассчитывать такие коэффициенты отдельно для критического пути и для проекта в целом: тогда можно получить объективную информацию о состоянии дел. Для закрепления материала советуем посмотреть наше видео с примером.

Базовый план стоимости проекта Базовый план стоимости проекта (Cost baseline) — это согласованная спонсором проекта версия бюджета, распределенная по периодам. Он не включает в себя управленческий резерв, и изменить его можно только через согласование со спонсором. Управленческий резерв (Management reserve) — это предусмотренные планом управления проектом средства, предназначенные для снижения стоимостных и временных рисков. Базовый план используется для сравнения фактических затрат, возникающих в ходе работ, с изначально запланированными. Разрабатывается он путем суммирования одобренных бюджетов для различных операций расписания работ, включая резерв на возможные потери (рис. 48).

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

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

Что делать, если проект опаздывает и не укладывается в расписание Мы разобрались с тем, что делать, если расписание проекта не укладывается в сроки еще на этапе планирования. А что делать, если уже идущий проект не вписывается в планы? Ответ простой: переделывать изначальное расписание проекта, используя те же методы. Здесь есть нюансы, которые нужно знать. У слома расписания, особенно на поздних этапах проекта, существуют негативные последствия. В нашей практике был вот какой случай. Для завершения работ проекта по разработке программного обеспечения требовалось два месяца, а остался только один. И неопытный менеджер предложил удвоить размер команды, чтобы успеть в срок. В подобных проектах это большая ошибка: после такого изменения производительность команды резко падает, потому что приходится отвлекаться на обучение новичков. Графически это можно проиллюстрировать следующим образом (рис. 45). Давайте разберем, что отображено на графике. Команда работает на своем плато производительности. При добавлении новых людей ребятам приходится тратить время на их обучение, и это ведет к потере производительности. На графике мы заштриховали эту потерю темным. Только через некоторое время новички смогут выполнять первые задачи самостоятельно — производительность команды начинает расти. Прирост производительности мы заштриховали светлым. Здесь главный вопрос — когда планируется заканчивать проект? Если окончание близко, то добавлением людей можно сделать только хуже. Если до завершения еще далеко, то улучшенная производительность увеличенной команды в какой-то момент перекроет время, потраченное на обучение новичков. То есть площадь прироста производительности (светлый штрих) будет больше площади потери производительности (темный штрих). В такой ситуации уже можно выиграть. Есть еще один вариант — прибегнуть к овертаймам и попросить команду поработать сверхурочно, но эта мера хороша лишь в качестве временной. В конце концов продуктивность сотрудников, месяц работающих в полторы смены, обязательно упадет. Команда устанет, и ее производительность рухнет. В худшем случае команда просто выгорит и потеряет интерес к проекту. Овертайм помогает увеличить продуктивность, но его лучше не внедрять дольше, чем на одну-две недели. В крайних случаях можно попросить команду поработать на выходных. Но не забывайте, что команде нужен отдых и энергия на новую рабочую неделю. Вместо рабочих выходных можно оставаться на несколько часов дольше в течение рабочей недели. Вышеперечисленные методы работают, и часто после адаптации расписания опаздывающий проект удается сдать в срок. Славянским народам в принципе свойственно умение в нужный момент мобилизоваться и очень эффективно справиться с горой накопившейся работы.

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

«Быстрый проход» сокращает сроки проекта, но часто приводит к дополнительным рискам и увеличению стоимости. В нашем примере, если разработчики в последние дни работы над проектом внесут в него серьезные изменения, тестировщикам придется начинать работу с самого начала, а все уже сделанное отправится в мусорку. Это как начать строить дом до того, как работы над фундаментом завершены, а потом понять, что фундамент недостаточно прочен и его нужно доработать. Проще говоря, придется разбирать все, что уже успели построить, переделать фундамент и потом начать строительство стен заново. Все это не добавляет хорошего настроения команде. Вряд ли кому-то понравится переделывать то, над чем он кропотливо работал неделями, особенно если до этого работать приходилось с овертаймами. Изменение подхода. Нужно посмотреть на проект и найти иной путь реализации. Представим, что в рамках проекта одна из задач — постройка беседки. Закупка стройматериалов и строительство отнимает неделю. Если нужно сократить сроки проекта, то мы можем обратиться в компанию, продающую готовые беседки. Таким образом мы можем получить беседку не за неделю, а за несколько часов. И далеко не всегда такой ход приводит к увеличению бюджета проекта. Самый яркий пример изменения подхода в IT — это отказ от написания собственного решения и покупка готового. Например, не разрабатывать систему управления программой лояльности, а купить готовую и проверенную временем, которая давно стала стандартом в области. Изменение подхода и покупка готового решения требуют от менеджера опыта и тщательности выбора. В противном случае можно потратить месяцы на интеграцию стороннего решения лишь для того, чтобы понять, что оно не подходит. Произвести переоценку зависимостей. Допустим, вы можете начать разработку ПО только после того, как купите мощный сервер. Это зависимость «Финиш — Старт». Дело в том, что сервер могут доставить только через три месяца. Может быть, не стоит терять это время и лучше попробовать начать разработку сейчас на том оборудовании, что есть, или арендовать сервер со схожими характеристиками? Вполне вероятно, что

После того как расписание построено, у вас есть дата завершения проекта. Если она всех устраивает, то менеджер утверждает расписание и принимается за работу. Очень часто бывает так, что проект не укладывается в желаемые бизнесом сроки, и тогда расписание нужно оптимизировать, чтобы проект был готов к определенной дате. Какие подходы может использовать руководитель проекта, чтобы сократить расписание? Есть четыре подхода: сломать расписание, «быстрый проход», изменение подхода и переоценка зависимостей. Сломать расписание (Crashing). Если один человек соберет яблоки в саду за десять дней, то два человека сделают это за пять дней. Таким образом, суть метода состоит в том, чтобы привлечь к проекту больше людей и выполнить его быстрее. Ломая расписание, менеджер смотрит на операции, лежащие на критическом пути проекта, и анализирует, можно ли выполнить их быстрее, если добавить людей в команду, — при условии, что у менеджера есть такая возможность. «Быстрый проход» (Fast tracking). Эта методика подразумевает сжатие расписания проекта с помощью полного или частичного распараллеливания операций, которые обычно выполняются последовательно. Например, обычно тестирование проводится после завершения разработки, но, вероятно, существует возможность начать тестирование за неделю до завершения разработки и тем самым завершить проект быстрее на неделю.