Неделькина задачка

Близится конец года. У крупных корпоративных клиентов, бизнесов, наблюдается синдром выполнения годовых целей “на шас”. Это выглядит следующим образом:

Часть 1. Начало. Некий менеджер планирует сделать по своему направлению свершение. В частности – автоматизировать процесс Управления/Контроля чего-нибудь в своей области ответственности. Планирует он это в начале года. Несколько месяцев вяло узнает кто это будет делать у ИТ. Потом небольшое ускорение и рождается первое уродливое ТЗ на 2 страницы подготовленное младшим экспертом его отдела.

Часть 2. Честный отъем денег за ТЗ мега консультантами. Это ТЗ отправляется супер консультантам на приведение в чувства. Супер консультанты за ХХХ долларов в час и сумму в несколько десятков тыш долларов рожают за месяц в два приема некий документ ТЗ – как правильно делать в их понимании. Бизнес заказчик глубоко мычит наблюдая лого компании консультантов, количество страниц и оглавление не три страницы. Десяток диаграм с 55 какими то прямоугольниками-кружуками-стрелочками в документе вселяют уверенность в решении их теории хаоса. Бизнес заказчика застывает на этапе читаем, обдумываем на пару месяцев. Как правило это лето.

Часть 3. IT послало заказчика. Когда бизнес заказчику надоедает стоять на местей кой месяц с документом и убеждаясь в отсутствии аналитического мышления у девочек в отделе он отсылает документ в ИТ. И приказывает ИТ сделать его сегодня а завтра дать исправленную и готовую к подписанию версию. ИТ нагунли, документ читается в самых интересных для ИТ местах и ИТ наносит ответный удар за нагнули – предлагаемая архитектура решения не соответствует корпоративному стандарту, ее отличает избыточность, ряд систем не учтено, не все роли есть и тп. И вообще – в ИТ нет бюджет в миллион долларов чтобы реализовать предложенную архитектуру. Есть только 50 тыш плюс-минус.

Часть 4. Вспомнить все за неделю. Глава ИТ, глава проектного офиса и директор направления бизнес заказчика сходятся в комнате с очень дорогими кожаными креслами. На столе лежит вариант ТЗ и к нему лист с аргументацией ИТ почему это ерунда. У ИТ директора есть еще один листик в котором припасены более жесткие и не очень цензурные аргументы ИТ  по поводу этого ТЗ. После часа поиска мифического козла в комнате определяется конструктивный путь. Из кармана одного из менеджеров вылетает лист с предложением ASAP пригласить местного подрядчика с вменяемыми компетенции и поставить ему задачу на переписать бизнес требования, архитектуру решения и посчитать 2-3 вариант проекта за 2 недели.

Часть 5. Поехали! ТЗ за цать тысяч долларов читается, из него забираются процентов 25% полезного, вся убойная для мозга графика уходит, рождается более компактный документ в котором вместо мега машины с двумя атомными двигателями появляется колесо на веревке с вариантом колесо в коже и колесо в потертой резине. Считается проект в рамках указанной перстом суммы. Бизнеса тихо грустят по миражу лоска первого варианта системы но понимают что ЭТО колесо от запрожца таки можно РЕАЛЬНО сделать. И проект запускается за две недели.

Продукт и решение

Если в самом начале проекта (построение отношений между поставщиком решений и клиентом) менеджер (по работе с клиентом, продавец, pre-sale) начнет с презентации продукта, то он может нарваться на стандартные грабли:

  • Представители клиента начнут умничать и вопросами заведут вас с одной стороны в ненужные дебри для данного проекта, с другой стороны – могут нарыть слабые места продукта
  • Клиент может испугаться сложности продукта
  • Клиент может сделать вывод что продукт не адекватен его задаче
  • Клиент может подумать что на него натягивают “резинку” стандартного решения

Чтобы не наступить на такие грабли необходимо:

  • Понять что есть проблемой у клиента
  • Понять что движет клиентом к поиску решения проблемы
  • Оценить стоимость проблем для клиента – понять выгоды от решения этих проблем
  • Представить вместе с клиентом видение решения
  • Представить РЕШЕНИЕ на основе вашего продукта, услуг  и усиленной вашим опытом, командой и методикой