Аналитик и продажи

09.06.2010 at 20:33 3 комментария

Опыт одной «провинциальной» ИТ компании.

К Летнему аналитическому фестивалю -ЛАФ 2010

Вводная

На дворе 2003г.  Компания, основной деятельностью которой является обучение в области ИТ, получила в 2001г эксклюзивный заказ на разработку индивидуальной системы, и за пару лет эту систему (какую-то ее N-ю версию) разработала. Конечно все сроки давно прошли (подписано несколько дополнительных соглашений к договору о переносе сроков), Заказчик практически все деньги заплатил, а сдать систему, хотя бы в опытную эксплуатацию, не получается. В чем проблема?

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

И тут пришел бизнес-аналитик

Вот так и получилось – пришел бизнес-аналитик, начал разговаривать с пользователями – систему сдали, потом попробовали, доработали и запустили.

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

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

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

Это и было сделано. Было разработано подробное маркетинговое описание системы и варианты коммерческих предложений.

Собственно о продажах.

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

Понятно, что период активной переписки с каждым конкретным потенциальным покупателем сменялся предложением встреч и презентаций. И тут, после различных экспериментов, выяснилось, что удачные продажи получаются тогда, когда на переговоры с клиентом выезжает команда в составе:

— Главный продавец – в нашем случае это был Директор компании

— Главный архитектор Системы – по должности –зам. Директора

— Главный бизнес-аналитик – по должности – руководитель отдела.

При этом, переговорам на уровне руководителей обычно предшествует презентация Системы для специалистов Клиента.

Главного Архитектора эта ситуация сильно раздражала, он считал такое представительство на продажах черезмерным, а свое участие – излишним.

Но на презентациях, куда приходили «большие начальники», с которыми надо было очень грамотно говорить на языке предметной области, всегда присутствовали и АСУшники. И когда наступала их очередь вопросы задавать, а отвечал именно архитектор ПО,  яркие впечатление получали все: АСУшники понимали кто перед ними, сколько он всего знает, и при этом, как  умеет говорить на этом профессиональном языке (вторая специальность –преподаватель учебного центра). Начальники, наблюдая эту беседу и видя реакцию своих АСУшников, проникались уважением к команде в целом. И часто это приносило успех.

Факт остается фактом – когда мы работали именно втроем, мало кто мог устоять перед таким напором. А если не получалось собраться вместе, контакт или вообще не получался, или требовал еще и еще дополнительных усилий. Вот был случай, что накануне запланированной поездки, я сломала руку. Поехал другой человек, тоже очень опытный, но в тот момент «не в теме». И этот клиент «ушел». Может быть совпадение, а может быть специфика компании и проекта.?!

У читателя возникнет вопрос – а менеджер проекта где? Какова его-то роль?

А здесь тоже все было коллективно. Общее управление велось этим же триумвиратом (с окончательным принятием решения, естественно, директором). Другое дело, что когда контракт уже случался, становился ясен объем работ и сроки, тогда назначался руководитель проекта внедрения (из моего отдела, который назывался «отдел бизнес-анализа и внедрения»).

И мне долго казалось, что у нас какая-то ненормальная ситуация. А вот недавно прочитала у А.Левенчука: «…теперь общепризнано, что на верхушке менеджерской «пирамиды» не остиё, а ровная площадка небольшой команды с разными мыслительными стилями».

Ну это прямо про нас – уж такие разные были мыслительные стили…Но это видимо и определило (на какое-то время) успех дела.

P.S.  Я приложила специальные усилия для того, чтобы не было понятно ни кто заказчики, ни о чем Система. Сейчас и с точки зрения конфидициальности не время об этом рассказывать, и для сути изложения это не важно.

Если получилось не понятно – отвечу на вопросы.

Когда доберусь до этой своей работы в мемуарной части – напишу все открытым текстом.

Реклама

Entry filed under: Бизнес/аналитик. Tags: .

AgileDays Екатеринбург 2010 завершилась Преподавание ИТ, я и НИИоргпром

3 комментария Add your own

  • 1. businessanalyst2009  |  01.07.2010 в 11:02

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

  • 2. bas  |  30.06.2010 в 19:19

    Честно говоря, на презентации многие так ездят, но не всегда такой триумвират принимает решения о трудоемкости и сроках.

  • 3. Grigory Grin  |  09.06.2010 в 23:12

    О! От определения терминов переходим к их содержательному наполнению 🙂

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Подписка на новости сайта

Подпишитесь на новости сайта (RSS)

RSS

Архивы

Рубрики

Главные книги аналитика

Современные методы описания функциональных требований к системам | Алистер Коберн
 Разработка требований к программному обеспечению |Карл И. Вигерс, Джой Битти

Требования для программного обеспечения: рекомендации по сбору и документированию |Илья Корнипаев
Анализ требований к автоматизированным информационным системам | Юрий Маглинец
Пользовательские истории. Гибкая разработка программного обеспечения |Майк Кон


%d такие блоггеры, как: