Аутсорсинг как сервис

>>История возникновения

Работая руководителем проекта (Project Manager) в аутсорсинговой компании и общаясь с представителями IT тусовки, я пришел к выводу, что айтишники уверены в том, что их работа абсолютно уникальна и не имеет аналогов в мире. И эта уникальность настолько по душе всем участникам этой тусовки, что мы стали это воспринимать на уровне аксиомы, которая не требует доказательства. И вроде бы все участники рынка от этого выигрывают: айтишники от осознания своей уникальности, работодатели от возможности получать большие деньги за уникальные ресурсы.

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

Пазл совпал и стало ясно, что наша уникальность важна и интересна нам, но не приносит видимой пользы клиентам. Багаж знаний, который я приобрел, увлекаясь маркетингом и рекламой (См. «Об авторе»), сразу же выдал очевидную подсказку: «Если не выигрывает Клиент, то в долгосрочной перспективе не выигрываем и мы…». Дальше логические выводы стали совсем неутешительными: А если у нас нет долгосрочной перспективы, то правильно ли развиваться как менеджер аутсорсинговых проектов? Будет ли это приносить стабильный доход моей семье в ближайшие несколько лет?

Решив посмотреть на проблему с другой стороны, переформулировал вопрос: «А что делают в других сферах бизнеса, когда нет долгосрочной перспективы?».  Но тогда надо отождествить аутсорсинговый бизнес с другими и найти те общие черты, которые позволят заимствовать лучшие приемы из других бизнесов.

«Простой алгоритм перебора» запустился и началось сравнение:

  • Производство товаров
  • Дистрибьюторство
  • Логистика
  • Аудит
  • Массовое обслуживание
  • СТО
  • Индивидуальные продажи (VIP)
  • Индустрия развлечений

Дальнейшее сравнение показало, что наш бизнес (outsourcing) больше всего совпадает с такими как: индивидуальные продажи и индивидуальный сервис (СТО, Аудит, дорогой ресторан). Какие же критерии стали основными:

  • Не рассчитан на массовый рынок. Т.е. сервис скорее индивидуален и требует тонкой настройки на потребности каждого клиента.
  • Требует большой вовлеченности от клиента. Т.е. то, что он хочет, нельзя описать быстро и предельно точно.
  • Мы (вероятнее всего) не будем являться потребителем того товара, который производим. Он будет передан клиенту.

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

>>Начинаем разворот в сторону Сервиса

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

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

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

С первым ограничением мы уже вряд ли что-то сделаем, разве что соорудим «Великий Китайский Файрвол» вокруг своей компании. А вот со вторым можно и нужно работать.

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

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

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

>>Что делать…?

Конечно, непросто описать айтишникам особенности и сложности нелогичной по своей сути концепции выстраивания отношения с клиентом. Клиенты – они не похожи на компилятор или SDK. Их функции не описаны и правило a-la «напиши письмо в 4 строки 2 раза в неделю и получишь бонус на новый год» вряд ли применимо ко всем клиентам.

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

В упрощенном варианте теории (adopted for IT), сервис – это когда клиент считает, что ваша команда обладает следующими качествами:

  • Заботливость
  • Вежливость
  • Честность
  • Готовность помочь
  • Предсказуемость
  • Оперативность
  • Доступность
  • Дружелюбие
  • Знания
  • Надежность
  • Профессионализм

И настраивая свою работу так, чтобы клиент отождествлял вашу команду с этими качествами, вы добьетесь того, что он скажет: «У них классный сервис!». И тогда ваша команда и компания получат те самые желанные «плюшки» от сервиса: большая цена, возможность выбирать клиентов и проекты, возможность нанимать лучших людей. (ура, таки добрались до того, что же хорошего нам даст этот подход).

Конечно же, все вышеперечисленные свойства строятся небыстро, если разбирать их отдельно. Я же предлагаю их рассматривать через призму «интегральных качеств»: доверия и visibility (искренне раскаиваюсь, но не могу найти ни одного полноценного русского аналога).

Если до этой строки дошли настоящие программисты, то мой дальнейший ответ на вопрос «Что же с этим делать?», наверное, их разочарует: Универсального рецепта нет! :-) . Если бы он был и описывался формулами, то, вероятно, все аутсорсинговые компании давно бы его внедрили и были бы счастливы.

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

На странице «Тренинги» можно посмотреть программу (пока одну) тренинга « Outsourcing as a Service: Customer», который направлен на то, чтобы сделать вашу команду более сервисно-ориентированной с точки зрения клиента.

Также на страницах блога я буду публиковать посты о тех best practices или просто идеях, которые помогут вам в этом.

To be continued…

