Технологии взаимодействия с внутренним заказчиком. Управление проектами. Информирование Заказчика о технологии ведения проекта

Следующий этап - это информирование заказчика о технологии .

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

Результатом этого этапа является то, что все ответственные лица заказчика прошли курс лекций и, самое главное, что руководство имеет четкое представление о том, как производятся работы (естественно, если оно контролирует проект достаточно плотно).

Организация отношений с Заказчиком

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

• Контракт-менеджер - это «плохой». Это может быть отдельный человек или кто-то из топ-менеджеров. Чаще всего функцию контракт-менеджера выполняет руководитель проекта (если он, конечно, в состоянии это сделать). Это человек «Нет» - он может прийти к лицу принимающему решения, и сказать: «у нас по контракту написано вот так, а вы сейчас делаете по-другому, и из-за этого возникает отклонение. Давайте разбираться». Он всегда указывает на недостатки, на несоблюдение технологии, призывает соблюдать документацию - поэтому он всегда «плохой».
• А объект-менеджер - это «хороший». Это человек, у которого в силу разных причин сложились хорошие отношения с лицом принимающим решения от заказчика. Может быть, он просто оказался ему симпатичен. Или, например, у них есть какие-то связи (родственные, клановые, дружеские - какие угодно). Главное, что клиент к нему расположен.
  Объект-менеджер у нас фактически ведет этот объект. Обратите внимание, это не проект-менеджер, это специальный человек, который занимается тем, что поддерживает хорошие отношения с руководством заказчика , и, когда возникают какие-то острые проблемы, он их сглаживает.
  Например, после того, как контракт-менеджер выговорил клиенту о несоблюдении каких-то условий наших договоренностей (это может закончиться, в общем-то, каким-то нелицеприятным для нас разговором), приходит объект-менеджер и начинает успокаивать клиента.
  Я не зря сказал, что объект-менеджер называется «хорошим». Обычно говорят, что «хороший парень» - не профессия. Но у нас это профессия. Объект-менеджер - это «хороший парень». Он может не быть специалистом-профессионалом ни в чем, но с ним клиенту хорошо - он пришел, поговорил с ним (может быть, о политике, о футболе и т.п.), и клиенту стало хорошо, у него изменилось отношение. Клиент до этого собирался нам что-то выговаривать, за что-то нас наказывать, но теперь он уже все понимает, ему вообще неудобно с нами плохо говорить.
  Вот это - функция объект-менеджера. Он закрепляется за каждым достаточно серьезным клиентом.

Конечно, все то, о чем я говорю, требует определенных ресурсов, затрат. И, естественно, создавать всю эту структуру ради маленького магазинчика не имеет смысла - это все делается только ради достаточно больших объектов.

Результатом данного этапа становится назначение подходящих контракт- и объект-менеджера для данного клиента, ведь очень важно подобрать этих людей правильно.

Организация проектных процессов

Следующий этап - это организация проектных процессов . По моему мнению, их бывает всего два:

• Мониторинг хода проекта;
• И принятие управленческих решений по результатам мониторинга.

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

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

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

Ограничение желаний клиента

Следующий этап - это ограничение желаний клиента . С этим, наверное, сталкивались все (когда начинаются так называемые «хотелки» - еще, еще и еще). Здесь мы поступаем достаточно просто:

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

Здесь я хочу привести еще один пример взаимоотношений. Мы работали с одной очень крупной компанией (они уже были на этапе обслуживания), и там периодически возникали какие-то задания на доработки: например, сделать какой-то мудреный отчет или еще что-то. И вот, главный бухгалтер компании нам поручил определенную работу, и мы ее сделали. А когда пришло время расплачиваться, он сказал: «В общем-то, я ошибся, это все нам совсем не нужно». Но работа-то была сделана, следовательно, надо было заплатить. А он говорит: «Нет, я за это платить не буду, я же не могу пойти к президенту компании и объявить ему, что я дурак, и заказал не то, что нужно». Причем, компания была очень крупная, нефтяная, отношения были хорошие и с ней, и с этим человеком. И мы не стали настаивать - не платит, так не платит. Хотя, из-за этого мы потеряли по тем временам достаточно большую для нас сумму денег (это был 2004 год). В конце года была деноминация (азербайджанский манат отбрасывал нули). И для всех клиентов, которые были у нас на обслуживании, мы делали этот перерасчет в рабочем порядке - никаких дополнительных денег. А вот к этому бухгалтеру (на тот момент с того случая прошло буквально меньше года), мы подошли и сказали: «Помните, вы нам не заплатили? Мы тогда пошли вам навстречу. А сейчас - деноминация. Давайте мы сделаем это небесплатно?» Без вопросов - мы выписали счет, он оплатил.

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

Кто занимается объяснением этого бюджета :

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

Обычно, если цифры расписываются очень подробно, тогда этой раскладки и её объяснения бывает достаточно.

Сдача работ

Сдача работ. Здесь, в общем-то, больших проблем обычно не бывает, потому что процедура сдачи работ у нас очень подробно прописана в соответствующих документах .

Но на этом этапе элемент неформальности (хорошее отношение ), конечно, также облегчает жизнь и нам, и заказчику тоже.

Цель этого этапа - добиться сдачи работ в полном соответствии с правилами, установленными в соответствующих документах, которые являются приложением к договору, подписанному и клиентом, и нами. Соответственно, всегда можно предъявить, что есть такие правила.

Постпроектные взаимоотношения

Ну и, наконец, постпроектные взаимоотношения. Это тоже очень важная составляющая. К чему мы должны стремиться по окончании проекта? К заключению договора на обслуживание, естественно. Но так происходит не всегда. Потому что есть понятие «результат», и есть понятие «итог» - и это немного разные вещи.

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

Почему это произошло? Потому что не было неформальных взаимоотношений. Мы тогда только что разработали свою технологию проектной документации, и это был клиент, на котором вся эта технология, в полной красе, была продемонстрирована. И когда мы спросили у заказчика: «Хорошо, вы с нами не будете работать - а есть ли какие-нибудь претензии к нам?» И нам сквозь зубы со злостью было сказано: «В том-то и проблема, что никаких претензий мы предъявить не можем - что вам ни скажи, у вас на все есть бумажка, и мы ничего не можем сделать. Нас так не устраивает, и больше мы с вами работать не будем. Другие компании можно попросить что-то сделать дополнительно, а вы отказываетесь - вот у вас бюджет, вот у вас так положено, вот срок. Шаг в сторону - и вы тут же показываете нам бумажку с нашей подписью».

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

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Приглашаем вас на новую конференцию .

Всем доброго времени суток! Сегодня хотел бы поговорить о путях взаимодействия клиента c аутсорсинговой компании, а также получить от Вас комментарии того, как Вы взаимодействуете со своими клиентами/разработчиками ПО. Данная статья написана на основании опыта работы и, по большей части, предназначена для заказчиков ПО. Целью является найти «узкие» места в вопросах отношений между заказчиком и компанией, которая предлагает услуги по разработке ПО.

Разрешите представиться: Я – Корхов Юрий и эта статья у меня на хабре первая. Закончил Белорусский Национальный Технический Университет (инженер по безопасности), Белорусский Государственный Университет (инвестиционный менеджер). Стаж работы - более 6 лет в IT на практически всех должностях: webmaster, верстальщик, web-дизайнер, программист, менеджер-проекта и по совместительству разработчик UI, руководитель отдела… В общей сложности, за это время, реализовано более 80 проектов: от маленьких сайтов, игр для мобильных телефонов до крупных интернет-порталов… Основной профиль - управление ходом разработки проектов в IT сфере. Работал как на стороне заказчика так и на стороне разработчика, как на Российский рынок так и на зарубежный.

Предыстория создания поста или Спасибо Wargaming.

Обойти историю создания данного поста было бы не хорошо, т.к. хабр я читаю уже очень давно, а вот написать статью руки никак не доходили, а здесь дело “случая” и вот статья готова.

Уже пару месяцев я отдыхаю от работы, потому что устал от аутсорсинга, решил найти смысл жизни и неторопливо подготовить к запуску свой проект, и в один прекрасный день раздался звонок. Рекрутер Wargaming (основатели “танчиков” и, по-моему мнению, одной из лучших фирм в Минске) позвонил мне с предложением пройти собеседование на вакансию Vendor Manager (здесь следует сказать, что работу я не искал, и, судя по их вакансии, я не очень подходил им). “Это же интересно!” - подумал я и решил выполнить тестовое задание, тем более, что оно было достаточно интересным для меня. Рекрутер сообщил, что у них созданы все условия для приятной, здоровой (фитнес, страховка и т.д) и высокооплачиваемой работы а также, что не маловажно, для выполнения тестового задания мне потребовалось бы около 3х часов. Я сомневаюсь, что у кого-то получилось бы сделать все тестовое задание в течение указанного срока, что касается меня – в общей сложности ушло около 6 часов.

К моему сожалению, feedback от компании был в телефонном разговоре и выражался сухой фразой “всё хорошо, всем понравилось” (дословно не помню, но суть такая) и без какой-то конкретики. Я сомневаюсь, что мне удалось указать все основные «узкие» места, а т.к. не хорошо пропадать труду, решил разместить ответы на тестовое задание (с небольшими изменениями, для удобства) на суд общественности и буду признателен аудитории habra за дополнения и здоровые комментарии к статье.

Схема взаимодействия заказчик – разработчик программного обеспечения от первого знакомства до окончания взаимоотношений.

1. Разработчик ПО способен выполнить проект.
2. С разработчиком ПО до этого договор не подписывался и никаких проектов не было.
3. ТЗ уже готово.
4. Условия оплаты регулируются договором.
5. Системы управления проектами и методологии разработки ПО (XP, Scrum, Lean, Kanban, ScrumBut и т.д.) используются.
6. Наполнение контентом приложения (если это необходимо) делается средствами клиента.

Аспекты контракта между software development вендором и заказчиком вендору выгодно избежать (упростить, вообще убрать из контракта).

1. Ответственность за соблюдение сроков лежит на стороне разработчика и в случае, если срыв сроков происходит в последний момент (т.е. разработчик заранее не уведомил о том, что не успевает до закрытия) должны накладываться штрафные санкции (здесь большой выбор вариантов).
   Причина: срыв сроков - одна из самых больших проблем и упоминать это в договоре не очень интересно, т.к. в большинстве своем срыв сроков лежит на стороне разработчика. Здесь нужно учитывать, что точно рассчитать сложно, но заранее предупредить о том, что разработчик не успевает выполнить этап разработки в определенный срок - обязан и это нужно прописывать в договоре.
2. Условия гарантий исправлений «багов» по вине разработчика, которые не были вовремя выявлены. Обычный срок гарантии 3 месяца.
   Причина: часто бывает, что некоторые “баги” не были устранены или появились уже в процессе работы, поэтому этот пункт часто пытаются не указывать или уменьшать время гарантии. Мое мнение, что меньше 3х месяцев мало.
3. Права на разработанное ПО, модули, блоки и т.д. принадлежат заказчику и не могут применяться для последующей перепродажи.
   Причина: разработчику выгодно обладать правами на интеллектуальную собственность или иметь возможность продавать/использовать наработки для других клиентов, что в свою очередь может поставить заказчика в неудобную ситуацию на рынке.
4. При разработка нового модуля в системе, который влияет на работу других модулей или всей системы, разработчик должен обеспечеить функционирование всей системы.
   Причина: часто разработка одного модуля может навредить работе другого модуля или вообще всей системе и дальнейшие доработки могут лечь на “плечи”(финансово) клиента. Разработчик обязан учитывать структуру всей системы и в случае “багов”, найденных клиентом, править бесплатно.
5. Техническая документация на разработку должна составляться с учетом требований заказчика.
   Причина: разработчикам выгодно полностью привязать себя к заказчику и часто бывает, что документация не ведется.
6. В случае разработки веб-сайта, исполнитель обязан учитывать SEO оптимизацию для сайта, а именно: описание изображений, страниц…
   Причина: экономия времени на “мелочи”, что в зависимости от условий договора может привести к финансовым потерям заказчика (разработчик ПО экономит время/финансы).
7. Тестирование системы должен обеспечивать разработчик системы.
   Приемка заказчиком готового модуля не должна превращаться в тестирование системы, т.е. разработчик обязан взять на себя устранение выявленных “багов” клиентом за свой счет. Это нужно для того, чтобы обеспечить качественное тестирование продукта со стороны разработчика. К моменту, когда разработчик говорит “сделано” и начинается тестирование на стороне клиента - “баги” правятся бесплатно.
8. Ответственность за размещение проекта на стороне заказчика берет на себя разработчик. При этом заказчик обязан обеспечить выполнение технических требований для площадки.
   Причина: размещение проекта на стороне заказчика иногда может вызвать определенные трудности, что может привести к “шапкозакидательству”, поэтому ответственность по размещению и настройке сервера должна быть на стороне разработчика ПО.
9. В случае если разработчик ПО вынужден прибегнуть к помощи специалистов вне своей команды он обязан взять на себя все сопутствующие риски за утечку, потерю данных или любой другой ущерб, который может нанести своим действием или бездействием сотрудник со стороны.
   Причина: бывает, что у разработчика может заболеть, уволиться и т.д. кто-нибудь из сотрудников. В этом случае заказчик должен быть застрахован.
10. Резервные копии проекта должны обеспечиваться на стороне разработчика не реже 1 раза в сутки. Любые проблемы с потерей данных по проекту должен брать на себя разработчик.
    Причина: здесь нужно обозначить кто несет ответственность за сохранность проекта в случае каких-либо сбоев.
11. Разработчик должен исходить из популярности использования применяемых им технологий при выборе.
    Причина: привязка к собственным технологиям, которые усложнят жизнь в случае перехода заказчика к другому разработчику.

Известные способы завышения стоимости аутсорсинговых работ относительно реальности.Полагаю их больше.

• Поверхностная оценка стоимости разработки проекта целиком, без разбиения на этапы, что может привести к 2х-3х кратному превышению стоимости проекта.
• Не предоставление отчетов о проделанной работе в определенный по договору срок или не возможность контролировать ход разработки со стороны клиента
• Неправильный выбор технологии при реализации технической части, может значительно увеличить стоимость разработки.
• Отсутствие в команде разработчика нужных специалистов, что увеличивает время и стоимость разработки.
• Фиксированная установка стоимости разработки проекта или модуля и дальнейшее увеличение стоимости за каждую мелочь, которую обе стороны понимали по разному.
• Фиксированная установка стоимости разработки проекта - более высокий риск заставляет закладывать в стоимость проекта.
• При разработке дизайна не используется прототипирование, а разработка дизайна ведется на основе текстового ТЗ, что в итоге приводит к большому количеству доработок/исправлений и соответственно увеличению стоимости проекта.
• Добавление/усложнение функционала. Можно сделать проще - делают сложней.
• “Красивости” там где они не нужны (можно сказать про админ. часть сайта, если можно использовать css фреймворки для быстрой кастомизации админ. части - начинают разрабатывать с нуля).

Шаблон взаимоотношений ‘заказчик - software development vendor’, который, как мне кажется, наиболее близок к практическому использованию.

Многие аутсорсинговые компании предпочитает не предоставлять доступ к своим системам управления проектами, не предоставляя подробную информацию, лично считаю, что доступ должен предоставляться по желанию заказчика. Клиент является ответственным за реализацию проекта и видеть ход разработки в реальном времени - важно!
Также, считаю, что разрабатывать ПО с учетом расчета полной стоимости проекта - трата средств и нерв, такая разработка обычно приводит к конфликтным ситуациям.

1. Оплата работы исходя из почасовой оплаты работы сотрудников или усредненной стоимости работы специалиста всей команды разработчика. Оценку этапов разработки делать необходимо. Почему считаю эту форму расчета цены оптимальной:
   • Не требует очень щепетильного подхода в оценке проекта, которую сделать на 100% точной практически нереально. В случае если оценка сделана неверно и разработчик ПО это начинает понимать, то происходит “ущемление” функционала везде где только можно, что в итоге будет сказываться на удобстве использования.
   • Улучшает взаимопонимание между разработчиком ПО и клиентом, т.к. основная задача сводится к принципу - “сделай качественно и быстро”, а не “вложись в жесткий бюджет и как будет работать так и хорошо”.
   • Клиент, на основе ежедневных отчетов о затраченных часах, может видеть какое время тратят сотрудники на разные блоки при разработке, что дает понимание скорости и качества работы сотрудников разработчика ПО.
   • Взаимодействие между заказчиком и менеджером-проекта ведется максимально на прямую, т.е. при использовании skype, телефонов и т.д.
2. Только 2х недельные отчеты и планы должны пересылаться в обязательном порядке по почте (для контроля).
3. Клиент предоставляет прототип приложения или его разрабатывает команда разработчика ПО, если это необходимо:
   • Упрощает понимание основного функционала проекта.
   • Увеличивает общую скорость разработки проекта.
   • Понятные требования к функционалу как у заказчика так и у разработчика.
   • Ясное понимание куда будет двигаться проект.
4. Система управления проектами для ведения хода реализации проекта и возможности мониторинга процесса, времени разработки, потраченной на каждую задачу в отдельности. К сожалению, доступ редко предоставляют разработчики.
5. Желательно, чтобы весь проект делала одна команда, т.е. не должно быть такого, что один этап делает одна компания, другой - другая и т.д.
6. Контрольные точки (“забег”) каждые 2 недели- оптимальное время для контроля проекта.
7. В разработке предпочтение отдается известным фреймворкам, также для более простой адаптации в случае какой-либо ситуации, когда необходимо передать проект другим разработчикам.
8. Качественное тестирование на стороне разработчика - прямая обязанность. При передаче клиенту проекта или какой-то его части, всё должно быть проверено досконально.
9. Поддерживать разные браузеры - прямая задача разработчика

Вывод : главное придерживаться партнерских/взаимовыгодных и доверительных отношений с пониманием того, что разработчики такие же люди и усложняя им жизнь усложняешь жизнь и себе! Каждый должен отвечать за свою часть работы, клиент-за предоставление внятного ТЗ и отвечать оперативно на возникающие вопросы, не забывая оплачивать работу, а разработчик - за качество, сроки, скорость. Идеал, конечно, не достигнут, но мы на верном пути.

Мне нравится

В разных источниках литературы по продажам можно найти разное количество этапов продажи . Каждый автор рассматривает их со своей точки зрения.

Предлагаю рассмотреть ключевые этапы в работе с Клиентом>:

1 этап «Вступление в контакт» или «Установление контакта»

С этого этапа начинается любая продажа .

Цель данного этапа : расположить к себе Клиента и заинтересовать его в дальнейшем контакте.

При установлении контакта с Клиентом важно поприветствовать его и представиться

«Добрый день. Меня зовут Михаил, я менеджер компании «Окна плюс».

Прежде чем начать разговор о потребностях Клиента, рекомендуется пообщаться с ним на отвлеченную тему (техника «Малого разговора»), либо предложить чай, кофе, можно сделать комплимент либо использовать ряд других техник этапа установления контакта.

«Что вы знаете о нашей компании? Почему выбрали именно нас? Что планируете приобретать?»

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

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

2 этап «Выявление потребностей»

Цель данного этапа : определить потребности Клиента.

Чем точнее менеджер определит потребности Клиента, тем эффективнее проведет презентацию товаров и услуг, что в последствии приведет к сделке.

При выявлении потребностей менеджеру важно уметь задавать вопросы и слушать Клиента.

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

«Какое окно вы планируете приобрести? Где будете менять окно? Какой климат в квартире зимой и летом? Кто еще проживает в квартире? По каким признакам Вы выбираете окно?»

Закрытые вопросы менеджера позволяют конкретизировать потребности Клиента.

«Вы часто проветриваете помещение? У Вас есть животные? Вам удобно если наш замерщик приедет завтра в 9 утра?»

Альтернативные вопросы предлагают клиенту выбор вариантов.

«Вам удобно чтобы замерщик приехал с утра или после обеда? Установку новых окон планируем на этой неделе или на следующей?»

В течение всей встречи с Клиентом полезно его внимательно слушать, так как зачастую Клиенты сами открыто говорят о своих потребностях. Если какие – то слова Клиента непонятны менеджеру или он их прослушал, желательно задать Клиенту уточняющие вопросы:

«Правильно ли я понял, что Вам нужно окно с повышенной шумоизоляцией? Насколько я понял, Вы хотите, что одна створка окна была поворотной, а другая – поворотно-откидной?»

Желательно подводить промежуточный итог после каждого обсуждаемого вопроса. Особенно если менеджер обсуждает с Клиентом несколько продуктов или услуг.

«Таким образом, мы с Вами договорились, что замер произведем завтра, а устанавливать окна будем на следующей неделе в пятницу. Итак, Вы планируете ставить два новых окна: в кухне двустворчатое с поворотно-откидными створками, а в комнате трехстворчатое, в котором две створки поворотно-откидные и одна «глухая»».

Важно точно выявить потребности клиента и только потом проводить презентацию товаров и услуг.

3 этап «Презентация»

Цель: предложить продукт или услугу максимально удовлетворяющие потребности Клиента.

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

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

Важно различать, чем преимущество продукта и услуги отличается от выгоды.

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

«С помощью данной услуги Вы сможете сэкономить время и сократить расходы на 10%». «Данная фурнитура позволяет сократить количество регулировок».

Выгода – это характеристика или преимущество, которые позволяют удовлетворить конкретную потребность Клиента.

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

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

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

«Как Вы относитесь к моему предложению?», «Что Вы думаете по этому поводу?», «Как Вам мое предложение?»

4 этап «Работа с возражениями»

Цель: развеять сомнения Клиента относительно покупки и снять негатив в отношении продукта или услуги.

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

Важно, воспринимать возражения Клиента как сигнал о том, что менеджеру нужно скорректировать свое поведение (особенно если возражений очень много).

Возражения у Клиента могут возникнуть и на предыдущих этапах продажи. Как же работать с возникающими возражениями?

Эффективно придерживаться схемы работы с возражениями:

1. выслушать Клиента;

2. нейтрализовать его эмоции, используя фразы понимания;

«Я вас понимаю», « Да, соглашусь, что неприятно…»

3. уточнить при необходимости информацию с помощью вопросов;

4. предложить конструктивные варианты решения или сделать альтернативное предложение.

Возражения Клиента бывают 4 видов:

1. возражения, связанные с изменениями.

«Зачем мне это нужно», «Я не вижу в этом смысла»

В работе с таким возражением менеджер должен объяснить Клиенту, что риски исключены, показать последствия, если ситуация сохранится, привести примеры, положительного опыта использования чего – либо впервые.

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

2. возражения, связанные с ценой.

«Это дорого для меня».

В аргументации менеджеру следует обратить внимание на дополнительную пользу, которую получает Клиент, можно сравнить стоимость товара со стоимостью любой другой не особо нужной вещи или разделить стоимость на какой-либо промежуток времени.

«Приобретая окно в нашей компании, Вы получаете в подарок набор по уходу за окнами, а также возможность воспользоваться бесплатной регулировкой фурнитуры», «Новое красивое окно в кухне будет Вам стоить всего 300 руб. в день».

3. возражения, связанные с негативным опытом.

«Я слышал у Вас плохой профиль».

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

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

4. возражения, связанные с принятием решения.

«Мне надо подумать», «Нужно посоветоваться с женой».

В работе с такими возражениями менеджеру можно еще раз уточнить, с чем связано такое решение, убедиться, что клиент воспринял и понял всю информацию, а также воспользоваться методами завершения сделки.

«Если мы с Вами подпишем договор сейчас, то уже в конце недели Вы сможете любоваться новым окном на кухне». «Только до конца месяца у нас действует скидка на данный товар».

5 этап «Завершение сделки»

Цель: подтолкнуть Клиента к сделке и подтвердить правильность принятого им решения.

Прежде чем завершать сделку (подписывать договор) менеджеру необходимо убедиться, что Клиент готов заключить сделку.

Это можно увидеть по сигналам, которые он показывает:

• положительные отзывы о продукте или услуге;
• Клиент выражает одобрение словам менеджера (поддакивает, кивает головой и тд.);
• прямо говорит, что он согласен;
• задает уточняющие вопросы.

Методы завершения сделки:

1. метод ограничения условий и времени.

«Если Вы подписываете договор сегодня, то мы даем Вам скидку на окно 20%».

2. метод комплимента.

«Вы действительно сделали правильный выбор».

3. беспроигрышная альтернатива.

«Вас записать на замер во вторник или в среду?»

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