.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

Value-Driven Development: опыт трансформации сервисной команды в продуктовую

Статья написана в соавторстве с Екатериной Сиротинской, HR-директором в Omnicore, и Дмитрием Куявцем, консультантом в области цифровых и организационных трансформаций.

Эта статья посвящена опыту трансформации украинской сервисной команды в продуктовую. Здесь вы найдете как теорию, так и информацию о реализации.

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

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

Развитие по количественному сценарию, очевидно, является тупиковым, поскольку (даже организовав демографический бум :) ) страна не сможет выиграть в конкурентной борьбе за стоимость услуг у перманентно демпингующих Индии, Пакистана или Филиппин. Второй, качественный, сценарий является более сложным и рискованным, но он позволит выстроить долгосрочную ценностно ориентированную стратегию. Многие IТ-аутсорсинговые компании делают ставку на проектную разработку, немногие — на исследования, и лишь единицы предлагают продуктовую разработку.

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

Вывод № 1: удобно, но нехорошо

И все-таки, помимо снижения доходов из-за высокой конкуренции и «генерации» огромного количества низкопрофильных ИТ-специалистов, зачем отказываться от столь удобного ИТ-аутсорсинга и что-то там строить? Хорошо ведь!

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

Случайно или наспех собранная сервисная команда не способна решать сложные задачи в долгосрочной перспективе. Кроме того, такая команда не в состоянии эффективно интегрироваться в компанию-заказчика для совместной разработки инновационного продукта. А учитывая статистику, «текучка» кадров в аутсорсинговых IТ-командах составляет более 20%, что вообще вызывает вопрос, может ли эта группа людей называться командой. Не радуют такие перспективы? Тогда читайте, как трансформировать сервисную команду в продуктовую ниже.

Вывод № 2: нет, не клиентоориентированность

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

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

Наверняка вы задаетесь вопросом, каким образом связаны между собою эти столь неравноценные уровни и как эту связь построить? На каждом из уровней релевантной является своя система ценностей, и самой важной задачей при построении эффективной продуктовой команды является понимание и разделение командой ценностей компании (бизнеса) и заказчика (продукта). Только при этом условии возможно ее дальнейшее развитие.

Ценности продуктовой команды как системы

Вывод № 3: эволюция, не революция

Что это за ценности, как с ними работать и как сделать так, чтобы появилась система ценностей, релевантная для команды, для клиента и для бизнеса одновременно? На этот нетривиальный вопрос хотелось бы ответить точным высказыванием: «Ценности — это не качества сотрудников, а идеи, за которыми стоит команда». То есть на передний план выходит понятие культуры как совокупности ценностей членов команды, которые inline с ценностями компании и заказчика, а также оказывают на команду и всю систему саморегулирующее управленческое воздействие.

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

Вывод № 4: нет, не денежное вознаграждение

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

Итак, 8 ключевых ценностей сотрудников продуктовых команд в порядке их приоритетности:

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

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

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

Вывод № 5: не линейно

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

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

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

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

История одной трансформации

Мотивационные факторы

Итак, изначально в нашем активе была маленькая команда Red Dot Square, состоящая из 7 человек, которые работали в сфере VR. На этапе маленькой команды нет необходимости в четко формализованной миссии и видении, достаточно наличия у сотрудников общих ценностей, которые будут их объединять. Также эта команда должна состоять из людей, имеющих одинаковый уровень ответственности (ownership) за свой продукт.

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

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

Чтобы более системно подойти к этой задаче, было принято решение взять за основу для развития команды теорию спиральной динамики. Состояние To-Be мы определили как уровень ценностей компании в спиральной динамике. Состояние As-Is — это тот уровень спиральной динамики, на котором находятся ценности команды в данный момент. К сожалению, готовых опросников по спиральной динамике нам не удалось найти, поэтому пришлось создавать собственные.

Эволюция развития команды Кантар

Дорожная карта трансформации из состояния As-Is в To-Be требовала ряда шагов, первых из которых стало создание инициативной группы агентов изменений (leadership team), миссией которых стала помощь команде в адаптации ценностей.

Миссия — агенты изменений

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

Для этого команда агентов изменений регулярно, с периодичностью один-два раза в две-три недели, собиралась для того, чтобы в неформальной обстановке прописать поведенческие стандарты, которые привязывались к каждой из ценностей. Например, We Develop — что это для нас значит? Означает ли это, что мы должны развиваться сами и помогать друг другу расти? Как нам это реализовать на практике? Так, расширить компетенции коллег можно посредством инициирования регулярных inspiration breakfast, когда еженедельно на протяжении часа любой член команды может поделиться своим опытом или новыми знаниями с коллегами. Сессия обязательна для всех членов команды.

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

Этапы каскадирования ценностей Кантар

Отладка взаимодействий в команде

Благодаря усилиям команды агентов изменений на момент «синей» организации в спиральной динамике нам удалось создать и имплементировать поведенческие стандарты, выстроить организационную структуру, прописать job-инструкции, а также создать handbook с прописанными правилами, корпоративными и социальными активностями.

Практики команды Кантар на этапе «синей» организации в спиральной динамике

И это все не осталось лишь «на салфетках». Так, поведенческие проявления (Behavior), которые являются следствием ценностей, имплементированными самими же сотрудниками, каждые полгода оценивались с помощью специального опросника 360 (опросник можно будет найти по ссылке ниже), который показывал, насколько ценности человека и его поведенческие паттерны соответствуют организационным. Продуктивность (Performance) сотрудника оценивалась по ряду KPI’s, которые отслеживались PMO-командой аудиторов заказчика и/или аутсорсинговой компании. Компенсация также была обязательной, однако зависящей от финансовых результатов компании.

Для оценки мотивации раз в квартал или раз в полугодие использовался специальный мотивационный опросник, который проводился один раз в квартал или один раз в полугодие в зависимости от этапа развития команды.

Мотивационный треугольник Кантар

Мониторинг процесса трансформации команды

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

В итоге наша система мониторинга прогресса трансформации свелась к:

  • имплементации системы разовых ежемесячных опросов сотрудников (профайлы DISC & Belbin профайлы) с разъяснением результатов команде;
  • введению системы регулярных опросов сотрудников (опросник по спиральной динамике, мотивационные факторы, Feedback, Team Self-Assessment) с проведением разъяснения результатов команде;
  • получению обратной связи от руководства компании и клиентов с последующим разъяснением результатов команде;
  • стандартизации активностей группы агентов изменений, в частности проведению inspiration breakfast, старта хакатонов и т. д.

Эволюция порога входа в команду Кантар

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

Этапы внедрения мотивационного треугольника Кантар

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

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

Те команды, которые уже сегодня готовы сделать свой первый шаг на пути трансформации, найдут разработанные нами шаблоны мотивационных факторов, целеполагания и опросник 360 по ссылкам ниже:

LinkedIn

19 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

Хорошие были времена. Много было сделано. Много людей очень «выросли» на этом пути (в том числе и я). Спасибо, Дима, Дима и Катя, за приятные воспоминания! ;)

А учитывая статистику, «текучка» кадров в аутсорсинговых IТ-командах составляет более 20%, что вообще вызывает вопрос, может ли эта группа людей называться командой.

В каких попугаях расчёт? Мутный сайт у EY, непонятно ни сколько стоит, ни как купить. Опять же непонятно, какова текучка кадров в продуктовой компании, не с чем сравнивать, сколько — 0%?

Цікаво, все-таки, людей взяли на роботу напряму у компанію-власника продукту і дали частку власності (акції, опціони), чи все так і залишилося на рівні мотиваційних ритуалів (презентації, опитування, дискусії, бонуси за досягнення), але той самий контракт на надання консультаційних ІТ послуг?

Плох тот аутстаффер который не хочет стать аутсорсером
Плох тот аутсорсер который не хочет стать продуктом

Хорош тот аутстаффер, который нанимает в гугл на 300k

Мне одному показалось что в статье о транформации комманды в продуктовую ни слова не сказано о продукте? Или я невнимательно читал?

статья о трансформации как процессе. Если нет продукта, то смысл куда то трансформироваться?

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

И да, я заметил слово «заказчик». Ребята, продуктовая разработка это когда в одном месте делается всё, от придумывания ыич до их тестирования. Если же программирование и тестирование переносится в низконалоговую юрисдикцию потому что дешевле и можно быстро уволить в случае чего, это тот самый оутсорсинг и есть — классическое определение.
Так что у вас нифига не продукт, это вас кто то обманул — натуральный оутсорсинг

На самом деле, есть достаточно явные маркеры с точки зрения разработчика:
1. Линейные разработчики собеседуются и общаются с кастомерами, выясняя бизнес-требования == аутстафф.
2. Линейные разработчики не общаются с кастомерами напрямую, выясняя бизнес-требования, а компания нанимает к себе сама == аутсорс. При этом часто кастомер проводит финальный собес, а компания продолжает без лишнего стеснения называть себя «аутсорс».
3. Вводили ещё такое понятие, как «продакт студио», но это просто эталонная реализация п. 2 для комплексного решения, которое подразумевает наличие определённых компетенций, оставаясь аутсорсом (пусть и самого высокого качества).
4. Компания является оунером своих разработок == продукт, не является — простите-извините.

Поэтому то, что описано — как превратиться из аутстаффа в аутсорс.

Вводили ещё такое понятие, как «продакт студио», но это просто эталонная
реализация п. 2

Максим, не совсем так.
Это мы вводил термин «Product Studio». Вот одна из статей dou.ua/...​a/columns/product-studio. Product Studio — это платформа для повторяемого создания и развития успешных продуктов.
Мы рассматриваем собственные и клиентские продукты как два полноценных направления которые дополняют друг друга по различным аспектам.
Например у нас уже 20% оборота приходит через собственные продукты и этот процент активно растет. Когда я говорю «собственные продукты» я именно это и имею ввиду все создано внутри компании от идеи до запуска и развития.

Согласен — незаслуженно использовал термин). Тогда возьмём «продуктовую команду», как в этой статье. Просто Вы такие пока одни вроде (может, и не совсем прям одни, но скейлить этот термин пока точно не получится) — речь о тренде «называться чем-то продуктовым», как в данном случае. Хотя разница основная в статье сводится к простому «всё под ключ» vs «не под ключ» — людям отдали под ключ, и вот...

Полностью согласен.
Как всегда маркетологи говорят, что «Продукты» популярны — все аутсорсеры меняют вывески. Но так происходит во всей индустрии. AI стал хайповым — теперь асе продукты стали вдруг AI, несмотря на то что внутри никакого AI нет.

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

Писал себе такой код, никого не трогал, а теперь должен ходить на inspirational завтраки и доказывать менеджеру и КОМАНДЕ что ты замотивирован.

обрати внимание в статье вообще нигде нет про то чтобы как-то писать код лучше писать код больше писать код сложнее и вообще хоть какое-то хард скиллы только софт скиллы

я таки уже говорил будут «менеджеры с продвинутыми навыками компьютера» программисты вымрут в эволюционной борьбе не будучи конкурентноспособными ))

Это называется поднимать value компании. Тут же рядом все эти митапы, конференции и воркшопы при фирме. Только в гуглах за эту «мотивированность» акциями платят, а в офшоре — разве что не выгоняют.
Радуйтесь, что в ISO 9001 еще софт-скилз не включили.

Подписаться на комментарии