Взаимодействие заказчиком процессе реализации проекта. Взаимодействие с заказчиком. Если клиентов переманил бывший сотрудник

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

Именно для этого случая была придумана методология управления проектами Agile.

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

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

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

Должностные обязанности руководителя отдела разработки

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

Зарплатные предложения и требования работодателей

Среднее зарплатное предложение для руководителя отдела разработки в Москве составляет 150 000 руб., в Санкт-Петербурге - 117 000 руб., в Волгограде - 66 000 руб., в Воронеже - 75 000 руб., в Екатеринбурге - 100 000 руб., в Казани - 75 000 руб., в Красноярске - 90 000 руб., в Нижнем Новгороде - 70 000 руб., в Новосибирске - 85 000 руб., в Омске - 75 000 руб., в Перми - 85 000 руб., в Ростове-на-Дону - 75 000 руб., в Самаре 75 000 руб., в Уфе - 75 000 руб., в Челябинске - 84 000 руб.

Соискатели, впервые претендующие на должность руководителя отдела разработки, должны иметь высшее образование (профильное или техническое), опыт создания программного обеспечения не менее 3 лет. Обязательно знание принципов объектно-ориентированного программирования и методологии разработки ПО (RUP, MSF), необходимы навыки работы с СУБД. Работодателями приветствуется знание нескольких языков программирования. Стартовый оклад начинающих руководителей отделов разработки в Москве составляет от 70 000 до 110 000 руб., в Санкт-Петербурге – от 55 000 до 86 000 руб., в Воронеже и Перми – от 35 000 до 55 000 руб.

Город	Уровень дохода, руб. (без опыта работы на данной позиции)
Москва	70 000 - 110 000	- Высшее образование (техническое / IT) - Знание одного или нескольких языков программирования - Понимание принципов объектно-ориентированного программирования - Знание методологии разработки ПО (RUP, MSF) - Знание английского языка на уровне чтения технической документации - Опыт работы с СУБД - Опыт работы в области разработки ПО от 3 лет Портрет соискателя в 1 диапазоне
Санкт-Петербург	55 000 - 86 000
Волгоград	30 000 - 48 000
Воронеж	35 000 - 55 000
Екатеринбург	47 000 - 74 000
Казань	35 000 - 55 000
Красноярск	42 000 - 66 000
Нижний Новгород	33 000 - 52 000
Новосибирск	39 000 - 62 000
Пермь	35 000 - 55 000
Омск	40 000 - 63 000
Ростов-на-Дону	35 000 - 55 000
Самара	35 000 - 55 000
Уфа	37 000 - 55 000
Челябинск	40 000 - 62 000

От кандидатов с опытом управления отделом разработки более 1 года работодатели ждут прежде всего развитых организаторских и руководящих навыков. Требования вакансий касаются наличия опыта планирования, организации и реализации проектов, разработки технической документации, а также навыков использования инструментальных средств управления проектами. Претенденты на соответствующие вакансии в столице могут рассчитывать на зарплату до 140 000 руб., в городе на Неве – до 109 000 руб., в Воронеже и Перми – до 70 000 руб.

Город	Уровень дохода, руб. (с опытом работы от 1 года)	Требования и пожелания к профессиональным навыкам
Москва	110 000 - 140 000	- Развитые организаторские и управленческие навыки - Навыки по планированию, организации и реализации проектов - Навыки использования инструментальных средств управления проектами - Навыки разработки технической документации Портрет соискателя во 2 диапазоне
Санкт-Петербург	86 000 - 109 000
Волгоград	48 000 - 62 000
Воронеж	55 000 - 70 000
Екатеринбург	74 000 - 94 000
Казань	55 000 - 70 000
Красноярск	66 000 - 84 000
Нижний Новгород	52 000 - 66 000
Новосибирск	62 000 - 78 000
Пермь	55 000 - 70 000
Омск	63 000 - 80 000
Ростов-на-Дону	55 000 - 70 000
Самара	55 000 - 70 000		Уфа	55 000 - 70 000	Челябинск	62 000 - 78 000

Дополнительное образование в сфере IT и опыт постановки полного цикла разработки – таковы наиболее типичные требования к соискателям со стажем управления разработками более 2 лет. Заработок, на который могут рассчитывать такие специалисты, в компаниях столицы достигает 175 000 руб., Санкт-Петербурга – 137 000 руб., Воронежа и Перми – 88 000 руб.

Город	Уровень дохода, руб. (с опытом работы от 2 лет)	Требования и пожелания к профессиональным навыкам
Москва	140 000 - 175 000	- Дополнительное образование в сфере IT - Опыт постановки полного цикла разработки (от ТЗ до сдачи проекта в эксплуатацию) Портрет соискателя в 3 диапазоне
Санкт-Петербург	109 000 - 137 000
Волгоград	62 000 - 77 000
Воронеж	70 000 - 88 000
Екатеринбург	94 000 - 117 000
Казань	70 000 - 88 000
Красноярск	84 000 - 105 000
Нижний Новгород	66 000 - 82 000
Новосибирск	78 000 - 98 000
Пермь	70 000 - 88 000
Омск	80 000 - 100 000
Ростов-на-Дону	70 000 - 88 000
Самара	70 000 - 90 000
Уфа	70 000 - 88 000
Челябинск	78 000 - 100 000

Наиболее высокие зарплаты предлагают руководителям отделов разработки крупные предприятия. Такие работодатели требуют от кандидатов опыта работы в организациях сходного размера не менее 3 лет. Компании, имеющие зарубежных партнеров, отдают предпочтение специалистам, свободно владеющим английским языком. Зарплатный максимум в Москве достигает 300 000 руб., в Санкт-Петербурге – 235 000 руб., в Воронеже и Перми – 150 000 руб.

Город	Уровень дохода, руб. (с опытом работы от 3 лет)	Требования и пожелания к профессиональным навыкам
Москва	175 000 - 300 000	- Опыт управления разработками в структуре крупной компании от 3 лет Возможное пожелание: знание английского языка на разговорном или свободном уровне Портрет соискателя в 4 диапазоне
Санкт-Петербург	137 000 - 235 000
Волгоград	77 000 - 130 000
Воронеж	88 000 - 150 000
Екатеринбург	117 000 - 200 000
Казань	88 000 - 150 000
Красноярск	105 000 - 180 000
Нижний Новгород	82 000 - 140 000
Новосибирск	98 000 - 170 000
Пермь	88 000 - 150 000
Омск	100 000 - 170 000
Ростов-на-Дону	88 000 - 150 000
Самара	90 000 - 150 000
Уфа	88 000 - 150 000
Челябинск	100 000 - 170 000

Портрет соискателя

Среди соискателей должности руководителя отдела разработки большинство составляют мужчины средних лет с высшим образованием. Представительниц слабого пола среди претендентов всего 5%, что является типичным для IT-сферы. 58% соискателей – специалисты в возрасте от 30 до 39 лет. 96% руководителей отделов разработки имеют высшее образование. Каждый третий соискатель свободно владеет английским языком.

Код для вставки в блог

Руководитель отдела разработки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сдача работ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первичными является звонок или e-mail , которые попадают на обработку к менеджеру по работе с клиентами. Менеджер рассказывает об услугах компании "Бихайв", дает ответы на все интересующие вопросы и объясняет дальнейший процесс взаимодействия заказчику.

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

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

Данные заносятся в систему для надежного сохранения всех необходимых данных заказчика и качественной разработки сайта в целом.

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

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

*Процесс от звонка до подписания договора обычно занимает не более 1-2 дней.

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

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

* Стоит понимать, что техническое задание является очень важным документом одновременно и для исполнителя, и для заказчика. Оно позволяет спроектировать и выполнить интернет-проект качественно и в срок.

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

Иногда заказчику трудно описать свои услуги самому или на это просто нет времени. В этом случае исполнитель готов выполнить работы по написанию недостающего контента на сайт (картинки, тексты, видео и т.п).

* Предоставление заказчиком необходимых материалов критически важен, так как:

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

* Уважаемые заказчики, не задерживайте пожалуйста разработку собственного же сайта и получение прибыли с него. Предоставляйте контент вовремя! В противном случае, проект будет заморожен до момент получения от вас информации и, соответственно, перенесен срок сдачи сайта. Если нет времени на сбор и написание информации, закажите написание текстов и обработку фотографий нам, это недорого.

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

* В зависимости от сложности проекта заказчику может быть предоставлен доступ к системе ведения проекта (например, Redmine), где можно выкладывать необходимые ресурсы проекта, следить за этапами разработки и публиковать замечания.

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

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

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

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

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

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

После проведения окончательного расчета вместе с документами и сайтом заказчик получает руководство пользователя, копию сайта на DVD и бесплатную техническую поддержку в течение 2-4 недель с момент сдачи-приемки сайта.

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

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

Надеемся, что описанная схема взаимодействия прозрачна и понятна. Если еще остались вопросы, то просим

Главная > Виды бизнеса

Взаимодействие заказчиком процессе реализации проекта. Взаимодействие с заказчиком. Если клиентов переманил бывший сотрудник

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

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

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

Сдача работ

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

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

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

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

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

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

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

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

Рекомендуем также