И снова о фэйлах

Спасибо отделу Интернет-рекламы за пост о FailConf! Сам я на эту конференцию не попал, но тема интересна. Так что — расскажу о своем собственном опыте ошибок в управлении проектами по созданию корпоративных информационных систем. За 5 лет занятия этим делом кое-что, как говорится, наболело.

Ну, во-первых, мы гордимся тем, что фатальных ошибок в этой нашей деятельности, пожалуй, не было. То есть — можно вспомнить буквально единичные проекты (из почти сотни), когда мы взялись внедрять информационную систему, и не довели ее до эксплуатации. А вот ошибки, связанные с экономической эффективностью проектов — были.

Ошибки можно поделить на два класса: связанные со взаимодействием с клиентом, и с персоналом (исполнителями работ). В случае с персоналом причины довольно очевидны, и сводятся к неспособности (невозможности) руководителя проекта обеспечить мотивацию, вовремя принять решение об увольнении неэффективного сотрудника, переоценке возможностей программиста в плане самостоятельной организации своей работы.
Ошибки, связанные со взаимодействием с клиентом, более разнообразны. В начале творческого пути причины таких ошибок также были банальны. Недооценка объема работ, неумение найти общий язык с клиентом (понять, что именно ему нужно, и объяснить, каким образом предлагаемое решение удовлетворит его потребности). Но вот потом, научившись их преодолевать, я столкнулся с гораздо более интересными вещами.

Итак, первый случай — назовем его «фэйл на доверии». Здесь, как и всюду ниже, я описываю конкретный пример из практики, но имен называть не буду, чтобы никого не обидеть.
Клиент, с самых первых минут общения, демонстрирует полное понимание темы автоматизации бизнес-процессов, уместно употребляет специальную терминологию, приводит примеры на материале других информационных систем, активно и вдумчиво участвует в составлении ТЗ… В общем, через какое-то время начинает казаться, что достигнуто полное взаимопонимание. Техническое задание похоже на документ, который отражает душевную гармонию обеих сторон процесса. Подписываем, начинаем работать. А когда доходит до сдачи… Клиент начинает утверждать, что ТЗ ему никуда не уперлось, что критерием достижения результата для него является его собственная практика (то есть довольно непостоянный набор желаний), а не какие-то там документы, пусть выверенные до последней запятой. Надо сделать еще вот это и вот это, а бюджет ограничен, так что вы, дорогие внедренцы, можете или сделать это очень дешево, или признаться в своей неспособности завершить проект. Правильным решением в этой ситуации, пожалуй, было бы пойти путем претензий и судебного процесса… Но клиент в это не особо верит, поскольку знает, что заработанный в моих глазах кредит доверия, а также уже вложенные в проект средства, будут заставлять до последнего надеяться на благополучный исход, и делать все новые послабления. Итог: проект близок к завершению, клиент получил то, что хотел, по максимальному варианту, за очень разумные деньги, а для нас этот проект, мягко выражаясь, коммерчески неэффективен. Оценивать происшедшее с точки зрения этики — наверное, нет смысла…

История вторая — «концепция изменилась». Для того, чтобы запустить проект по созданию информационной системы, в компании-заказчике должен существовать некий «беспокойный ум», которому эта система нужна. С ее помощью он надеется решить какие-то свои серьезные проблемы. Но создание системы — дело не быстрое, и бывает так, что где-нибудь на середине проекта этот ум теряет к нему интерес, и переключается на что-нибудь другое. С самыми плачевными результатами для проекта (неполная оплата, не принятие в эксплуатацию из-за ненужности, и т.д.) В чем здесь фэйл? А в том, что, по идее, таких клиентов можно диагностировать заранее — и просто с ними не работать. Тут меня подводит управленческая жадность — неспособность отказаться от проекта, из соображений «плохого прогноза». Таких ситуаций было несколько, и я не отказался от проекта ни в одной 🙁

История третья, «как перестать бояться и начать жить». Совсем недавняя. Заказчик смертельно боится принимать проект, поскольку предполагает, что после подписания акта приемки работ мы начнем «выкручивать ему руки» — требовать неадекватных денег за доработки, и т.д. В результате, он придумывает все новые требования, как может — притягивает их за уши к основному ТЗ, заставляет реализовывать угрозами полного отказа от проекта, или, на худой конец, подписывает дополнительное соглашение, с условием оплаты после закрытия работ по основному договору. Или просто неделями не выходит на связь в ситуации, когда следующий шаг должен последовать с его стороны. История длится уже больше года. Снова — в проект с нашей стороны вложены такие средства, что бросить его крайне сложно психологически, хотя, пожалуй, давно пора. Что интересно, заказчик добивается эффекта, противоположного желаемому — в начале работы не было ни малейшего желания проявлять к нему нелояльность после приемки проекта, а сейчас я действительно готов начать делать то, чего он боялся, сразу после подписания акта… Люди сами запрограммировали свою судьбу — своим страхом 🙂
В чем фэйл с моей стороны? В том, что не сумел найти «волшебный ключик» к сердцу клиента, который избавил бы его от этих страхов, или закрыть проект (как только ситуация стала очевидной), чтобы ограничить денежные потери.

2 комментария to “И снова о фэйлах”

  1. Евгений Курочкин:

    По поводу второго фейла:
    Есть система — ФФФ. (Fix Time and Budget, Flex Scope). подробнее: http://gettingreal.37signals.com/ch02_Fix_Time_and_Budget_Flex_Scope.php

    Коротко: договориться с клиентом на запуск не полной версии проекта, оставить только то, без чего проект потеряет всякий смысл. Срок запуска сократится, а все остальное будет сделано уже после запуска. Позволит сохранить интерес «беспокойного ума» к проекту, так как он будет в разы быстрее запущен.

    Основная сложность здесь — договорится с клиентом.

  2. Евгений Бурмицкий:

    В «как перестать бояться и начать жить» ты забыл указать еще и постоянные попытки клиента обвинить нас в том что мы не отвечаем на его письма, звонки и пр. А довод — что это мы больше всех участников этой истории хотим завершить проект, получить деньги, добавить еще один пункт в портфолио и по возможности забыть такого клиента, как то особо его не впечатляет…
    А по поводу того чтобы воплотить его страшные сны в реальность (я про «башенные» цены на услуги после подписания акта), то это не просто месть, а необходимость — надо же как-то страховаться, он же все так принимать будет…

Коментарии