Аутсорсинг как сервис
>>История возникновения
Работая руководителем проекта (Project Manager) в аутсорсинговой компании и общаясь с представителями IT тусовки, я пришел к выводу, что айтишники уверены в том, что их работа абсолютно уникальна и не имеет аналогов в мире. И эта уникальность настолько по душе всем участникам этой тусовки, что мы стали это воспринимать на уровне аксиомы, которая не требует доказательства. И вроде бы все участники рынка от этого выигрывают: айтишники от осознания своей уникальности, работодатели от возможности получать большие деньги за уникальные ресурсы.
Но из этой цепочки счастливых людей выпало одно звено, о котором мы и не думали. Мы, менеджеры проектов, живем внутри проекта и видим его изнутри. А если посмотреть «снаружи», то в цепочке будет заметно пропущенное звено, которое называется «наш Клиент» – это тот человек или группа людей, которые дают нам заказ на разработку продукта.
Пазл совпал и стало ясно, что наша уникальность важна и интересна нам, но не приносит видимой пользы клиентам. Багаж знаний, который я приобрел, увлекаясь маркетингом и рекламой (См. «Об авторе»), сразу же выдал очевидную подсказку: «Если не выигрывает Клиент, то в долгосрочной перспективе не выигрываем и мы…». Дальше логические выводы стали совсем неутешительными: А если у нас нет долгосрочной перспективы, то правильно ли развиваться как менеджер аутсорсинговых проектов? Будет ли это приносить стабильный доход моей семье в ближайшие несколько лет?
Решив посмотреть на проблему с другой стороны, переформулировал вопрос: «А что делают в других сферах бизнеса, когда нет долгосрочной перспективы?». Но тогда надо отождествить аутсорсинговый бизнес с другими и найти те общие черты, которые позволят заимствовать лучшие приемы из других бизнесов.
«Простой алгоритм перебора» запустился и началось сравнение:
- Производство товаров
- Дистрибьюторство
- Логистика
- Аудит
- Массовое обслуживание
- СТО
- Индивидуальные продажи (VIP)
- Индустрия развлечений
- …
Дальнейшее сравнение показало, что наш бизнес (outsourcing) больше всего совпадает с такими как: индивидуальные продажи и индивидуальный сервис (СТО, Аудит, дорогой ресторан). Какие же критерии стали основными:
- Не рассчитан на массовый рынок. Т.е. сервис скорее индивидуален и требует тонкой настройки на потребности каждого клиента.
- Требует большой вовлеченности от клиента. Т.е. то, что он хочет, нельзя описать быстро и предельно точно.
- Мы (вероятнее всего) не будем являться потребителем того товара, который производим. Он будет передан клиенту.
В итоге, можно прийти к выводу, что эти характеристики присущи высокотехнологичному индивидуальному сервису. А значит к нашей области разработки программного обеспечения на заказ (outsourcing) все-таки применимы, хотя возможно и с некоторой адаптацией, законы рынка индивидуального сервиса.
>>Начинаем разворот в сторону Сервиса
Сейчас в мире так сильна конкуренция, что даже если вы пионер в какой-то области, то буквально сразу же у вас появится куча конкурентов, которые попытаются отнять у вас кусочек вашего рынка и, соответственно, ваших денег 
. А так как альтруизм на планете еще не победил, то эти самые деньги нам нужны и отдавать их мы не стремимся.
Поэтому нам, как менеджерам проектов, нужно переориентировать себя и свою команду на то, чтобы клиент обращался к нам вновь и вновь, а также рекомендовал нас другим клиентам. Но этого добиться очень не просто по причине двух главных ограничений:
- Клиент всегда лоялен к носителям уникальных знаний и умений. А в нашем мире информация (даже очень конфиденциальная) распространяется так быстро, что любое промедление ставит вас вровень с конкурентами, которые об этом узнали.
- Наши любимые «айтишники» не очень-то понимают, как строить Сервис для клиентов.
С первым ограничением мы уже вряд ли что-то сделаем, разве что соорудим «Великий Китайский Файрвол» вокруг своей компании. А вот со вторым можно и нужно работать.
Сначала приведу яркий пример того, что сервис в наших реалиях понятие утопическое. Закройте глаза и представьте себе каждого из ваших программистов или тестировщиков в роли… ну официанта :-D. Да-да, я когда задумался, что меня будет обслуживать такой «человеколюбивый» и дружелюбный официант, мне стало жутковато
Если отбросить шутки, то я уверен, что большинство наших коллег рассматривает клиента, как некое мифическое существо, которое иногда пишет злые письма или присылает бонусы. Как работать с этим «созданием» не знает никто. Есть набор правил похожий на конспект заклинаний у мага-ученика: «Как не злить клиента», «Как его задобрить», «Как на клиентов действует проваленный дед-лайн».
Надеюсь, что вы разглядели в описании паттерны, которые применимы и к вашему проекту, поэтому можно переходить к части:
>>Что делать…?
Конечно, непросто описать айтишникам особенности и сложности нелогичной по своей сути концепции выстраивания отношения с клиентом. Клиенты – они не похожи на компилятор или SDK. Их функции не описаны и правило a-la «напиши письмо в 4 строки 2 раза в неделю и получишь бонус на новый год» вряд ли применимо ко всем клиентам.
Поэтому начнем мы работу с проджект менеджера – человека, который немного вышел за пределы кода и смотрит «наружу», который начал осознавать (или уже осознает), что мир не описывается жесткими правилами (кстати, в тренинге этому посвящен целый раздел). И если нужно принести в проект инновацию извне, то только у него хватит сил и полномочий.
В упрощенном варианте теории (adopted for IT), сервис – это когда клиент считает, что ваша команда обладает следующими качествами:
- Заботливость
- Вежливость
- Честность
- Готовность помочь
- Предсказуемость
- Оперативность
- Доступность
- Дружелюбие
- Знания
- Надежность
- Профессионализм
И настраивая свою работу так, чтобы клиент отождествлял вашу команду с этими качествами, вы добьетесь того, что он скажет: «У них классный сервис!». И тогда ваша команда и компания получат те самые желанные «плюшки» от сервиса: большая цена, возможность выбирать клиентов и проекты, возможность нанимать лучших людей. (ура, таки добрались до того, что же хорошего нам даст этот подход).
Конечно же, все вышеперечисленные свойства строятся небыстро, если разбирать их отдельно. Я же предлагаю их рассматривать через призму «интегральных качеств»: доверия и visibility (искренне раскаиваюсь, но не могу найти ни одного полноценного русского аналога).
Если до этой строки дошли настоящие программисты, то мой дальнейший ответ на вопрос «Что же с этим делать?», наверное, их разочарует: Универсального рецепта нет! 
. Если бы он был и описывался формулами, то, вероятно, все аутсорсинговые компании давно бы его внедрили и были бы счастливы.
Но отчаиваться тоже не стоит. Мой личный опыт, а также опыт моих коллег позволяет собрать несколько рекомендаций, которые могут быть применимы практически в каждом проекте.
На странице «Тренинги» можно посмотреть программу (пока одну) тренинга « Outsourcing as a Service: Customer», который направлен на то, чтобы сделать вашу команду более сервисно-ориентированной с точки зрения клиента.
Также на страницах блога я буду публиковать посты о тех best practices или просто идеях, которые помогут вам в этом.
To be continued…
visibility = прозрачность
я бы так перевел
Хожу я на много IT мероприятий. И все как один докладчики уверены что у нас уникальная область и есть куча методик (и только ихние работают ) ) для того, чтобы убить белого мамонта.
На самом деле отучившись на организационного психолога могу сказать, что область никакая не уникальная и большинство из методик убийства белого мамонта его только испугають )
В общем автор первый человек которого я нашел, который трезво смотрит на наш айтишный мир)
to Konstantin
После долгих размышлений и споров с самим собой я решил последовать вашему совету. Спорил, потому что мне казалось, что слово visibility немножко “шире”, чем “прозрачность“. Но в обсуждениях с коллегами и в кругу семьи понял, что не хочу плодить новомодных терминов и пользоваться родным русским. Спасибо за совет!
to Oleg
Да, но это выгодно! Нам хочеться быть уникальными и верить в свою неповторимость. Вы, как прикладной психолог, наверное сможете многое рассказать по этому поводу
Спасибо за отзыв. Не соглашусь, что я единственный, просто единомышленники почему-то маскируются
Сергей,
“Если до этой строки дошли настоящие программисты, то мой дальнейший ответ на вопрос «Что же с этим делать?», наверное, их разочарует: Универсального рецепта нет! . Если бы он был и описывался формулами, то, вероятно, все аутсорсинговые компании давно бы его внедрили и были бы счастливы.”
А ведь универсальный рецепт есть! Только он никому, почему-то, не нравится
Неважно считаем-ли мы себя уникальными или же думаем, что все наши проблемы имеют место быть и в других областях народного творчества, универсальность рецепта заключается в том, считает-ли команда себя собственником того, что делает, или нет.
Если команда работает над “своим проектом”, то на вопрос “почему нужно упираться и “жить” на работе если заказчик не додумался изначально, что этот фичер не подходит к уже реалзиованным?” ответ один “да, влипли, непродумали. теперь придется попотеть, чтобы сделать хоть что-то, а в будущем нужно подумать как такие ситуации минимизировать”.
Если команда работает над “проектом заказчика”, то ответ на этот вопрос традиционный, как в том анекдоте: “вася, у тебя руль, ты и поворачивай”.
Другими словами, сервис получается сам собой, если воспринимать работу, которую мы делаем, как свою личную. Но это практически всегда на начальном этапе приводит к переработкам, стрессам и т.д. в то время как овертаймы не оплачиватюся
Безусловно, что после стабилизации отношений с заказчиком, когда он уже понял, что команда может думать не хуже него и первые пару версий продукта успешно вышли в свет, полоса “постоянных проблем” сменяется полосой “почевания на лаврах”, так всегда бывает. Беда в том, что до белой полосы не дойдеш за пару месяцев, а на дольше не у всех хватает батарейки. Вот и возникает расхожее мнение, что “где-то трава зеленее” и нужно менять проект, чтобы чему-то научиться.
Visibility точнее переводится как разрекламированность, но слово это неудобное, и всё-таки менее ёмкое в данном контексте.
Прозрачность не очень подходит, так как сотрудник может быть абсолютно прозрачным и при этом неинтересным (бесполезным).
Ещё как вариант можно было бы использовать “засвеченность” от “засветился на проекте”, но это ещё более грмоздкое и тяжёлое слово.
to December
“Засвеченность” выглядит очень интересно! Плохо, что в русской культуре это слово носит скорее негативный оттенок.
Почему мне нравится visibility, как некое аггрегированное понятие от “узнаваемости”, “прозрачности”, “засвеченносити”, “открытости” и “предсказуемсти” (хотя последнее это явно замахивается на что-то большее).
Сергей, а с точки зрения фрилансера или удаленного работника – советов можно просить? Сам по себе удаленный работник ведь тоже аутсорсит свои услуги.
To Felix
Фрилансеры и удаленные работники – это cutting edge аутсорсинга. Им то как раз приходится тяжелее всех.
Если смогу помочь чем-то, буду только рад
Сергей, а учли ли вы такую специфичную черту, которая отличает outsourcing от перечисленных вами отрослей, как неединство заказчика и потребителя услуги?
Часто, будь то при разработке, внедрении ли или поддержке Заказчиком и плательщиком является одно лицо, а потребителем услуг другое (или другие).
И получается некий замкнутый круг:
заказчик хочет заплатить меньше, потребители хотят получить как можно больше, исполнитель предлагает потребителям попросить, чтобы Заказчик оплатил их пожелания, потребители нехотят просить заказчика, исполнитель не в силах удовлетворить запросы потребителя без оплаты, потребители недовольны, заказчик оценивает исполнителя по мнению потребителей, заказчик тоже недоволен работой исполнителя.
Таким образом внутренние проблемы между заказчиком и потребителем отражаются на исполнителе.
То Павел.
Я не сергей, но если вы не против, хотелось бы прокомментировать:
Думаю, что все будет зависить от отношений между Исполнителем и Плательшиком. Если вам как РМу удалсь наладить более-менее доверительные отношения – то проблем не будет.
Просто стоит сразу договариваться о “кто девушку танцует” и “кто за это платит”. Плательщик должен точно знать за что он платит, и что он получает. Если Заказчик (как третья сторона) выходит за рамки договоренностей, то могут быть два варианта:
1. Если Исполнтелю легко (и недорого и быстро) это сделать, можно сделать в качестве бонуса. При этом обязательно сообщить Заказчику и Плательщику, что это исключение из правил и только одн раз и только для них.
2. Переадресовать Плательщику с расчетом стоимости данного пожелания.
visibility = видимость, и самый буквальный перевод все-таки наиболее точен, а все остальное – бизнес-сленговые наносы и профессиональные деформации, не более (имхо, естесссссно)