Кросс функциональное взаимодействие в компании

DevOps обычно рассматривается в двух ипостасях:

1. Инструментарий — техника, tooling, технические процессы, CI/CD и прочие штуки — авто-всё, всё как код и т.д.
2. Культура — это как отдельным разработчикам прийти всем вместе к «мир, дружба, жвачка».

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

У таких команд, помимо «мы так не умеем, потому что так раньше не делали», есть и другие вызовы. Михаил Бижан рассказал на конференции 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. Давайте определимся с терминами:

• Монофункциональность (i-shape). От греческого μόνος — один. Допустим, я — разработчик Java: я умею писать на Java и больше ничего не умею и уметь не хочу (причем очень воинственно). Даже если умею, ни за что об этом не расскажу, потому что мне платят за то, что я пишу код на Java. Я — i-shaped, узконаправленный моноспециалист, я творец, пишу код, если вы против — до свидания!
• Полифункциональность (t-shape). От древнегреческого πολύς — многочисленный. Это когда я становлюсь менее агрессивным Java-кодером и говорю: «ОК, я могу еще тесты написать. Не себе, потому что это будет странно, а, например, — тебе» Или, например, я понимаю, как работает инфраструктура, на которой мой продукт функционирует, и могу там скрипты позапускать, пописать, повидоизменять. То есть я в целом имею представление о том, как работает весь ландшафт, в котором мой код существует, и в случае чего хотя бы пойму, что там не так работает. А если я совсем крут, то я могу еще что-нибудь поправить.
• Омнифункциональность (π-shape). От латинского omnis — каждый, всякий. Это достаточно новая в нашей индустрии штука. Ее называют π-shape, расческа-shape, как угодно-shape. Суть в том, что у вас вертикальных палочек с core-экспертизой становится больше — ты не просто крутой Java-разработчик, но ты еще крутой DevOps-инженер. Например, ты очень хорошо представляешь, как работает твой CI/CD, в идеале ты его еще и сам создал под свой Java-проект, ты молодец, ты — π-shaped!

Это не значит, что все умеют всё

Очень важный момент. Если мы из нашего π-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. Это недопустимо.

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

Инфраструктура

Инфраструктурный департамент — это те обслуживающие подразделения, которые представляют сервисы командам для того, чтобы они могли пилить свои продукты — железо, сети, и так далее. При этом, сама по себе инфраструктура — это адский ад сложностей. Потому что никто снаружи не понимает, как она устроена и какие есть планы ее развития. Они говорят: «Друзья, у вас сейчас голый Docker, мы пилотируем ванильный Kubernetes, еще в январе у нас будет Tanzu, еще где-то там рядом Openshift». А потом: «Все, это мы больше не поддерживаем, переезжай вон туда». Когда и чем всё это кончится, непонятно:

Вы всегда должны понимать, что происходит и будет происходить с вашей инфраструктурой, причем под инфраструктурой я понимаю и 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 года, в том же Крокус-Экспо. Сформированная программа конференции не меняется, билеты автоматически будут перенесены, проживание в гостинице (если бронировали через нас) будет автоматически перенесено на новые даты.

Официальный телеграм-канал конференции поможет вам быть в курсе событий и изменений, а неформально обсудить можно в этом. Забронировать билет можно здесь. Встречаемся в феврале в Крокус Экспо!

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

Что может снизить напряженность в кросс-функциональном взаимодействии?

1. Оценка кросс-функциональной интеграции (выявление «болевых» точек);
2. Приборные панели по совместным задачам, помогающие повысить осведомленность и увеличить скорость коммуникации.

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

Как оценить кросс-функциональную интеграцию?

Произвести оценку кросс-функциональной интеграции можно при помощи анализа:

• Кооперации — постановка общих целей, совместная работа для достижения общей цели
• Координации — принятие управления процессом, управление взаимодействием по деятельности, ориентация на улучшение рабочих процессов
• Коммуникации — поддержание взаимных потоков информации, обмен актуальной информацией, обеспечение ясности намерений

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

В данном процессе вам могут помочь следующие методики:

• Методика D. Pellathy

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

• Методика A. Ferreira & all

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

• Опросник увлеченности работой Schaufeli & Bakker

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

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

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

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

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

Эффективность сотрудников напрямую коррелирует с лучшими бизнес-результатами.

Как произвести исследование кросс-функциональной интеграции?

1. Интервью с руководителем, определение целей и задач участвующих подразделений
2. Опрос сотрудников онлайн (примерно 10-15 минут на заполнение)
3. Статистическая обработка данных, формирование отчета и рекомендаций, рассылка отчетов с графиками и комментариями на основе опроса
4. Дистанционная встреча с обсуждением результатов.

В этом процессе стоит обратить внимание на:

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

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

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

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

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

Учитывая объем технологий, созданных для улучшения командной коммуникации, межфункциональное сотрудничество должно быть проще, чем когда-либо. С его помощью мы можем немедленно связаться с коллегами из любого офиса, отдела или филиала. Мы можем обмениваться документами по всему миру с помощью Google Disk. Мы можем назначать задачи и сотрудничать с проектами в «Асане». Однако введение нового программного обеспечения в вашу команду — не всегда достаточная мера. Вероятно, у вас есть другие барьеры для преодоления, которые носят более личностный характер.

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

Общее определение

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

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

Преимущества

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

Как добиться эффективного взаимодействия

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

Развитие разнообразия

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

Сопротивление стремлению к перерасчету заседаний

При работе с большими, разнообразными, разобщенными командами иногда может потребоваться несколько недель, чтобы составить расписание каждого собрания для встречи. Регулярные встречи также превращаются с того момента, когда ваша команда приступает к работе над своими обычными задачами, что разочаровывает ее участников. По этим причинам важно ограничить количество собраний по совместному функциональному сотрудничеству, используя для этого минимальное количество времени. Удостоверьтесь, что вы используете новые технологии такие, как средства коммуникации и совместной работы. В компании KaiNexus, к примеру, используются такие инструменты, как Google Docs, GoToMeeting и, собственно, KaiNexus. Программное обеспечение Continuous Improvement — отличный способ заставить команды сотрудничать между встречами. Это делает и другие ваши встречи более продуктивными, а также помогает в поиске и анализе проблемных зон кросс-функционального взаимодействия.

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

Добивайтесь подлинного взаимодействия между людьми!

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

Привлечение лидеров

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

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

Поощрение заслуг

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

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

Трудности, связанные с недоверием

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

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

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

Кросс-функциональное управление и общение между сотрудниками

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

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

Кросс-функциональное общение

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

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

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

Проблемы кросс-функционального взаимодействия

Натали Поорски, директор по развитию Creative Kingdoms, взяла этот точный подход к объединению работы своих разработчиков программного обеспечения и создания контента, подключив рабочие процессы от Smartsheet и JIRA.

Creative Kingdoms, дочерняя компания Great Wolf Resorts, работает с такими организациями, как «Космический центр Кеннеди», для разработки имиджевого программного обеспечения, которое могло бы интегрировать в жизнь клиентов опыт многочисленных специалистов. Традиционно различные команды, участвующие в создании контента для игр, управляли своей работой с помощью различных инструментов. Siled work не позволяло командам общаться друг с другом в нужное время, чтобы наиболее эффективно выполнять заказы клиентов.

Натали была в эпицентре этих усилий и описала эту проблему как «действительно уникальную ситуацию в управлении проектами, потому что мы используем метод разработки Agile в методологии JIRA и Waterfall с нашей командой контент-мейкеров». Групповая работа была невероятно сложной, потребляла время и делала множество ошибок.

Вместо того, чтобы отказываться от Smartsheet и JIRA и искать новое решение, Натали работала над тем, чтобы найти способ подключения двух систем, а не просить ее команды найти новые способы работы. Соединяя Smartsheet и JIRA, контент по-прежнему продвигается по типу Waterfall, разработка продукта управляется в JIRA, и разные группы могут видеть весь жизненный цикл работы, а не только отдельные ее части. Члены команды теперь уверены, что они всегда смотрят на самую последнюю информацию о проекте, продолжая общаться в своем предпочтительном стиле со всей группой.

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

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

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

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

Кросс-функциональные коммуникации: что идет не так

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

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

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

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

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

Техники эффективных кросс-функциональных коммуникаций

Давайте кратко разберемся с тем, какие техники кросс-функциональных коммуникаций позволят нам избежать описанных выше проблем.

а) Ликвидация механизма «Мы — Они»

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

б) Информированность

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

в) Навыки медиации

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

г) Знания руководителей

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

Взаимодействуем правильно: итоги

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

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

09 окт 2018

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

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

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

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

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

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

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

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

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

Что такое кросс-функциональное сотрудничество?

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

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

Преимущества кросс-функционального сотрудничества

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

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

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

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

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

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

Рекомендации по созданию кросс-функциональных команд

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

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

Вот некоторые примеры факторов, которые нужно разнообразить при формировании вашей кросс-функциональной команды:
– Опыт- Способности- Навыки- Стаж работы- Срок полномочий- Возраст- Пол- Место нахождения

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

3. Измерьте реальное влияние
Когда у кросс-функциональных групп есть возможность увидеть, какое влияние они оказывают, устойчивость команд повышается. Люди хотят знать, что их усилия имеют значение; глядя на свои результаты, они будут больше заинтересованы в продолжении командной работы. В более широком масштабе разработка стандартного способа для измерения влияния каждой кросс-функциональной группы может помочь в определении ROI постоянного развития организации.

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

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

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

7. Поддерживайте инициативы
Все эти стратегии могут быть неэффективны, если сотрудники не получат признания, а коллективные усилия не будут вознаграждены. Нередко финансируются предложения, соответствующие целям какого-то одного отдела. Это идет в разрез с оплатой труда сотрудников и приводит к плохим результатам. Для совершенствования кросс-функционального сотрудничества лидеры должны ставить актуальные цели и вознаграждать людей за улучшение всей системы, а не только какой-то ее части.  Отличным примером межфункционального сотрудничества является случай компании Array Architects. Она включила в команду, занимающуюся решением проблемы бухгалтерского учета, архитектора. Он предложил подход, который сам проверил на практике. Его идея позволила решить проблему и сэкономила деньги и время компании, благодаря использованию программного обеспечения, уже имеющемуся у компании. Это решение никогда бы не было найдено без кросс-функциональной группы.

Почему кросс-функциональное сотрудничество на практике сталкивается с трудностями?

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

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

• Нехватка доверия

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

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

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

• Социальная леность

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

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

• Трудности в коммуникации

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

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

• Несовпадающие цели и задачи

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

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

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

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

Перевод: Алина Фалинская, тренинговый портал Аспект

Источник: kainexus.com