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


Источник

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

Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».

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

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

Как понять, стоит ли вообще пытаться?

Заранее никак не понять.

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

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

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

Итак, команда

Вот вы новый руководитель некоей (любой) команды. Приходите и говорите, что вы ёжик и теперь будете жить с ними. Моделей вот в этом процессе я видел две: Капитан Америка и «серый кардинал».

Капитан Америка приходит на работу и надевает костюм. Врывается «с ноги». Говорит: «Эй, я кэп, я тут. Давай будем работать». Замыкает всё или всех, но по очереди на себе. Где-то реально делает правильно. Он кэп. Он знает. Он в костюме. После этого он начинает потихоньку делегировать то, что замкнул до этого на себе. Дальше отходит и просто наблюдает.

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

Быть «серым кардиналом»: вжиться в команду

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

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

У нас уже на этой стадии стало понятно, что команда очень хочет перемен. Структура была «маленькие отряды»: разработчики недовольны разработчиками, тестировщики — разработчиками, фронты на ножах с бэками, РП вообще никем не удовлетворён. По впечатлениям команды он скорее эцилоп, который приходил бить палкой по ночам на ретро, чем помощник. Забегая вперёд — нет, он как раз пытался помочь, но начал не с процессов, а с разборов конкретных косяков.

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

На каждой встрече я записывал:

1. Для чего эта встреча нужна: цели.
2. Получилось ли на встрече этих целей добиться.
3. Что мешает, если нет?

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

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

Дальше — пожелания. «Сеня, опять-таки расскажи, чего бы тебе хотелось». Сеня — айтишник, поэтому всегда первой фразой говорит: «Хочу денег». Вы: «Давай что-нибудь поинтереснее». Дальше, может быть, он расскажет, а может быть, и нет.

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

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

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

Ревью процесса

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

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

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

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



Если в процессе всплывает проблема, например, «аналитики не согласовывают с разработчиками» или «тестировщики заводят хреновые баг-репорты», то записываем отдельно, а потом возвращаемся.

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

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

Выход этого шага — документ, который описывает работу команды.

Решение проблем (патчим баги, рефакторим)

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

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

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

Чаще приносят реально боль, которую можно исправить. Вот кто-то сказал, что у нас очень долгое планирование. Садимся и обсуждаем. Аналитики рассказывают, от чего зависит срок. Оказывается, им не хватает части данных, они их мучительно получают. Просим заказчика предоставлять эти данные сразу — и проблема решается. Точнее, переезжает к заказчику на самом деле, но он с этим согласен.

Повторяем итерации «согласен», «есть комментарий» или «не согласен» до тех пор, пока не пройдём весь процесс.

В итоге получается процесс, который понятен всем, и под каждым пунктом все подписались. Это важно, потому что, когда люди подписываются под чем-то, они чувствуют какую-то персональную ответственность. Когда разработчик сказал: «Я согласен с тем, что теперь буду писать комменты на английском языке» — это вы поговорили. А когда вы при этом записали такое обязательство — это уже нечто более существенное. Так принято. Это документация. Это часть работы команды. Важно, чтобы во всём этом каждый член вашей команды поучаствовал, чтобы каждый мог сказать своё «фи». Люди не должны чувствовать, что к ним пришли и что-то навязали. Они сами — авторы процесса. Они сами сделали и подписались под тем, как они теперь живут и работают.

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

На выходе — целый документ, который можно использовать. Если приходит кто-то новенький — можно показывать его уже как онбординг и регламенты. Если приходит бизнес и спрашивает: «А что вы вообще делаете?» (у меня такое часто было) — есть ответ. Вроде работают 20 человек, а вроде не работают, результата мало. Бизнесу сократить бы издержки, то есть он ищет кого-то, кого можно перевести из команды в другое место или уволить. А вы в ответ показываете документ и говорите: вот каждая роль. На практике, кстати, хорошо помогает подсветить проблемы. У меня зачастую бизнес был автором задержек. И вроде как бизнес пришёл жаловаться на неэффективность, а уходит с новыми задачами )

Отстаём от разработчиков

У нас многие проблемы были из-за непрозрачности внутри команды. Например, РП постоянно приходил и спрашивал: «Ты сделал? Ты сделал?» Это было похоже на постоянное стояние над душой и мало кому нравилось. Решили отобрать у него вообще необходимость задавать такие вопросы, сделали дашборд с понятными метками. А меток не было, потому что не было Джиры, а Джиры не было, потому что не договорились, что работаем по процессу с ней, только с ней и по определённым правилам. А умирать всё начало при переходе на удалёнку, когда в курилке уже никто не ловился и коммуникации стали асинхронными. Починили, почувствовали победу.

А ещё разработчики попросили от них отстать. Это наследие тех самых ненужных встреч, которые тоже как грибы выросли после пандемии. Менеджеру дёшево всех выдернуть, разработчикам дорого это слушать. Ввели часы тишины. Общее правило такое: если кто-то работает мозгами, а не руками, то трогать его в эти моменты нельзя. То есть пока разработчик разрабатывает — НЕ ВЛЕЗАЙ, УБЬЁТ! Разработчики увели четыре часа в день в тишину, а остальные стали сильно внимательнее относиться к их времени.

Что дальше

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

Естественно, надо было время от времени что-то менять и в самом процессе.

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



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


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

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

Почему так получилось с командой?

На этом этапе вопрос уже не имеет значения: это история.

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

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

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

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

Если вы думаете, что дальше всё это обсуждали, процесс исправляли и всё шло гладко, то нет. Дальше исправляли только баг, а процесс оставался таким же.

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

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

Напоследок

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

Чек-лист:

• Аудит ресурсов.
• Аудит встреч.
• Личные знакомства.
• Документ или схема по текущему процессу.
• Провалидировать процесс всем вместе.
• Делегировать команде самой менять процесс.
• Начать решать проблемы.
• Научиться отслеживать последствия изменений.

Всё. Не болейте!