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