Что такое кросс функциональное взаимодействие
Кросс-функциональное взаимодействие
Современные технологии позволяют наладить мгновенную коммуникацию, упрощая сотрудничество. Таким образом, координация работы разных сфер может быть практически исключена.
Сфера кросс-функционального взаимодействия обширна. Это могут быть повседневные задачи, единовременные проекты, работа с клиентами, продажи и многое другое. Данная система позволяет решать вопросы комплексно, внося изменения на каждом этапе реализации.
Преимущества кросс-функционального взаимодействия в том, что каждый член группы вовлечен в рабочий процесс, может реализовать себя и узнать что-то новой в смежных областях. Также повышается командный дух и доверие в коллективе.
Подобное сотрудничество может принести максимальную эффективность в компании. Однако, наладить данный процесс не так то и просто.
На начальном этапе участник группы имеет слабые представления о том, чем именно занимается его коллега. И не может в полной мере оценить их вклад. Для того-чтобы команда работала единым фронтом необходимо знакомство и общение всех участников. А также информационный портал, где каждый участник может узнать обязанности своих коллег.
Для успешной и автономной работы, руководителю группы необходимо грамотно расставить цели, задачи, этапы, сроки и наладить коммуникацию. А также распределить их по всем участникам. Работники могут находиться в разных офисах, городах или странах и важно донести информацию до каждого.
Важно знать, что кросс-функциональному взаимодействию необходимы: четкая связь и высокая квалификация участников. Работники должны уметь работать в команде, быть ответственными и автономными. В данной схеме большую роль играет доверие и общение. Ведь традиционные подходы решения возникающих проблем очень часто не работают, при подобном взаимодействии. Важно предоставить возможность работникам выполнять работу в своем привычном ритме. И создавать инструменты для совместной работы.
Стоит отметить, это метод является новшеством в сфере менеджмента, и данная модель взаимодействия подходит высокотехнологичным компания.
Agile
Кросс-функциональные команды и самоорганизация в основе Agile. Part 2.
В первой статье из цикла “Кросс-функциональные команды и самоорганизация в основе Agile” мы рассмотрели само понятие и явление Agile культуры, обсудили имеющиеся стереотипы и заблуждения, сформировавшиеся вокруг данного термина, а также рассмотрели принципы, лежащие в основе Agile.
Основная цель данной статьи — разобраться с явлением “кросс-функциональных команд”, понять в чем же именно заключается особенность данного подхода и что делает его столь популярным и эффективным.
Кросс-функциональные команды
Обращаясь к понятию кросс-функциональных команд мы часто сталкиваемся с большим количеством разночтений и отсутствием четкой определенности “кросс-функциональности”.
Термин “кросс-функциональная команда” берет корни из фреймворка Scrum. В то же время, опыт множества проектов показывает, что такой подход к формированию команд является оптимальным как с точки зрения скорости внедрения изменений, так и в плане оптимизации процесса разработки и снижения издержек — ключевых принципов подходов Kanban и Lean. Это позволяет применить данную концепцию и в рамках других Agile фреймворков.
В поисках определения данного термина, логичным будет обратиться к Scrum Guide (здесь и далее приводятся цитаты из официальной русскоязычной версии Scrum Guide):
Scrum‐команды являются самоорганизующимися и кросс-функциональными… Компетенций кросс-функциональной команды достаточно для выполнения полного объема работ. Под последним следует понимать весь комплекс работ в сочетании с оптимальным способом ее исполнения, необходимым для реализации бизнес‐ценности.
Прежде всего стоит обозначить, что сама сущность кросс-функциональной команды подразумевает активное участие в ней не только технических специалистов (Back-end, Front-end разработчиков и QA специалистов). Такая команда может и по возможности должна включать в себя бизнес-аналитиков, маркетологов, UX-дизайнеров и других специалистов, принимающих активное участие в проекте. Все это делается для достижения следующего немаловажного пункта из Scrum Guide:
Модель команды в Scrum предполагает минимизацию внешних зависимостей, располагая к гибкости, творчеству и продуктивности.
Роли в рамках кросс-функциональной команды
Какие же роли есть в кросс-функциональной команде? Раз уж мы начали рассмотрение данной концепции на примере Scrum, предлагаю продолжить и взять за пример состав стандартной Scrum Команды:
При этом в рамках Команды Разработки отсутствует формальное деление по “зонам ответственности” и грейдам — все являются равноценными членами команды и несут равную степень ответственности как за успехи, так и за провалы.
В некоторых командах это приводит, например, к отсутствию выделенного QA специалиста, ведь итоговое качество продукта и его соответствие ожиданиям бизнеса является ответственностью и критерием качественной работы всей команды, а не отдельно взятого специалиста. В связи с этим, широкое распространение получили такие технические практики как Test-Driven Development и Pair Programming, являющиеся частью фреймворка Extreme Programming(XP). Возможность применения практик из различных фреймворков, дополняющих базис основного — одно из главных свойств и преимуществ Agile.
Кросс-функциональный подход к формированию команды может применяться и в рамках любого другого фреймворка. Главное ограничение — размер команды. При этом оно не носит формального характера. Вы не обязаны укладываться в рекомендованный Scrum Guide размер “3–9 человек”, но всегда стоит помнить про формулу, предлагаемую нам Project Management Body of Knowledge (PMBOK):
Общее количество каналов коммуникации равно n(n-1)/2, где n — количество участников проекта.
Таким образом, для команды из 10 участников, число потенциальных каналов коммуникации будет равно 45, для 9 человек — 36, и так далее. В справедливости данной формулы не трудно убедиться. Возьмите стандартный набор инструментов коммуникации внутри команды:
Прибавьте к этому такие варианты как CRM-система, использование разных мессенджеров для общения внутри команды и с Заказчиком, телефон и любые другие варианты, которые есть в Вашей компании, и цифра стремительно пойдет вверх.
На мой взгляд, оптимальный размер команды равен 5+/-2 человека.Стоит учитывать, что в рамках Scrum роли Scrum Master’а и Product Owner’а вынесены за пределы команды разработки и не учитываются при определении размера команды.
Преимущества кросс-функционального подхода
Каковые же преимущества кросс-функциональных команд над классическими?
Чтобы ответить на этот вопрос, давайте вернемся к нашему списку принципов, лежащих в основе Agile культуры, который мы озвучили в первой статье цикла. Грамотное применение данного подхода позволяет реализовать сразу половину из них:
Собираем кросс-функциональную “команду мечты”
Конечно я не смогу дать Вам универсальный рецепт состава команды на все случаи жизни. Вместо этого я предлагаю кое-что получше — перечень инструментов и факторов, которые стоит подготовить и/или принять во внимание при формировании кросс-функциональной команды для Вашего продукта или проекта.
Следующие факторы должны помочь убедиться что все, кто нужен для работы над проектом, на борту:
Надеюсь в данной статье Вы смогли найти для себя весомые доводы в пользу кросс-функционального подхода к формированию команд или ответы на вопросы о данном подходе.
В следующей статье из цикла мы рассмотрим принцип, лежащий в основе работы кросс-функциональных команд — самоорганизацию.
Зачем HR-специалисту становиться «расческой», или Кросс-функциональность как конкурентное преимущество
Что такое кросс-функциональность и чем она хороша
В интернете можно встретить термин «люди-расчески» — это про тех специалистов, которые оттачивают знания сразу в нескольких сферах. Признаюсь, что такое название мне не близко, однако в своей работе я замечаю стойкий спрос на кросс-функциональных специалистов. Это может быть юрист, обладающий знаниями в области психологии конфликтов, логист, разбирающийся в экономике или sales-менеджер с экспертизой в аналитике.
Вы слышали разговоры о том, что через какое-то время специалистов заменят роботы? Так вот, не заменят, или, вернее, заменят не всех. Машине можно передать рутинные процессы, но творческая деятельность, генерация новых идей и умение в сложной ситуации найти необычное решение останется за человеком.
Кросс-функциональный специалист, работающий на стыке двух или более сфер, — это как раз такой незаменимый «винтик». Он ведет свою карьеру по пути, по которому до него либо вообще никто не шел, либо шло очень ограниченное количество людей. Он постоянно сталкивается с новыми вызовами и обладает принципиально новым, уникальным опытом.
Например, специалист по маркетингу, в обязанности которого входит подготовка новостей, пресс-релизов и контента для рассылки по клиентской базе, начинает заниматься программированием и версткой сайта компании. В какой-то момент он становится уникальным профи на стыке маркетинга и ИТ.
Развитие в новой сфере может стать хорошим вариантом для человека, который достиг карьерного потолка или столкнулся с эмоциональным выгоранием. В этом случае подумайте, в каких близких отраслях или даже соседних отделах можно применить ваши знания? Универсальный пример: вместо того чтобы увольняться, секретарь может продолжить развитие в рамках своей компании на позиции младшего маркетолога или аналитика.
Зачем кросс-функциональность HR-менеджеру
Сфера HR остро нуждается в кросс-функциональных менеджерах. Успешные HR-специалисты постигают основы маркетинга и учатся грамотно применять самые разные маркетинговые инструменты — от «воронок» до исследований и таргетинга, чтобы сделать поиск специалистов эффективнее и быстрее. Марчар, или HR-маркетолог, — это уже не столько новый тренд, сколько новая реальность, объявления о поиске таких специалистов постоянно появляются на hh.ru.
Растет спрос на HR-специалистов с опытом и экспертизой в ИТ-сфере. Знание основ программирования дает новые инструменты для оптимизации поиска и найма, рынок диджитал-инструментов для управления персоналом растет, и для того, чтобы ориентироваться в них и грамотно использовать, нужны навыки работы с высокими технологиями и глубинное понимание диджитал-процессов.
Чтобы выигрывать в борьбе за таланты, компании серьезно работают над своим работодательским брендом. Представьте, какую пользу делу может принести HR-специалист, который знает современные тренды, умеет анализировать целевую аудиторию, проводить исследования, «упаковывать» и доносить уникальное предложение работодателя до потенциальных сотрудников самым эффективным способом. Такой человек, сочетающий функции HR-специалиста, социолога, маркетолога и порой SMM-специалиста, на рынке труда обладает мощным конкурентным преимуществом.
Как стать кросс-функциональным
В первую очередь — задуматься над тем, чем вам действительно нравится заниматься. Решение стать кросс-функциональным специалистом — отличная возможность чуть больше полюбить свою работу, добавив в нее той деятельности, которая приносит вам удовольствие.
Может, вы увлекаетесь словесностью, много читаете и друзья часто говорят, что вы хорошо пишете? Или следите за трендами в социальных сетях и смотрите вебинары для эсэмэмщиков? А может, у вас есть чувство вкуса и вам интересен дизайн сайтов? Все эти навыки можно отточить и развить с пользой для карьеры и для компании.
Не обязательно и даже не нужно сразу идти на второе высшее. Присмотритесь к краткосрочным курсам, интенсивам, мастер-классам от профи.
Не гонитесь за модой и не уходите в какую-то сферу просто потому, что «все так делают». Повальное увлечение языком программирования Python привело к тому, что рынок стал перенасыщен «питонистами», тогда как хорошие программисты на более сложном языке JAVA по-прежнему в дефиците.
Следуйте за своим интересом, учитесь, пробуйте, находите что-то новое, становитесь уникальными экспертами — и это обязательно принесет результат.
Как сформировать кросс-функциональную команду
Воплощение большинства бизнес-проектов требует широкого спектра навыков и знаний. Если вы руководите таким проектом, то практически обязательно вам приходится управлять группой представителей разных профессий. Они могут быть частью вашей организации, представлять различные подразделения вашей компании или работать в совсем отдельных структурах. Откуда бы они ни были, они объединены в то, что называется «межфункциональной» или «кросс-функциональной» командой.
Как менеджер проекта, над которым работает команда, вашей задачей является организация членов команды с тем, чтоб превратить их эффективную и слаженную группу специалистов, способную достичь целей, поставленных перед проектом. Сложная задача? Бесспорно, сложная — даже запутанная и трудоемкая. Однако, если следовать определенным правилам, сплочение команды может стать вполне благодарным занятием, а также более легким и вполне успешным. В этой статье изложены самые основные моменты.
Что необходимо знать
Я новичок в менеджменте проектов и мне необходимо сформировать кросс-функциональную команду. С чего мне начать и как найти подходящих людей?
Начните с того, какие задачи ставит перед собой проект и каких навыков требует их выполнение. Затем присмотритесь к сотрудникам и определите, кто из них обладает необходимыми знаниями и энтузиазмом. В то же время необходимо определить, требует ли проект привлечения сотрудников извне. После этого надо нанять людей, которые вам подходят, — для этого может понадобится разного рода одобрение вашего и их начальства. Очевидно, что список кандидатов может сильно разниться в зависимости от характера проекта и объемов необходимой работы.
Если, например, вам необходимо совершить переезд в более подходящее для проекта рабочее помещение, то вам скорее всего понадобятся планировщики, упаковщики, грузчики, электрики, специалисты по установке оборудования, специалисты по телекоммуникациям и т.п. Вероятно, вашим новым сотрудникам нужно будет переехать из разных подразделений компании, потому что вы выбрали именно тех, у кого есть необходимые знания и навыки и тех, кто готов хорошо выкладываться.
Вполне вероятно, что человек, заинтересованный в выполнении проекта — то есть тот, кто назначил вас руководителем, — будет вашим союзником и поможет вам выбрать необходимых людей и нанять их.
Как соблюсти правильные пропорции личностных качеств и знаний в команде проекта?
Это правильный ход мыслей! Взаимодействие разных по характеру личностей во время работы может внести разлад в общее дело, или даже совсем застопорить его. В конечном счете может оказаться, что то, как члены команды взаимодействуют между собой, было гораздо важнеей тех знаний, которыми они обладали.
Так какие же типы личностей должны быть присущи членам новой команды?
Начнем с десятка стандартных командных ролей, выделенных доктором Мередитом Белбином, выдающимся британским автором книг о бизнесе, преподавателем и консультантом. Эта классификация появилась благодаря его исследованию, проведенному в конце 1960-х годов. Классификация прошла проверку временем и по сей день актуальна по обе стороны Атлантики.
В идеале, пропорции личностей указанных типов должны быть разумно соблюдены, поскольку если представителей одного типа будет больше, это может создавать проблемы. Представьте себе команду, состоящую из судей или испытателей! И помните о том, что один член команды может выполнять несколько ролей одновременно.
Так что не переживайте, если в вашей команде по несколько человек на одну роль — это тоже можно использовать. Скажем, можно разбить команду на более мелкие подгруппы, каждая из которых будет заниматься определенными аспектами работы и делать таким образом вклад в общее дело.
Что делать дальше
Ознакомьтесь со стадиями формирования команды
С момента формирования команда проходит через ряд этапов, и на каждом из них могут возникать сонмы проблем и испытаний.
Например, ваша команда пытается разрешить запутанную дилемму, в процессе чего, естественно, возникают конфликты и споры. Если вы вовремя поймете, что это просто такой период развития внутрикомандных отношений, а не будете ломать голову на тем, как успокоить сотрудников, — вы гораздо легче сможете оценить объем необходимой работы, а не тратить время на конфликты.
На стадии устаканивания необходимо подтолкнуть команду в нужную сторону
Для каждой команды необходимо определить вектор. Векторы — это как бы направляющие, и каждый из членов получает свою такую направляющую, руководствуюясь собственными представлениями, мыслями и стремлениями. Для команды было бы катастрофой, если бы все векторы были направлены в разные стороны, и даже если один из членов команды движется в противоположном направлении, это может сослужить дурную службу.
Одна из первостепенных задач менеджера проекта — заставить всех двигаться в одном направлении, чтобы достичь общих целей — это называется «направленность». Хоть это и очевидно, все равно удивляет количество проектов, которые терпят неудачу из-за того, что члены команд тянут одеяло на себя, и на это никто толком не реагирует.
Что мотивирует, а что раздражает членов команды
Мотивация крайне важна для того, чтоб команда работала эффективно и гармонично. Исследования мотивирования показывают, что мотиваторы и демотиваторы — это не совсем связанные вещи. Нечто способное мотивировать людей и подпитывать их энтузиазм — это не всегда то, при отсутствии чего они будут чувствовать неудовлетворение, недовольство и апатию.
Вот список из десяти мотиваторов для членов проектной команды и десяти демотиваторов.
(Из книги Р.Дж. Юрзака «Мотивация в проектах»)
Держите в памяти эти списки, пройдитесь с ними по списку сотрудников и подумайте, что могло бы наилучшим образом промотивировать каждого из них по отдельности или в небольших группах. Затем подумайте, какие из демотиваторов присутствуют на вашеи проекте. Наконец, подумайте, как можно усилить эффект от положительных явлений и снизить влияние негативных.
Делегируйте, но не забывайте контролировать
Делегирование полномочий — еще один важнейший инструмент руководства проектной командой. Раздавать задания — что и является сутью делегирования — кажется очень просто, но далеко не все справляются с этим, особенно, в начале.
Секрет успешного делегирования в том, чтоб почувствовать себя в шкуре членов команды. Скажем, вы опытный и ответственный профессионал, вы хорошо разбираетесь в своей работе и любите ее, но над вами стоит менеджер проекта, который постоянно заглядывает вам через плечо, готовый заранее раскритиковать каждый следующий ваш шаг! Или, к примеру, вы совсем новичок, неуверенный в себе, своих способностях и обязанностях, а над вами стоит руководитель, который умывает руки и ждет, выплывете вы сами, или утонете. Как бы вы вели себя в каждой из ситуаций?
Делегирование требует правильного баланса между контролем и независимостью
Потому, помимо советов по делегированию, запомните еще и правила контроля за выполнением.
Быстро решайте конфликтные ситуации
Чего стоит избегать
Невовлечение коллег в первоначальное планирование
Устанавливать все правила самостоятельно, диктовать методы без обсуждения с командой — это поиск неприятностей на свою голову. Вы собрали этих людей вместе, потому что они опытны и хорошо разбираются в своей работе — так вовлекайте же их в общее дело с самого начала. Они не только преоставят информацию и полезные идеи, но еще и почувствуют себя соавторами общего плана, что поможет им следовать ему в будущем более ответственно и лучше вкладываться в проект.
Отказ от лидерства
С другой стороны, команда — это не совет и не комитет, чтоб коллективно руководить проектом. Вы все еще руководитель, и от вас ожидают, что вы направите все усилия участников в нужное русло, ставя на службу общему делу все полезные идеи и опыт, которые есть у вас в распоряжении. Лучший способ поддерживать согласие в команде — вовлечь всех в планирование на начальном этапе, объяснив объем работы и масштабы проекта. Обязательно нужно добиться комментариев и замечаний, и затем, держа их в уме, пересмотреть еще раз конечные задачи с теми, кто будет их выполнять, и откорректировать план так, чтоб всех он устраивал.
Микроменеджмент
Просто забудьте о нем. Вы не сможете уследить за каждой мелочью самостоятельно. Более того, ваша команда потеряет всяческий интерес к самостоятельной работе. Большинство членов команд гордятся тем, что для проекта выбрали именно их, и это помогает им выполнять свою задачу. Используйте это. Передавайте задачи, поручайте отдельные куски работы, следите за выполнением должным образом, но сосредотачивайтесь на проекте в целом — не упускайте из виду целостную картину. Именно в этом заключается работа руководителя проекта.
Как стать кросс-функциональной командой
DevOps обычно рассматривается в двух ипостасях:
У таких команд, помимо «мы так не умеем, потому что так раньше не делали», есть и другие вызовы. Михаил Бижан рассказал на конференции DevOps Conf 2019 о тех, с которыми встретилась его команда в Райффайзенбанке, и как они это решали. Михаил отвечает за автоматизацию в банке, вместе с командой внедряя инженерные практики и поддерживая инструменты автоматизации.
Раньше Михаил уже внедрял культуру DevOps в Сбербанке. Но до этого, работая на стороне интегратора (в основном на «госов») наловил кучу анти-паттернов. Потому что чем характерны госзаказчики? Годовалыми проектами, невообразимыми бюджетами и полным отсутствием намека на Agile и DevOps. Там все строго. Сначала ты пишешь ТЗ, чтобы стопка бумаги была метр от пола. Если меньше, это не ТЗ (и даже не проект) — это несерьёзно. Потом ты разрабатываешь, а если что-то не получается — виноват ты и денег не получаешь (хотя госзаказчик, скорее всего, все равно счастлив, потому что бюджет освоен и что-то формальное достигнуто).
Так что у Михаила большой опыт в том, как делать не надо. А как делать можно — понимает из чтения книг и общения с сообществом и коллегами. Как системный аналитик, Михаил не старается решить всё методами разработки, а анализирует проблему, чтобы понять её root cause и сделать так, чтобы она больше никогда не повторялась. На этом сочетании и построен доклад.
Сегодня поговорим о том, что болит у всех и всегда, и что иногда кажется невозможным — о кросс-функциональности в энтерпрайзе. Энтерпрайз — это любая компания, которая разрабатывает более, чем один IT- продукт. Если у вас языковая школа, и вы пилите в целом всё для неё, у вас вряд ли энтерпрайз. А если у вас, например, универсальный банк, где есть розничное кредитование, факторинг, кэш-менеджмент, и все это legacy, спагетти-код и прочее, — скорее всего, у вас энтерпрайз. Или если вы системный интегратор, у вас тоже может быть энтерпрайз, потому что вы пилите для большого количества заказчиков всякое счастье и используете все виды технологий, процессов в ежедневной деятельности.
Поэтому в энтерпрайзе задача создания и развития кросс-функциональных команд кажется мало выполнимой.
Разберемся с матчастью
Что вообще такое продуктовая команда?
Есть мнение, что DevOps летает только там, где есть Agile. С одной стороны это так, с другой стороны — необязательно. Но суть Scrum-, Agile-, DevOps-, каких угодно продуктовых команд в том, что одна группа людей создает один продукт «под ключ». Это может быть сложносоставная группа из нескольких feature-teams, которых объединяет только единый бэклог, но в любом случае это единый продукт. У продуктовой команды единые цели, структура прибыли, структура затрат и один продукт:
Такое описание продуктовой команды — это краеугольный тезис, который толкает вас в дебри невозможности кросс-функциональности, потому что у любого адекватного человека начинается смех и истерика, когда ему говорят: «Ребята, вы теперь будете делать всё. У вас 20 человек в команде, делайте розничное кредитование», например. Скорее всего, после такой постановки задачи вы поинтересуетесь у коллег, где скачать заявление на увольнение, потому что неохота от руки писать.
Но вам говорят; «Спокойно, мы будем делать из вас кросс-функциональную команду, вас всему научим, всё вам дадим!» И получается примерно так:
Кросс-функциональностью что только не называют. Я встречал мнение, что это система, при которой какой-то огромный департамент с индусами каждой продуктовой команде разрабатывает всё, что не относится к логике работы самого продукта. Если нужно что-то ещё, команды опять прибегают к этому огромному департаменту. Но, по сути, это — внутренний аутсорс, когда вы примерно половину своей работы передаете какому-то «дежурному терапевту».
Все-таки обычно под кросс-функциональностью понимают тестирование, плюс разработку (иногда безопасность, если вы совсем крутые) и обязательно сопровождение (внедрение). И всё это происходит внутри одной команды, которая должна уметь заменить любого своего участника в случае чего.
С точки зрения продуктовой разработки, одним из базовых является принцип «You build — you run it». Только пока ты сам сопровождаешь то, что накодил — только тогда ты понимаешь все проблемы, которые твои клиенты, пользователи и смежные команды испытывают при работе с твоим продуктом. Об этом очень важно не забывать.
Маленький экскурс в Википедию
Обычно все говорят, что кросс-функциональность — это про t-shape. Давайте определимся с терминами:
Это не значит, что все умеют всё
Очень важный момент. Если мы из нашего π-shaped специалиста будем делать расческу, добавляя много ключевых экспертиз, то его госпитализируют в Кащенко (потому что он сойдет с ума). А если не сойдёт, то его экспертиза будет не такой уж глубокой, потому что человеческой жизни не хватит на то, чтобы стать экспертом во всем:
Каждый новый скилл, который вы приобретаете, и каждая новая экспертная область, с которой вы знакомитесь, должна позволять вам более эффективно выполнять свои текущие задачи. Если вы прочитали на Хабре, что ML — это круто, и решили на досуге выучить Python, то это ваше хобби. Когда у вас появятся задачи, связанные с Python или с ML, за которые вам будут платить — тогда можно говорить, что вы наращиваете горизонтальные навыки. Например, я люблю играть на гитаре, но за это в банке мне не доплачивают (к сожалению). То есть я не могу сказать, что я π-shaped в сторону игры на гитаре.
В энтерпрайзе команда должна уметь делать неочевидные вещи
Когда мы говорим про энтерпрайз (банки, телеком и пр.), есть ряд неочевидных штук, про которые все либо никогда не задумывались, либо задумывались, но не придавали им значения до тех пор, пока им не сказали: «Ребята, вы теперь продуктовая кросс-функциональная команда!»
Взаимодействие с клиентом
Продукт — это то, за что клиенты платят вашей компании. У продукта всегда есть P&L (Profits and Losses). Он отчуждаемый. Например, кредитная карта — это продукт, потому что за нее вы платите деньги банку. А банк несет за неё какие-то расходы: он ее запрограммировал, создал бизнес-модель, как-то её рекламирует, печать пластика, доставка, логистика и пр. Банку может казаться, что супер-крутая карта, сделанная из чистого золота с гравировкой лица вашей мамы или бабушки — это супер-свежая бизнес-модель, которая прямо сейчас взорвет рынок, и все придут к нему, отключившись от всех остальных банков. Но это может оказаться не так, если банк предварительно не спросит об этом у вас — клиента.
Это кажется банальностью, но очень многие продуктовые команды (и даже компании) не знают, чего хотят их клиенты. Они делают то, что хочет, например, их CEO. Вы сами можете вспомнить 100500 таких примеров:
При создании продукта вы должны не просто понимать, что нужно вашему клиенту. Вы должны знать, что хочет ваш клиент сегодня, завтра, послезавтра и в любой другой день. Специфика банковского рынка такова, что наша прибыль не будет расти, если мы будем повышать цены на услуги или наращивать комиссии. Единственный рабочий драйвер — рост клиентской базы. Но это справедливо и наоборот — демпинг не сработает. Условно, ипотека везде стоит плюс-минус 10%. Но если сегодня мы сделаем ипотеку 5%, у нас будет очень много клиентов, но у ЦБ будут серьезные вопросы. Поэтому вместо этого мы вкладываемся в маркетинг и даем клиентам какие-то другие плюшки, например хороший сервис или скидки на другие продукты. Причем давать нужно именно то, что хочет клиент — это поможет выбрать именно наш ипотечный продукт.
Механизмы взаимодействия с клиентом, которые позволят вам слушать и слышать его голос — это то, что любая продуктовая команда должна уметь и иметь возможность сделать by design. Это важная штука.
Горячая линия 24/7
Ещё до Сбербанка, работая проектным менеджером, я, как и многие айтишники, дежурил по выходным. И это был отстой! Я ничего не умел делать с кодом и чувствовал себя максимально тупым и бесполезным в это время. Я сидел перед монитором с графиками только для того, чтобы в случае аварии взять такси и доехать до дома моего разработчика и позвонить в дверь, потому что он телефон не слышит. Не рекомендую!
Если бы тогда я знал то, о чём сейчас рассказываю, мы бы на берегу договорились с командой о правильной организации поддержки. Обычно в энтерпрайзе есть отдельная выделенная линия поддержки 24/7, колл-центр где-нибудь не в Москве. И любая команда должна иметь возможность с ним работать.
Допустим, я — product owner той же кредитной карты. Я могу написать условный скрипт (инструкцию в Word), отдать в 24/7 и сказать, что если на горячую линию банка будут звонить по таким-то вопросам, то звоните Пете, если по таким — то Коле, а все остальное — не наше. Это я уже наполовину молодец.
Чтобы мне стать полностью молодцом, нужно еще при каждом изменении функционала моего продукта оповещать об этом службу 24/7. Если Коля заменился на Аллу, функциональность добавилась или убавилась, колл-центр должен об этом узнавать.
Клиент – это тот, кто платит. У нас для продуктовой разработки специфично и характерно то, что все клиенто-центрично, а не IT- или CEO-центрично. Клиент хочет быстро получать всё, что ему нужно. И если у него есть проблема, он должен максимально быстро получить решение, просто позвонив или написав. Никто этого сейчас, наверное, нормально делать не умеет, но это то, к чему нужно стремиться.
Технологический долг и инциденты
Технологический долг — это то, с чем каждый из нас работает так или иначе. Это может быть автоматизацией регресса, рефакторингом старого кода, разработкой API для чужого кода и т.д. Это понятие очень широко трактуют. Я знаю компании, в которых под технологическим долгом понимают исключительно архитектурные несоответствия спецификации, но это очень узко и на мой взгляд некорректно.
Инциденты, баги, аварии прода и так далее — это то, что случается у всех. Но когда это начинает случаться часто и по одним и тем же причинам, это вызывает серьёзное раздражение. Тем не менее, мы не должны заливать эту проблему человеческими или какими угодно другими ресурсами («На 20 падений сервисов ответим наймом 20 новых DevOps-инженеров!»), нужно сесть и подумать, почему сервис падает и как сделать так, чтобы он не падал. Тогда наши инженеры могут заниматься новыми более классными штуками, например, попилотировать CI/CD инструменты, которые они еще не трогали, чтобы потом к нам прийти и сказать: «Чувак, я нашел что-то круче Jenkins»:
То есть root cause — работа с технологическим долгом, который не всегда будет вашим, кстати. Продуктовая команда в энтерпрайзе иногда вынуждена менять не свой код (например, в случае сервисной шины) для того, чтобы внедрить фичу в продакшн, изменение в функциональности и выкатить его на рынок.
Взаимодействие со смежными сервисами
Представим, что мы разрабатываем функционал выдачи кредитов в мобильном приложении. Я — product owner в розничном кредитовании с отличным отделяемым P&L. И есть ряд каналов, через которые я этот продукт продаю — сайт, iOS и Android приложения, мобильное рабочее место операциониста.
В мобильном приложении банков, как вы знаете, какой только функциональности нет — от переводов между картами до выпуска новых карт, погашения ипотек, алиментов, оплаты ЖКХ и прочего. Это круто, это XXI век:
Но я, как product owner, отвечаю только за свой продукт — за розничное кредитование. А если в мобильном приложении, например, iOS, которым пользуются миллионы людей, вдруг сбойнул текущий счет и человек просто свой баланс не видит? Он не будет, заходя в приложение, даже думать о том, чтобы взять кредит. Он скажет: «О! Где мои сто тысяч рублей?!» и будет звонить в банк и спрашивать: «Доколе?!»
Поэтому взаимодействие со смежными сервисами — это та часть жизни вашей продуктовой команды, который может вам как сильно помочь в чем-то, так и сильно помешать.
В чем он может вам помочь? Если вы делаете какие-то смежные маркетинговые компании и продвигаете их через единый канал (например, мобильное приложение), вы можете получить синергию. Например, я выпускаю функционал по розничному кредитованию и могу предложить кредит на супер-условиях для молодых семей. А команда ипотеки то же самое делает, но для пенсионеров и лиц пожилого возраста. Мы можем прекрасно скооперироваться и вывести единый релиз под эгидой социальной защищенности.
Или если вы имеете внутренний опенсорс, то часть компонентов, которые вы используете со смежными сервисами, можно переиспользовать. Например, API или графические интерфейсы. Это вообще true — никто давно уже не переписывает фронт или элементы дизайна каждый себе. Так вы сможете а) сэкономить, б) потенциально не потерять аудиторию (если что-то пойдет не так) или не вызвать волну хейта именно к вашему продукту.
Также потенциально вы можете получить совершенно неочевидные бенефиты, если будете более плотно дружить и общаться не только с клиентом, который вам платит, но и с теми людьми, которым он платит тоже. Это люди, которые “сидят” на тех же каналах с вами, в одном банке.
И наоборот. Они могут у нас увести активную аудиторию, сломать приложение, которое является каналом продажи наших услуг. Синхронизация релиз трейнов, расписания поставок, или чего угодно, что вы используете — важно.
Прикладные платформы
Это частный случай смежных сервисов. Ранее упомянутая шина — одна из них.
В банках это чаще всего DWH и АБС — автоматизированные банковские системы. АБС — это монструозная конструкция, в которой делается собственно банкинг. Там происходят основные финансовые операции, генерируется отчетность ЦБ. Это мозг зверя по имени банк. А все остальные его органы с АБС так или иначе взаимодействуют. Обычно АБС в банке ровно одна, потому что больше не надо. Есть исключения, например, при объединении банков какое-то время они живут с двумя, а то и тремя АБС, но обычно это нерационально. Так же, как и в случае с процессингом.
Любая платформа — это, по сути, черепаха, на которой стоит мир. Клиенты пользуются вашими услугами – они покупают кредитку, скачивают мобильное приложение, отправляют друг другу стикеры и чатятся. Но если у вас где-нибудь умрет процессинг, всё пойдет насмарку:
С процессингом вы можете общаться, либо выпиливая из него некоторые сервисы, микросервисы и другие абстракции, либо попросить свои платформы, чтобы они сделали унифицированный канал общения всех сервисов с ними. Тогда случай, происходящий с одним продуктом, не будет аффектить на платформу, и как следствие, — на другой продукт.
Это базовая безопасность, которая позволит вам не упасть в случае падения платформы. Если в вашей компании упадет сервисная шина, ваш продукт упадет и не будет работать тоже. Если в банке упадет процессинг, через 5 часов вам позвонят из ЦБ, а через сутки заберут лицензию, каким бы банк ни был, даже №1. Это недопустимо.
Когда вы дизайните вашу кросс-функциональную (продуктовую) команду, платформа — это то, что вы должны держать в поле зрения. Вы должны уметь безопасно работать с платформой, а платформа должна уметь безопасно работать с вами.
Инфраструктура
Вы всегда должны понимать, что происходит и будет происходить с вашей инфраструктурой, причем под инфраструктурой я понимаю и hardware, и базовые middleware штуки, и те самые оркестраторы всего на свете, которые вы используете при работе. Вы должны знать в моменте, как их использовать, как их точно не использовать и что с ними будет дальше. Потому что это даст вам возможность не только не допустить ошибку (классика), но и потенциально получить гешефт.
Хороший пример: у нас недавно появилась новая команда, которой нужна помощь в настройке CI/CD. У нас в банке CI/CD тулой сейчас является Atlassian Bamboo. Мы могли им сказать: «Друзья, вот Atlassian Bamboo, вот SDK, вот человек, который вам поможет это настроить. Мы готовы отправить вас на наш курс CI/CD, где вам расскажут основные паттерны взаимодействия — наслаждайтесь».
Но прямо сейчас мы в банке пилотируем другие альтернативные инструменты, так как нас во многом не устраивает Bamboo. Этой команде мы объяснили, что расклад такой — прямо сейчас есть Bamboo, есть пилоты такого и такого инструментов: «Не хотите ли вы попробовать сделать на них?» Риски понятны: если пилот не пойдет, им придется все это перевезти на тот, который будем внедрять. Но мы гарантируем поддержку и поможем им перепилить, чтобы безопасно перейти на тот, который будет выбран целевым.
То есть мы им дали информацию о том, какие минусы есть у текущего инструмента и какие плюсы у потенциально будущего. И дали информацию о том, как работает наша инфраструктура, чтобы они сделали осмысленный выбор. Они сказали: «Да, кайф», и выбрали тот пилот, в котором им было бы интересно поучаствовать. Без этой информации, просто выбрав «линию партии» и продолжив на Bamboo, через пару месяцев мы бы получили волну негатива, когда поменяли бы наш CI/CD-оркестратор: «Ребята, мы два месяца назад приходили. »
Танцуем от цели
Очень часто команды изобретают велосипед. Например, мне нужно выбрать инструмент оркестрации контейнеров. Я смотрю в Google какой-нибудь рейтинг от Gartner и вижу там K8S: «Нам нужен Кубер прямо сейчас!» — «Почему именно Кубер?» — «Да потому что я нагуглил, и он в каком-то рейтинге первый».
Но такой способ выбора решения не самый оптимальный. Нужно танцевать от цели. Какая у нас цель, зачем мне вообще оркестрация контейнеров? Зачем мне в принципе контейнеры? Затем, что я не хочу, чтобы каждая из команд, которые я обслуживаю (которым я служу — есть такой термин servant leadership, лидерство как служение), тратила по неделе рабочего времени одного человека на то, чтобы заполучить базовые образы, которые они потом будут в своем CI/CD конвейере использовать. Я хочу создать централизованно полный набор образов, которые будут безопасны, всех удовлетворять и прочее. Куда-то их положить, чтобы всем было хорошо, комфортно и удобно, и пусть юзают.
Поэтому целесообразно спросить тех, кто ими пользоваться будет. Клиенты — это мои команды: «Ребята, у вас какие ожидания?» Если они будут называть названия оркестраторов — это не то, что мне нужно. Мне интересны принципы, по которым они выбирают.
Один скажет, что ему нужно, чтобы работало быстро: быстро писалось и быстро читалось. Второму важно, чтобы на рынке была экспертиза представлена, потому что он ноль в этом, а ему надо брать с рынка джуниоров, которые в этом быстро разберутся (т.е. чтобы было просто). Третьему нужно, чтобы какой-нибудь PCI DSS проходил (стандарты по работе с картами Visa, Mastercard и НСПК) — особенные требования к безопасности — должен прийти аудитор и кадилом помахать: «Ваше управление контейнерами удовлетворяет требованиям PCI DSS».
Я выписываю эту критериальную таблицу и на ее основе принимаю решение, какой оркестратор мне нужен. У любой команды-потребителя сервиса должна быть возможность влиять на тот стек инструментов, который вы ей предлагаете. Я за то, чтобы люди сами определяли, что им нужно и как они хотят решать свои проблемы. А я предлагаю те решения, которые на мой взгляд удовлетворяют этим потребностям.
Конечно, у меня сбоку будет своя критериальная таблица типа: сколько это стоит, насколько просто это поддерживать, модель лицензирования и т.д. Но команды всегда дают input, что они хотят от своей инфраструктуры. Они хотят быстро, дешево, гибко — ОК, это их право. Они имеют право это требовать от нас, как от сервисных подразделений.
Как все это сделать?
Вы можете сказать: «Молодец, рассказал очевидные вещи — спасибо, кэп! — а что с этим делать?» Ответ очень простой: создать в вашей компании такую среду, чтобы работать неправильно было некомфортно, слишком дорого, сложно и т.д.:
Взаимодействие с клиентом
Как заставить, побудить, продать (какие угодно слова можно использовать) наши команды взаимодействовать с клиентом, чтобы они начали его слышать и слушать? Вы должны включить им голос клиента в какой-то мониторинг, либо в цели. Хоть радио в офисе повесьте с записями из отделений банка, как бабушки кричат том, что полчаса не могут пенсию снять.
Как это сделано у нас. Мы безальтернативно проводим опрос клиентов по основным банковским услугам, потом безальтернативно всем его показываем. Например, вы продаете кредитные карты, а вы дебетовые: вами довольны, а вами — нет. Люди видят результаты друг друга и понимают, что происходит не так. Их никто за это не наказывает, просто им стыдно. Когда один продукт любят, а второй нет, то вторые придут к первым и попросят рассказать секрет – что я делаю не так, что ты делаешь так, почему так происходит? Со временем эта история всегда выравнивается, потому что системы (а корпорация – это конечно система) склонны к равновесию.
Это очень долго, если у вас инертная компания, но, если вы молодые и энергичные ребята — это будет быстро. Если вам не все равно, процесс можно ускорить — ходить и пальчиком тыкать: «Смотри, у них хорошо, у тебя плохо. Не хочешь присмотреться?» Мы так делаем.
Резюме
Кросс-функциональная команда умеет:
1. Измерение клиентского опыта
Давать тут какие-то советы на мой взгляд не нужно, потому что литературы написано более чем достаточно. Просто перестаньте додумывать за клиента, и попробуйте любым способом узнать, что он на самом деле хочет.
2. Поддержка продукта 24/7
Помните, как раньше учили детей плавать? Вывозишь на лодке на середину реки и бросаешь в воду: «Давай, встретимся на берегу!» В переводе на нормальный язык с языка метафор это значит, что пусть команда пострадает.
Вы им говорите: «Вас 10 человек. Есть возможность работать с горячей линией 24/7, но для этого нужны скрипты, которые вы должны дать. Но вы можете этим не пользоваться — живите, как хотите!», а потом все звонки на горячую линию, когда какая-нибудь кредитка умерла, роутить прямо на product owner. В субботу ночью? ОК! В воскресенье ночью? ОК! В понедельник примерно к 5 утра он задумается о том, что же он делал в этой жизни не так, и к обеду скрипт будет в службе 24/7 — готовый и со всеми нюансами.
3. Технологический долг и инциденты
Тут несколько вариантов решения. Можно использовать тот же самый метод тотальной открытости, когда все видят, что одни перформят, другие нет — и смотрите, почему. А можно попытаться обосновать, что устранение технологического долга дает им измеримый бенефит.
Например, у вас и у соседней команды плюс-минус похожие продукты, но у вас стремный legacy-код, а у соседней команды — нет. В результате у вас есть некий постоянный уровень аварийности (допустим, 10 аварий в год), в отличие от той команды. Тут очень важный момент — нужно найти человека, который согласится исправить что-то один раз. Найдите конкретный legacy-фрагмент в коде и поймите, на что это влияет. Потом убедите команду это изменить и покажите цифры: «Вот у тебя было 10 аварий в год, теперь их 8! Давай сделаем дальше, и будет у тебя еще все более круто».
4. Взаимодействие с прикладными платформами
В структуре организаций частенько встречается некая платформенная команда, которая сидит, отгородившись отрядом лучников, скелетов, черных драконов, и никого к себе не подпускает: «Вам нужна доработка — приходите через 9 месяцев».
В этом случае мы задаём вопрос — что я могу сделать, чтобы я получил быстрее то, что я хочу? У продуктовой команды в целом таким и должно быть мышление — если вам что-то нужно, но говорят НЕТ, то узнайте, что нужно сделать, чтобы было ДА. То есть узнать, что нужно сделать, чтобы прикладная платформа внедрила изменения на своей стороне, которые нужны вам, быстрее (например, через месяц) — должны вы, как идеологи DevOps. Например, давайте сделаем API, или давайте продуктовая команда сделает изменения в платформенном коде, только чтобы все это было безопасно и т.д.
5. Взаимодействие со смежными сервисами
Аналогично — никаких секретов, просто человеческое общение, поиск взаимовыгодных условий совместной работы и ad hoc решение задач.
6. Инфраструктура
Как это бывает: приходит новая команда и говорит, что им нужны среды: «Нам нужен продакшн-сервак, у нас релиз через месяц». «Хорошо, вот заполни Excel, что конкретно ты хочешь, там всего 120 строчек». Я смотрю в эту таблицу и понимаю оттуда от силы 20 строчек, а для остальных мне нужен переводчик — человек, который знает, как их заполнять. Когда мы первый раз сказали нашей инфре, что это странно, — даже мы в этом не шарим, — то они дали нам образец, как это заполняется. С образцом я стал уметь заполнять 40 строчек из 120.
Я как потребитель постоянно говорю, что именно мне неудобно до тех пор, пока сервис не станет идеальным. Это один из принципов Agile —делаем не сразу идеально, а движемся постепенно к тому, чтобы стало хорошо, постоянно делаем лучше и лучше. Сейчас наша инфраструктура понимает, что она в первую очередь сервис, и теперь думает, как сделать жизнь своих клиентов легче.
Это шесть основных моментов, на которые, как показал опыт моей команды, нужно обращать внимание.
Если вы знаете еще какие-то вещи, которые кросс-функциональная продуктовая команда должна уметь делать со своим окружением — пишите, обсудим.
Вместо заключения: это будет непросто
Это невероятно сложная и неблагодарная работа — всё это провернуть и претворить в жизнь. Вам будет очень тяжело, если вы встанете на этот скользкий путь. Нам было очень тяжело:
Каждый раз, когда вы говорите, что будете менять среду таким образом, чтобы она побуждала людей сделать что-то, чего они раньше не делали, это будет дико демотивировать вас и ваших людей. Вы будете выгорать и ненавидеть весь мир. Но потом (через пару лет), люди, у которых стало хорошо, скажут: «Я красавчик, я всё сделал. Ты мне помогал, я помню. Но это фигня, а вот я красавчик!»
У нас важная новость о конференции HighLoad++ 2020. Во-первых, в Подмосковье (где находится Крокус-Экспо) введён полный запрет на массовые мероприятия с 21 октября по 7 ноября включительно. Вероятность продления запрета очень высока, а узнаем мы об этом, согласно стилистике публичных заявлений властей, накануне утром. Как бы нам не хотелось провести HighLoad++ именно сейчас, мы, с досадой и разочарованием, вынуждены подчиниться.
HighLoad++ 2020 пройдет оффлайн в новые даты — 17 и 18 февраля 2021 года, в том же Крокус-Экспо. Сформированная программа конференции не меняется, билеты автоматически будут перенесены, проживание в гостинице (если бронировали через нас) будет автоматически перенесено на новые даты.
Официальный телеграм-канал конференции поможет вам быть в курсе событий и изменений, а неформально обсудить можно в этом. Забронировать билет можно здесь. Встречаемся в феврале в Крокус Экспо!