Хотелось написать заголовок “Как утопить любой проект?”, но получился бы уж слишком абстрактный. Поэтому в продолжение статьи Как получить экономическую целесообразность при внедрении VDI? напишу свои мысли по ИТ-проектному управлению. Дальше идёт сплошное IMHO aka поток мыслей.
Проект как плот
Для меня управление проектом – это плот, который несёт полезную нагрузку. Грузоподъёмность плота определяется качеством управления, командой, ресурсами, финансами. Затраты (финансовые; трудовые, включая способность к воплощению задуманного) на реализацию проекта – этот тот груз, который плот может осилить. Если мы плот перегрузим, то утопим судно.
Откуда берётся перегруз?
Предположим, что проектная команда отлично потрудилась и пообещала выполнить проект в сроки и бюджет с допуском +/- 10%, то есть максимальный проектный перегруз нашего плота составляет 10%: меньше можно, больше нельзя.
Неожиданно, как обычно, появляются попутчики со своим грузом.
Приходят “сетевики” и говорят, в проекте VDI требования к VSAN All-flash от 10 Гбит/с, заложите в проект модернизацию сетевой инфраструктуры ЦОДа. А ещё на рабочих местах местами старые свитчи и хабики стоят, сеть работает на 10 мегабит/с, надо бы АСО поменять. Да, и не забудьте, были заявки на прокладку СКС, но работы не были выполнены, накиньте в проект.
Приходят “энергетики”, говорят – если в ЦОД желаете новое оборудование, то надо бы ИБП-шник прикупить, на другую подстанцию заодно переключиться – заложите в проект.
Приходят “печатники”, в VDI сканеры и LPT-принтеры криво работают, надо бы на сетевые МФУ денежку предусмотреть.
Что в этом момент происходит с затратами (в попугаях):
| Статья затрат | Сумма |
| Замена МФУ | 2 |
| Прокладка СКС | 2 |
| Обновление АСО серверной | 2 |
| Электропитание серверной | 2 |
| Обновление АСО | 3 |
| Обучение персонала+ФОТ, оплата подряда (VDI) | 3 |
| Приобретение серверов (VDI) | 6 |
| Приобретение систем хранения (VDI) | 6 |
| Приобретение тонких клиентов (VDI) | 7 |
| Приобретение лицензий (VDI) | 10 |
| Итого VDI | 32 |
| Общие затраты | 43 |
Сумма на проект была 32 попугая, каждый приходил (возможно, к разным участникам проектной команды) с добавкой не более 10% и ни одно желание не превышало статей затрат внутри проекта, скорее всего эти хотелки принимались, ведь они все были направлены на обеспечение реализации проекта.
Что получили в итоге? – 35% превышения бюджета – плот утонул, проекту крышка.
Кто виноват и что делать?
При разборе ситуации, в большинстве случаев оказывается, что ситуация сложилась исторически и накопился технологический долг. Эти уважаемые “сетевики”, “энергетики”, “печатники” вовремя не запустили своих проектов модернизации и поэтому хотят добавить свой груз на плот (советую прочитать книгу “Одноминутный Менеджер и обезьяны” за авторством Бланшар Кеннет, Берроуз Хэл).
Самый простой вариант – этих доблестных людей информировать о проекте как можно раньше, дать возможность запустить свои проекты.
Из “на подумать” – сделать приоритизацию и оптимизацию задач. Например, проработать со списком рабочих мест и не ставить VDI туда, где нет сети. Вместо приобретения новых тонких клиентов рассмотреть конвертацию существующих системных блоков.
Вариант из книжки Джеффа Сазерленда по SCRUM* – делайте проект как можно быстрее и прекратите при достаточной реализации целей, это также может помочь сократить затраты, как минимум ФОТ.
Выводы
Соблюдайте границы проекта, не берите попутчиков с излишним багажом.
*Пример проекта из SCRUM (страница 153):
“Пару лет назад я услышал о компании-разработчике, применявшей Scrum, которая получила контракт по разработке программного обеспечения для крупной строительной компании на десять миллионов долларов. Стороны договорились о временных рамках в двадцать месяцев. Однако компания добавила в контракт примечание, гласившее: «Если строительная фирма захочет приостановить контракт в любой момент – а по договору она имела на это право, – в таком случае ей нужно будет выплатить лишь 20 процентов от стоимости остающейся стоимости контракта. То есть если программное обеспечение работало так, как нужно заказчику, он мог в любой момент остановить работу скрам-команды. Разработчики начали спринты длиной в один месяц. После первого месяца клиент перенаправил часть усилий разработчика, чтобы получить большую ценность. Во второй месяц ситуация повторилась. После третьего месяца клиент приостановил контракт, внедрил программное обеспечение и начал с ним работать. Они получили ту ценность, которая была им нужна. Давайте посчитаем, чтобы увидеть, кто остался в выигрыше. На самом деле и заказчик, и исполнитель. За первые три месяца контракта клиент заплатил команде полтора миллиона долларов. Приостановив контракт раньше времени, он обязан был выплатить 20 процентов от остававшихся 8,5 миллиона – это 1,7 миллиона. Заказчик заплатил 3,2 миллиона долларов за программное обеспечение, которое, по его ожиданиям, должно было обойтись в десять миллионов долларов, а исполнитель получил свои деньги на семь месяцев раньше. И они были не единственными, кто остался в выигрыше: компания взялась за проект с ожидаемой маржей прибыли в 15 процентов. Поэтому за первые три месяца на разработку они потратили 1,3 миллиона долларов. Но в результате получили 3,2 миллиона долларов. Их маржа прибыли выросла с 15 до 60 процентов. То есть увеличение дохода на 400 процентов. К тому же теперь, когда разработчики освободились, они могут браться за новые проекты.”