ИЗОБРЕТАЯ ВЕЛОСИПЕД
Юху! Наконец-то лонгрид!

Сегодня хочется затронуть матрицу компетенций. А конкретно – ее базу. Что должно быть основанием для определения уровня / грейда сотрудника?

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

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

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

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

Так вот, фреймворк предполагает 7 уровней, как раз таки, зрелости специалиста, которые подразумевают разные уровни ответственности:

1. Follow (следует) – следует инструкциям, делает простые задачи
2. Assist (помогает) – работает в команде, берет на себя ответственность за результат задачи
3. Apply (применяет) – работает в рамках установленных правил и системы, делает задачу от и до со всеми ограничениями
4. Enable (поддерживает) – делает работу сам и помогает другим, вносит существенный вклад в результаты команды
5. Ensure, advice (обеспечивает, консультирует) – обеспечивает управление и результаты всей команды, дает экспертные консультации
6. Initiate, influence (определяет политику, влияет) – принимает важные решения, формирует правила, руководит направлениями работ
7. Set strategy, inspire (определяет стратегию, вдохновляет) – все понятно из названия, отвечает за стратегию и будущее

И вот вся эта моделька как нельзя прекрасно ложится на мою идею про ответственность. Более того, много где в мире ее для этого и применяют ?

1. Follow (следует) – стажер или начинающий Junior
2. Assist (помогает) – хороший крепкий Junior
3. Apply (применяет) – настоящий Middle
4. Enable (поддерживает) – уже Senior
5. Ensure, advice (обеспечивает, консультирует) – TeamLead в чистом виде
6. Initiate, influence (определяет политику, влияет) – уровень тактического управления: HH, DM, TGM и много других названий этой позиции
7. Set strategy, inspire (определяет стратегию, вдохновляет) – это уже директор, стратег, CTO

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

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

“МОЛОТОК” В КОМАНДООБРАЗОВАНИИ
Часто провожу обучения и пишу посты по темам командообразования и аудита команд. Очень уж они мне нравятся. Потому что здесь, как нигде лучше, раскрывается многообразие всяких разных менеджерских инструментов. И можно действовать не по наитию или своему креативу, а, практически, “по методичке”. Да, инструменты в менеджменте вещь условная и абстрактная, нужно все это “приземлять”. Это бесспорно. Но в теме командообразования этих инструментов так много, что точно что-нибудь свое, да подберешь.

Буквально недавно мне попался инструмент, который по праву можно считать эдаким “молотком” в теме командообразования. Потому что он столь же прост, и столь же эффективен. И имя его – пирамида GRPI (картинку закину следом за постом).

В чем суть. В рамках командообразования нам нужно проработать 4 основных блока:

1. Цели – какие цели у команды, насколько они хорошо сформулированы, насколько откликаются у всех участников

2. Роли – здесь и компетенции команды, и командные роли, чего где не хватает и каков баланс

3. Процессы – основные процессы и правила, необходимые для нормальной работы команды, все ли на месте и все ли оптимальны

4. Межличностные отношения – насколько команда “сыграна”, какие есть малые группы внутри, кто с кем конфликтует

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

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

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

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

И это классный фреймворк, который можно расширять другими инструментами:

1. Цели – от Мамонта до OKR-ов
2. Роли – от матрицы и карты компетенций до ролей Белбина или Бенна/Шитса
3. Процессы – от базовых 1/1 до сложных процессов Delivery с Аджайлами и Скрамами
4. Межличностные отношения – от теории малых групп до границ Берна

Расширяй - не хочу! Приземляй – не хочу! Ну просто сказка, а не инструмент!

Пользуйтесь!

А картинка следом, как и обещал.

JOB SECURITY
На одном интервью меня спросили: “какой ваш главный факап, как руководителя?” Задумался. Если не отделять себя от компании в моменте, то есть что вспомнить. Не успели разогнать продажи к дедлайну. Не получилось продать правильную стратегию CEO. Не удержал важнейшего сотрудника. И т д и т п. У каждого менеджера есть толстый блокнот с факапами, такое “кладбище решений”. И чем толще блокнот, тем лучше будет менеджер, как по мне.

Но это все, что называется, “вжившись в роль”. А есть ли что-то, если отделить себя от конкретной компании? Как наемный менеджер, сам по себе. И тут я понял, что такое есть, и ответ для меня однозначный: не следил за Job Security.

Что такое этот ваш Job Security? Если упростить, то ваша уверенность, что лишившись конкретной текущей работы, вы все еще окажетесь нужны рынку. И у этого понятия есть несколько составляющих:

1. Количество похожих вакансий – для программистов это десятки тысяч, для тимлидов тысячи, для EM и DM это уже сотни, для СТО десятки

