Привет, Хабр! Меня зовут Павел Новиков. Я руковожу группой разработки мобильных редакторов приложения МойОфис Документы. Мы реализуем его на Kotlin и Swift, и всё это – на базе кроссплатформенного C++17-ядра.
Недавно наша команда решила внедрить подход, описанный в книге «6 гениев команды». Она делит рабочие предпочтения на три категории: «гений» — то, что вдохновляет и заряжает энергией, «навык» — то, что получается хорошо, но не приносит особого удовольствия, и «раздражитель» — то, что даётся с трудом и вызывает дискомфорт. Мы адаптировали этот подход под нашу команду и посмотрели, как он работает в реальной разработке. В этой статье расскажу, что получилось и какие выводы мы сделали.
О подходе
Основная идея книги сводится к тому, что почти любую работу можно разложить на последовательные этапы, и каждый из них требует особого типа активности.
Сначала появляется Задумка (Wonder) — поиск проблемы, которую стоит решить. Затем следует Изобретение (Invention) — продумывание возможного решения. После этого включается Оценка (Discernment), когда мы анализируем найденное решение, ищем в нём сильные и слабые стороны. Далее идёт Гальванизация (Galvanizing) — тот момент, когда нужно увлечь и подтолкнуть команду к действию. На этом пути возникают трудности, и тут важна Поддержка (Enablement) — помощь команде в их преодолении. И наконец, всё замыкает Доводка (Tenacity) — доведение решения до конца. Я буду использовать именно русские названия из официального перевода, но полезно держать в уме и оригинальные термины, чтобы перевод не помешал передать суть.
Важно и то, что эти этапы чередуются по своей природе: одни из них проактивные, ориентированные на создание нового, другие — реактивные, когда мы отвечаем на уже возникшие вызовы.
Предрасположенность
У каждого из нас есть этапы работы, к которым мы предрасположены больше, и те, которые даются тяжелее. Обычно предпочтения проявляются не во всех задачах сразу, а в схожих по характеру этапах.
В книге такие предрасположенности разделяются на три категории. «Гений» — это вдохновляющая часть работы, которой мы занимаемся с удовольствием и легко теряем счёт времени. «Навык» — то, что получается хорошо и без стресса, но не вызывает особого энтузиазма. А «Раздражитель» — работа, которая добавляет напряжения: мы можем выполнять её успешно, но длительное погружение приводит к эмоциональному истощению.
Баланс
Команда работает устойчиво и эффективно, когда разные этапы берут на себя люди, для которых они находятся в области «гения» или хотя бы «навыка». Такой подход повышает вовлечённость, снижает риск выгорания и позволяет участникам раскрывать свой потенциал. Наоборот, если человек вынужден постоянно работать в зоне «раздражителей», его эффективность снижается, а возможности для проявления сильных сторон остаются нереализованными.
Как всё началось
Я прочитал книгу и заинтересовался описанным в ней подходом. Особенно подкупили чёткое описание этапов работы, их цикличность (реактивные и проактивные стадии) и то, как авторы снимают излишнюю «сакральность» с предрасположенности людей к реактивным задачам.
Во-вторых, несмотря на то что в книге речь идёт не об IT-компании, аналогии с работой наших команд напрашивались сами собой.
Мне захотелось оценить свою гипотезу о пользе этого подхода, и я начал с обсуждения идеи с одним из лидов. Его мнение помогло подтвердить, что идея заслуживает внимания. И именно здесь случилось первое любопытное открытие: наши взгляды на предрасположенность к разным этапам оказались диаметрально противоположными. При этом мы довольно точно определили «гении» и «раздражители» друг друга. Более того, у нас появилась новая терминология, которая объяснила, почему нам комфортно работать вместе: мы закрывали «раздражители» друг друга и не конкурировали в «гениях».
Следующим шагом стало определение круга коллег, которых можно подключить к знакомству с подходом. Здесь сработал классический ход — формирование «ранних последователей» идеи. Если стоит задача вовлечь всю команду в обсуждение новой идеи, важно двигаться итеративно: начинать с более открытых участников, которые готовы быстро сформулировать и донести свою позицию, а затем опираться на ядро сторонников, чьё мнение может послужить дополнительным стимулом для тех, кто сомневается.
Примерно через месяц почти вся команда прочитала книгу, и мы перешли к следующим этапам.
Мы завели общую табличку, где каждый отметил свои «гении», «навыки» и «раздражители». Это позволило увидеть распределение по всей команде, а ещё — подняло ряд вопросов. Например, почему некоторые люди распределили себя так или иначе, ведь сама методика достаточно обобщённая и не всегда учитывает контекст.
Распределение членов команды по самостоятельной оценке
Заключительным этапом мы провели две часовые встречи, где обсудили не только сами характеристики, но и то, как они проявляются в нашей повседневной работе.
Пример приземления
Как и во многих командах разработки, у нас есть практика проведения code review. По договорённости в ней участвуют все разработчики, а не только лиды.
Когда мы с командой обсуждали, к какому этапу деятельности можно отнести code review, большинство выбрало «оценку». Это логично: нужно оценить, насколько решение соответствует задаче и контексту. Но нашлись и те, кто отнёс этот процесс к «поддержке». Для них ревью — это скорее помощь коллегам в профессиональном росте и поиск лучших технических решений.
Здесь я сделал несколько наблюдений. Во-первых, мой собственный взгляд как «оценщика» немного расширился. Во-вторых, я раньше чувствовал, что разные члены команды подходят к ревью по-разному, но теперь эта разница стала понятнее и получила конкретные примеры.
Важно и то, что различие в восприятии не является проблемой само по себе. Оно даёт руководителю выбор: оставить процесс как есть, жертвуя скоростью, но получая встроенный механизм обучения внутри команды за счёт энтузиастов, или добавить формальное описание целей ревью, чтобы сделать его максимально предсказуемым. Понимание мотивации людей превращает этот выбор в осознанное управленческое решение, но не обязывает идти только одним путём.
Что это дало
Применение подхода принесло несколько заметных результатов:
Улучшение коммуникации. В нашем «командном словаре» появились новые термины, которые помогают проще и быстрее понимать друг друга. Например, мы можем прямо сказать, что у нас возникли трудности с «доводкой» задачи. Это сигнал: работа почти завершена, но, возможно, потребуется помощь на последнем этапе.
Новый взгляд на коллег. Совместное обсуждение книги позволило увидеть друг друга с новой стороны. Оказалось, что у некоторых участников два «реактивных» гения, и ждать от них постоянной проактивности во всей работе не только нелогично, но и вредно. Такой контекст позволяет корректнее формировать ожидания и распределять роли.
Кроме того, обсуждение показало, что не всем легко определить свои «гении» и «раздражители». В нашем случае, таких людей было немного, поэтому поиск причин такой ситуации я отношу к разряду психологических спекуляций и в рамках данной статьи не рассматриваю.
Упрощение найма. Зная текущий срез команды и её подкоманд, мы лучше понимаем, какие качества и предпочтения нам важны при найме. Общая терминология упростила обсуждение кандидатов после собеседований: теперь мы можем явно проговаривать впечатления и быстрее приходим к взвешенным решениям.
Наблюдения
По мере внедрения подхода я сделал несколько наблюдений, которые кажутся мне важными.
Во-первых, этот метод точно не «серебряная пуля» и не единственно верная модель формирования команды. Он не исключает другие стратегии, а лишь добавляет ещё один инструмент, которым лидер может пользоваться в работе.
Во-вторых, в разработке ПО нередко сложно определить, к какому именно виду деятельности отнести тот или иной этап. Здесь ценность я вижу не столько в точности классификации, сколько в самом процессе обсуждения внутри команды. Совместное размышление даёт продуктивную дискуссию и помогает формировать общее понимание.
Кроме того, открытый разговор о своих «гениях» и «раздражителях» сближает команду. Такие обсуждения помогли нам чуть лучше понять друг друга и стали шагом к более здоровому взаимодействию.
Отдельно хочу отметить отношение к «раздражителям». Для конкретного человека это не значит, что его нужно полностью ограждать от подобных задач. И уж точно это не повод отказываться от них под предлогом «мне неудобно». Знание о собственных «раздражителях» полезно само по себе: оно позволяет быть готовым к тому, что именно этот этап окажется более тяжёлым и вызовет стресс. Осознавая это, проще относиться к задаче спокойнее, ведь трудности связаны не со всей работой целиком, а только с её частью.
А для руководителя такая информация — ещё один инструмент, который помогает выстраивать работу команды так, чтобы на длинной дистанции люди занимались в основном тем, что их заряжает и вдохновляет.
Вывод
Подход из книги «6 гениев команды» оказался полезной техникой для нашей команды. Он не требует серьёзных затрат, не несёт рисков и при этом даёт ощутимые преимущества — от улучшения коммуникации до более осознанного найма новых сотрудников. Главное — не считать его универсальным решением всех проблем. Скорее, это дополнительный инструмент, который помогает команде лучше понять себя и друг друга, а руководителю — выстроить более продуктивное и здоровое взаимодействие.
Пишите в комментариях, какие фреймворки для распределения обязанностей используете в команде и что думаете о книге Ленсиони.
Ну а если вы тоже прислушиваетесь к «гениям» и раздражителям» членов вашей команды и знаете, как выработать «сыгранность» между коллегами — скорее кликайте на нашу новую вакансию менеджера продукта в команду разработки настольных редакторов.