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

• Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
• Проектирование структуры программы
• Кодирование (набор программного кода согласно проектной документации)
• Тестирование и отладка
• Внедрение программы
• Сопровождение программы
• Утилизация

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

UML - является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)

Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):

Диаграмма вариантов использования (use case diagram)

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

Диаграмма классов (class diagram)

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

Диаграмма состояний (statechart diagram)

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

Диаграмма последовательности (sequence diagram)

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

Диаграмма кооперации (collaboration diagram)

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

Диаграмма компонентов (component diagram)

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

Диаграмма развертывания (deployment diagram)

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

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

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

Всем доброго времени суток! Сегодня хотел бы поговорить о путях взаимодействия клиента 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. Поддерживать разные браузеры - прямая задача разработчика

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

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

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

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

Компании, которые , успешно продвигают его и постоянно взаимодействуют со своими клиентами, выигрывают от этого разными способами:

• Это отличает компании друг от друга. Поиск возможностей для привлечения клиентов приводит к появлению запоминающихся особенностей.
• Это повышает удовлетворенность клиентов, помогает удерживать их, а также запускает сарафанное радио.
• Это создает доверие между компаниейи клиентами. Трудно почувствовать недовольство клиента после покупки, когда бренд постоянно взаимодействует с ним – даже после продажи.

Именно из-за измеримых, проверенных преимуществ, подобных этим, 98% маркетологов разработали четкие стратегии взаимодействия с клиентами. Однако, несмотря на их усилия, почти половина этих стратегий строго ограничена одним внутренним препятствием.

Ваши усилия по привлечению клиентов не будут эффективными без поддержки руководства. Несмотря на то, что 98% маркетологов понимают ценность эффективной стратегии взаимодействия с клиентами, но только 56% согласовывают ее с руководством.

В этой статье будут описаны действия, которые помогут добиться согласованности стратегий на исполнительном уровне.

От чего или кого зависит успешное взаимодействие с клиентами

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

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

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

Ключом к любой из них, вне зависимости от масштаба компании, является вклад руководства.

Конечно, стратегия для привлечения клиентов нужна. Но как получить участие и одобрение руководства?

1. Создайте кейс взаимодействия с клиентами

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

Опишите преимущества количественными показателями.

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

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

• 60% потребителей ожидают улучшения опыта взаимодействия от брендов, с которыми они связаны;
• 54% потребителей используют бренды, чтобы получать последние новости о товарах и услугах;
• 66% потребителей B2B советует своим знакомым бренды, с которыми у них хороший опыт взаимодействия;
• 66% потребителей B2B ожидают, что все отношения с брендом будут персонализированы.

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

2. Представьте свои цели взаимоотношений с клиентами

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

Создайте несколько целей на основе показателей, которые вы выбрали для количественной оценки, и экстраполируйте эти улучшения на ваши доходы. Например, вы знаете, что из всех отправленных вами писем открывается только Х%. Стратегия взаимодействия с клиентами направлена на улучшение этого показателя, чтобы открывалось Y%, что в течение одного года приведет к дополнительному доходу около Z долларов.

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

3. Опишите стратегию

Томас Эдисон как-то сказал:

«Видение без исполнения – это галлюцинация»

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

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

4. Послушайте и дайте обратную связь

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

Общими этапами взаимодействия с заказчиком являются следующие моменты:

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

Важной формой взаимодействия с заказчиком является документация, разрабатываемая в ходе реализации проекта в соответствии с требованиями ГОСТ 34 и RUP.

Рабочие группы формируются под конкретные задачи проекта. Синхронизация действий осуществляется через совет делегатов от рабочих групп. Участники рабочих групп самостоятельно вырабатывают принципы взаимодействия в группе. Группы могут привлекать к решению задач участников других групп. Успешные формы взаимодействия как внутри групп, так и между группами, могут быть взяты на "вооружение" новыми участниками проекта