2. Среднерыночный уровень ЗП – вы классный на своем месте и вам часто готовы платить много, просто потому что вы классный на своем месте, а если место поменяется, то вы уже не так уж и нужны, поэтому начинают предлагать что-то средненькое на рынке

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

Так вот, оглядываясь назад, понимаешь, что полезная штука этот Job Security. И надо за ним следить. Я вот не следил, последние лет 5 до прошлого года. Не смотрел вакансии, не ходил по собеседованиям, мало общался с ЛПРами. Сам много нанимал, уровень ЗП знал, потому что мы регулярно такую аналитику заказывали. Но на этом и все.

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

1. Регулярно следить за вакансиями на вашу позицию. Чтобы понимать требования к кандидатам, уровень ЗП, тренды в найме и т п

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

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

4. Развивать свой бренд. Не надо здесь упарываться, но 1-2 раза в год можно что-нибудь интересное рассказать. Отлично работает и для понимания, что нужно рынку, и для развития нетворкинга. Да и могут на собес куда-то пригласить

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

6. Иметь план Б. В любой момент “скрипач может оказаться не нужен”. И вы должны быть к такому готовы. И морально, и материально. Мой лучший рецепт здесь – диверсификация, всего и вся

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

Это мой список. Субъективный, не всем подходящий. Но реально прожитый.

А вы пишите, что еще сюда можно добавить!

P.S. А еще мы тут со Стратопланом запилили целую конфу про фейлы и факапы. 11 мая, в субботу. Я в этот раз не уместился, поэтому излил душу сюда вам ? Но рекомендую!

КАК ПОДРУЖИТЬ DISCOVERY И DELIVERY
Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?

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

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

Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.

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

Как быть? Как по мне, нужно сделать 2 вещи:

1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься

2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI

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

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

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

Что скажете? Согласны с такой идеей? Какие еще есть варианты?

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

Посмотрите, вдруг и вам что-то будет полезно.

Что внутри?
✅ авторские экспертные каналы
✅ личный опыт, инсайты и кейсы
✅ свежие идеи и лайфхаки
✅ море пользы и вдохновения

Подписывайтесь на папку ProБизнес и забирайте все, чем делятся коллеги. Можно подписаться на все каналы сразу или выбрать самые интересные для себя.

УПРАВЛЕНИЕ РИСКАМИ В КОМПАНИИ
Недавно делали для одного из курсов Eduson модуль по управлению рисками. И там было 2 интересные темы, которыми хочу поделиться. Про риски.

Как управлять рисками на проектах, в целом, понятно. PMBOK нам все про это рассказал: идентифицируем, оцениваем, приоритезируем, митигируем. Дальше контролируем. А как работать с рисками на уровне всей компании?

Во-первых, есть специальные стандарты. Их очень много. Есть общие и универсальные. Есть локальные. Есть специфические для отрасли, например, целая куча стандартов есть в банкинге. Наиболее интересные и популярные:

- ISO 31000
- FERMA
- COSO
- …

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

Во-вторых, есть совершенно классная модель “3 линий защиты”. Как понятно из названия, мы делаем 3 уровня работы с рисками:

1. Уровень функций – реализуется в каждом подразделении, выполняется мониторинг, контроль и реагирование на риски. Например, тимлид следит за исполнением требований ИБ своими сотрудниками.

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

3. Уровень внутреннего аудита – какой-то орган, чаще всего комитет, реже – прям выделенное подразделение, которое оценивает общее качество риск-менеджмента в компании, постоянно адаптирует процессы под стратегию компании. Например, изменение политик ИБ, если появились изменения ФСТЭК.

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

1. Люди или команды, которые выполняют работу согласно процессу

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

3. Дополнительный механизм пересмотра работы процесса и его согласованности с текущей реальностью

Вспоминаю, как мы внедряли Scrum. Тимлиды на местах и команды реализовывали фреймворк. Delivery Manager-ы определяли, как адаптировать Scrum к проекту, как его внедрять и как мониторить потом. Ну а топ-менеджмент давал добро или недобро на всякие изменения, когда того требовали новые цели компании или конкретный проект не мог раскатать тот процесс, который был нужен нам. Эдакие “3 линии внедрения Scrum”. Интересно ?

Вот такие мысли. И такие инструменты. Надеюсь, будет полезно.

НАЙМ СТО И ИСПЫТАТЕЛЬНЫЙ СРОК
И еще один крутой вопрос, теперь от @sapatolog

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

Ответ:С точки зрения найма, СТО мало отличается от любого C-level-а. Пожалуй, только вариантов специализации может быть много, что сильнее сужает воронку. А так, любого ТОПа нанимать трудно, дорого, и высока вероятность облажаться.

Как сократить вероятность ошибки? Мне в голову приходит несколько вариантов:

