?

Log in

No account? Create an account

serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Ошибки в управлении проектами
serge_gorshkov

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

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

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

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

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

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

  • 1
Как-то ты про управление персоналом скомкал - "всё просто, причины очевидны". Да, в принципе названные тобой причины верны, сама именно по этим граблям хожу - и решение "уволить/оставить" принимается тяжело и запоздало, и лишком доверяю и надеюсь на ответственность исполнителя там, где стоило бы больше контролировать, и тому подобное.

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

Кстати, сейчас, когда вы в компании внедрили новые способы мотивирования, интересно было бы спустя некий срок, скажем полгода, узнать, какая из мер показала себя эффективной, какая нет. Думаю, полезный опыт для всех.

Работаю пока один, но вот истории о проектном внедрении ИС у клиентов со всеми вытекающими знакомы на 146%.

>А в том, что, по идее, таких товарищей можно диагностировать заранее - и просто с ними не работать. Тут меня подводит управленческая жадность - неспособность отказаться от проекта, из соображений "плохого прогноза". Таких ситуаций было несколько, не отказался от проекта ни в одной :(

по Вашему опыту, по каким признакам можно было "диагностировать заранее" ?




Вот основные признаки:
1. Руководство проектом внедрения ИС поручено человеку, не имеющему реальных полномочий, или человеку, которого ни во что не ставит собственное начальство. Тогда велик риск того, что при сдаче проекта (а в приемке начальство в любом случае будет участвовать) руководители дезавуируют любые заявления своего подчиненного, и скажут, что все достигнутые результаты ничего не стоят.
2. У клиента имеется несколько ЛПР с равными или примерно равными полномочиями, и не все из них сочувствуют идее внедрения ИС.
3. Формальный признак: клиент хочет заключить договор внедрения не на свое основное юр. лицо, а на какую-нибудь сомнительную фирму (значит, предусматривает вероятность судебного иска со стороны подрядчика; в нашей практике этот признак срабатывал в 100% случаев - действительно, наступает момент, когда ничего не остается, кроме подачи иска).
4. Клиент не может внятно сформулировать, чего конкретно он хочет от ИС. То есть, общие слова может сказать - например, "усовершенствовать обмен информацией между сотрудниками", или даже "повысить контролируемость менеджеров по продажам". Но от ответов на конкретные вопросы (например, "какие количественные показатели деятельности менеджеров вы бы хотели отслеживать") уходит.
5. Клиент слишком нервный, или есть подозрения в его человеческой неадекватности.

Вообще, за полгода, прошедшие с написания этого поста, мы поменяли концепцию развития.
С тех пор мы с легким сердцем отказались от нескольких проектов, и радикально уменьшили количество геморроя для себя... Жить стало веселее )

Увидел перепост этой заметки в аналоговом журнале "Itnews".
Спасибо, что поделились, полезно!

В тему к последнему абзацу - известная вещь про дохлую лошадь:

"Лошадь сдохла? Слезь с лошади!

В жизни есть огромное количество ситуаций, вещей, или людей, которые нас не устраивают и уже давно. Например:
— Отношения, которые давно в тягость.
— Работа, которая давно надоела.
— Бизнес или проект, который приносит одни убытки.

Но по неизвестным причинам мы цепляемся за борт тонущего корабля в надежде, что он может быть, поплывет когда-нибудь, тратя на это оставшиеся нервы, время, деньги.

Разумеется, если принимать во внимание установки – «терпенье и труд, всё перетрут», необходимо проявлять упорство и не сдаваться. И в этом случае должен быть индикатор–показатель — точные сроки исполнения целей.

Но если его нет, тогда уясни древнюю индейскую пословицу:

"Лошадь сдохла - слезь!"

Казалось бы все ясно, но...

Мы уговариваем себя, что есть ещё надежда.
Мы бьём лошадь сильнее.
Мы говорим "Мы всегда так скакали".
Мы организовываем мероприятие по оживлению дохлых лошадей.
Мы объясняем что наша дохлая лошадь гораздо "лучше, быстрее и дешевле".
Мы организовываем сравнение различных дохлых лошадей.
Мы сидим возле лошади и уговариваем её не быть дохлой.
Мы покупаем средства, которые помогают скакать быстрее на дохлых лошадях.
Мы изменяем критерии опознавания дохлых лошадей.
Мы посещаем другие места чтобы посмотреть, как там скачут на дохлых лошадях.
Мы собираем коллег, чтобы дохлую лошадь проанализировать.
Мы стаскиваем дохлых лошадей - в надежде, что вместе они будут скакать быстрее.
Мы нанимаем специалистов по дохлым лошадям.

Если лошадь сдохла - слезь..."

Золотые слова...
Чем закончился один из этих фэйловых проектов - я описал в отдельном посте. Пост пока виден только друзьям... Эта кидательская история еще не совсем закончена.

Подведены итоги всех трех кейсов, описанных в этом посте. Прочитать можно здесь.

  • 1