Меня зовут Влад Колонтаев, я тимлид и системный аналитик продуктовой команды F.Message от Faktura.ru. Несмотря на небольшую численность (12 человек) мы успешно поддерживаем и развиваем сервис по информированию клиентов различных продуктов ЦФТ.
Эта статья будет полезна всем, кто, как и я, столкнулся с суровой реальностью, когда разработка и сопровождение работают параллельно и находятся в тотальной рассинхронизации. Здесь я поделюсь, как мы выстраивали взаимодействие между этими отделами, а в итоге превратились в одну продуктовую команду с общими целями и направлениями развития.
Шаги, которые я опишу дальше, независимы друг от друга, их можно применять по мере необходимости. Всё повествование я поделил на три основных блока, чтобы наглядно показать причины, действия и следствия.
«Что-то на богатом» или почему сопровождение и разработка оказались разделены
Всё идёт от потребностей бизнеса. Для молодых продуктов или продуктов с небольшой аудиторией нормально, когда команда разработки сама же и поддерживает пользователей своего продукта. Но когда мы нарабатываем большую аудиторию, задачи сопровождения меняются и настаёт время выделять под них отдельных квалифицированных людей.
Это даёт нам несколько основных преимуществ:
Повышается качество поддержки продукта и, соответственно, лояльность пользователей. Это связано с тем, что сопровождением занимаются технически подкованные специалисты, заточенные при этом на общение с людьми. Их основная задача и ценность – решить проблему пользователя;
С ростом аудитории продукта появляются типовые вопросы, не предполагающее непосредственное участие разработки, например инфраструктурные или интеграционные. Решение таких вопросов полностью закрывается силами сопровождения;
Благодаря этому разработка, которая изначально занималась поддержкой продукта, может больше времени уделять его развитию и созданию нового функционала;
Масштабировать раздельные команды проще благодаря тому, что у них разные задачи и требуются разные по специфике специалисты.
Причины
Зачем что-то менять, если кажется, что всё хорошо?
Этой статьи про наш опыт могло и не быть – нас всех всё устраивало (или нам так казалось).
Каждый был занят своим делом. Разработка поставляла фичи: на анализе → в разработке → в тестировании → готово. Сопровождение разбирало заявки, решало их или передавало задачи в разработку. Так продолжалось по кругу, пока однажды мы не поняли: никто из нас не видит весь контекст целиком и не понимает, какую на самом деле бизнес-задачу мы решаем. Каждый фокусируется на задачах в том виде, в котором они доходят до исполнителя. Это привело нас к мысли, что на самом деле всё далеко не так радужно, как нам казалось, и нужно что-то менять.
Важную роль сыграло и то, что я тогда работал в компании недавно, был джуном с горящими глазами, который только-только пришёл в команду. При этом у меня было чёткое представление, как должно выглядеть эффективное взаимодействие разработки и сопровождения, и я был готов его выстроить. Но перед этим нужно было доказать, что так, как сейчас, не работает (или работает плохо). И тут пригодились мои навыки аналитика и помощь команды.
Что поможет открыть глаза на истинное положение вещей?
Субъективные ощущения – это важно, но чтобы доказать свою позицию, нужны были и объективные данные, то есть цифры. Поэтому, подумав, мы выделили три категории маркеров:
Внешний субъективный: как к нашей работе относится внешний мир (конкретные заказчики, коллеги).
Внутренний субъективный: как к нашей работе относимся мы сами (наши ощущения).
Внутренний объективный: как проблема отражается на нашей работе (реальные факты).
Внешний субъективный маркер
Команда не находится в вакууме. Её всегда окружают те, кто зависит от её работы: пользователи, клиенты, смежные команды, менеджеры продукта / проектов, линейные руководители, менеджеры продаж. Если представители этих групп чем-то недовольны, у команды проблемы.
Чтобы понять, есть ли проблемы у нас, мы для начала выделили два ключевых лица: менеджера продукта (как заказчика команды разработки) и линейного руководителя группы технического сопровождения (как ответственного за помощь клиентам в случае проблемных ситуаций). И решили с ними поговорить – как оказалось, не зря.
Выяснилось, что для менеджера продукта наша команда – большая неопределённость. Мы не можем гарантировать, что все необходимые настройки и конфигурации включены; не знаем, как живёт наша доработка в промышленной эксплуатации; в случае обработки проблем с промышленной схемы не понимаем, на чьей стороне мяч: на нашей или у сопровождения. Словом, тотальная рассинхронизация.
Для линейного руководителя сопровождения ситуация оказалась не лучше. Сотрудники, которые приходили с огнём в глазах и жаждой перемен, спустя время угасали: искреннее желание помочь сменялось на базовое исполнение алгоритмов без возможности отойти в сторону. У ребят не было инструментов, которые бы давали им возможность влиять на развитие продуктов, предлагать свои идеи, учитывать эффект от новых фич на работу. В итоге достигалось состояние роботизации человека.
Внутренний субъективный маркер
Роботизация – опасный знак. Он означает, что мы перестаём решать проблему клиента и начинаем ставить процессы выше людей – для саппорта это путь в никуда.
Поэтому следующим этапом нам нужно было понять, совпадает ли ощущение руководителя с ощущением сотрудников сопровождения. Для этого мы провели опрос среди ребят, в котором попросили их оценить, насколько, как им кажется, они влияют на изменения, чувствуют себя важной частью команды. Шкалу выбрали десятибалльную, в которой оценка 7 и выше отражает позитивное состояние сотрудника. Если же оценка ниже, это повод задуматься о том, что мы делаем не так.
Результаты, как вы понимаете, были неутешительными и подтвердили наши опасения.
Внутренний объективный маркер
Субъективные маркеры позволяют понять, что проблема есть. Но как именно она на нас отражается, какой эффект оказывает на бизнес? Лучше цифр на этот вопрос ничто не ответит.
Мы решили посмотреть, как изменяется динамика задач от сопровождения, которые получает команда разработки. Это должно помочь ответить на вопросы:
учитываются ли интересы ребят при разработке?
делаем ли мы продукт пригодным для сопровождения и эксплуатации?
Как видно из результата, потребности сопровождения растут достаточно быстро. Меньше чем за год они выросли в два раза. Решаются при этом они, поверьте, не так оперативно.
И вот мы остались наедине с целым списком проблем…
Рассинхронизация. Разработка и сопровождение не могут продуктивно контактировать друг с другом. Вместо установки прозрачных взаимоотношений мы лишь порождали неопределённость.
Рост запросов в разработку от сопровождения. Сопровождение системы становится дорогим, и нам нужно разобраться, почему так происходит.
Выгорание. Мы явно видим, что у сопровождения «тухнет» огонёк в глазах, уходит желание что-то менять. В результате снижается личная ответственность и, как следствие, ухудшается качество услуг, которые мы оказываем.
Нет понимания, что мы единая команда. Разработка и сопровождение не чувствуют, что они двигают один продукт к одной цели.
Отсутствие атмосферы для роста. Люди не видят, что могут расти и совершенствовать навыки внутри своего коллектива и продукта.
Действия
Что делать?
У нас было несколько вариантов ответа на этот вопрос. Например:
Автоматизировать основные сценарии работы сопровождения. Казалось бы, правильная мысль, но достаточно дорогая, требует множество ресурсов со стороны команды разработки. А без выстроенной коммуникации мы рискуем скатиться в производственный ад. Запоминаем это направление как развитие на будущее и идём искать решение дальше, чтобы создать для него почву.
Расширить штат сотрудников для решения растущих задач от сопровождения. Этот способ решает последствия (причём не все), а не причину проблем. Он не способствует сплочению команды, скорее, наоборот, чем больше численность, тем острее будут чувствоваться проблемы. Отметаем такой подход.
Принять проблему как данность. Этот вариант подходит, когда цена решения проблемы выше, чем получаемый профит. В нашем случае это не так. Мы хотим делать полезные фичи, а для этого нужно успевать за бизнесом. Игнорирование проблемы не поможет нам в этом.
Провести организационные изменения. Способ, который позволит изменить наше взаимодействие друг с другом, покажет, где и чего нам не хватает. Та самая «почва» для дальнейших улучшений. Это наш вариант, его и будем использовать.
Как понять, что мы идём «туда»? Надеваем розовые очки
Мы выделили основные проблемы, наметили решение, с помощью которого будем эти проблемы решать, но двигаться всё ещё рано. Сначала нужно выработать основные ориентиры, на основании которых будем выбирать каждый последующий шаг. Это то, что позволит убедиться, что мы движемся в верном направлении.
Для генерации этих ориентиров мы на время надели розовые очки и помечтали, отвечая на вопрос «каким хотим видеть наше будущее?»
Вот что получилось:
1. Разработка и сопровождение – часть одной продуктовой команды
Вся наша работа направлена на то, чтобы в итоге принести пользу конечным пользователям и бизнесу. Эта цель – повод объединиться вокруг своего продукта.
При этом пользовательский опыт – это не только про пользование самим продуктом, он формируется и при взаимодействии с поддержкой. Скорость и качество решения проблемы напрямую влияют на лояльность клиента и его отношение к продукту. При таком подходе развитие продукта обязано учитывать развитие его сопровождения.
Для владельца продукта при этом сопровождение перестаёт быть чем-то сторонним, а становится его «руками» на бою.
Для сопровождения тоже есть польза: владелец продукта, видя в сопровождении свою часть, заинтересован в метриках, которые, в свою очередь, смогут выдать для сопровождения явные триггеры к действию.
Чтобы понять, есть ли с этим ориентиром проблемы, есть безотказный способ. Если услышите фразу «это у них проблемы» – это самый яркий и часто слышимый мной признак сепарации разработки и сопровождения. Ведь у одной команды и проблемы общие.
2. Сотрудник должен быть мотивирован
Пришёл я как-то в офис рано утром в том состоянии, в котором обычно люди приходят рано утром на работу в понедельник. Каково же было моё удивление, когда коллега (который пришёл ещё раньше!) светился от удовольствия. Я спросил, в чём дело, и получил в ответ: «Круто же. Рад вас всех видеть, сегодня ещё что-нибудь крутое сделаем. Кайф». Вот цель этого ориентира – добиться кайфа для всех участников продуктовой команды.
Мотивированный сотрудник, как показывает практика, будет решать именно проблему, а не двигаться по определённому алгоритму просто потому что так надо.
3. Если есть ответственность, есть и полномочия
Если мы дали сотруднику какую то задачу / обязанность, то должны дать ему и инструмент для её решения. Инструмент не обязательно будет чем то физическим. Прозрачная платформа, чтобы донести потребности, – тоже инструмент.
4. Управление как услуга
Этот ориентир говорит о том, что управление командой не должно быть директивным. Задача управления – помочь команде построить процессы таким образом, чтобы профессионалы работали ещё лучше. И делать это нужно до тех пор, пока команда в этом нуждается.
5. Минимизация выполнения запросов и времени простоя
Тут всё просто. Быстрее выполняем запросы клиентов и наш сервис доступен всегда → мы обладаем преимуществом на рынке.
Начинаем движение к цели
Сейчас мы реализовали три шага, которые дали значительное ускорение в нашем командном развитии: уменьшили время неопределённости для клиентов, создали единое инфополе, систематизировали подход управления в команде как услуги.
Шаг 1. Снижаем неопределённость для клиентов
С чем работаем: построение продуктовой команды, минимизация выполнения запросов и простоя.
Если хочешь понять, как что-то работает, нарисуй этот процесс. Так мы и сделали, когда поняли, что с нашим взаимодействием что-то не так: схематично набросали, как работают сопровождение и разработка при разборе запросов клиентов.
Красным выделили участок, когда клиент находится в состоянии неопределённости: его заявка не двигается с места, и он не понимает, чего ему ждать. И попробовали это исправить.
В данной ситуации размер команды – наше преимущество. Мы можем быстро обсуждать любые непонятные вопросы и принимать решение, что делать дальше.
Благодаря этому небольшому изменению мы в достаточно сжатые сроки устраняем неопределённость со стороны клиента, работаем с его ожиданиями.
При этом мы начали лучше понимать друг друга, видеть слабые места нашей системы на бою, понимать, какие боли бывают у сопровождения.
На этом этапе можно смело сказать, что наши правила взаимодействия работают на решение проблемы, а не существуют ради самого существования.
Стоит учитывать, что в нашем случае мы заменяем формальные взаимоотношения неформальными, а в них тоже есть свои правила, которые человек так или иначе запоминает. Минус неформальных правил – они часто индивидуальны для разных людей. Поэтому способ отлично работает при соотношении 1:1 (одна группа разработки – одна группа сопровождения), без дополнительных связей. При любом другом раскладе адаптируйте его под себя.
Шаг 2. Создаём единое инфополе
С чем работаем: построение продуктовой команды, ответственность и полномочия, минимизация выполнения запросов и простоя.
Я уже писал, что полномочия могут иметь не только физическое отражение: продвигать свои идеи, влиять на приоритизацию, быть в контексте происходящего – тоже необходимые инструменты. Чтобы это было возможно, нужно создать единое инфополе. Мы решали этот вопрос с двух сторон.
Во-первых, пригласили представителя сопровождения на свои ежедневные стендапы. Поначалу он просто слушал, погружался в контекст происходящего, в правила проведения дейлика. Потом начал активно задавать вопросы по волнующим его задачам, давать обратную связь команде и в моменте отвечать на вопросы. Если он понимал, что для боя критична какая-либо тема, он озвучивал её, и разработка тут же приоритизировала эту историю в своём плане на день.
Это привело к тому, что планы разработки стали прозрачными для сопровождения, стало понятно, почему та или иная задача находится в работе. Планирование задач разработки теперь учитывает интересы сопровождения, а разработчики стабильно начали получать обратную связь.
Во-вторых, сопровождение позвало менеджера продукта и тимлида разработки к себе. Раз в две недели мы собираемся и обсуждаем статусы по текущим проектам, планируем новые. Слушаем, с какими проблемами сталкиваются ребята, и строим roadmap по их решению. Рассказываем о планах и будущих релизах. Так мы достигаем эффекта, при котором сопровождение учитывает интересы разработки.
Если понимаем, что всё стабильно и вопросов для обсуждения нет, просто расходимся, но ни в коем случае не отменяем встречу. Лучше потратить 15 минут сейчас, чем потом неделю исправлять ошибку нашей дискоммуникации (прецеденты отмены и пожинания последствий были).
В этом шаге мы учли, что мир не однополярный, и позволили информации распространяться в границах нашей продуктовой команды.
В сочетании с первым шагом сформировали условия, при которых негатив от внешнего воздействия не остаётся на ребятах из сопровождения, а «размазывается» о командное единство, что позволяет в спокойной обстановке решать проблемы.
Шаг 3. Систематизируем подход управления в команде как услуги
С чем работаем: построение продуктовой команды, мотивация сотрудника, управление как услуга, ответственность и полномочия, минимизация выполнения запросов и простоя.
Это самый важный шаг, который и стал основной платформой всех дальнейших изменений.
Для начала мы решили в явном виде обозначить в команде, что мы все равны. Команда имеет цели, и все наши навыки направлены на их достижение. Кто-то хорошо программирует, кто-то сопровождает, а я строю процессы. Это даёт чёткое понимание, что каждый делает свою работу, позволяет наладить доверительные отношения.
Услуги, которые мы можем предложить с помощью управления:
Развитие сотрудника
Построение самоорганизации
Управление во время ЧС
Развитие сотрудника
Рост специалиста – это не только его мотивация. Это шанс для роста продукта, возможность решать более сложные и комплексные задачи.
Тимлид в команде – второй человек после самого сотрудника, кто заинтересован в его развитии. Несмотря на то, что тимлид не обладает административным ресурсом, он может активно участвовать в развитии сотрудника, потому что ему понятно, как соотнести желания человека с целями и задачами команды и продукта. Это работает на то, чтобы сотрудник прокачивал скиллы и, как следствие, двигался по карьерной лестнице.
Построение самоорганизации
Самоорганизованная команда в моём понимании – это то состояние зрелости, когда достаточно прийти с задачей или проблемой, а команда сама найдёт решение и реализует его. Роли тимлида при этом распределены между участниками команды, тимлид как отдельная роль становится не нужен.
Для достижения такого состояния необходимо создать культуру генерации идей.
Вот инструменты, которые нам в этом помогли:
Делегирование. Мы даём ребятам возможность самостоятельно управлять маленькими проектами внутри продукта. Никто не принимает решение за них, руководитель лишь задаёт вопросы, чтобы сотрудник мог учесть те нюансы, которые не кажутся прозрачными сразу. При этом в случае поражения мы не бросаем его, а защищаем от внешних сил и с помощью ретроспективы выясняем, что можно сделать лучше.
Умение приносить идеи. Каждая идея должна приходить с обоснованием, пониманием конечного результата, который мы хотим получить. Когда сотрудник приходит с идеей, команда помогает ему докрутить её до состояния питча. Если она хороша, то сможет дойти до него. Если нет, сотрудник сам поймёт все слабые места и либо проработает их, либо отложит идею.
Умение обсуждать идеи. Мы в команде взяли за правило, что свои идеи можно питчить. При этом есть условие: мы обсуждаем предложение и его последствия без перехода на личности. Это правило мы строго соблюдаем, потому что так создаётся безопасная среда, в которой ребята готовы раскрываться.
Благодаря этому шагу улучшением продукта заинтересовалась большая часть команды, а у владельца продукта появилось поле для выбора идей для его технического и бизнесового развития. Он перестал быть в этом аспекте одинок.
В конечном итоге на многих проектах и задачах мы получили такой результат, как на картинке
Управление во время ЧС
Инструменты, которые я описал, делают сотрудников самостоятельными, и это их безусловное преимущество. Но у всего есть цена, и в данном случае это время. А когда происходит инцидент и мы начинаем терять деньги в онлайне, как раз времени у нас и нет.
Однако и эту проблему мы решили, выделив роль координатора. Координатор – не руководитель, им может быть любой член продуктовой команды, который разбирается в области, где произошёл инцидент. От инцидента к инциденту обладатель этой роли меняется.
Задача координатора – отследить, что команда предпринимает все действия, чтобы разрешить инцидент, и управлять коммуникацией с внешними лицами, которые заинтересованы в решении проблемы. После закрытия инцидента роль с исполнителя снимается.
Последствия (It works!)
Мы не сомневались, что все наши действия приведут к изменениям и работа станет более эффективной. Но чтобы, опять же, опираться не на субъективные ощущения, а на реальные цифры, решено было всё замерить. Динамика оказалась очевидной!
Первый из интересных результатов проявился в том, что у нас уменьшилось количество инцидентов.
Создав общий контекст для разработки и сопровождения, мы сделали так, что проблемы, которые раньше выстреливали на бою, устраняются теперь ещё до релиза.
Второе достижение – в разработку теперь поступает намного меньше задач от сопровождения.
Это связано с тем, что мы значительно уменьшили количество рудиментарных задач. Т.е. избежали тех ситуаций, когда задача выставляется, тухнет в бэклоге, а потом уже никому не нужна. Оптимизация управления ожиданиями клиента и единое инфополе привели к тому, что в разработку стали попадать только те задачи, которые действительно нужны.
И, наконец, третьим важным достижением стало то, что субъективное ощущение сотрудников улучшилось. И для меня это главное, потому что за любым проектом стоят люди, и важно, чтобы они чувствовали свою причастность, хотели сделать крутой продукт.
Как-то в начале пути нам сказали «снимите розовые очки», но именно эти розовые очки помогли нацелиться на те идеалы, к которым мы двигаемся и, как показывает практика, двигаемся успешно. Ещё раз обращу внимание, в центре всех этих идеалов находятся люди. Именно работая с людьми мы можем закрыть не только множество базовых проблем, но и вырастить ту культуру, которая продолжит решать проблемы без нашего участия.