1. Сформировать небольшой, но емкий консалтинговый проект и пригласить кандидата его сделать. C-level-ы часто идут на такие форматы, а кто-то только в таких и работает, на самом деле ? Это дает возможность посмотреть человека в деле, при этом не тратя огромных денег, ни на онбординг, ни на оффбординг и парашют, если вдруг чего. И еще это не подставляет команду и репутацию компании, потому как если не получится сработаться с СТО, то это ж не настоящий СТО, так, консультант просто, ничего страшного

2. Делать долгий и нудный процесс отбора. Многие играют в эту игру. Десятки собесов, с каждым руководителем компании, чтобы вот точно все приняли и можно было абсолютно все риски определить. В отличие от инженеров, которые разбаловались 1-2 интервью, для ТОПов длинный процессинг найма – это ок. Хотя и тут, конечно, во всем важна мера. Дело случая, дойдет ли ваш кандидат до конца или выберет какой-то другой оффер по пути

3. Собирать отзывы от прошлых коллег и работодателей, искать “по знакомству”. Неплохой вариант, но с привкусом некоторой субъективности конкретных людей, которых вы можете и не знать. Почитайте отзывы на врачей – там обычно диаметрально противоположные 50/50) С бывшими коллегами такая же история

Как оценить результаты на испытательном сроке? В идеале – нужны маленькие победы. Не ставить глобальную цель сократить в 10 раз TimeToMarket или за год вырастить подразделение в 4 раза. А что-то близкое, но на квартал. Например, провести анализ проблем TimeToMarket, добиться его улучшения на 10-15%. Или сформировать операционную модель для команды, составить план по росту на год, реализовать какой-то первый шаг.

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

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

Но это все моя колокольня. Делитесь теперь вашей!

ВНИМАНИЕ ТИМЛИДА
Следующий вопрос от @alina_tr_FM

Вопрос:Расскажите, пожалуйста, как тимлиду распределять внимание внутри команды: например, один коллега просто работает, а второй работает + постоянно хочет обсуждать свое состояние/настроение/отношения внутри команды.
К чему может привести такой перекос? Нужно ли его искусственно выравнивать?

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

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

А вот теперь про перекосы. Очевидно, от вашего внимания к сотруднику должна быть какая-то польза. Ваша польза! Например, он делает суперважную задачу, которую вы ему делегировали. Или он приносить 80% кода всей команды каждый спринт. Тогда оно того стоит. И вы сможете это легко объяснить, и самому себе, и команде. Вряд ли кто-то расстроится.

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

Я думаю, логика тут понятна. Есть польза – даем много внимания. Нет пользы – даем, как и всем остальным.

А всем остальным – это как? Вряд ли у вас получится зафиксировать единый для всех формат и в нем жить. Условно, 1/1 раз в неделю на полчаса и дейлики каждый день. Как уже рассуждали выше – люди разные. Но зафиксировать какие-то рамки, вилку своего внимания – вы можете. Условно, нормой считается 1-3 встречи по 30 минут в неделю с сотрудником. Если больше – думаем, анализируем, сокращаем.

Такие рамки можно обрисовать команде изначально, как правила игры. И тогда вообще не должно быть вопросов, почему именно так, а никак иначе.

Надеюсь, получилось ответить на вопрос.

КАК СОЗДАВАТЬ DREAM TEAM
Начинаем разбирать вопросы с розыгрыша. И первый – вопрос от победителя @qVlad : “как создавать dream team?”

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

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

И вот приходят нам на помощь сразу несколько инструментов. Давайте разбираться.

1. Общий “мамонт” – нужно выдать команде общую цель, ради которой она будет работать. Ради которой каждый ее участник будет приходит ни свет ни заря, и уходить глубоко за полночь, и то не каждый день. Я как-то писал о том, что в общей цели важно показать конкретному сотруднику свою выгоду, корреляцию его хотелок и общей цели. А как быть, если такой корреляции нет? Получается, цель команды появляется чуть ли не раньше самой команды, и на этапе отбора людей в нее нужно проверять, что сотрудник себя в этом реализует. Ок, запомнили.

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

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

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

Чего не хватает такой команде до состояния dream team? Предположу, что крутого лидера. И это важнейший критерий.

4. Поставить команде настоящего лидера, который будет тащить ее вперед, своим примером показывая, как надо (или самому стать таким лидером).

Мне кажется, такой рецепт. А вы как считаете?

ПОВТОРЕНЬЕ - МАТЬ УЧЕНЬЯ! МОДЕЛЬ ТАКМАНА
Продолжаем вспоминать полезные инструменты. И развиваем дальше тему аудита команд.

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

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

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

Здесь надо четко понять, что команда - это не группа людей. Команда - это группа РОЛЕЙ. И эти роли должны четко разложиться по тем людям, что есть в команде. Отсюда и шторминг.

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

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

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