Кросс-функциональная команда

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

4 типа команд

4 типа рабочих команд наиболее часто встречающихся в организациях:

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

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

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

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

    Используй мощь разнообразия

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

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

    [1]

    Зачем нужны кроссфункциональные команды?

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

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

    ● разработка бизнес-дизайна новой бизнес-единцы или стартапа

    ● дизайн и разработка новых бизнес-моделей, продуктов и услуг;

    ● выбор и внедрение новых технологий во всей корпорации повсеместно;

    ● совершенствование цепочки превращения услуг в прибыль;

    ● сокращение себестоимости продукции.

    Основные задачи кроссфункциональных команд

    Управление непрерывными корпоративными переменами >>>

    ● создание предприятия с целостным системным подходом к управлению процессами

    ● управление процессами, нацеленными на повышение эффективности и продуктивности

    ● повышение ценности создаваемой компанией для потребителей и всех участников

    Выполнение конкретных насущных задач в заданные сроки

    ● разработка радикально инновационной технологии, продукта или услуги

    ● моделирование сценариев развития проекта с помощью бизнес-игры ИННОБОЛ

    ● управление комплексными проектами, охватывающими все стороны бизнеса

    Routes to finance

    4 Упражнения Для Проверки Скорости Работы Мозга (Sep 2019).

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

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

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

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

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

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

    Многие кросс-функциональные команды Exist

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

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

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

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

    Как я могу попасть в кросс-функциональную команду

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

    Кому не нужны кросс-команды

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

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

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

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

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

    Для каких бизнес-задач эффективны кросс-команды?

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

    Должны ли быть в компании специальные условия для того, чтобы складывались такие команды?

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

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

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

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

    ЛАЙФХАК Как определить состав для кросс-команды? С чего начать?

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

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

    Приходилось ли вам в практике идти от интересов сотрудников: например, человек выгорел и хотел бы перейти в другой отдел, но у него нет достаточных компетенций… Включили бы вы его кросс-проект?

    Безусловно. Мы в GE часто используем так называемый bubble assignment (т.е., дополнительный проект на ограниченное время), когда сотрудники из одной функции, которые по тем или иным причинам начинают уставать от повторяющихся операций или хотели бы сменить направление работы, включаются в работу других подразделений, на несколько часов в неделю. Это дает эффект оживления для самих таких сотрудников и свежий взгляд на проблему для команд из подразделения, куда они включены, а также возможность понять, если сотрудник хотел переходить в другое подразделения, справится ли он с новым родом занятий. И это, безусловно, помогает решить несколько задач — у сотрудников больше возможностей для развития, а компания может гибко распределять ресурсы для реализации стратегии.

    Многие компании перенимают опыт лидеров и в частности, формируют кросс-команды. Всем ли они нужны?

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

    Были ли случаи, когда кросс-команды не получались, не давали результата? В каких случаях они неэффективны и как это заметить? Когда они точно не нужны?

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

    Читайте так же:  Оповещение об увольнении и его законность

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

    Масштабирование без кросс-функциональных команд

    Как масштабировать разработку при отсутствии кросс-функциональности? Рассмотрим несколько реальных примеров.

    Перевод доклада Mike Burrows Scaling without cross-functional teams с конференции Øredev 2016 выполнен с разрешения автора.

    Майк является владельцем компании AgendaShift, консалтинговой компании, которая фокусируется на Lean-Agile трансформациях и Agile-коучинге.

    Майк — автор книг о Kanban-методе.

    Он работал в роли GDM (Global Delivery Manager), CTO (Chief Technical Officer) в крупных проектах по разработке программного обеспечения (ПО), в том числе на правительство Великобритании.

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

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

    В рассказе Майка минимум философии — максимум практичности.

    Пример 1 — Ранний рост

    В тот момент, когда Майк подключился к проекту, была одна команда — команда VBA (Visual Basic Application). Она разрабатывала настольное приложение для управления рисками на рынке бондов.

    Владельцы бизнеса решили, что нужно больше разработчиков для ускорения, и была создана новая команда — Web. Часть людей перешли из команды VBA в Web, часть была нанята извне. Люди из команды VBA отлично знали предметную область, так как пришли из операционной части бизнеса. Это здорово помогало команде развивать продукт.

    Роль Майка была в управлении поставкой обеих команд, официально роль называлась CTO.

    Команда VBA была частично зависима от команды Web с точки зрения данных: веб-сервисы команды Web были источником данных для настольного приложения команды VBA.

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

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

    Ключевая проблема была в том, что релиз новых версий продукта «разрушительно» влиял на работу бизнес-процессов компании. Для исправления ситуации в команду добавили владельца продукта (Product Owner, PO) и бизнес-аналитика (Business Analyst, BA). Над командами образовалась управленческая тройка: СТО, PO и BA. Они решали, в какую команду лучше отдать задачу в зависимости от того, с какой скоростью нужно было ее сделать и как долго потом поддерживать.

    Что получилось в итоге:

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

    В качестве вывода можно процитировать закон Галла:

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

    Пример 2 — Глобальный департамент

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

    Майк был в роли GDM (Global Delivery Manager).

    В каждую региональную команду (столбики на диаграмме выше) входили:

    • Бизнес-аналитик (BA) и проектный менеджер (Project Manager, PM).
    • Разработчики (Dev).
    • Техническая поддержка (Technical Support, TS).

    Так выглядела идеальная «маркетинговая» картинка. В действительности же было несколько по другому:

    • в одной локации не было команды разработки;
    • в одной локации не было BA/PM;
    • в двух самых больших локациях были подкоманды тестировщиков (Quality Assurance, QA);
    • в одной самой большой были компонентные команды разработки (на графике ниже обозначены буквами С, то есть Component).

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

    Реальная организационная структура была такой:

    Видео (кликните для воспроизведения).

    Поставка бизнес-ценности требовала совместной работы региональных команд (на картинке ниже обозначены буквой R, то есть Regional) и компонентных команд (на картинке ниже обозначены буквой С). Поддержка нужна была с обеих сторон:

    Также требовалось взаимодействие с технической поддержкой:

    Для полноты картины рассмотрим, как выглядел процесс релизов:

    Планирование, разработка, тестирование и развертывание были разнесены по итерациям.

    Идея простая и заманчивая, но по факту отвратительная:

    • из-за высокой стоимости синхронизации между релизами;
    • из-за высокого Cycle Time задачи от 4-6 недель.

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

    Еще один более яркий пример высокой стоимости синхронизации — это архитектурное взаимодействие между компонентами. Так выглядела высокоуровневая архитектура банковского приложения:

    Было много мелких изменений множества Front-систем и гораздо более редкие изменения нескольких Backend-систем. Синхронизация всех 3 слоев систем по релизам в такой структуре может быть настоящим адом.

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

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

    Пример 3 — Переход от внешнего подряда к более интегрированной модели с внутренней разработкой

    Забавный факт: в Великобритании большая часть Agile-коучей работает в проектах для правительства страны. Майк работал в одном из них, предметной областью которого была социальная поддержка. Это был проект в программе Government Digital Services (GDS — это аналог Госуслуги России). Мантрой людей, которые работали в проекте, была: «Начинайте с реальных потребностей. Потребностей вашего пользователя, а не правительства».

    Читайте так же:  Основное понятие. в каких случаях применяется документ

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

    Поток инициатив в проекте был следующим:

    [2]

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

    Шаг 1 “Discovery” — понять, что действительно нужно людям? Как люди будут пользоваться сервисом? Есть ли у людей доступ к технологиям? Что если у них нет доступа? Что если у них ограниченные возможности?

    Шаг 2 “Alpha” — быстрое прототипирование. Если не можем создать прототип в виде программного продукта, то делаем его на бумаге. Тестируем сервис с внутренними пользователями. Вырабатываем перечень функциональности для бета-версии, первой версии для внешних пользователей.

    Шаг 3 “Beta” — тестирование с людьми с улицы. Итоговая цель — наладить стабильную работу сервиса. Это сложно, но это ключевой шаг для перехода дальше. Без плана по стабильности проект не мог запуститься.

    Шаг 4 “Live” — система переходим в промышленную эксплуатацию, начинаются поэтапные улучшения.

    Перейдем к ролям в проекте:

    • Service manager — отвечает не только за доставку ПО, но и за сервис целиком (включая работу службы поддержки, внутренних обеспечивающих подразделений и прочего).
    • Часто его дополняли Product Owner и Project Manager (иногда эти роли совмещались). Project Manager — удобный прокси для другой части организации (обеспечение согласований, утверждение бюджетов и прочее).
    • User Research/Experience — тестирование системы с пользователями и проектирование интерфейса.
    • Delivery Manager — отвечает за программную часть сервиса (поставку ПО), в этой роли был Майк.
    • Название остальных ролей говорит само за себя.

    Очень важно понимать, что это роли, а не отдельные люди! Не надо на каждую проблему нанимать «менеджера проблемы». Совмещайте роли, если это возможно.

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

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

    Пример доски для отслеживания зависимостей:

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

    Люди и их навыки важнее, чем роли и организационная структура

    1. Роли заставляют человека думать в рамках ограничений, акцент на роли блокирует выполнение работы, которую человек реально может сделать!
    2. Организационная структура является затруднением, если люди думают только о ней. Правила коммуникаций в компаниях зачастую не требуют соблюдения иерархии. Это ограничение заложено в головах людей. Его нужно снимать.
    3. Начинайте с того, что у вас есть сейчас и что реально работает.
    4. Пусть реальные потребности приводят к развитию навыков и возможностей. Задайте себе вопросы: какие есть пробелы в текущей команде сейчас? Что нужно будет в будущем?

    T-shaped или узкие специалисты — у вас есть место для всех

    1. Если у вас 1 разработчик может взять задачу и реализовать ее на всех уровнях, проверить и выпустить ее — это очень круто!
    2. Если у вас есть 1 человек может написать лучшие скрипты развертывания — это тоже круто! Доверьте это ему.
    3. Помните и цените узких специалистов, их уход будет вам очень дорого стоить.

    Сплоченность крайне важна

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

    Частая поставка творит чудеса

    1. Начните там, где можно быстро поставлять (к примеру, веб и мобильная разработка)
    2. НО у вас должна быть стратегия расширения на другие части системы.

    Как стартовать Scaled Agile Framework® в условиях проектного подхода к бюджетированию.

    Сергей Рогачев (ScrumTrek) и Сергей Кононенко (Raiffeisenbank).

    В статье вы найдете фасилитационные материалы и фотографии с митапа.

    Артем Анин

    ИТ, управление проектом и продуктом, разработка ПО

    April 28, 2018

    Кросс-функциональные команды – это классно!

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

    Сейчас я работаю с большой командой, которая строит продукт под несколько клиентских платформ (мобилки и веб), а также через бекенд интегрирована с другими системами компании. Долгое время команда делилась на компонентные подкоманды: iOS, Android, Web, Back. Казалось бы, это самый оптимальный вариант – объединить сотрудников одной компетенции вместе, добавить им тестировщиков, и пусть они выпустят нам готовый продукт. На деле же между подкомандами существует множество зависимостей по API, по способу реализации фич, по продуктовой работе и так далее.

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

    Рекомендуемые онлайн-курсы

    Рекомендуемые материалы

    Кросс-функциональная роль HR: как объединить необъединяемых

    Почему кросс-функциональную команду (спасающую компанию и дающую ей новый рост) нужно формировать не по психотипам, совместимости и темпераментам, а по умению ставить задачи «не своим подчиненным»; как объединить этот разношерстный и порой конфликтующий коллектив и что должен сделать эйчар, чтобы участники такой команды не разбежались со словами «Да больше никогда!» – порталу HR-tv.ru рассказала руководитель отдела персонала (Supply Chain& Regions) компании FM logistic Юлия Мещерякова.

    — Юлия, в чем вы видите кросс-функциональную роль HR-службы? Для чего нужно развивать кросс-функциональных связи и коммуникации в компании?

    Читайте так же:  Что такое пифы

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

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

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

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

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

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

    По каким принципам нужно собирать кросс-функциональные команды?

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

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

    Как избежать кросс-функциональных конфликтов и как их решать?

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

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

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

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

    Что получают организации в итоге, если научились работать кросс-функциональными командами?

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

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

    Выделенные команды развития Scrum и кросс-функциональность

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

    Читайте так же:  Как написать заявление на командировку

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

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

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

    Позволяет использовать разнообразные материалы для разработки для оптимальных решений.

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

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

    Позволяет людям работать над различными вещами и сохраняет интересную работу.

    Существует несколько способов создания кросс-функциональных лиц из кросс-функциональных групп:

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

    Используйте парное программирование. Обычно используемые в разработке программного обеспечения, такие как eXtreme Programming, парное программирование может использоваться командой разработчиков для разработки любого типа продукта. Два разработчика работают вместе над одним и тем же компонентом. Разработчик A тактически развивается (например, сокращает код), в то время как разработчик B может свободно анализировать функциональность (масштабируемость, расширяемость, риски и т. Д.). Они переключают эти роли в течение дня. Поскольку эти разработчики работают так тесно, они могут быстро ловить ошибки.

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

    [3]

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

    Эффект Хоторна (или эффект Наблюдателя) основан на исследованиях, показывающих, что производительность рабочего увеличивается, когда кто-то наблюдает за ними. Он назван в честь Hawthorne Works, электрической компании за пределами Чикаго, где были проведены первые эксперименты.

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

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

    Видео (кликните для воспроизведения).

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

    Источники


    1. Марченко, М.Н. Общая теория государства и права. Академический курс в 3-х томах. Том 1 / М.Н. Марченко. — М.: Зерцало, 2002. — 546 c.

    2. Астахов, Павел Правописные истины, или Левосудие для всех / Павел Астахов. — М.: Эксмо, 2016. — 368 c.

    3. Сычев, Павел Хищники. Теория и практика рейдерских захватов / Павел Сычев. — М.: Альпина Паблишер, 2011. — 184 c.
    4. Тихомиров, М. Ю. Увольнение по инициативе работодателя. Практическое пособие / М.Ю. Тихомиров. — М.: Издание Тихомирова М. Ю., 2015. — 499 c.
    5. Малько, А.В. Теория государства и права (для бакалавров). Учебник / А.В. Малько, др.. — Москва: Высшая школа, 2015. — 196 c.
    Кросс-функциональная команда
    Оценка 5 проголосовавших: 1

    ОСТАВЬТЕ ОТВЕТ

    Please enter your comment!
    Please enter your name here