12 comments
  1. Konstantin
    Oct 4th, 2010 at 13:05 | #1

    visibility = прозрачность
    я бы так перевел

  2. Oleg
    Oct 5th, 2010 at 14:18 | #2

    Хожу я на много IT мероприятий. И все как один докладчики уверены что у нас уникальная область и есть куча методик (и только ихние работают ) ) для того, чтобы убить белого мамонта.

    На самом деле отучившись на организационного психолога могу сказать, что область никакая не уникальная и большинство из методик убийства белого мамонта его только испугають )

    В общем автор первый человек которого я нашел, который трезво смотрит на наш айтишный мир)

  3. Oct 5th, 2010 at 18:59 | #3

    to Konstantin
    После долгих размышлений и споров с самим собой я решил последовать вашему совету. Спорил, потому что мне казалось, что слово visibility немножко “шире”, чем “прозрачность“. Но в обсуждениях с коллегами и в кругу семьи понял, что не хочу плодить новомодных терминов и пользоваться родным русским. Спасибо за совет!

  4. Oct 5th, 2010 at 19:10 | #4

    to Oleg

    Хожу я на много IT мероприятий. И все как один докладчики уверены что у нас уникальная область и есть куча методик (и только ихние работают ) ) для того, чтобы убить белого мамонта.

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

    В общем автор первый человек которого я нашел, который трезво смотрит на наш айтишный мир)

    Спасибо за отзыв. Не соглашусь, что я единственный, просто единомышленники почему-то маскируются :)

  5. Igor
    Oct 19th, 2010 at 08:12 | #5

    Сергей,

    “Если до этой строки дошли настоящие программисты, то мой дальнейший ответ на вопрос «Что же с этим делать?», наверное, их разочарует: Универсального рецепта нет! . Если бы он был и описывался формулами, то, вероятно, все аутсорсинговые компании давно бы его внедрили и были бы счастливы.”

    А ведь универсальный рецепт есть! Только он никому, почему-то, не нравится :)

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

    Если команда работает над “своим проектом”, то на вопрос “почему нужно упираться и “жить” на работе если заказчик не додумался изначально, что этот фичер не подходит к уже реалзиованным?” ответ один “да, влипли, непродумали. теперь придется попотеть, чтобы сделать хоть что-то, а в будущем нужно подумать как такие ситуации минимизировать”.

    Если команда работает над “проектом заказчика”, то ответ на этот вопрос традиционный, как в том анекдоте: “вася, у тебя руль, ты и поворачивай”.

    Другими словами, сервис получается сам собой, если воспринимать работу, которую мы делаем, как свою личную. Но это практически всегда на начальном этапе приводит к переработкам, стрессам и т.д. в то время как овертаймы не оплачиватюся :(

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

  6. Nov 9th, 2010 at 08:00 | #6

    Visibility точнее переводится как разрекламированность, но слово это неудобное, и всё-таки менее ёмкое в данном контексте.

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

    Ещё как вариант можно было бы использовать “засвеченность” от “засветился на проекте”, но это ещё более грмоздкое и тяжёлое слово.

  7. Nov 9th, 2010 at 12:23 | #7

    to December

    “Засвеченность” выглядит очень интересно! Плохо, что в русской культуре это слово носит скорее негативный оттенок.
    Почему мне нравится visibility, как некое аггрегированное понятие от “узнаваемости”, “прозрачности”, “засвеченносити”, “открытости” и “предсказуемсти” (хотя последнее это явно замахивается на что-то большее).

  8. Dec 8th, 2010 at 10:15 | #8

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

  9. Dec 8th, 2010 at 10:54 | #9

    To Felix
    Фрилансеры и удаленные работники – это cutting edge аутсорсинга. Им то как раз приходится тяжелее всех.
    Если смогу помочь чем-то, буду только рад :)

  10. Feb 3rd, 2011 at 13:14 | #10

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

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

    Таким образом внутренние проблемы между заказчиком и потребителем отражаются на исполнителе.

  11. Дмитрий
    Jun 2nd, 2011 at 09:30 | #11

    То Павел.

    Я не сергей, но если вы не против, хотелось бы прокомментировать:
    Думаю, что все будет зависить от отношений между Исполнителем и Плательшиком. Если вам как РМу удалсь наладить более-менее доверительные отношения – то проблем не будет.
    Просто стоит сразу договариваться о “кто девушку танцует” и “кто за это платит”. Плательщик должен точно знать за что он платит, и что он получает. Если Заказчик (как третья сторона) выходит за рамки договоренностей, то могут быть два варианта:
    1. Если Исполнтелю легко (и недорого и быстро) это сделать, можно сделать в качестве бонуса. При этом обязательно сообщить Заказчику и Плательщику, что это исключение из правил и только одн раз и только для них.
    2. Переадресовать Плательщику с расчетом стоимости данного пожелания.

  12. Nusha_Po
    Aug 4th, 2011 at 14:31 | #12

    visibility = видимость, и самый буквальный перевод все-таки наиболее точен, а все остальное – бизнес-сленговые наносы и профессиональные деформации, не более (имхо, естесссссно)

Leave a comment