Содержание
Всем привет! Продолжаю повествовать про парк-радар. Так уж получилось, что я кулачки держал за него зря, потому что в один непрекрасный день парк-радар снова завыл. Если кому-то помогает держание кулачков за чтобы то (кого бы то) ни было, отпишитесь. А то многие пишут, что держат за кого-то (чето-то) кулачки, но никто не отписывался о результатах.
Делать нечего, менять так менять, всё-таки не зря покупал и красил новые датчики. Решил снова попытать официального дилера. А тут как раз оказия случилась, климат-контроль перестал справляться с жарой. А жара была этим летом аж до 28 выше нуля поднималась. 6 лет машине, как-никак, пора бы и заправиться свежим хлад-агентом, а то старого, я так понял, что уже и не осталось совсем.
Приехал я в назначенное время с проблемой кондиционера, невзначай так говорю, а можно, мол, заодно бампер снять, мои датчики поставить и поставить бампер взад. И сколько эта музыка будет стоить? В этот раз гораздо более толковый менеджер, после недолгих подсчётов, выдал мне сумму в 4 тысячи. Это вместе с заправкой кондиционера. Вот это сразу видно — профессионал, знающий своё дело! По-рукам, говорю я обрадованный. Ну и плюс на скидочной карте у меня завалялась тысчёнка рублей, так что вся музыка вместе с 4-мя новыми парктрониками мне обошлась в 6 т.р. Заметьте, как сильно эта сумма диссонирует с изначально объявленными мне, 35 тысячами за ровно тоже самое. Прекратите нанимать «эффективных менеджеров» и люди к Вам потянутся. Истинно Вам говорю.
В общем поменяли все датчики, не без труда, конечно. Я сказал всем большое спасибо и поехал, радуясь рабочим парктроникам. Но недолго же я радовался. А всё потому что через день после установки новых датчиков, я обнаружил, что с машиной опять что-то не то, она как-то взбрыкнула, когда я стартанул двигатель. Не обратил особого внимания на этот печальный факт, а надо было. Заглушить авто и снова попытаться завести, а не ехать. Потому что, когда закончился рабочий день, машина заводиться уже не хотела. А напряжение сигнализация мне показала в 10,5 Вольт. Хорошо, что у меня механика, и машину завели при помощи троса и Тигуана. Хорошо, сдох аккумулятор. А что же его так высадило то? спросите Вы. И конечно же я первым делом подумал на новые датчики, Вы, надеюсь, подумали про них же? Купил я новый аккумулятор, сдав старый и приехал на следующий день канифолить мозги дилеру. Мол, так и сяк, выясните, плез, в чём причина скоропостижной смерти аккумулятора, и не новые ли датчики этому виной, провались они совсем и будь они неладны. Подключился значит, электроспец, со своим нутыбуком к моей машине и говорит, мол, а что, всё в порядке, ошибок нет. Вот и отлично, значит, сдох аккумулятор и это просто совпало так, что он сдох почти сразу после замены датчиков парк-радара. На всякий случай, я периодически проверял напряжение, но всё хорошо, проблемы с аккумулятором больше не было. Хорошо, что аккумулятор сдох летом, а не зимой. Купил я в этот раз какой-то Мутлу, подходящий по параметрам и размеру. Изначально ехал за бошем, но продаван отговорил и подкупило то, что дата выпуска у этого мутлу — Май 2020.
Напряжение пока стабильно держится на 13,1 Вольтах при закрытой машине. Сдохший аккумулятор показывал 12,6 стабильно, пока был в рабочем состоянии.
Вернусь к тому, с чего начал, к парктронику. А он, будь он трижды неладен, не показывает самых ближних рисок к нарисованной машине на экране. Благодаря этим ближайшим красным рискам можно понять, что ты подъехал к препятствию ближе, чем на 15 см. И именно этого мне и не хватает, когда я паркуюсь в стеснённых условиях. Т.е. ради чего весь сыр-бор и затевался. Когда я об этой проблеме рассказал менеджеру, тот озвучил её электроспецу, а электроспец и говорит, что мол, а это штатный режим вообще-то. Т.е. как это штатный? Менеджер не стал мне ничего объяснять, пригнал новую машину и показывает мне работу парктроника. Я смотрю, а он действительно, ближайшую к машине рисочку-то и не показывает. Что передние датчики, что задние. Ни слова больше не говоря, показываю менеджеру работу датчиков на октавии:
Вот те и раз, говорит менеджер. Да уж, подкузьмил производитель. Ухудшение характеристик налицо. Теперича я записался к одному спецу по кодировкам, может получится-таки привести работу парк-радара в окончательную норму, чтобы и передние датчики заработали как-надо. Нужно ли держать кулачки? Отпишитесь, кто в курсе. )
Адаптация нового менеджера по продажам — одна из главных составляющих успеха компании. От эффективности этого процесса зависят следующие факторы:
- Стоимость менеджера по продажам;
- Скорость подбора менеджера;
- Какие качества нужны будут менеджеру по продажам;
- Срок, через который менеджер начнет приносить доход.
Хотите выстроить идеальную систему продаж?
Расскажу одну историю, случившуюся на нашем проекте: Партнер жалуется, что перебрали много менеджеров, но они приходят, сидят месяца 3, вникают в продукт, ничего в итоге не продают и все начинается заново. Постоянная текучка, постоянные затраты на зарплату, налоги и организацию работы менеджеров, а результатов никаких. Ситуация типичная для многих компаний. Далее произошел забавный диалог:
Эксперт: «А как вновь пришедшие менеджеры вводятся в работу?»
Партнер: «Ну как, приходят, смотрят, как работают старые менеджеры, вникают в ситуацию и начинают работать.»
Эксперт: «А существующие менеджеры хорошо продают?»
Партнер: «Нет, очень плохо!»
…..
Забавный диалог, не правда ли? Хорошо, что закончилось все хорошо и подобная адаптация не привела к банкротству, но не все имеют возможность понять простые истины. Именно поэтому написана эта статья. По прочтении обещаю показать, как:
- За 2 недели понять, будет ли менеджер успешен, даже если цикл сделки 1 год;
- Какие материалы необходимо подготовить менеджеру, чтобы он начал продавать в первый день работы;
- Как подготовиться к выходу нового менеджера на работу.
Почему мы рассчитываем, что новый менеджер по продажам, выйдя на новую работу, должен знать, что ему нужно делать и будет делать это успешно? Надеемся, что к нам придет самородок, который сам проведет анализ рынка, выстроит алгоритм оптимальных действий и будет успешен в этих действиях? Да, такие самородки, конечно, попадаются, только не знаю, выигрывает компания, заполучив их или попадает от них в зависимость. Гораздо эффективнее определить четкий алгоритм достижения успеха в вашем бизнесе, дать менеджеру четкие инструменты, которые он будет применять на этом пути и просто контролировать его действия в соответствии с алгоритмом.
Чтобы было более наглядно, объясню на простом примере
Менеджеру ставится задача из точки А (отсутствие продаж) прийти в точку В (выполнения плана продаж). Мы можем оставить на откуп менеджеру, каким путем он пойдет, а можем для него определить этот путь. Тем самым мы снижаем требования к менеджеру, он не должен быть стратегом и картографом, а должен быть тактиком и уметь перемещаться по карте. Далее разделяем его маршрут на отрезки. В результате оцениваем не по одному критерию «Дошел или не дошел до точки В», а разделяем его путь на множество отрезков, каждый из которых является критерием. Ежедневно оцениваем перемещение менеджера по карте. Если на второй день он все еще в точке А, возможно, мы не дали ему каких-то инструментов. Если через 2 дня он все еще в точке А, стоит задуматься и помочь менеджеру сделать первый шаг. Если через 2 недели он сделал несколько неуверенных шажков, и все еще не пришел в точку А1, есть смысл надеяться, что через несколько месяцев менеджер дойдет до точки В? Я бы на это не рассчитывал.
Теперь возвращаемся в наш отдел продаж и определяем, как это должно выглядеть:
- «Нарисовать карту». Значит определить, каких клиентов нужно искать, по каким параметрам их выбирать, по какому сценарию привлекать этих клиентов, какие этапы переговоров нужно пройти, какие аргументы использовать и т.д.;
- «Измерять ежедневно, куда дошел менеджер». Значит понимать, сколько звонков, встреч или других действий совершил менеджер для привлечения новых клиентов. Как продвинулся в работе с каждым из этих клиентов.
- «Оценивать работу над ошибками». Понятно, что мы не ожидаем от менеджера, что он сразу будет делать это наилучшим образом. Но мы будем с ним ежедневно обсуждать ошибки, будем давать ему советы, как лучше двигаться и если через 2 недели он будет совершать те же ошибки и будет встречать те же барьеры, что и в 1 день, есть смысл ждать, что этот менеджер чему-нибудь научится? Я бы не стал;
Есть еще один нюанс. Многие скажут: «Как менеджер, ничего не зная о товаре, может начать его продавать? Именно 2-3 месяца и нужно менеджеру, чтобы изучить товар.»
Вот тут и загвоздка. Сколько бы менеджер ни читал о товаре, сколько бы он не изучал свой сайт, сайты конкурентов, какие бы справочники он не перебирал, он никогда не изучит товар в достаточной степени, пока не услышит вопросы от конкретного клиента, пока не пропустит через себя информацию, пока не услышит от клиента «как это на самом деле». Поэтому я против того, чтобы тратить время на доскональное изучение товара. В большинстве бизнесов достаточно базового представления о товаре или услуге и FAQ самых популярных вопросов и возражений клиентов.
Итак, ответы на вопросы:
Как за 2 недели понять, будет ли менеджер успешен, даже если цикл сделки 1 год?
Определить, что должен сделать менеджер за 2 недели, чтобы выполнить план через месяц или год. Давать ему обратную связь по эффективности его работы и оценивать, как он работает над ошибками.
Какие материалы необходимо подготовить менеджеру, чтобы он начал продавать в первый день работы:
- 1. Общее описание рынка, отрасли, продукции;
- 2. Сравнительная характеристика с конкурентами;
- 3. FAQ (ответы на самые популярные вопросы и возражения);
- 4. Алгоритм привлечения клиентов в компании;
- 5. 20-30 характерных записей разговоров успешных менеджеров;
Как подготовиться к выходу нового менеджера на работу:
- 1. Подготовить материалы указанные выше;
- 2. Установить систему записи разговоров и CRM систему;
- 3. Определить критерии ежедневной оценки эффективности менеджера;
- 4. Определить форму обратной связи по работе менеджера.
Ничего сверхъестественного и необыкновенного. Но как показывает практика — это очень действенно. Если не хватает опыта, чтобы создать систему, которая позволит быстро и эффективно ввести менеджеров в работу, мы готовы в этом помочь за скромное вознаграждение. Блиц-аудит вашего бизнеса бесплатно.
Ларри Пейдж и Сергей Брин всерьез считали, что их компании управленцы незачем. В 2002 году они попытались выстроить горизонтальную оргструктуру — без менеджеров, руководящих программистами. Так, считали они, ничто не будет мешать быстрому обмену и появлению идей. Кроме того, им хотелось воссоздать ту атмосферу студенческой жизни, которая так нравилась им в университете. Эксперимент длился недолго: спустя несколько месяцев его пришлось прекратить. Брин и Пейдж изменили свое мнение о внутреннем устройстве компании, когда сотрудники валом повалили к Пейджу с вопросами, далекими от творчества: с финансовыми отчетами, жалобами друг на друга и т.п. А уж когда компания стала расти, ее основатели убедились, что управленцы полезны и в других отношениях: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.
Тем не менее, многие разработчики до сих пор считают, что менеджеры им не нужны. Так ли это? Давайте разбираться вместе.
Когда менеджер – это плохо
Очень часто разработчики недовольны менеджерами. Вместо того, чтобы писать код и думать об идеальной архитектуре, их заставляют заполнять какие-то отчеты и заниматься другой скучной и непонятной работой. Менеджеры часто отсуствуют на рабочем месте, принимают участие в огромном количестве митингов, а результат их работы очень сложно измерять в строках кода, а это как раз то мерило, за которое в результате платит заказчик.
Доля правды (причем, очень существенная) у этой точки зрения есть. Очень часто менеджеры, дабы оправдать отсутствие каких-либо результатов своей работы, заставляют своих подчиненных рисовать ежедневные отчеты, фиксировать каждый шаг, например, потраченное время на посещение курилки, с целью имитации бурной менеджерской деятельности. Некоторые менеджеры только тем и занимаются, что «внедряют процесс”, проводят скрамовские пятиминутки и организовывают митинги по каждому поводу.
Первое правило плохого менеджера: не знаешь, что делать – организуй митинг.
Причина того, что многие ИТ-менеджеры не очень компетентны, заключается в том, что у нас нет полноценного образовательного института, который готовил бы менеджеров с ИТ-уклоном. Поэтому в менеджеры часто идут либо очень плохие, либо очень хорошие разработчики, либо те, кто в ИТ никогда не работали, но хорошо говорят на английском. Во всех этих случаях наличие менеджера на проекте, скорее, вредит проекту, чем помогает.
В одной компании, где в отделе работало около десяти проджект-менеджеров, был проведен небольшой опрос на тему: читали ли они книгу «Deadline: роман об управлении проектами”. Результат был ошеломляющий: книгу не читал никто. Спрашивать о Бруксе и его мифическом человеко-месяце никто не стал.
Почему никто не готовит менеджеров? Давайте займемся арифметикой. Чтобы из айтишника сделать менеджера нужно от 0.5 года (практически идеальный и редко встречающийся в дикой ИТ-природе случай) до четырех лет. Средняя продолжительность работы айтишника в компании – год/полтора. Таким образом, если компания начнет вкладывать деньги в процесс трансформации «айтишник-менеджер”, то с большой долей вероятности трудами этого обучения воспользуются конкуренты. Поэтому компании с удовольствием обучают айтишников на курсах повышения квалификации, но не готовы вкладывать в обучение менеджеров.
Что же делать айтишнику в таком случае? Во-первых, решить, хочет ли он в будущем быть менеджером. Если ответ положительный, то, начиная где-то с уровня мидл, нужно параллельно с книгами по технологиям начинать читать книги по психологии, риск-менеджменту и проджект-менеджменту.
Когда менеджер – это хорошо
И все же, для чего нужны менеджеры? Вначале статьи Пейдж и Брин уже немного ответили на этот вопрос: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.
Хотим добавить в копилку еще несколько важных задач менеджера.
Задача №1: быть стеной между заказчиками и исполнителями
Как-то одному нашему знакомому, будучи еще довольно молодого возраста, довелось выступить в роли «23-летнего сеньора” (а еще и в роли тим-лида) для одного очень серьезного заказчика (Fortune 100). Проект был не сложный технически, но непростой с точки зрения интеграции и требований к аппаратной среде. Для интеграции была выделена отдельная машина (на стороне заказчика), где всё благополучно запустилось. Но инженерам заказчика этого показалось мало и они решили развернуть систему на персональном ноутбуке, а также на рабочем компьютере. И в какой-то момент система не завелась. Пришлось долго разбираться почему, причем проблемы возникали одна за другой.
Это могло продолжаться довольно таки долго, если бы в ситуацию не вмешался менеджер. Он запретил инженерам заказчика давать исполнителю задания без его ведома и разворачивать систему на не проверенном железе. После этого вмешательства ситуация устаканилась, разработчика перестали дергать, а проект был благополучно сдан спустя несколько дней.
Задача №2: брать на себя ответственность за весь проект
– У нас проблемы с проектом, — сказал как-то топ-менеджер компании, для которой делался проект. У разработчика похолодело внутри. – Но ты не переживай, это не твоя область ответственности, – добавил он.
Стоит запомнить одну простую мысль: программист кодит, менеджер отвечает. Если программист плохо накодил – в любом случае виноват менеджер, ведь он не проследил за ходом выполенения проекта и/или нанял не подходящего сотрудника.
Да, менеджер получает больше плюшек, но и ответственность у него на порядок выше.
Задача №3: гарантировать достижение цели в условиях ограниченного доступа к ресурсам
Причем ему нужно гарантировать достижение целей как заказчика, так и исполнителей. Это удается редко. Ведь менеджер сталкивается с миллионом различных проблем: отсутствием и недостаточным количеством кадров, времени и бюджета, злым или не компетентным заказчиком, отсутствием экспертизы и т.д.
Но если менеджер может гарантировать результат, то не важно, где, сколько и как он работает. Более того, менеджер, который будет работать по 7-8 часов в день – гарантированно завалит проект. Менеджеру должны платить за его решения и конечный результат. В идеале менеджер должен получать основной доход в виде бонусов за вовремя выполненные проекты, а не за количество просиженных в linkedin или skype часах.
Задача №4: быть мотиватором и следить за развитием подчиненных
Если бы разработчики нас спросили, в какой компании лучше всего работать, мы бы без раздумий ответили: в той, где у них будет адекватный менеджер (даже если денег там будут платить вдвое меньше).
В одной из компаний, программист получил большой кредит доверия от своего менеджера. Доверие заключалось в полном одобрении принятых им (программистом) решений, автономность работы, помощи при организации встреч разработчиков, учебных курсов и поездок на всевозможные конференции. Результат не заставил себя долго ждать: был открыт новый отдел на 5-6 человек; знания, полученные на мероприятиях, были внедрены в рабочий процесс, на проектах начали использовать современные технологии и иструменты. Итог? Все предложения других компаний (включая предложения с более высокой зарплатой), на протяжении года-полтора были отклонены программистом без капли сожаления.
Какой он, идеальный менеджер?
В Google выделяют 8 качеств хороших менеджеров:
1. Чуткий наставник.
2. Предоставляет коллективу свободу и не контролирует каждый шаг.
3. Следит за успехами подчиненных и старается помочь.
4. Компетентен и нацелен на результат.
5. Умеет разговаривать с людьми — выслушивает и делится информацией.
6. Помогает подчиненным делать карьеру.
7. Имеет четкое представление о будущем своей группы и понимает стратегию её работы.
8. Обладает основными профессиональными навыками, поэтому может давать советы группе.
Мы бы добавили к этому портрету следующее: идеальный менеджер должен быть компетентным в вопросах авторского права, риск-менеджменте, в таких областях, как психология, мотивация, управление ресурсами, юриспруденция, а также должен обладать рядом дополнительных качеств: коммуникабельность, твердость, справедливость, адекватность.
Идеальных менеджеров мало, но если человек с такими качествами и навыками вам случайно попадётся, отличные результаты не заставят себя долго ждать.
11 Января 2015 Болтовня 
8 
0
У меня менеджер проектов на работе в последнее время реально раздражает меня и просто бесит тупизмом.
Недавно подходит ко мне и спрашивает, когда я могу обновить UAT сервер (сервер с сайтами, где клиент тестирует все перед тем, как разрешить деплой на рабочий публичный сервер). Договорились, что я обновлю его на следующий день. В тот же день через некоторое время приходит письмо с претензией, что клиент может найти определённую фишку на сайте UAT. Конечно же не может найти, потому что я код не обновлял.
Недавно в помощь мне дали Web программиста, который должен будет исправить CSS и HTML косяки другой компании. В проекте, который я сейчас делаю, весь HTML был написан другой компанией, но они много накосячили и так и не исправили свои проблемы, а у меня исправлять времени нет, потому что проект должен быть сдан через три недели.
Web программист подходит ко мне и говорит: «Michael, что мне делать, я не понимаю, что от меня хочет менеджер проекта». Меня раздражает, как канадцы произносят Миша, поэтому я уже лучше пусть называют меня Майклом. Короче, два дня менеджер проекта почему-то пытался красивыми словами загрузить Web программиста и они ничего не делали, только трындели, а программист просто стеснялся послать менеджера.
Дальше привожу примерный наш разговор:
Я: Что должен делать Pau (так зовут Web программиста)?
Менеджер: Компания прислала нам исправления и он должен интегрировать их CSS в нашу CMS и потом…
Я: Заткнись. Мы не интегрируем никакие CSS в CMS. Та компания вообще к CMS никакого отношения не имеет, они делают HTML и CSS для морды сайта. Нужно обновить CSS?
Менеджер: Да
Я: Хорошо, это один файл, который я просто копирую из их репо в наш (делаю это прямо на его глазах). Все. Что дальше должен делать Web программист?
Тут я вижу, что менеджер в шоке. Он два дня пиздел с Web программистом, что-то там решали и загружали друг друга, а тут работа закончилась за минуту и еще 4 можно потратить на чашечку кофе. Через минуту менеджер просыпается:
Менеджер: Ну теперь он будет тестировать, что там сделала компания и исправила ли она все косяки
Я: Для этого у нас есть QA (Quality Assurance), которые нашли эти косяки, которые знают где их искать и которым платят за то, чтобы они искали косяки. Web программисты этим не занимаются.
Два дня работы в трубу. У нас горят сроки, а человек совершенно не понимая, как что-то работает, продолжает умничать и кидаться красивыми словами. Для чего?
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым