Хотите самоходных сотрудников и команд? Создайте для этого условия: пруфы

Что было

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

Как меняли

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

Что стало

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

Сейчас я работаю в Yandex Infrastructure менеджером в командах, которые делают инструменты для разработчиков Яндекса. Здесь мне довелось вкусить все прелести и ответственность такой короткой петли обратной связи.

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

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

Сейчас я работаю в B2B продукте. Клиенты далеко от разработки: есть прослойка через PO, аналитика и сэйлзов. В итоге разработчики разрабатывали, как знают и чувствуют, без понимания, как удобно клиенту, ведь «клиенты не шарят».

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

Было:

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

Как меняли:
Мы стали приглашать на Sprint Review заказчиков от бизнеса, показывали наши результаты работы и объясняли, что и для чего было сделано. Плюс бизнес стал тоже рассказывать, что сейчас на рынке происходит и показывать все метрики.
Плюс навели порядок в чате, в котором напрямую писали партнеры, когда они хотели что-то реализовать. Туда же добавили и разработчиков. Впоследствии у одной команды в практику дежурств добавили пункт отвечать заказчикам. Поначалу разработчикам было тяжеловато: запросов был целый шквал, зато они были реальными и в моменте.
Потребовался отдельный менеджмент запросов: что отправлять через Support, что является падением и надо инцидент открывать, а что – хотелка. В чат писали про запросы и боли.

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

Я полностью согласен с Вероникой, что силы на то, чтобы вынырнуть из рутины, очень важны.

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

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

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

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

Один из примеров пользы такого подхода – мы видели регулярную боль внутренних сотрудников по организации ежегодной конференции. И вот в какой-то момент мы собрались, покастдевили людей, попроектировали с точки зрения ui/ux и архитектуры разработки. В результате сделали небольшую внутреннюю CRM-систему для приема заявок, работы программного комитета, коммуникации со спикерами, работы кучи людей из бэк-офиса по своим нужным активностям.

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

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

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

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

Что было

В той же американской финтех компании основная идея продукта принадлежала СТО. Он был локомотивом всех изменений, которые безропотно принимались с одной стороны бэкэндерами и дата-сайентистами, с другой — командой продаж. С ростом компании с 15 до 50 человек стало ясно, что мощностей СТО не хватает на то, чтобы генерить идеи для всех и толкать одновременно несколько направлений

Как меняли

Сделали новый процесс внедрения новых фичей и усовершенствования продукта с помощью ГитХаба. Так как команда была изначально распределенная, все привыкли, что документация и задачки хранятся там. Привычный способ организации работы был такой: приходит СТО, открывает задачу, ставит приоритет, назначает исполнителя.  Мы же построили новый процесс открытия целей-майлстоунов.

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

Что стало

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

Как-то на консалтинге мне довелось собирать с нуля команду и процессы для разработки онлайн DIY-магазина. С онлайном, разработкой, да еще в распределенной команде там не умели работать.

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

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

До сих пор считаю, что он – один из приятнейших и мудрейших руководителей, с которыми я когда-либо работал.

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

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

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

Было

Провела стратсессию, на которой определяли цели и стратегию выхода на новые рынки. Все расписали, даже ближайшие планы на полгода. Лид команды понес эти цели CEO. Получил фидбэк “это не стратегия, переделай”. Лид взял, переделал САМ, ни с кем не обсуждая больше, и понес CEO. Они утвердили. Дальше лидер спустил команде новую стратегию. Команда в шоке: планировали на большой общей встрече совсем иное.

Что сделали

Я отдельно сказала лиду, что так нельзя. Вернула, что мы 100 раз проговаривали, кто нужен на встрече для принятия решения, переспрашивали, не надо ли позвать CEO, и получили ответ, что не надо, — мол лид сам пойдет потом к CEO и легко идею продаст. Без этого окончательное решение по стратегии по идее МОГЛО быть принято нами. А так получилось, что мы риски переделок формально приняли, но на презентации CEO не проговорили, что это черновик, и не договаривались, что лид один всё переделает после фидбэка. Лучше бы привлек команду. Плюс потом тоже самое проговорили на синке с участниками сессии, что они увидели сильно обесценивание этой работы по планированию и ее результатов, и мол проще в следующий раз ничего не планировать. Лид все понял и принял, пообещал отстаивать позицию команды. Плюс договорились, что на следующей сессии мы сами себе оставляем пространство на корректировку стратегии. То есть план такой: наборосок целей, дальше лид синкует его с СЕО, если есть фидбек, приносит команде, и вместе решают, что с ним делать, и как редактировать цели.

Результат

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

Я работаю над всякими вещами для сотрудников в компаниях, и популярная метрика измерения их счастья от любой такой деятельности — eNPS. Измеряется через вопрос в духе «Вы бы порекомендовали работу у нас своему другу?» и оценку от 1 до 10. Но на ответ по этому вопросу влияет куча факторов:

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

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

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

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

Затем мы стали проводить опросы раз в месяц и чаще, обкладывать проекты локальными метриками (например, об эффективности обучения судить по многофакторной оценке сразу после него, а не по метрике “оцените удовлетворенность системой обучения в компании”). И раз в полгода примерно моя команда устраивала серию глубинных интервью на актуальные в моменте темы: а что у нас с культурой после найма кучи новичков, а что у нас с внутренними коммуникациями и прозрачностью, а как именно и чему хотят учиться синьор-разработчики, и так далее.

Благодаря смене подхода и команде стало проще видеть результаты своей работы, и сотрудникам стало видно, что проекты и решения (или отказы от них) не из воздуха берутся, а из стыковки их и бизнесовых запросов. Как бонус наша стратегия на 22 год, основанная на таких же, более локальных и кастомных метриках, выполнилась вопреки всей турбулентности того года.

И да, eNPS все время наших экспериментов со странными метриками и проектами продолжал расти. Совпадение? Не думаю!