кросс функциональный проект что это
Кросс функциональный проект что это
[Сейчас будет штамп, но по-другому тут и не скажешь, ведь]
Наверняка, каждый из вас сталкивался с проблемой сложности выстраивания коммуникаций с другими командами. У этих «других» ведь все как-то иначе: у «этих» задачи разработчики вместо аналитиков заводят, «вот эти» по спринтам живут, а «вон те» вообще говорят, что до II квартала 21-ого года задачи не принимают…
И ты такой стоишь посреди всего этого великолепия и не знаешь, с чего начать, чтобы все же сделать задачу? Надеюсь, эта статья поможет тебе.
Хочу рассказать о том, как мы все можем сделать работу над кросс-проектами в нашем IT более предсказуемой, понятной и более эффективной. Работая над проектом по запуску постаматов, наша команда накопила кое-какой опыт. В этой статье постараюсь донести все полезные наработки, которые может использовать каждый сотрудник IT подразделения.
Сначала давайте обговорим, что же такое кросс-функциональные проекты и какой проект можно к ним отнести, а какой нет. За общий случай мы берем:
Кросс-функциональные проекты – проекты или крупные фичи, в которых задействовано 2 и более функциональных модуля от разных команд
Почему именно разные функциональные модули и разные команды? Все просто: в рамках одного модуля у нас постоянно происходит взаимодействие между разными командами. Например, между бэком и фронтом. Это уже настолько обыденная ситуация, что было бы странно объявлять это кросс-проектом и как-то по-особому с ним работать. Тоже самое касается и «разных команд»: если одна и та же команда работает над двумя модулями, то у нее тоже вряд ли возникнут проблемы в реализации, особенно, если писать код или аналитику будет один и тот же разработчик или аналитик. Но если команды разные и модули разные – тут уже вполне могут начаться проблемы…
При работе с постаматам мне и моей команде очень повезло: очень четко были определены цели проекта, обозначены сроки и выделены ресурсы. Более того, объем ресурсов даже позволял, в теории, уложиться в обозначенные сроки! Но встал большой вопрос – как всем этим хозяйством распоряжаться?
Быстро выяснилось, что так или иначе задействованы будут практически все модули ЭК5 и интеграции. Одних только аналитиков было задействовано 19 человек! При этом изначально вся наша команда: я в качестве PM и Мария Колесникова как главный аналитик проекта.
1. Убедись, что понимаешь, что и зачем тебе нужно сделать. Если нет – самое время спросить у главного по твоему направлению.
2. Если нет главного – стоит спросить об этом своего менеджера. И о том, что непонятно и о том, почему нет главного по направлению. Менеджер не любит вопросов (фи-и-ить, щютка), так что он, наверняка, быстро организует назначение «точки входа».
3. Убедись, что ты и твои коллеги составили план работ – понятный всем и выполнимый (хотя бы на ближайшую перспективу). Если нет – подними этот вопрос сам в общем чате или же снова напомни о себе менеджеру (надеюсь, меня не побьют и не отравят).
4. Если что-то меняется в проекте – не забудь предупредить об этом коллег по проекту. Может быть, это даже не у тебя меняется, а ты где-то на митинге услышал об этом: если считаешь, что это может что-то задеть в проекте – лучше «перебдеть» и лишний раз переспросить.
5. Верь в своих коллег! Даже если у них срываются сроки и они тебя подводят – скорее всего, они это не специально и расстроены не меньше твоего (если это не так – да осквернят шакалы прах их предков). Лучше спроси их, чем можешь помочь и поддержать.
6. Если твои задачи систематически «задвигаются» коллегами – тут уже не стоит это терпеть. Время ставить вопрос о том, что «без моей левой гусеницы танк тоже не поедет!»
Сейчас мы работаем над трансформацией вышеописанного в простой и понятный регламент работы по кросс-функциональным проектам. А вообще, самый лучший регламент – это ответственное отношение к своему делу и окружающим.
Agile
Кросс-функциональные команды и самоорганизация в основе Agile. Part 2.
В первой статье из цикла “Кросс-функциональные команды и самоорганизация в основе Agile” мы рассмотрели само понятие и явление Agile культуры, обсудили имеющиеся стереотипы и заблуждения, сформировавшиеся вокруг данного термина, а также рассмотрели принципы, лежащие в основе Agile.
Основная цель данной статьи — разобраться с явлением “кросс-функциональных команд”, понять в чем же именно заключается особенность данного подхода и что делает его столь популярным и эффективным.
Кросс-функциональные команды
Обращаясь к понятию кросс-функциональных команд мы часто сталкиваемся с большим количеством разночтений и отсутствием четкой определенности “кросс-функциональности”.
Термин “кросс-функциональная команда” берет корни из фреймворка Scrum. В то же время, опыт множества проектов показывает, что такой подход к формированию команд является оптимальным как с точки зрения скорости внедрения изменений, так и в плане оптимизации процесса разработки и снижения издержек — ключевых принципов подходов Kanban и Lean. Это позволяет применить данную концепцию и в рамках других Agile фреймворков.
В поисках определения данного термина, логичным будет обратиться к Scrum Guide (здесь и далее приводятся цитаты из официальной русскоязычной версии Scrum Guide):
Scrum‐команды являются самоорганизующимися и кросс-функциональными… Компетенций кросс-функциональной команды достаточно для выполнения полного объема работ. Под последним следует понимать весь комплекс работ в сочетании с оптимальным способом ее исполнения, необходимым для реализации бизнес‐ценности.
Прежде всего стоит обозначить, что сама сущность кросс-функциональной команды подразумевает активное участие в ней не только технических специалистов (Back-end, Front-end разработчиков и QA специалистов). Такая команда может и по возможности должна включать в себя бизнес-аналитиков, маркетологов, UX-дизайнеров и других специалистов, принимающих активное участие в проекте. Все это делается для достижения следующего немаловажного пункта из Scrum Guide:
Модель команды в Scrum предполагает минимизацию внешних зависимостей, располагая к гибкости, творчеству и продуктивности.
Роли в рамках кросс-функциональной команды
Какие же роли есть в кросс-функциональной команде? Раз уж мы начали рассмотрение данной концепции на примере Scrum, предлагаю продолжить и взять за пример состав стандартной Scrum Команды:
При этом в рамках Команды Разработки отсутствует формальное деление по “зонам ответственности” и грейдам — все являются равноценными членами команды и несут равную степень ответственности как за успехи, так и за провалы.
В некоторых командах это приводит, например, к отсутствию выделенного QA специалиста, ведь итоговое качество продукта и его соответствие ожиданиям бизнеса является ответственностью и критерием качественной работы всей команды, а не отдельно взятого специалиста. В связи с этим, широкое распространение получили такие технические практики как Test-Driven Development и Pair Programming, являющиеся частью фреймворка Extreme Programming(XP). Возможность применения практик из различных фреймворков, дополняющих базис основного — одно из главных свойств и преимуществ Agile.
Кросс-функциональный подход к формированию команды может применяться и в рамках любого другого фреймворка. Главное ограничение — размер команды. При этом оно не носит формального характера. Вы не обязаны укладываться в рекомендованный Scrum Guide размер “3–9 человек”, но всегда стоит помнить про формулу, предлагаемую нам Project Management Body of Knowledge (PMBOK):
Общее количество каналов коммуникации равно n(n-1)/2, где n — количество участников проекта.
Таким образом, для команды из 10 участников, число потенциальных каналов коммуникации будет равно 45, для 9 человек — 36, и так далее. В справедливости данной формулы не трудно убедиться. Возьмите стандартный набор инструментов коммуникации внутри команды:
Прибавьте к этому такие варианты как CRM-система, использование разных мессенджеров для общения внутри команды и с Заказчиком, телефон и любые другие варианты, которые есть в Вашей компании, и цифра стремительно пойдет вверх.
На мой взгляд, оптимальный размер команды равен 5+/-2 человека.Стоит учитывать, что в рамках Scrum роли Scrum Master’а и Product Owner’а вынесены за пределы команды разработки и не учитываются при определении размера команды.
Преимущества кросс-функционального подхода
Каковые же преимущества кросс-функциональных команд над классическими?
Чтобы ответить на этот вопрос, давайте вернемся к нашему списку принципов, лежащих в основе Agile культуры, который мы озвучили в первой статье цикла. Грамотное применение данного подхода позволяет реализовать сразу половину из них:
Собираем кросс-функциональную “команду мечты”
Конечно я не смогу дать Вам универсальный рецепт состава команды на все случаи жизни. Вместо этого я предлагаю кое-что получше — перечень инструментов и факторов, которые стоит подготовить и/или принять во внимание при формировании кросс-функциональной команды для Вашего продукта или проекта.
Следующие факторы должны помочь убедиться что все, кто нужен для работы над проектом, на борту:
Надеюсь в данной статье Вы смогли найти для себя весомые доводы в пользу кросс-функционального подхода к формированию команд или ответы на вопросы о данном подходе.
В следующей статье из цикла мы рассмотрим принцип, лежащий в основе работы кросс-функциональных команд — самоорганизацию.
Зачем HR-специалисту становиться «расческой», или Кросс-функциональность как конкурентное преимущество
Что такое кросс-функциональность и чем она хороша
В интернете можно встретить термин «люди-расчески» — это про тех специалистов, которые оттачивают знания сразу в нескольких сферах. Признаюсь, что такое название мне не близко, однако в своей работе я замечаю стойкий спрос на кросс-функциональных специалистов. Это может быть юрист, обладающий знаниями в области психологии конфликтов, логист, разбирающийся в экономике или sales-менеджер с экспертизой в аналитике.
Вы слышали разговоры о том, что через какое-то время специалистов заменят роботы? Так вот, не заменят, или, вернее, заменят не всех. Машине можно передать рутинные процессы, но творческая деятельность, генерация новых идей и умение в сложной ситуации найти необычное решение останется за человеком.
Кросс-функциональный специалист, работающий на стыке двух или более сфер, — это как раз такой незаменимый «винтик». Он ведет свою карьеру по пути, по которому до него либо вообще никто не шел, либо шло очень ограниченное количество людей. Он постоянно сталкивается с новыми вызовами и обладает принципиально новым, уникальным опытом.
Например, специалист по маркетингу, в обязанности которого входит подготовка новостей, пресс-релизов и контента для рассылки по клиентской базе, начинает заниматься программированием и версткой сайта компании. В какой-то момент он становится уникальным профи на стыке маркетинга и ИТ.
Развитие в новой сфере может стать хорошим вариантом для человека, который достиг карьерного потолка или столкнулся с эмоциональным выгоранием. В этом случае подумайте, в каких близких отраслях или даже соседних отделах можно применить ваши знания? Универсальный пример: вместо того чтобы увольняться, секретарь может продолжить развитие в рамках своей компании на позиции младшего маркетолога или аналитика.
Зачем кросс-функциональность HR-менеджеру
Сфера HR остро нуждается в кросс-функциональных менеджерах. Успешные HR-специалисты постигают основы маркетинга и учатся грамотно применять самые разные маркетинговые инструменты — от «воронок» до исследований и таргетинга, чтобы сделать поиск специалистов эффективнее и быстрее. Марчар, или HR-маркетолог, — это уже не столько новый тренд, сколько новая реальность, объявления о поиске таких специалистов постоянно появляются на hh.ru.
Растет спрос на HR-специалистов с опытом и экспертизой в ИТ-сфере. Знание основ программирования дает новые инструменты для оптимизации поиска и найма, рынок диджитал-инструментов для управления персоналом растет, и для того, чтобы ориентироваться в них и грамотно использовать, нужны навыки работы с высокими технологиями и глубинное понимание диджитал-процессов.
Чтобы выигрывать в борьбе за таланты, компании серьезно работают над своим работодательским брендом. Представьте, какую пользу делу может принести HR-специалист, который знает современные тренды, умеет анализировать целевую аудиторию, проводить исследования, «упаковывать» и доносить уникальное предложение работодателя до потенциальных сотрудников самым эффективным способом. Такой человек, сочетающий функции HR-специалиста, социолога, маркетолога и порой SMM-специалиста, на рынке труда обладает мощным конкурентным преимуществом.
Как стать кросс-функциональным
В первую очередь — задуматься над тем, чем вам действительно нравится заниматься. Решение стать кросс-функциональным специалистом — отличная возможность чуть больше полюбить свою работу, добавив в нее той деятельности, которая приносит вам удовольствие.
Может, вы увлекаетесь словесностью, много читаете и друзья часто говорят, что вы хорошо пишете? Или следите за трендами в социальных сетях и смотрите вебинары для эсэмэмщиков? А может, у вас есть чувство вкуса и вам интересен дизайн сайтов? Все эти навыки можно отточить и развить с пользой для карьеры и для компании.
Не обязательно и даже не нужно сразу идти на второе высшее. Присмотритесь к краткосрочным курсам, интенсивам, мастер-классам от профи.
Не гонитесь за модой и не уходите в какую-то сферу просто потому, что «все так делают». Повальное увлечение языком программирования Python привело к тому, что рынок стал перенасыщен «питонистами», тогда как хорошие программисты на более сложном языке JAVA по-прежнему в дефиците.
Следуйте за своим интересом, учитесь, пробуйте, находите что-то новое, становитесь уникальными экспертами — и это обязательно принесет результат.
10 правил создания кросс-командного проекта
Продакт-менеджер Joom Анна Васильева рассказала, какие ошибки совершали в совместной работе, а главное — как их потом исправили.
Любая компания, чтобы расти, должна запускать новые проекты. Но порой усилий и компетенций одной команды для нужного результата не хватает. Тогда нужно объединить несколько команд и настроить их взаимодействие так, чтобы договоренности соблюдались, задачи исполнялись, а проект поддерживался даже после завершения.
Мы поделимся своим опытом сотрудничества внутри компании, расскажем как сделать чтобы все участники только выиграли от объединения, а у каждой кнопки в вашем продукте не было отдельного менеджера. Статья написана по мотивам выступления продакт-менеджера Joom Анны Васильевой на Product Camp — спасибо, что позвали!
Всё началось с того, что летом 2020 мы решили сделать новую экосистему магазинов внутри приложения Joom. Это альтернативный способ поиска товаров. Проект сложный, в нём должны были участвовать несколько команд: клиентский продукт, продукт для продавцов, команды рекомендаций, поиска, акций, маркетинг и другие. Мы объединили усилия и конечно, поначалу наделали кучу ошибок.
На первом этапе над проектом работали три команды. Чтобы решить, как организовать процесс, мы провели встречу продактов этих трёх команд:
Но, конечно же, так это не сработало.
Мы решили, что нужно придумать, как выстраивать кросс-командные процессы, не меняя структуру компании, не нанимая новых людей, не меняя процессы и систему планирования. Мы хотели, чтобы в проекте был лидер, и команда понимала, с кем решать все проблемы. Ещё нам важно было четко обозначить роли и зоны ответственности.
В итоге у нас получилось придумать правила создания кросс-командного проекта. Они достаточно простые, но вся фишка — в деталях, которые мы упускали с самого начала.
Мы отказались от идеи разбивать цели по направлениям, несмотря на то, что в кросс-команде есть разработчики из разных команд внутри компании. Теперь цели у нас общие. Они прописаны на специальной странице в Notion. Все стремятся к ним и смотрят в одну сторону: и разработчики, и продакт-менеджеры, и маркетологи.
Мы с этого начинали, и вернулись к этому. Проект достаточно сложный, и реализовывать его силами только одного лидера нам показалось неправильным. Если у вас есть возможность оставить несколько голов, которые могут думать над проектом и работать вместе, стоит это сделать. Продукт будет развиваться более сбалансированно. На менеджерских синках мы обсуждаем стратегические цели, тактические подходы.
Это значит, что в команде есть все нужные специалисты из разных команд, которые могут выполнить проект полностью. В начале квартала мы определяем, какие нужны ресурсы под наш проект и выделяем для него разработчиков из разных команд. Во время квартала разработчик может делать и другие задачи, не связанные с этим направлением, но задачи кросс-команды у него всегда идут первым приоритетом: как только он нужен в проекте, остальные задачи ставятся на паузу. Этот же разработчик будет ходить на все командные синки.
Раньше во время работы с кросс-командой менеджер ходил на планирование разных команд (бэкенд, фронтенд…) и распределял задачи, которые нужно взять в следующий спринт. Мы сделали только одно общее планирование нашего направления — максимум на полчаса. Это очень удобно, потому что если задачи связаны друг с другом, люди хорошо понимают, в какой команде какая задача в какой момент начнет делаться. На встрече мы договариваемся, что, например, этот разработчик сейчас задачу не возьмет, потому что другая команда ещё не приступила к нужной части проекта.
Чтобы общие синки не превращались в балаган, их стал вести один менеджер. Разработчики стали получать задачи от одного человека и понимать, к кому приходить с вопросами, если вдруг что-то изменилось. У нас появилась одна входная точка и решилась проблема с коммуникацией внутри команды.
Мы сделали правило, что по каждой новой фиче, которую мы берем в следующий спринт, мы обязательно встречаемся. Неважно, маленькая она, большая, или очень большая. Мы обсуждаем (именно голосом) каждую задачу. Даже если нужно созвониться на две минуты, это все равно нужно делать.
На кикоф-встречи мы зовем и аналитиков, и тестировщиков, чтобы они сразу знали, какая задача им придет на разметку, что им потом упадет в тестирование. Мы делаем это, чтобы все сразу услышали, что нужно сделать, быстро это обсудили и ушли спокойно работать. Это экономит кучу времени менеджеру: люди слушают все требования от одного человека, сразу задают вопросы, а не начинают приходить с вопросами в разное время, когда берутся за задачу.
Внутри кросс-команды должен быть не только продуктовый лидер. Нужно постараться найти среди разработчиков внутри этой команды технического лидера, который станет правой рукой для продакт-менеджера.
Технический лидер должен быть в курсе того, что вы планируете делать в ближайшее время. Он помогает создать такую архитектуру, на которую хорошо ложатся все последующие изменения. Если такой человек будет, он будет ходить на все митинги, будет в курсе того, что происходит, и как бы собирать технический пазл продукта.
В наших кросс-командных проектах тематических чатов два. Первый — это инбокс, куда любой коллега может написать свой вопрос. Этот чат разбирает продакт. Второй — это чат разработки. В нём мы создаём треды, где обсуждаем отдельно фичи. Все разработчики знают, что они могут пойти в этот чат и задать вопрос.
Каждые две недели после нашего планирования мы остаемся ещё на полчаса после встречи и проводим демо. Все, у кого накопились какие-то новости, кто сделал какую-то фичу, показывают результаты. Это вовлекает ребят в кросс-командную разработку. Когда один человек сделал что-то в личном кабинете продавцов, а мы протянули это все в пользовательский продукт, то он видит, ради чего всё это делал, как всё заработало вместе, какие результаты эксперимента получились. Недооценить командное демо сложно, но очень важно отделять его от планирования.
Раз в квартал мы делаем общее ретро. На нём мы рефлексируем о том, как прошел квартал: что было хорошо и что можно улучшить. Планируем, как будем совершенствовать процессы. Кстати, именно общее ретро помогло нам придумать эти десять правил, по которым мы сейчас создаем разные кросс-командные проекты.
Строить кросс-команду — это живой процесс. У нас ещё остались незакрытые вопросы. Например:
Мы пока не чувствовали в этом острой необходимости. Но если у вас есть опыт, расскажите в комментариях.
Вроде бы очевидные вещи были и так до того как пришли. Что разделение команд по платформам ни к чему хорошему не приводит.
Странно что происходит обсуждение фич и ничего не сказано про блокирование фичи, если фича пришла дичь)
Несите дичь! ЗЫ: если я правильно помню, то это не первый секрет Полишинеля от Joom здесь.
Ну типа план наверное делают по статьям или реальная проблема менеджерская при формирование команды)
Всё может быть. Не знаю, не работал там.
Любые вещи, которые хорошо работают, часто кажутся элементарными тем, кто не пришёл к ним сам. Мы общались с другими компаниями и читали про создание кросс-команд: многие сталкиваются с проблемами, и то, что наши правила кажутся простыми, как раз говорит о том, что мы наконец нашли рабочий вариант.
Кросс-команда объединяет разработчиков не только из разных платформ (iOS, Android, Web), но и других частей компании — команды рекомендаций, поиска, рекламы. Это ключевой момент.
О причинах, почему не надо менять структуру компании и разбивать всех сразу на команды, есть в тексте, но проговорю еще раз:
— чтобы каждый раз не нанимать новую команду под проект,
— чтобы не менять структуру компании под проект,
— чтобы можно было одинаково легко и собрать команду, и разойтись, если решим свернуть проект.
Основная проблема заключается в том, что опыт появляется после того, как он был нужен. 🙂
Главное забыли упомянуть все это не работает если платить налоги, НДС, пошлины и прочие вещи, а не завозить из Китая посылки.
Ладно, к делу.
Про аджаил не говорил наверное только немой, но в статье веет каким-то лютым формализом процессов на пустом месте, без какой либо гибкости на деле.
Есть владелец продукта: тот, кто знает как продукт должен выглядеть и как работать. Он составляет видение продукта, декларирует набор и объем фич, которые надо сделать, потом тип лиды собираются и договариваются кто что и в какой последовательности делает.
Вот тут могут быть все, кому в общем интересно что делается.
Далее лиды отдельно определяют кто от кого зависит и кому и что надо сделать, если прям какие-то глобальные изменения, то можно позвать оунера.
Лид вполне может делегировать конкретную реализацию конкретной фичи разработчику, который сходит и сам утрясет детали с потребителем. (Вот он этот самый отджаил, когда лид ДОВЕРЯЕТ разработку фичи, но сам, ели что контролирует.)
И дальше все работают, бэк энд разработчик идет к конкретному фронту, или же наоборот, они делают фичу и выкатывают ее как результат работы, мини кросс команда так сказать, показывают оунеру, который всю картину держит в голове и если что корректирует бизнес реализацию. Все что можно пилить отдельно от всех, пилится отдельно и за пределы команды не особо выходит.
Не нужны эти 100500 встреч митингов и демо, которые время убивают впустую. Условный Петя/Вася лучше поковыряет бэк и что-то там заимплементит или зарефакторит, чем будет случашать как там красят UI, или какие представления добавили.
Не надо в людей впихивать ненужную информацию, она не то, что вылетит, она даже не залетит. Информацию люди потребляют по необходимости и вот над источниками инфы и их доступностью и надо работать.
Условно если некий Вася с бэк энда, который не вылазит с перфоманса, дампов, логов и прочего, вдруг захотел узнать что-то про UI. То ему владелец продукта, обязан дать ссылки на видео, тексты и другую медиа где этот Вася ознакомится со всем что его интересует и задаст вопросы.
Он же не обезъяна, а разумный человек, который может самостоятельно прочитать, понять и задать вопросы и в случае чего изучить что-то более общее.