Как (не) утопить проект VDI?

Хотелось написать заголовок «Как утопить любой проект?», но получился бы уж слишком абстрактный. Поэтому в продолжение статьи Как получить экономическую целесообразность при внедрении 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 процентов. К тому же теперь, когда разработчики освободились, они могут браться за новые проекты.»

Запись опубликована в рубрике Статьи. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *