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


Сегодня я хочу рассказать вам про метод под названием «Звёздная карта» для планомерного упрощения решения этих и других проблем, а также о подводных камнях связанных с внедрением этого инструмента, ведь ничто не совершенно, особенно когда речь заходит о работе в команде.

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

Немного о звёздной карте

Сразу оговорюсь, что данный термин придуман не мной, впервые я его услышал на тренинге от команды Unusual Concepts и тренера Сергея Дмитриева. Нечто похожее также встречалось мне в разных фирмах под названием «матрицы компетенций», но там инструмент более тяжеловесный. Да и не об истории происхождения, а о применении дальше в статье пойдёт речь.

Звёздная карта — это таблица, где по горизонтали расположены столбцы с важными для работы конкретной команды навыками/знаниями, а по вертикали — сотрудники. На пересечении колонки и столбца каждый сотрудник ставит себе оценку в простой градации:

0 = не знаю ничего или знаю очень мало
1 = знаю достаточно, чтобы в среднем самостоятельно справляться с задачами на эту тему, но не эксперт
2 = эксперт, могу не только самостоятельно решать задачи, но и ГОТОВ ОБЪЯСНЯТЬ ДРУГИМ.

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

Несколько советов по составлению и поддержанию карты:

• Карта должна быть известна и открыта для просмотра всем в отделе, не только начальнику.
  Помимо того, что это избавит начальника от необходимости постоянно выступать маршрутизатором между сотрудниками в духе «я знаю, кого тебе нужно спросить», но и оценка навыков разных сотрудников будет уравновешиваться мнением других сотрудников.
  
• Только востребованные в работе команды навыки/знания
  Важно, чтобы перечисленные знания, вроде тонкостей конкретных технологий или специфики работы какого-либо внутреннего компонента, были востребованы при работе именно в этой команде. Если кто-то знает React или Node JS, а все компоненты отдела используют на frontend-е Angular и на backend-е Java, то нет смысла указывать в звёздной карте неиспользуемое, эти знания всё равно в обозримой перспективе никому в команде не потребуются.
  
• Ограничивайте число колонок 20-30, не более
  Довольно распространённой ошибкой является создание монструозного исчерпывающего списка навыков на 200-300 пунктов. Конечно, хорошо, если он есть, но скорее всего сотрудники будут избегать поисков в этой громоздкой таблице и просто обратятся с вопросами к тому, кто на их взгляд знает ответы на все вопросы.
  
• Детализируйте и пересматривайте эту карту регулярно
  Со временем, людям свойственно что-то забывать из-за отсутствия практики или наоборот, наращивать свои знания. Часть технологий и компонентов теряют свою актуальность и им на смену приходят новые, сопоставляйте список навыков с реально решаемыми в отделе задачами, к примеру раз в 1-2 спринта.
  

Типы сотрудников(идеализированные)

Итак, карта составлена, ниже приведён её пример, а заодно будут рассмотрены разные типы людей, в зависимости от их hard-skills. У каждого из типов в художественном прототипе есть черты, по которым вы можете опознать у себя этих сотрудников.

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



Шерлок Холмс — тоже довольно опытный сотрудник, но его знания не так всеобъемлющи. В каких-то интересных для него областях он может тягаться с Чаком Норрисом (или даже в редких случаях превосходить его), в то время как в других областях он полный ноль. Оригинальный Шерлок Холмс был экспертом во всём что касалось сыскного дела, но к примеру не знал элементарных вещей из астрономии. «Мне всё равно, земля вращается вокруг солнца, или солнце вокруг земли, для моей работы это не важно,» — подобные высказывания чаще всего звучат именно из уст Шерлоков Холмсов.

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



Ван Дам — это так называемый «универсальный солдат», а в применении к IT такие люди часто являются full stack developer-ами. В эту же категорию зачастую попадают и full stack developer-ы в командах с узкоспециализированными back и front. В отдельно взятой команде может не быть front или back разработки в принципе, тогда у них не будет full stack, но там всё равно может быть Ван Дам. Они во всех необходимых для их работы областях обладают необходимым минимумом знаний и только в небольшой области их знания выше средних по команде. Часто такими становятся сотрудники, которых поставили на багофикс и саппорт широкого спектра компонентов и волей-неволей они успели познакомиться со всеми ими, также с сопутствующими библиотеками. Глубина знаний часто определялась потребностями отдела и сложностью решаемой Ван Дамом прямо сейчас задачи.

Основная сила Ван Дама в том, что даже если его оставить с парой менее опытных сотрудников, это всё ещё будет полноценная команда, готовая к решению любой задачи(пусть и медленно порой). Проблема в том, что это именно командный игрок и выделение его на изолированную задачу сильно снижает эффективность остальной команды и самого Ван Дама. Если его убрать из команды, то новички вдруг перестанут решать свои задачи столь же быстро, а он в одиночку должен будет проявить себя в узкой области, где половина его знаний не нужна. «Знать бесконечно мало о бесконечно многом, необходимом в работе»- их принцип обучения, который во многом перекликается с Шерлоками Холмсами, но с другого конца.



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



Итак, что же с этим всем теперь делать?

Использование звёздной карты (идеализированное)

Определяем слабые места

Прежде всего, пройдитесь по колонкам навыков и посмотрите, что в каждой колонке есть хотя бы по одной 2 и 1. Это значит, что в команде найдётся кто-то, кто сможет решить даже сложную задачу, требующую этого навыка, а также есть ещё один человек, который подстрахует первого и в случае его отправления в отпуск, пусть и не идеально, но сможет заниматься этой задачей. Если в какой-либо колонке встретится только пара единиц, ситуация уже хуже и кого-то может быть стоит направить на дообучение. Если есть колонка с единственной цифрой, отличной от 0, это уже веский повод бить тревогу, даже если это 2 и знания сотрудника в этой области крайне глубоки. Значит, что всего один человек в отделе, кто разбирается в этой технологии или компоненте и стоит скрестить пальцы, лишь бы его знания не потребовались, когда он будет в отпуске/на больничном или соберётся увольняться. В конце концов, этот сотрудник может «захватить участок кода в заложники» и шантажировать этим, но об этом чуть позже.

Увеличиваем стабильность команды

Определив слабые места, нужно распределять задачи исходя из закрытия дыр в знаниях/навыках, по возможности учитывая пожелания самих сотрудников (помним про + и -, которыми они обозначали своё желание/нежелание что-то развивать). Даже небольшие исправления ошибок или улучшения кода способны поднять знания с нуля до 1 и закрыть уязвимости в первом приближении. В идеале, мы сможем доучить начинающих участников команды в самых критичных для команды участках заранее, пока более опытные сотрудники могут делиться своими знаниями. При этом не возникает вопроса, почему изучается именно это, а не другое, ведь по звёздной карте всем видно, что сейчас необходимо развивать.

Балансируем нагрузку на экспертов

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

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

Но всё это происходит так только в идеализированном мире, где команда работает как часы, а каждый человек в ней — мотивированный профессионал, интересы которого полностью совпадают с интересами команды. Эта система учитывает исключительно hard skills, указанных в ней. Сейчас посмотрим, как всё меняется с появлением таинственных soft skills и тёмной стороны сотрудника каждого типа.

Тёмная сторона каждого типа сотрудников

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

Основная сложность с soft skills, в отличие от рассмотренных ранее hard skills в том, что их сложнее протестировать. Формальное выделение их в несколько колонок и открытое вынесение на суд остальной команды обычно выходит за рамки этики и приводит только к бесконечной ругани и не даёт объективной оценки происходящего руководству. HR-ы часто подходят к этому вопросу, увы, тоже довольно однобоко, ограничиваясь формальным общением с сотрудником раз в год или не менее формальным тестированием по старым как мир и однообразным унылым тестам. Даже если с HR повезло, они скорее всего не знают работу команды изнутри, а сотрудники отдела не обладают компетенциями HR, чтобы грамотно оценить эти скилы. Вероятно, решение проблемы уже существует в нескольких вариантах, но я не буду здесь замахиваться на исчерпывающее решение этой проблемы, а хочу для начала просто подсветить факт её наличия.

Рассмотрим альтернативную, тёмную версию каждого типа сотрудника и посмотрим, как даже единственный сотрудник с низким значением soft skills способен вывернуть работу всего отдела наизнанку и существенно снизить общую эффективность.


Грегори Хаус — искажённый вариант Чака Норриса. Ровно также, как и его добрый альтер эго Чак Норрис, он знает практически всё, что только может потребоваться для его работы и даже больше. Но в отличие от первого, его коллеги(и чаще всего подчинённые) Грегори Хауса хотя и уважают его технические знания, но предпочли бы не иметь с ним дела. Этот эксперт отличается тем, что морально унижает и давит на коллег, используя любые способы для преуменьшения их заслуг, постоянных подколов и уличения в незнании чего бы то ни было. Он знает, что при его техническом багаже, ему простительны почти любые выходки и вольности в общении с менее титулованными и зарекомендовавшими себя коллегами. Зная об устойчивости положения Грегори Хауса, он довольно редко встречает сопротивление от коллег и его часто предпочитают просто терпеть или молча уходить из компании с таким сотрудником, дабы в разборках не подпортить себе отзыв с предыдущего места работы.

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

Шелдон Купер — искажённый вариант Шерлока Холмса. Как и в случае Шерлока Холмса, чей набор навыков крайне узко заточен, Шелдон Купер интересуется только парой смежных областей, но его главный принцип — считать пылью под ногами любого, кто в этих областях менее подкован технически, чем он. Оригинальный персонаж из сериала «Теория большого взрыва» жил вместе с несколькими друзьями-учёными, эрудированными в других науках, но даже близко не воспринимал их равными себе и регулярно принижал их. Тут схожая ситуация.



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



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

Положение Тёмных (Шелдона, Остапа Бендера и тем более Винни Пуха) в компании нельзя назвать столь же устойчивым, как у Грегори Хауса, и чем дольше они задерживаются в коллективе, тем активнее именно выслуживанию перед начальством посвящают они основное своё время. Винни Пух за свои дела и вовсе может покинуть компанию, если только информацию о нём собирать с коллектива, а не 1-2 сотрудников.

«Тёмные» выслуживаются как раз перед теми, кто принимает о них решение, а начальник, обманутый выслуживанием «Тёмного», может:

1. не спросить у других и принять обособленное решение (идеально для Тёмного)
2. не поверить критике других сотрудников, простить «Тёмного» за ошибки и попросить того исправиться (тот открестится, пустит пыль в глаза и оправдается).

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

Методы всех тёмных мало чем отличаются от описанных для Грегори Хауса (захват кода в заложники, принижение заслуг/знаний остальных, отказ от ответственности за ошибки и присвоение лавров), но на практике мы их рассмотрим ниже.

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

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

Один в поле саботажник, чужой среди своих

Как же будет складываться взаимодействие токсичного сотрудника с остальными коллегами, если он является единственным с низкими soft skill-ами в команде?

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

Запросы к Шелдону/Бендеру от коллег он отметает под эгидой развития в них самостоятельности, также блокирует Чака Норриса от ответов на запросы помощи других коллег и таким образом ещё сильнее повышает вероятность того, что к концу спринта его задача будет выполнена лучше всех остальных. В моменты, когда Чак Норрис всё же отказывается помогать Шелдону/Бендеру, тот переключается паразитировать на других и скорее всего это будет Ван Дам или Шерлок Холмс, если его специализация сгодится. При этом вероятность критики и вывода на чистую воду выше в случае взаимодействия токсичного сотрудника с Холмсом, как менее командным игроком, нежели с Ван Дамом или Чаком Норрисом. Чак Норрис в общем потоке вопросов к нему может и не обращать какое-то время внимание на то, что ему приходится консультировать одного коллегу чаще, чем всех остальных. Тем более что вопросы Шелдона всё же более продвинуты, нежели обычные вопросы от новичков. Ван Дам тоже в силу широкого кругозора не станет упрекать Шелдона Купера в незнании чего-либо, отвечая на его вопросы, ведь и он сам не безупречен. Но Шерлок Холмс, знаток в своей области, скорее всего более аргументировано раскритикует некомпетентность Шелдона Купера и нежелание решать свои задачи самостоятельно. Поэтому токсичный Шелдон скорее всего перестрахуется и на случай таких рисков соберёт доказательства того, что помощь ему не очень помогла и он до всего дошёл сам, а Шерлок Холмс его просто отвлекал.

Что же будет происходить на каждом статус-митинге и по итогам спринта?



Задачи Ван Дама, Чака Норриса, Шерлока Холмса и всех Пятачков-новичков задерживаются по срокам и только Шелдон Купер, единственный герой в этом всём апокалипсисе, успевает в срок или идёт с опережением графика и всем доволен, если только его не критикуют. На ретроспективе Шелдон преуменьшит участия остальных в его успехе и напомнит остальным об организованности, ведь кто должен отвечать за проблемы других людей, если не они сами, неужели Шелдон? Если команду не распускают некоторое время и ситуация повторяется регулярно, то наш герой, достаточно заработав кармы на чужих головах, вовремя почувствует момент для перетасовки до разоблачения и попросится на другую активность. Там ситуация рискует повторится.

Токсичный лидер и сам себе молодец

Ещё интересно, что если Шелдона поместить в условия, когда он — самый опытный сотрудник в команде, то он с одной стороны будет регулярно посылать малоопытных коллег на самостоятельное решение проблем вместо помощи, при этом руководству будет сетовать, насколько много времени у него отнимает общение с этими несчастными глупцами. Тактика «любые успехи команды — мои успехи (даже если не имею к ним отношения), а любые провалы — это не мои проблемы» станет в поведении такого Шелдона/Бендера самой основной.

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

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

Ложка мёда в бочке дёгтя

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

По итогам спринта, полезность работы команды стремится к нулю, все со всеми в непрерывной конфронтации и особенно недовольны скрам-мастером, отчасти заслуженно. Конечно, такое положение дел свидетельствует о неэффективной работе команды, а значит и скрам-мастера, как главного ответственного за этот показатель, но главный вывод: высокое среднее арифметическое по техническим навыкам в команде не гарантирует её успех. ГРУППА более технически подкованных специалистов может даже в долгой перспективе уступать по продуктивности малочисленной слаженной КОМАНДЕ мотивированных сотрудников средних навыков.

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

Для правильной организации работы требуется немалое терпение и умение scrum-мастера и желание всех остальных развиваться, поэтому и набирают обороты scrum и agile.
Что же с этим всем делать?

Идеально работающего для всех случаев решения проблемы не существует, для одних команд подойдут одни методы, для других — другие, но вот вам несколько идей для решения:

• Формирование открытой и доступной всем звёздной карты
  
  Отчасти, само формирование такой звёздной карты уже снижает эффект от токсичных сотрудников, ведь если они не будут делиться с остальными знаниями, команда может справедливо потребовать их снизить все свои показатели с 2 до 1. Звёздная карта не даёт хвалиться своими знаниями без обмена с остальными и помощи другим. Также начинают возникать вопросы по заявленной компетенции в какой-либо области знаний, если мнимый эксперт постоянно обращается за помощью к остальным или регулярно не может ответить на поставленные ему вопросы.
  
• Открытая приоритизация задач и известная чёткая цель спринта
  
  Если всем известно, что наиболее приоритетными в этом спринте являются задачи А и Г, то токсичному сотруднику с его задачей Б могут дать от ворот поворот при обращении за помощью, а то и принудить к помощи другим коллегам, чьи задачи более приоритетны в этом спринте.
  
• Регулярное общение и проведение ретроспектив в разных форматах
  Двухсторонняя открытость (и начальников, и подчинённых) обычно снижает возможности токсичных сотрудников к манипуляциям в мутной воде недомолвок. Пускание на самотёк коммуникаций в коллективе хотя и соблазнительно-просто для начальника, чревато проблемами.
  
• Завязать зарплату (или премии) каждого на общие успехи команды
  
  Чаще всего, токсичные сотрудники достаточно эгоистичны и честолюбивы, поэтому ограничения в духе «никто в команде не получает премии, если цель спринта не достигнута хотя бы на 50%» становятся для них настоящим ударом. Это означает, что для каждого становится важен прогресс остальных и нет гарантий, что в интересах спринта именно задача этого сотрудника будет доведена до конца, если её приоритет ниже чем у остальных. Это осложняет возможности выслуживаться.
  
• Завязать премии каждого на отношение к нему внутри команды, а не только начальника.
  Идея открытого обсуждения распределения премий по итогам спринта является достаточно революционной, далеко не всем организациям хватит духу на внедрение подобного. Стоит предупредить, что этот подход имеет множество подводных камней и может дать негативный эффект, к примеру, в случае внедрения в команду нового сотрудника или наличия неформального лидера. Но привычка идти по головам остальных в таких условиях однозначно выходит боком. Даже периодическое применение этой практики повышает желание обосновывать свои действия другим участникам команды и даёт возможность получить заслуженные премии тем, кто больше ратует за общий успех.
  
• Вовремя замечать сопротивление внедрению предыдущих советов.
  
  Именно токсичные сотрудники первыми заметят для себя риски связанные с таким подходом, поэтому будут явно или тайно саботировать процесс внедрения этой практики, стараться всячески дискредитировать её прежде, чем она урежет им возможности для паразитирования на других.