Цитаты из книг автора «Алексей Минкевич»

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

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

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

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

связано с тем, что обычно при работе над задачей выясняются и уточняются новые данные, которые могут увеличить объем работ. Вдобавок могут сработать риски, что приведет к увеличению первоначально определенной трудоемкости. Распределение выглядит так (рис. 17). Наиболее вероятно (НВ), что мы выполним задачу за пять дней, но если повезет, то можем и за три. Если же что-то пойдет не так, то решение задачи может растянуться на девять дней. Таким образом, вероятность того, что задача будет выполнена ровно за пять дней, невелика. Именно поэтому при оценке нужно указывать интервал (рис. 18). Если мы говорим, что выполним задачу за пять дней минус 10% плюс 25%, то вероятность попасть в интервал существенно выше.

Характеристики методов оценок В разных ситуациях требуется разная точность оценки. Существует три категории точности: порядок величины (Rough Order of Magnitude, ROM), бюджетная (budget) и полная оценка (definitive). В таблице 3 отображена разница между ними. Точность оценки и предположения, на которых основывается оценка Каждая оценка должна содержать указание точности и предположения, на которых она основывается. Поэтому опытный руководитель проекта на вопрос, сколько времени у него сегодня займет обед, отвечает так: «50 минут, минус 5 плюс 10 минут, при условии, что кафе не закрыто на спецобслуживание». В таком ответе есть четкое указание на точность оценки и предположение, на котором она основана. Заметили ли вы, что точность оценки имеет разные значения в минус и в плюс? Все дело в распределении вероятности. Если выполнение задачи оценивается в пять дней, то вероятность выполнить задачу раньше ниже, чем вероятность задержки. На практике это

длительности каждого пакета в отдельности. Сумма оценок пакетов показывает общую стоимость и длительность проекта. Оценка начинается с самого нижнего уровня ИСР и идет вверх. Оценка по аналогам. Предполагает использование исторических данных по выполненным проектам. В этом методе за основу берется похожий проект, который компания уже выполняла в прошлом. Метод подходит, если у компании есть опыт работы над похожими проектами. Параметрическое моделирование. Оценка проекта производится при использовании модели с параметрами. Например, мы знаем, что помыть одно окно займет 1,5 часа. В офисе 14 окон. Следовательно, трудоемкость всего проекта по мытью окон в офисе считается так: 1,5 часа × 14 окон = 21 час. Экспертные оценки. Суть метода заключается в проведении интервью с одним или несколькими экспертами, обладающими опытом подобной работы. В итоге эксперт дает свою оценку, базируясь на собственном опыте и имеющейся на данный момент информации о проекте. Чем выше уровень эксперта, тем точнее обычно его прогноз. PERT (оценка по трем точкам). Похожа на предыдущий метод, но эксперт дает не одну, а три оценки: наиболее вероятную, пессимистичную и оптимистичную. Далее считают по формуле (рис. 16). Метод хорош тем, что корректирует наиболее вероятную оценку с учетом количества рисков, связанных с выполнением задачи. Если пессимистичная оценка не сильно отличается от наиболее вероятной, значит, исполнитель не видит больших рисков, связанных с задачей. Если наиболее вероятная оценка — неделя, а пессимистичная — шесть недель, то, скорее всего, у задачи есть серьезные риски. Анализ предложений поставщиков. Метод заключается в анализе предложений других поставщиков услуг. Для этого проводится тендер, участников которого просят оценить стоимость выполнения проекта. Допустим, пришло пять предложений: $80 000, $130 000, $140 000, $150 000 и $230 000. Далее отсекаются крайние значения, поскольку, скорее всего, они неадекватны ($80 000 и $230 000), а из оставшихся выводится среднее: (130 + 140 + 150) / 3 =140. Эта сумма и берется в качестве оценки стоимости проекта. Такой метод компании используют, когда нужно оценить проект в той сфере, где у них совсем нет или мало экспертизы.

Процесс оценки показан на рисунке 15. Допустим, менеджер узнал, с какой целью и точностью необходимо делать оценку, собрал детали проекта и создал соответствующую ИСР. Теперь нужно решить, каким методом оценки воспользоваться. Методы оценки При проведении оценки можно использовать один или несколько методов. Использование нескольких методов позволяет подтвердить правильность оценки. Оценка «сверху вниз». При этом методе разрабатывается первый уровень ИСР, и на базе прошлого опыта (реализованных ранее проектов) выполняется оценка крупных частей проекта. Затем полученные оценки складываются, и получается итоговая цифра. Оценка «снизу вверх». При этом подходе разрабатывается ИСР, детализированная до уровня пакетов работ. Далее проводится оценка стоимости и

Трудоемкость (Effort) — количество единиц труда, необходимое для выполнения задания. Обычно измеряется в человеко-часах. Длительность (Duration) — количество рабочих периодов, за исключением праздников, выходных и других нерабочих дней, необходимое для завершения одного пакета работ проекта (операции). Длительность обычно выражается в рабочих днях или неделях. Операции проекта могут быть двух типов: основанные на трудоемкости и основанные на длительности. Например, мы знаем, что помывка окон в доме занимает 16 часов — это операция, основанная на трудоемкости. Если один человек моет окна за 16 часов, то два работника одинаковой квалификации вымоют их за восемь. При добавлении ресурсов на операцию, основанную на трудоемкости, ее длительность уменьшается. Существуют операции, основанные на длительности. Например, тестирование программного обеспечения после внесения изменений в ядро системы занимает два дня. И это не зависит от того, три или четыре человека будут проводить тестирование.

Реестр обновляется после каждого промежуточного этапа проекта. В него вносится следующая информация: выявленные риски и их описание, включая причины их возникновения, триггеры и возможное влияние на цели проекта; результаты качественного и количественного анализа; согласованные стратегии реагирования для каждого риска и действия, необходимые для активации стратегий реагирования; кто «владеет» теми или иными рисками и несет за них ответственность. Вот пример реестра рисков для проекта по внедрению единого решения автоматизации бизнес-процессов в сети гостиниц (рис. 14). Контроль рисков У каждого риска должен быть человек, который за него отвечает. Это может быть любой член команды. Задача ответственного лица — наблюдать за триггерами, то есть событиями, которые могут спровоцировать наступление риска, отслеживать их приближение и убеждаться, что мероприятия по реагированию на риск выполняются. Задача руководителя — следить, чтобы процессы управления рисками работали. Выводы Управление рисками хорошо начинать во время создания иерархической структуры или сразу после того, как она готова. Когда у вас перед глазами есть список дел по проекту, вам гораздо легче идентифицировать риски, связанные с работами проекта. Работа с рисками помогает уточнить содержание проекта. Это как следующий уровень проработки дел проекта. От каких-то очень рискованных дел можно отказаться. Для надежного выполнения других работ что-то понадобится добавить. В случае, если мы принимаем стратегию снижения для рисков, направленная на доведение риска до приемлемого уровня работа должна быть включена в иерархическую структуру работ проекта, оценена и внесена в расписание проекта. Управление рисками — это не разовый, а повторяющийся процесс. Как часто вы будете его повторять, зависит от текущего состояния проекта, его новизны для команды и уровня лояльности к рискам в компании.