IT-блоги. Фэйлы системного интегратора…
Пользователь сервиса LiveJournal Сергей Горшков (ЖЖ serge_index), технический директор в Центре информационных технологий index.art (Екатеринбург), оставил в своем блоге запись под названием «Ошибки в управлении проектами»:
«На прошлой неделе в нашем городе состоялось мероприятие под названием FailConf – конференция, на которой руководители разных IT-компаний рассказывали о своем опыте управленческих ошибок. Сам я туда, к сожалению, не попал (жалко тратить субботу на деловые мероприятия, ничего не поделаешь). Но тема, безусловно, интересна. Так что расскажу о своих собственных ошибках в управлении проектами по созданию корпоративных информационных систем. За пять лет занятий этим делом кое-что, как говорится, наболело.
Мы гордимся тем, что фатальных ошибок в этой нашей деятельности, пожалуй, не было. То есть можно вспомнить буквально считаные проекты (из почти сотни), когда мы взялись делать информационную систему и не довели ее до эксплуатации. А вот ошибки, связанные с эффективностью проектов по деньгам и времени, были. Их можно поделить на два класса: связанные с взаимодействием с клиентом и связанные с персоналом, исполнителями работ. В случае с персоналом причины довольно очевидны и сводятся к неспособности (невозможности) руководителя проекта обеспечить мотивацию, вовремя принять решение об увольнении неэффективного сотрудника, переоценке возможностей программиста в плане самостоятельной организации своей работы.
Ошибки, связанные с взаимодействием с клиентом, более разнообразны. В начале творческого пути причины таких ошибок также были банальны: недооценка объема работ, неумение найти общий язык с клиентом (понять, что именно ему нужно, и объяснить, каким образом предлагаемое решение удовлетворит его потребности). Но вот потом, научившись их преодолевать, я столкнулся с гораздо более интересными вещами.
Итак, первый случай, назовем его “фэйл на доверии” (здесь я описываю конкретный пример из практики, но имен называть не буду). Клиент с самых первых минут общения демонстрирует полное понимание темы автоматизации бизнес-процессов, уместно употребляет специальную терминологию, приводит примеры на материале других ИС, активно и вдумчиво участвует в составлении ТЗ... В общем, через какое-то время начинает казаться, что достигнуто полное взаимопонимание. Техническое задание похоже на документ, который отражает душевную гармонию обеих сторон процесса. Подписываем, начинаем работать. А когда доходит до сдачи... Клиент начинает утверждать, что мерилом результата для него является его собственная практика (читай “хотелки”), а не какие-то там документы вроде ТЗ, пусть и выверенные до последней запятой. Надо сделать еще вот это и вот это, а бюджет ограничен, так что вы, дорогие внедренцы, можете или сделать это очень дешево, или признаться в своей неспособности завершить проект (здесь “берет на слабо”). Правильным решением в этой ситуации, пожалуй, было бы пойти путем претензий и судебного процесса... Но клиент в это не особо верит, поскольку знает, что заработанный в моих глазах кредит доверия будет заставлять до последнего надеяться на благополучный исход и давать ему все новые послабления. Итог: проект практически завершен, клиент получил то, что хотел, по максимальному варианту за очень разумные деньги, а для нас этот проект, мягко выражаясь, коммерчески неэффективен. Оценивать происшедшее с точки зрения этики, наверное, нет смысла, но понятно, что эта история настолько “ухудшила карму” клиенту, что дальнейшая работа с ним будет строиться на совсем других основаниях.
История вторая: “концепция изменилась”. Для того чтобы запустить проект по созданию ИС, в компании-заказчике должен существовать некий “беспокойный ум”, которому эта система нужна. С ее помощью он надеется решить какие-то свои серьезные проблемы. Но создание системы дело небыстрое, и бывает так, что где-нибудь на середине проекта этот ум теряет к нему интерес и переключается на что-нибудь другое. С самыми плачевными результатами для проекта (неполная оплата, непринятие в эксплуатацию из-за ненужности и т. д.). В чем здесь фэйл? А в том, что по идее таких товарищей можно диагностировать заранее и просто с ними не работать. Тут меня подводит управленческая жадность – неспособность отказаться от проекта из соображений “плохого прогноза”. Таких ситуаций было несколько, не отказался от проекта, к сожалению, ни в одной.
История третья: “как перестать бояться и начать жить”. Совсем недавняя. Заказчик смертельно боится принимать проект, поскольку предполагает, что после подписания акта приемки работ мы начнем выкручивать ему руки: требовать неадекватных денег за доработки и т. д. В результате он придумывает все новые требования, как может, притягивает их за уши к основному ТЗ, заставляет реализовывать угрозами полного отказа от проекта или, на худой конец, подписывает допсоглашение с условием оплаты после закрытия работ по основному договору. Или просто “динамит”, неделями не выходя на связь в ситуации, когда следующий шаг должен быть с его стороны. История длится уже больше года. Снова в проект с нашей стороны вложены такие средства, что бросить его крайне сложно психологически, хотя, пожалуй, давно пора. Что интересно, заказчик добивается противоположного эффекта: в начале работы не было ни малейшего желания проявлять к нему нелояльность после приемки проекта, а сейчас я действительно готов начать делать то, чего он боялся, сразу после подписания акта... Люди сами запрограммировали свою судьбу – своим страхом. В чем фэйл с моей стороны? В том, что не сумел найти “волшебный ключик” к сердцу клиента, который избавил бы его от этих страхов, или закрыть проект, как только ситуация стала очевидной, чтобы ограничить материальные потери.
Источник: IT News №10 (июнь 2012 года)
Опубликовано 29.05.2012