В мире уже давно признано, что управление проектами - особая область менеджмента, применение которой дает ощутимые результаты. Профессионалы в этой области высоко ценятся (в США это третья по средней величине оплаты профессия после юристов и врачей), а сама методология управления проектами стала фактическим стандартом управления на многих тысячах предприятий и применяется в той или иной степени практически во всех крупных корпорациях. В прошлом году приняты стандарты управления проектами ANSI, разработан проект стандартов управления проектами ISO 10006.

Великолепные мероприятия. Технологии и практика event management. Шумович Александр Вячеславович

Процедуры взаимодействия с Клиентами

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

– регистрацию, подтверждение участия. Детально продумайте, как Клиент может сообщить о своем решении участвовать в вашем мероприятии (почта, телефон, факс, сайт, лично) и при помощи чего (анкета, звонок, покупка билета…);

– действия после регистрации. Сообщите о ваших действиях Клиенту. Должны ли вы выслать ему подтверждение? Должны ли (когда и как) напомнить о мероприятии? Отработайте и внутренние действия: составление списков участников, ведение базы данных. В зависимости от поступающих данных о количестве и составе участников корректируйте свои планы и действия;

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

– отказ или замену. Поскольку мы имеем дело с услугой, наши Клиенты могут передумать участвовать в мероприятии. Отработайте процедуру отмены участия или замены участника. В случае замены участника своевременно вносите изменения в базу данных. В случае отмены участия возвращайте деньги, если соблюдены оговоренные при регистрации условия. Это тоже важный момент: отказ вернуть деньги на ранней стадии может навредить вашим отношениям, и Клиент не захочет в дальнейшем с вами работать. С другой стороны, наступает момент, когда вы уже произвели необходимые затраты и, узнав об отказе от участия, не можете ничего изменить. Пусть ваши Клиенты будут информированы об этом, пусть понимают вашу позицию;

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

(Текст из буклета Eventum)

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

«Если вы желаете направить на мероприятие группу сотрудников, мы будем рады обсудить специальные условия и предоставить вам скидку.

Если вы предпочтете добраться в пансионат самостоятельно, пожалуйста, проинформируйте нас об этом и сообщите номер вашего автомобиля».

Из книги Компетентность в современном обществе автора Равен Джон

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

Из книги Большая книга директора по персоналу автора Рудавина Елена Роленовна

6. З. Документационное обеспечение процедуры аттестации – Только я вам ее не отдам. Потому что у вас документов нету. Мультфильм «Трое из Простоквашино» В перечне документов для аттестации есть составляемые руководителем структурного подразделения отзыв или

Из книги Покажите мне деньги! [Полное руководство по управлению бизнесом для предпринимателя-лидера] автора Рэмси Дэйв

Из книги Настольная книга по внутреннему аудиту. Риски и бизнес-процессы автора Крышкин Олег

Из книги Салон красоты: от бизнес-плана до реального дохода автора Воронин Сергей Валентинович

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

Из книги Управленческая элита. Как мы ее отбираем и готовим автора Тарасов Владимир Константинович

Новшество. Процедуры от GUINOT Процедура «Hydradermie Lift»Целый час отдыха и блаженства для вашей кожи!Долгие лабораторные исследования института GUINOT воплотились в поистине уникальную процедуру Hydradermie lift. Результат – разглаживание мимических морщин и мгновенный омолаживающий

Из книги Развитие потенциала сотрудников. Профессиональные компетенции, лидерство, коммуникации автора Болдогоев Дмитрий

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

Из книги Практика управления человеческими ресурсами автора Армстронг Майкл

Процедуры – возможности Этот параметр оценки в чем-то похож на предыдущий, однако есть и существенные отличия: мы оцениваем не столько склонность к процессу или результату, сколько то, каким путем идет человек в решении своих задач. Надо отметить, что речь идет скорее о

Facebook

Twitter

Вконтакте

Google+

Переводчик