Чтобы вернуть бывших заказчиков, нужно понять, что повлияло на их уход. Тогда вы сможете предпринять правильные действия и вновь наладить сотрудничество
В этой статье вы прочитаете:
- Особенности работы с заказчиками, которые следует знать управленцам
- Какие правила работы с заказчиками удержат самых выгодных из них
Особенности работы с заказчиками в сфере b2b часто схожи от компании к компании. Приводим 4 совета для руководителей, которые помогут в организации работы с заказчиками и облегчат взаимодействие с ними.
Лучшая статья месяца
Мы подготовили статью, которая:
✩покажет, как программы слежения помогают защитить компанию от краж;
✩подскажет, чем на самом деле занимаются менеджеры в рабочее время;
✩объяснит, как организовать слежку за сотрудниками, чтобы не нарушить закон.
С помощью предложенных инструментов, Вы сможете контролировать менеджеров без снижения мотивации.
1. Если клиентов переманил бывший сотрудник
Ситуация . Уволившийся менеджер открывает свой бизнес и уводит часть клиентов, утверждая, что действует от имени своей бывшей организации. В таком случае нужно принять следующие решение в организации работы с заказчиками.
Решение . После увольнения сейлза сообщите всем его клиентам, какой именно сотрудник теперь будет с ними работать. Лучше всего, если генеральный директор лично позвонит руководителю каждой из компаний-клиентов. Заодно можно получить гарантии дальнейшего сотрудничества и разоблачить бывшего подчиненного.
2. Если клиента не устраивает уровень сервиса
Ситуация. Дотошный клиент требует, чтобы его заказ выполнили как можно скорее. Менеджер ссылается на затруднения, переносит сроки, раздражается или грубит. Заказчик отказывается от сотрудничества.
- Мотивация менеджеров по продажам: что действительно работает
Решение. Лично позвоните клиенту, объясните ситуацию и извинитесь. В одной из российских организаций беременная сотрудница, устав от привередливого клиента, бросила трубку. Генеральный директор перезвонил заказчику и рассказал, в чем было дело. На следующее утро клиент приехал в компанию с корзиной цветов для сотрудницы и сам принес извинения.
3. Если сотрудники не борются за возвращение клиента
Ситуация. Менеджеры не стремятся удерживать имеющихся или возвращать ушедших покупателей, притом что привлечение новых обходится компании недешево.
- Обучение менеджеров по продажам: готовим новичка в 3 шага
Решение . Введите материальную мотивацию. Например, можно выплачивать премию сотруднику, который после длительного перерыва в работе с тем или иным заказчиком сумеет заключить с ним новый договор.
4. Если клиенту предложили более выгодные условия
Ситуация. Заказчик не видит разницы между вашей компанией и конкурентами и выбирает более низкую цену. При этом он может не понимать, что потеряет в качестве.
Решение. Если вы не можете уменьшить цену без ущерба для качества, предложите клиенту особые условия сотрудничества (бонус, подарок, бесплатные услуги). В исключительных случаях, когда клиент стратегически важен, можно пойти и на снижение прибыли. С такими заказчиками должен общаться лично генеральный директор. Не бойтесь прямо спрашивать клиента, на каких условиях он согласен работать, - будет проще договориться.
Управление отношениями с заказчиком
Одним из самых многообещающих современных инструментов увеличения эффективности компании является управление отношениями с заказчиками (CRM). На реализацию CRM компании расходуют миллионы долларов, однако результаты во многих случаях оставляют желать большего.
Имеющиеся данные убедительно подтверждают, что 55% проектов по внедрению CRM не приносят позитивных результатов. Проведенное, по отзывам компаний, ранжирование современных инструментов управления бизнесом на основе критерия "степень удовлетворения результатами применения" отводит CRM последние три места из 25 сравниваемых методов.
Для того, чтобы понять причины такого положения, авторы (руководство компании Bam & Company, Boston, USA) за последние 10 лет исследовали более чем 200 компаний, среди которых были как успешные, так и неуспешные в части внедрения CRM.
Обобщенный вывод этого исследования может кому-нибудь показаться парадоксальным :
Большинство руководителей просто не понимает существа того, что они пытаются внедрить.
Неправильно оценивают стоимость внедряемого инструмента.
Не представляют необходимого временного отрезка для внедрения CRM.
Если говорить по существу, то исследование достаточно убедительно показало, что большинство руководителей, пытающихся внедрить CRM, попадают в одну из четырех ловушек. Эти ловушки - прямое следствие отношения к CRM, как к некоему программному продукту, который может автоматически управлять отношениями с заказчиком в нужном для вашей компании ключе. На самом деле этого не будет. Поскольку CRM - это процедура увязывания в единый комплекс стратегии заказчика и иных процессов, поддерживаемых некоторым программным продуктом, с целью увеличения лояльности заказчика по отношению к вашей компании, что может также и увеличить ее экономическую эффективность. Именно такое определение CRM будет использоваться далее во всех четырех разделах о подстерегающих менеджеров ловушках.
На самом деле, если не делать ошибок и не попадать в ловушки, внедрение CRM может дать существенный эффект и становится в настоящее время все более распространенным инструментом бизнеса. Если в 1989 г. зафиксировано первое - и единственное - упоминание об CRM в масс-медиа, то в 2000 г. число таких упоминаний превышает 14 000. Эти данные подтверждают и собственный вывод авторов о том, что CRM действительно становится наиболее популярным методом управления бизнес-процессами. Поэтому следует всего лишь грамотно использовать CRM, избегая ловушек, о которых и пойдет речь.
ЛОВУШКА 1
Внедрение CRM до создания стратегии взаимопонимания с заказчиком
Любой новый инструмент для управления бизнесом является в определенной степени соблазнительным, особенно это касается программных продуктов, которые как будто заранее обещают сами собой разрешить вечные проблемы. Это относится и ко многим программным продуктам CRM, обещающим автоматизировать деликатный и трудно формализуемый процесс привлечения выгодных и, одновременно, отторжения невыгодных заказчиков.
На самом деле CRM может и должна выполнять процесс привлечения заказчиков, однако только после того, как реализована стратегия взаимопонимания с заказчиком. Вот лишь краткие рекомендации к тому, как реализовать эту процедуру.
Начните с создания перечня заказчиков, с которыми вы хотите в дальнейшем работать, исключив из него тех, кто по тем или иным причинам вам неинтересен. Каждый заказчик предъявляет различные требования и по-разному оценивает существующие потенциальные услуги и продукты вашей компании. Следовательно, база данных ваших заказчиков должна быть сегментирована по группам, начиная с самых выгодных заказчиков, с которыми вы хотите расширять взаимоотношения, и, кончая теми заказчиками, с которыми, как вы считаете, не имеет смысла продолжать контакты. Распределение по группам поможет прояснить характер направления инвестиций в ту или иную группу: увеличивать инвестиции в выгодные взаимоотношения; управлять затратами на те группы, которые в перспективе могут стать выгодными, или прекратить инвестиции в невыгодные группы заказчиков. Задача построения стратегии взаимоотношений на основе поддержания знакомства с заказчиком достаточно сложна, однако вы на правильном пути, если во время этого процесса пытаетесь найти ответы на следующие пять вопросов:
Насколько должна измениться ценность наших предложений, чтобы заслужить большее внимание заказчика?
Каковы допустимые стратегические пределы финансово-экономических возможностей для преобразования наших услуг и продуктов в соответствии с пожеланиями заказчика?
Какой степени лояльности можно добиться от наших заказчиков? Насколько этот уровень может измениться за счет сегмента, определяемого заказчиком?
Каким количеством времени и финансовых ресурсов мы располагаем в настоящий момент для внедрения CRM?
Если мы верим в эффективность развития взаимоотношений с заказчиком, то почему мы сегодня же не предпринимаем шагов навстречу программе CRM? Что мы реально можем сделать на следующей неделе для развития взаимоотношений с заказчиком, не затратив ни одного цента на эту технологию?
Отвечая на эти вопросы, вы можете прийти к заключению, что CRM может затормозить снижение затрат вашей компании.
Вы можете решить, что дифференцированный подход к заказчикам не отвечает вашим интересам или не согласуется с философией компании. Это нормально. Все равно первый шаг - это создание базы данных, на основе которой компания сможет понять, с чем связана выработка стратегии взаимоотношений с заказчиком.
ЛОВУШКА 2
Попытка внедрить CRM до реализации соответствующих организационных изменений
Пожалуй, наиболее серьезной ошибкой является попытка внедрить CRM до построения организационной структуры вашей компании, ориентированной на заказчика. Если компания хочет улучшить взаимоотношения с выгодными заказчиками, она должна в первую очередь преобразовать свои ключевые бизнес-процессы, непосредственно взаимодействующие с заказчиками таким образом, чтобы удовлетворять их требования. Наличия понятной стратегии еще недостаточно: CRM начнет действовать эффективно только тогда, когда организация и процессы в ней - набор выполняемых работ, возможность измерения производительности труда, компенсационные системы, программы тренинга и т. д. - будут реструктурированы с целью более полного удовлетворения пожеланий заказчиков. С этой точки зрения также не менее важно оценить существующие в компании подразделения, выпускаемые продукты и действующие в других странах структуры. Достаточно часто, предполагая, что CRM непосредственно влияет только на процессы, ориентированные на заказчика, руководители вовсе забывают о необходимости изменения внутренней структуры компании, прежде чем инвестировать в технологию CRM.
Наиболее успешно внедрившие CRM компании, прежде чем приступить к реализации программы по CRM, по несколько лет работали над своей реструктуризацией. Таким образом, все компании, эффективно использующие CRM, предварительно проводили огромную работу по внедрению философии, строго ориентированной на заказчика, по изменению своей внутренней структуры, бизнес-процессов и внутренней культуры. До того как все эти мероприятия успешно реализованы, не имеет смысла обращаться к проектам по внедрению CRM. Разумеется, вся эта предварительная работа может потребовать месяцы и годы, но без нее попытки получить эффект от CRM безосновательны.
ЛОВУШКА 3
Представление, что чем больше разных технологий включено в CRM, тем лучше
Многие руководители полагают, что CRM должно быть обязательно насыщено технологиями.
На самом деле это не так. Взаимоотношения с заказчиком могут управляться различными способами, и задачи CRM могут быть выполнены без громадных инвестиций в технологии, а, например, простым ориентированием персонала на повышенное внимание к запросам заказчиков. Полагаться только на технологические решения или на применение высоких технологий вместо обычных, более простых, - это прямой путь к неоправданным затратам. Компании, где CRM эффективно используются, применяют весь спектр существующих технологий: низких, средних и высоких, а также смешанные сочетания этих технологий.
Начинать программу CRM целесообразно с внедрения самых простых технологий - может оказаться, что другие и не понадобятся. Обдуманное, постепенное наращивание технологий позволит менеджерам использовать индивидуальные программные продукты, которые на каждом новом шаге будут поддерживать последующие, более высокие технологии. Это тоже даст возможность менеджерам экспериментировать на своем уровне и находить реальные способы улучшения взаимодействия со своими лучшими заказчиками, независимо от усложнения применяемых технологий.
ЛОВУШКА 4
Пытаться добиться расположения заказчиков, не учитывая - их отношения к вашей компании
Эта проблема является следствием того, что существует множество видов взаимоотношений между производителями и потребителями услуг или продуктов, которые определяются разными факторами: принадлежностью компаний к той или иной отрасли; внутриотраслевыми отличиями компаний друг от друга; отношениями разных заказчиков к одному и тому же поставщику и т. п.
Кроме того, характер взаимоотношений между вашей компанией и заказчиком в немалой степени определяется тем, какими хотят иметь эти отношения обе стороны. К сожалению, достаточно часто менеджеры, внедряя CRM, пытаются построить взаимоотношения с заведомо неперспективными заказчиками или, наоборот, пытаются добиться расположения выгодных заказчиков неверными методами, Игнорирование всех этих факторов зачастую приводит к катастрофическим последствиям.
Необходимо всегда помнить, что взаимоотношения - это дорога с двусторонним движением. Пытаясь добиться лояльности выгодных заказчиков, следует не забывать об отношении этих заказчиков к вашей компании. С другой стороны, если вам не удастся добиться расположения таких заказчиков, совершенно очевидно, что они уйдут к вашим конкурентам. При этом необходимо учитывать временной фактор: затрачивая много времени и ресурсов на попытки привлечения равнодушных к вашим услугам или продуктам заказчиков, вы рискуете заслужить славу бездарной компании среди потенциально выгодных заказчиков. Следует иметь в виду, что наличие у менеджеров вашей компании контактов с определенными заказчиками еще не означает, что ими надо немедленно воспользоваться; это должно определяться в рамках построения стратегии взаимопонимания с заказчиками, а не программой CRM.
В итоге необходимо отметить, что CRM - это мощный инструмент развития современных бизнес-процессов, хотя и не простой для внедрения. При этом можно утверждать, что внедрение CRM нисколько не сложнее, чем внедрение других современных инструментов, используемых в бизнесе, если оно связано с реструктуризацией компании. Хотелось бы еще раз подчеркнуть, что успешное внедрение CRM в большей степени зависит от вашей стратегии построения взаимоотношений с заказчиком, чем от величины ресурсов, затраченных на технологию. Единственный путь заставить CRM успешно функционировать - это не жалеть временных затрат на построение успешной стратегии взаимоотношений с заказчиком, которая поможет вашему персоналу понять, что и зачем они собираются делать и, соответственно, выстроить ваши бизнес-процессы до того, как вы начнете внедрять собственно технологию CRM. Хотя технология и является могучим стимулятором процесса управления взаимоотношениями с заказчиком она остается только стимулятором и не более того. Современный инструмент развития бизнес- процессов -CRM (управление отношениями с заказчиками - УОЗ) - не является некоторым программным продуктом, который автоматически выстраивает взаимоотношения с заказчиками в нужном вашей компании направлении. На самом деле, в отличие от приведенного выше мнения многих руководителей, CRM включает необходимость построения достаточно сложной стратегии взаимоотношений с заказчиками, включающей привлечение выгодных заказчиков.
Итак, зачем нужна CRM, когда она будет работать и какие проблемы сможет решить?..
версия для печати
Итак, с чего начинаются взаимоотношения с клиентом ?
Как приходит клиент? Либо он сам обращается, либо нам кто-то рекомендует его, как компанию, которая хочет автоматизироваться.
С чего мы начинаем? Мы не бросаемся к телефону сразу договариваться о встрече - мы начинаем собирать информацию об этой компании .
- Для этого можно использовать открытые источники (СМИ, интернет, сайт, отзывы и пр.). Собираем все, что можно собрать - любую информацию.
- Потом идет самое интересное - это информация из неофициальных источников. Стараемся найти каких-то знакомых, друзей, бывших коллег и т.д., чтобы выяснить об этой компании все, что можно.
Для чего это нужно? Для эффективной работы, чтобы на основании полученной информации выработать тактику первоконтакта.
Потом происходит первоконтакт . На нем мы, в первую очередь, выясняем :
- Что нужно клиенту ?
- Адекватен ли он с точки зрения своего представления о порядке рыночной стоимости за данную работу и согласен ли платить за то, что ему нужно? Это - очень важный вопрос. Естественно, на первой встрече никто не называет каких-то конкретных сумм, но может быть назван порядок цифр или некий интервал, куда скорее всего попадет проект. Выясняется отношение к этим цифрам. Например, если мы приблизительно оцениваем, что этот проект стоит 3-5 миллионов, а потенциальный заказчик считает, что миллион - это очень много, то, наверное, у нас с ним ничего не получится. К тому же часто бывает, что у клиента нет четкого представления о том, что ему нужно: просто хочет, чтобы все было хорошо.
- На основе этого мы уже можем сделать вывод - нужен ли нам такой клиент, и нужен ли такой проект.
Установление взаимоотношений
Второй этап - это установление отношений с клиентом :
- Наверное, лучше всего , чтобы с клиентом были построены неформальные, теплые отношения . Конечно, это получается не всегда.
- В любом случае, с первого контакта мы стремимся установить с клиентом именно партнерские отношения . Это непростой и не быстрый процесс. Особенно если речь идет о крупных клиентах (компаниях с большим оборотом, со статусом) - они всегда смотрят свысока. Они зовут автоматизатора, как вызывают электрика для замены лампочки: «вот эту, пожалуйста. Вот вам деньги, вы свободны» . С таким отношением мы стараемся боремся с самого начала и, порой до конца проекта. Вся наша технология выстраивания взаимоотношений с клиентом основывается именно на формировании партнерских отношений.
Результатом этого этапа является предварительное решение о работе с данным клиентом и формирование положительного образа в глазах клиента.
Хочу остановиться на формировании положительного образа. На основе собранной первоначальной информации мы решаем, кому из наших сотрудников можно доверить представлять нашу фирму на первой встрече с клиентом. Это очень важный момент. Например, если мы отправим на первоконтакт прекрасного специалиста, но у него серьга в ухе, набриолиненный «кок» и т. д., то клиент может посмотреть и сказать: «да ну его!» Такое бывает. Или, например, пришел аккуратненький, подстриженный, в костюме с галстуком, но мальчик лет 20. И клиент смотрит и говорит: «Это же мальчишка, о чем с ним говорить? Как с ними работать - они меня совсем не уважают, прислали ко мне мальчишку!». Поэтому сбор этой информации нужен в том числе и для того, чтобы понимать, кому доверить первоконтакт и как себя вести контактеру, как выстраивать легенду, как преподносить себя.
Выявление лиц, принимающих решения
Следующий очень важный вопрос - это выявление лиц, реально принимающих решения (так называемые ЛПР). Этот этап состоит из двух пунктов:
- Выясняется , кто принимает решения по нашему проекту.
- И второй пункт - выявляются лица, влияющие на ЛПР
.
Что это значит? Например, известно, что решения в компании принимает генеральный директор, а еще у него есть финансовый директор и бухгалтер. Это может быть бухгалтер, который выполняет все, что скажет директор, и сидит тихо в уголочке, а может быть и наоборот, бухгалтер, который говорит директору, что надо сделать вот так и директор его слушается. И если мы изначально выявили, что этот человек имеет влияние на своего директора, то это - наш козырь, следовательно, нужно попытаться установить отношения именно с этим бухгалтером. Я условно сказал, что это бухгалтер - им может оказаться кто угодно (например, начальник отдела продаж или какой-то зам, которому полностью доверяет генеральный директор или собственник компании). Надо устанавливать отношения именно с лицом, влияющим на лицо принимающее решения.
Цель, как вы уже видите, - это выявление ЛПР. И результат - это список ЛПР и лиц, влияющих на ЛПР.
Наш опыт показывает, что нужно постараться как можно быстрее встретиться с лицами, принимающими решения - обычно ими является либо высшее руководство, либо собственник компании. Это необязательно должно произойти на первом контакте, но если такая встреча на предварительном этапе не происходит, то, как правило, ничего хорошего из нашего проекта не получится.
Установление партнерских отношений
Следующий этап - установление партнерских отношений .
- Мы изначально делаем акцент на двусторонней ответственности : даже в договоре, если это возможно, прописываем не Заказчик-Исполнитель, а «Первая сторона » (это Заказчик) и «Вторая сторона » (это Исполнитель). Правда, иногда какие-то крупные госструктуры говорят, что юридический отдел им этого не разрешает, потому что документы проверяет казначейство, Минфин и прочии. В этом случае мы прописываем стандартные формулировки - «Заказчик и Исполнитель». Но если есть возможность, то - «Первая» и «Вторая сторона».
- Всеми силами мы пытаемся донести, что это - совместная работа. Руководители с обеих сторон выступают, как высокие договаривающиеся стороны - именно они решили сделать этот проект автоматизации. Для реализации этого проекта они набирают команду, состоящую как из сотрудников первой стороны, такииз сотрудников второй стороны - это так называемая «Объединенная рабочая группа », которая и делает проект. Естественно, каждая сторона вкладывает в проект свои ресурсы: материальные, технологические, методологические, финансовые - потому что, в общем-то, речь идет о достаточно больших проектах.
- Работу объединенной рабочей группы контролирует «Объединенная наблюдательная комиссия» - это высший контролирующий орган, обычно состоящий из топ-менеджмента обеих сторон.
- И расписывается ответственность каждой стороны , чтобы сотрудники заказчика понимали, что за проект отвечаем не только мы, но и они. Мы тратим очень много сил и времени, чтобы донести до клиента то, что мы делаем этот проект вместе с его сотрудниками, и что от и от их работы напрямую зависит с каким качеством и особенно, в какие сроки будет выполнен проект.
Ну и результатом этого этапа является фиксация (формальная или неформальная) отношений равных партнеров:
- Формальная фиксация - это договор.
- А неформальная - это могут быть какие-то служебные документы, в которых мы всегда стараемся прописывать «Первую и Вторую сторону» и их отношения.
Информирование Заказчика о технологии ведения проекта
Следующий этап - это информирование заказчика о технологии .
- На крупных проектах у нас, в обязательном порядке, есть «Курс лекций и семинаров по введению в проектную технологию
». В этом курсе лекций мы доводим до сотрудников заказчика, как будет происходить весь процесс проекта:
- Как делается проект по нашей технологии?
- Кто за что отвечает?
- Кто что делает?
- Для чего делаются те или иные действия?
- Для чего нужен тот или иной документ? Что он дает обеим сторонам? (чтобы сотрудникам стало понятно, что партнерские отношения дают преимущества не только нам, но и заказчику).
- При каждом удобном случае мы информируем ЛПР обо всех возникающих в ходе работы проблемах . Для этого у нас есть ряд специальных ежедневных документов - например, «Дневник контактов» или «Ведомость отклонений». И пусть не ежедневно, но через каждые несколько дней руководство заказчика должно с ними знакомиться. А поскольку, как правило, сразу находятся отговорки: был занят, не читал и прочее, то, соответственно, об этом надо постоянно напоминать, может быть, даже смоделировать какие-то ситуации, заставляющие руководство читать эти документы.
Результатом этого этапа является то, что все ответственные лица заказчика прошли курс лекций и, самое главное, что руководство имеет четкое представление о том, как производятся работы (естественно, если оно контролирует проект достаточно плотно).
Организация отношений с Заказчиком
Следующий этап - это организация отношений с Заказчиком. Здесь я хочу вам рассказать об одной интересной «фишке»: у нас на проекте есть такие роли (это не должности, а именно роли), как «Контракт-менеджер» и «Объект-менеджер» (чаще всего они могут быть также совмещены и с какими-то другими обязанностями). Как здесь на слайде указано, эти роли соответствуют определениям «плохой» и «хороший».
- Контракт-менеджер - это «плохой». Это может быть отдельный человек или кто-то из топ-менеджеров. Чаще всего функцию контракт-менеджера выполняет руководитель проекта (если он, конечно, в состоянии это сделать). Это человек «Нет» - он может прийти к лицу принимающему решения, и сказать: «у нас по контракту написано вот так, а вы сейчас делаете по-другому, и из-за этого возникает отклонение. Давайте разбираться». Он всегда указывает на недостатки, на несоблюдение технологии, призывает соблюдать документацию - поэтому он всегда «плохой».
- А объект-менеджер
- это «хороший». Это человек, у которого в силу разных причин сложились хорошие отношения с лицом принимающим решения от заказчика. Может быть, он просто оказался ему симпатичен. Или, например, у них есть какие-то связи (родственные, клановые, дружеские - какие угодно). Главное, что клиент к нему расположен.
Объект-менеджер у нас фактически ведет этот объект. Обратите внимание, это не проект-менеджер, это специальный человек, который занимается тем, что поддерживает хорошие отношения с руководством заказчика , и, когда возникают какие-то острые проблемы, он их сглаживает.
Например, после того, как контракт-менеджер выговорил клиенту о несоблюдении каких-то условий наших договоренностей (это может закончиться, в общем-то, каким-то нелицеприятным для нас разговором), приходит объект-менеджер и начинает успокаивать клиента.
Я не зря сказал, что объект-менеджер называется «хорошим». Обычно говорят, что «хороший парень» - не профессия. Но у нас это профессия. Объект-менеджер - это «хороший парень». Он может не быть специалистом-профессионалом ни в чем, но с ним клиенту хорошо - он пришел, поговорил с ним (может быть, о политике, о футболе и т.п.), и клиенту стало хорошо, у него изменилось отношение. Клиент до этого собирался нам что-то выговаривать, за что-то нас наказывать, но теперь он уже все понимает, ему вообще неудобно с нами плохо говорить.
Вот это - функция объект-менеджера. Он закрепляется за каждым достаточно серьезным клиентом.
Конечно, все то, о чем я говорю, требует определенных ресурсов, затрат. И, естественно, создавать всю эту структуру ради маленького магазинчика не имеет смысла - это все делается только ради достаточно больших объектов.
Результатом данного этапа становится назначение подходящих контракт- и объект-менеджера для данного клиента, ведь очень важно подобрать этих людей правильно.
Организация проектных процессов
Следующий этап - это организация проектных процессов . По моему мнению, их бывает всего два:
- Мониторинг хода проекта;
- И принятие управленческих решений по результатам мониторинга.
Самое главное - это убедить заказчика работать по нашей технологии . Этот порядок работы объясняется заказчику и в личных беседах с лицами, принимающими решения, и при посещении ответственными сотрудниками курса лекций (там объясняется, как и что будет происходить на проекте - сотрудники заказчика должны в обязательном порядке, под подпись, посещать этот курс).
Иногда убедить заказчика работать по нашей технологии бывает очень сложно. Например, у нас был один клиент - очень крупная ИТ-компания. Причем она сама занималась автоматизацией на MS Navision, но в силу определенных причин решила позвать нас, чтобы мы их автоматизировали на 1С. Так вот, работа с ними была настоящим кошмаром - плакали все, и менеджеры, и программисты. Потому что это была очень крупная компания (мы по сравнению с ними мелкие), и они считали, что они все знают, и пытались нас учить. Они постоянно говорили: «ребята, вы не так все делаете, есть же такая-то технология, вы должны делать так». Естественно, это происходило только на уровне среднего звена, руководитель (который был основным собственником и генеральным директором компании), конечно, все прекрасно понимал, и после его вмешательства все решалось, но его очень трудно было достать. А на уровне среднего звена были постоянные проблемы, постоянные попытки научить.
Мы на каждом проекте, в обязательном порядке, стараемся донести до клиента мысль о том, что в своем бизнесе он профессионал (и мы туда, естественно, не лезем), а в вопросах автоматизации - мы профессионалы, поэтому нам надо доверять, и не пытаться указывать нам, что и как делать. Тем более, если нам не просто указывают, а пытаются нас заставить: «давайте сделаем по-другому, потому что я так хочу». Вот эти вещи мы сразу стараемся пресечь. Конечно, «пресечь» - это громко сказано, во всяком случае, постараться достаточно мягко объяснить. Если уж мы согласились на этот проект, решили, что нас он устраивает, ввязались в эту «битву», то теперь, естественно, приходится с этим работать.
Ограничение желаний клиента
Следующий этап - это ограничение желаний клиента . С этим, наверное, сталкивались все (когда начинаются так называемые «хотелки» - еще, еще и еще). Здесь мы поступаем достаточно просто:
- Например, когда клиент говорит, что в отведенные рамки бюджета и сроки надо еще сделать вот это и вот это, то начинается достаточно порой, сложная процедура объяснений, как все это работает
. Мы напоминаем клиенту о том, что у нас с ним заложен бюджет, выделены люди (объединенная рабочая группа), каждая сторона проекта вкладывает свои ресурсы. Поэтому если возникает дополнительная работа, то требуются дополнительные часы, дополнительные люди. Откуда их брать?
Или если клиент задерживает проект, то и наши, и его люди простаивают, а им платятся деньги. Откуда брать эти ресурсы? Я уже не говорю о том, что эти люди не просто получают зарплату, но и приносят какую-то прибыль компании. Естественно, компания не хочет терять эту прибыль. Достаточно подробно клиенту объясняется, и клиент обычно очень хорошо реагирует. - Мы разъясняем, даем подробную цифровую раскладку - откуда, что, до копеечки. И говорим, что если вы хотите, чтобы мы сделали еще и вот это , то - пожалуйста, это займет столько-то часов, и их надо оплатить . В конце концов, клиент с нами соглашается и либо отказывается от своей "хотелки", либо оплачивает дополнительные часы. Конечно, бывает по-разному - я сейчас немного идеализирую картину.
Здесь я хочу привести еще один пример взаимоотношений. Мы работали с одной очень крупной компанией (они уже были на этапе обслуживания), и там периодически возникали какие-то задания на доработки: например, сделать какой-то мудреный отчет или еще что-то. И вот, главный бухгалтер компании нам поручил определенную работу, и мы ее сделали. А когда пришло время расплачиваться, он сказал: «В общем-то, я ошибся, это все нам совсем не нужно». Но работа-то была сделана, следовательно, надо было заплатить. А он говорит: «Нет, я за это платить не буду, я же не могу пойти к президенту компании и объявить ему, что я дурак, и заказал не то, что нужно». Причем, компания была очень крупная, нефтяная, отношения были хорошие и с ней, и с этим человеком. И мы не стали настаивать - не платит, так не платит. Хотя, из-за этого мы потеряли по тем временам достаточно большую для нас сумму денег (это был 2004 год). В конце года была деноминация (азербайджанский манат отбрасывал нули). И для всех клиентов, которые были у нас на обслуживании, мы делали этот перерасчет в рабочем порядке - никаких дополнительных денег. А вот к этому бухгалтеру (на тот момент с того случая прошло буквально меньше года), мы подошли и сказали: «Помните, вы нам не заплатили? Мы тогда пошли вам навстречу. А сейчас - деноминация. Давайте мы сделаем это небесплатно?» Без вопросов - мы выписали счет, он оплатил.
К чему я привел этот пример? К вопросу о важности хороших отношений. Если бы мы тогда встали на дыбы и потребовали заплатить нам эту сумму, то у нас был бы риск потерять хорошего клиента. А так мы сохранили с ним отношения.
Кто занимается объяснением этого бюджета :
- Этим в рабочем порядке занимается проект-менеджер - руководитель объединенной рабочей группы, которая, собственно, и выполняет проект.
- Если у него не получается, то подключается контракт-менеджер , который объясняет по циферкам и говорит, что это - нарушение контракта, нарушение договоренностей .
- В самых сложных случаях подключается объект-менеджер , который старается объяснить (уже, конечно, без каких-то жестких рамок) заказчику то, почему ему необходимо ограничить свои желания.
Обычно, если цифры расписываются очень подробно, тогда этой раскладки и её объяснения бывает достаточно.
Сдача работ
Сдача работ. Здесь, в общем-то, больших проблем обычно не бывает, потому что процедура сдачи работ у нас очень подробно прописана в соответствующих документах .
Но на этом этапе элемент неформальности (хорошее отношение ), конечно, также облегчает жизнь и нам, и заказчику тоже.
Цель этого этапа - добиться сдачи работ в полном соответствии с правилами, установленными в соответствующих документах, которые являются приложением к договору, подписанному и клиентом, и нами. Соответственно, всегда можно предъявить, что есть такие правила.
Постпроектные взаимоотношения
Ну и, наконец, постпроектные взаимоотношения. Это тоже очень важная составляющая. К чему мы должны стремиться по окончании проекта? К заключению договора на обслуживание, естественно. Но так происходит не всегда. Потому что есть понятие «результат», и есть понятие «итог» - и это немного разные вещи.
Приведу пример. У нас был проект с одной очень серьезной компанией, и результат на том проекте был для нас блестящим - это был один из тех редчайших случаев, когда мы полностью уложились и в бюджет, и в срок, абсолютно так, как изначально было запланировано. Такой был результат. А итог проекта заключался в том, что договор об обслуживании не был подписан. Более того, заказчик сказал, что он никогда больше не будет работать с нами. Вот такой итог. Иными словами, результат блестящий, а итог - весьма печальный.
Почему это произошло? Потому что не было неформальных взаимоотношений. Мы тогда только что разработали свою технологию проектной документации, и это был клиент, на котором вся эта технология, в полной красе, была продемонстрирована. И когда мы спросили у заказчика: «Хорошо, вы с нами не будете работать - а есть ли какие-нибудь претензии к нам?» И нам сквозь зубы со злостью было сказано: «В том-то и проблема, что никаких претензий мы предъявить не можем - что вам ни скажи, у вас на все есть бумажка, и мы ничего не можем сделать. Нас так не устраивает, и больше мы с вами работать не будем. Другие компании можно попросить что-то сделать дополнительно, а вы отказываетесь - вот у вас бюджет, вот у вас так положено, вот срок. Шаг в сторону - и вы тут же показываете нам бумажку с нашей подписью».
Поэтому итог получился печальным. Но еще раз подчеркиваю, что такой итог получился из-за того, что не было неформальных взаимоотношений.
Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.
Приглашаем вас на новую конференцию .
Проекты бывают разные, и управлять ими нужно по-разному. В крупных проектах, где занято большое количество разработчиков, не говоря уже о бизнес-аналитиках, тестировщиках и собственно заказчиках проекта, вопрос координации действий встает на первый план, заслоняя собой все другие задачи.
Именно для этого случая была придумана методология управления проектами 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% руководителей отделов разработки имеют высшее образование. Каждый третий соискатель свободно владеет английским языком.
Код для вставки в блог
Руководитель отдела разработки
Навыки управления проектами – такое требование часто встречается в вакансиях для руководителей отдела разработки. На деле за этими словами может скрываться намного больше, чем кажется на первый взгляд.
Выделенная команда
Эта модель позволяет заказчикам расширить свою штатную команду за счет специалистов, работающих офсайт. ScienceSoft выделяет команду из специалистов, предварительно выбранных заказчиком. Команда перенимает нормы и методологии разработки программного обеспечения и управления проектами заказчика. Управление проектом может выполняться как на стороне заказчика, так и из офиса ScienceSoft. В обоих случаях заказчик имеет полный контроль над жизненным циклом ПО.
