Писать о провальных проектах всегда не просто. Особенно, когда надо честно проанализировать причину, а не просто показать на кого-нибудь пальцем.
С точки зрения традиционных подходов проект успешный, если он закончился в срок и в рамках отведенного бюджета. Но я бы сюда еще добавила удовлетворенность заказчика, потому что в нашем бизнесе просто подписать акты недостаточно. Хотелось бы, чтобы клиенты отзывались о компании положительно, и, в идеале, принимали референсы.
В данной статье я попытаюсь проанализировать факторы, приведшие к проблемам на одном проекте, и дам оценку тому, как я бы поступила в данной ситуации сейчас.
Итак, о проекте. Компания занималась производством и реализацией сувенирной продукции (под «производством» у них понималась только нанесение логотипов и надписей на закупленную «сувенирку»). Клиент работал на сильно переписанной 7.7 (кажется, изначально это была «Торговля и склад», но за несколько лет активной кастомизации от типовой конфигурации ничего не осталось). Доработка велась собственной ИТ-службой, двумя действительно хорошими программистами. К моменту, когда мы зашли на проект, они уже прошли курсы по 8ке и были готовы влиться в проектную команду.
Основной причиной перехода было постепенное «умирание» базы из-за объема: она занимала под сотню Гб (тут могу ошибаться), и еще имела несколько распределенных узлов: документы еле «ползали», стоимость материалов уже не считалась. А бизнес расширялся, и собственники опасались, что еще одного года база не переживет.
Хотя речь шла только об управленческом учете, окно для перехода в новую конфигурацию было очень коротким – два месяца: апрель-май. В остальное время шла закупочная компания и подготовка к массовой новогодней корпоративной «сувенирке» - основному доходу Заказчика.
В старой базе предприятие вело только торговый учет (включая логистику, CRM и т.д.), в новой они дополнительно хотели видеть реальную себестоимость заказов (с учетом производственных операций) и бюджетирование.
В то время требование: торговля + себестоимость + бюджетирование - означали УПП. Тем более, что мы в то время специализировались в основном на внедрении данного программного продукта.
Первую фазу внедрения – проработку Функциональной модели - мы начали в мае-июне. Уже сразу стало понятно, что программный продукт в части торгового блока не подходит им на 90%. У них было отдельно ведение клиентов и партнёров, деление номенклатуры на сегменты с разным ценообразованием для разных категорий покупателей. Были справочные адресные склады и подписки клиентов на события. И еще много чего, что в то время уже было частично реализовано в УТ11.
Наверное, сейчас бы я вовремя рассмотрела варианты с другими конфигурациями. Точнее, предоставила бы заказчику всю информацию, в том числе предложила запустить второе параллельное моделирование процессов на УТ 11. Да, это стоило бы им дополнительных денег, но позволило бы принять более осмысленное решение и, возможно, снизило бы риски внедрения. Не знаю, куда бы вывернул проект в таком случае (на нем хватало и других проблем). Но с тех пор я стараюсь, во-первых, во время признавать свои ошибки. А, во-вторых, вовлекать в процесс принятия решений руководство заказчика.
ФМ на УПП шел очень тяжело. Пользователи не видели нужного им функционала, и буквально все приходилось объяснять друг другу «на пальцах». В итоге концепт мы все-таки защитили, но он предполагал почти 200 доработок объемом под 4 тысячи человеко-часов. Бюджета на такое дело у них не было, так что от половины (!!!) доработок было решено отказаться, а оставшуюся часть поделить пополам с их ИТ-службой.
Даже объем в 1 тысячу часов кодирования мы на тот момент еще ни разу не «поднимали». Это сейчас уже понятно, зачем нужны интеграционные тесты, формализация требований к общим справочникам и так далее. Но в то время я просто решила набрать на проект побольше программистов (некоторые «выжившие» вспоминают то кодирование до сих пор).
На этапе разработки технических заданий руководство клиента решило, что согласовывать их будет именно ИТ-служба, а не конечные пользователи. Сейчас мы больше на такое не соглашаемся. Ставить задачу должны те люди, которые потом будут принимать систему. Но в то время это показалось хорошей идеей: два «технаря» по идее должны были быстрее договориться по поводу требований к функционалу.
Для проекта это было фатальной ошибкой: ИТ-служба ставила нам задачу так, как они понимали ее сами: с технической стороны, а не с точки зрения процесса. К тому же, как показал запуск, очень много моментов, которые они считали неважными, были упущены. Также люди, которые кодировали доработки 10 лет назад, уже просто частично подзабыли, как именно они должны были функционировать.
Все это «вылезло» на этапе первого контакта системы с реальными пользователями, и привело к 400м часов запросов на изменение (то есть почти 50% от нашего объема доработок). Примерно столько же «прилетело» и на ИТ-службу, что, конечно же, не улучшило наших отношений.
Но сначала, до нашего эпического «первоначального обучения ключевых пользователей» разразился кризис в самом кодировании: программисты мешали друг другу; в одни и те же справочники добавлялись одинаковые по смыслу реквизиты с разными названиями; накатывание одних доработок приводило к неработоспособности других. Причем, найти виновных было невозможно, потому что каждый кодировал свой кусок («к пуговицам вопросы есть?»).
Уже гораздо позже, по результатам полученного (через кровавые слезы) опыта у нас в фирме родился документ «Стандарты кодирования», в котором мы описали (и актуализируем до сих пор) основные принципы разработки.
Глобально с того проекта я вынесла правило «учись на чужих ошибках»: если ты чего-то не делал на проекте раньше, то сядь и подумай, что может пойти не так; поспрашивай народ на форумах, почитай переписку, литературу и так далее – в нашем бизнесе сложно придумать что-то действительно новое, чего раньше никто не делал.
Но в то время мы просто «бились головой о стену», съедая отпущенные на разработку часы и время. Своих проблем добавила и платформа, в которой от версии к версии хранилище работало все хуже и хуже: куски кода пропадали целыми блоками, уже протестированные доработки переставали работать; некоторые вещи пришлось реализовывать по нескольку раз. С тех пор мы с очень большой настороженностью относимся к любым обновлениям платформы в ходе проекта.
Разработку мы должны были закончить в январе, чего, конечно же, сделать не успели. Февраль-март ушли на доведение системы до ума и на интеграцию с доработками, которые сделала к тому времени ИТ-служба заказчика, наступавшая на те же грабли.
А в апреле мы совместно пошли сдавать систему ключевым пользователям, и это было мероприятие в стиле «я кинул атомную бомбу, и она жахнула…». Начались истерики, швыряния документов и бесконечные совещания.
Спасло меня в тот момент только наличие подписанных технических заданий (всегда прикрывай «пятую точку» бумажкой, ибо никто не знает, когда что выстрелит). Заказчик скрипел зубами, но платил за переработку. Правда, его лояльность быстро упала «ниже плинтуса».
Сейчас мы, конечно, уже так не работаем. За 15 лет работы в этом бизнесе я еще не встретила заказчика, который может на этапе ФМ или даже ТЗ полностью осмыслить будущее поведение системы. Все равно на этапе эксплуатации вылезают вещи, которые надо подправлять. В определенный момент я приняла этот факт как данность, и теперь просто закладываю в стоимость доработок примерно 20% на их «допиливание» на ходу. Клиенту проще один раз пережить большой бюджет, чем каждую неделю бегать к собственнику с допниками.
Также в ОПЭ я закладываю время на работу программиста: просто на отчеты или печатные формы, про которые все забыли на этапе ФМ, и прочие «бантики».
Нужно ли в таких условиях согласовывать ТЗ? Да, нужно, потому что с ним можно в любой момент остановиться, отметая откровенную «ересь».
На проекте с запросами на изменение мы провозились до середины мая. Дальше сдвигаться возможности уже не было, окошко «закрывалось». Приняли решение стартовать 20го мая, не смотря ни на что.
В первый же день прилетела вторая «атомная бомба»: как оказалось, выделенные в апреле ключевые пользователи тоже не владели полной информацией: были люди (а иногда и целые отделы), которые работали «чуть-чуть по-другому». GoLive Tracking рос как снежный ком, и в нем было 2 статуса: «исправить до завтра» и «исправить немедленно». Программисты (и наши, и их) работали по 14 часов в сутки, поедая часы на ОПЭ с экстремальной скоростью. В итоге заказчик «забил» на бюджетирование и «забил» на себестоимость. Весь бюджет был перенаправлен на доведение системы хоть до какого-то приемлемого состояния.
После 6-ти недель экстремального кодирования, часы закончились, и выделять на проект еще денег собственник уже был не готов. Довнедрение системы было поручено ИТ-службе, в итоге они ее постепенно довели до ума, и работают на ней до сих пор.
Акты нам подписали, но ни о каком положительном отзыве не могло быть и речи. Общий перерасход часов по всем работам составил 30%. Реальный перерасход – больше 50%.
Наверное, именно с этого проекта у меня и началась ломка сознания: изначально я выросла из программистов, потом перешла в консультанты, потом стала РП, но управление проектом воспринималась как побочная деятельность – ты, типа, берешь себе самый сложный блок, общую архитектуру, и заодно еще распределяешь между консультантами некий список задач.
На самом деле это плохо работает. При таком раскладе на одной чаше весов находится понятная, увлекательная и ощутимая работа по внедрению, а с другой – некая деятельность, которая в лоб не дает никакого прямого результата. Ну, ты один раз напишешь формальный «реестр рисков», второй раз, проведешь совещание с заказчиком по «статусу проекта». А потом на проекте постепенно начнут накапливаться вопросы, которые требуют перепроектирования, перекодирования и так далее. Ты все время что-то разруливаешь и перекодируешь, и все время занят. Ты уверен, что затягивание сроков и рост бюджета происходят по объективным причинам – ты же пропускаешь все решения через себя, и видишь, что заказчик со своей стороны не очень-то хочет что-то делать, консультанты «косячат», программисты выдают «г..нокод» и т.д.
Здесь надо себя просто переломить: основная функция РП – это двигать проект в нужном направлении и с нужной скоростью. Под «двигать» я имею в виду как своих спецов, так и Заказчика (то, что его сотрудники не горят желанием взваливать на себя доп.работу нормально – им за это редко доплачивают). В некоторых книгах по управлению проектам пишут, что РП на проекте вообще должен управлять только рисками: то есть постоянно прогнозировать (самому и с помощью проектной команды), что именно на проекте может пойти не так. И, самое главное, увидеть, что процесс где-то затормозился, объективно оценить причину и во время среагировать, чтобы не попасть в пресловутую ловушку «98-ми процентов».
В провале проекта почти всегда виноват именно его менеджер – в какой-то момент приходится это принять и начать работать над собой.
Закончить хочу словами Джо Мараско (за точность цитаты не ручаюсь): «проекты похожи на восхождение альпинистов – трудно планировать, важна слаженность команды и природа по определению сильнее тебя. Однако есть альпинисты, которые водят группы успешнее других».
Предыдующие публикации на тему управления проектами:
- Мотивация персонала //infostart.ru/public/605716/
- Как всё начиналось //infostart.ru/public/608547/
- Проектная команда //infostart.ru/public/612086/
- Проектная технология при внедрении 1С:ERP //infostart.ru/public/614725/
