Как работать в команде и не сойти с ума
Я посмотрела 1,5 часовое выступление скрам мастера и стендап комика Ильи Якямсева про работу в команде. Под катом расшифровка выступления на 15–20 минут чтения. А вот выжимка на 30 секунд:
- Если команда/компания работает в цикле выгорания — вы тоже выгорите.
- Для некоторых компаний цикл выгорания — способ не платить за переработки.
- Общение с командой должно идти с командой, а не с отдельными представителями / лидерами / менеджерами и пр.
- Электронная почта для общения команды — зло, мессенджеры с каналами рулят.
- Если какой-то процесс должны регулярно выполнять два и больше людей, автоматизация в помощь.
- Если вас можно понять неправильно, вас поймут неправильно. Избавьтесь от двусмысленности. Для особо сложных случаев — заведите словарь проекта.
- Абсолютного знания не существует. Есть опыт прошлого в контексте прошлого.
- Психологическая безопасность в коллективе — когда в коллективе люди не боятся сморозить глупость по рабочему вопросу.
- Флудильня — индикатор, живой у вас коллектив или как.
Промотать к видео
Я совершенно случайно заговорил про депрессию и выгорание. Я не специалист по выгоранию, как человек, который сидел в доме во время пожара — не специалист по пожарам. Я просто пережил «пожар» и рассказал свои ощущения.
Я специалист по командам и хотел бы сегодня поговорить о том, что все зависит не только от отдельного человека, но и от команды целиком.
Я аgile сoach в «Wiley» и организовываю команды во что-то разумное. Прошу воспринимать мои слова как набор гипотез. Я многое пробовал и могу поделиться своим опытом, как сделать жизнь людей в команде более приемлемой для людей. Но речь всегда идет об аgile-командах.
Надеюсь, вы найдете что-то полезное для себя.
«Wiley» занимается образованием: продажа научных журналов, доступ к базам знаний, обучение, а начинала компания как издательство. Я занимаюсь созданием продуктовых команд в российском офисе «Wiley».
План:
Я вижу ненормальных людей — причина моего доклада.
Я не понимаю, что такое команда — как разобраться команда вы или набор случайных людей, которые столкнулись в одном офисе.
Как говорить с этими людьми — как построить коммуникацию.
Почему я должен это все делать — где в этой коммуникации будете вы.
«Илья, ты прочитал нам клевый доклад по депрессию и выгорание. В моем офисе все выгорели. У всех депрессия» — говорят мне. «Как мне им помочь» — хорошая формулировка. Или «Что мне с ними делать» — не очень хорошая формулировка.
И это сложный запрос. Люди привыкли новые знания проверять не на себе, а на других.
Что делать вам, вы знаете: спорт, прогулки, питание. Мы уже разобрались с этим (Илья Якямсев: Эффективность не работает).
Когда говорят про выгорание, обычно советуют выйти из офиса. Но в офисе мы хотя бы часов 6 в день проводим. Что же там делать.
Во многих иерархических организациях команду определяют как «группу людей под кем-то». Не важно, знакомы ли они, есть ли у них какие-то общие практики.
Я воспринимаю команду как человека. Команда нормальная, когда вы можете сказать: «Эй, команда, дайте мне ответ» и команда даст один, понятный всем ответ.
Когда вы разговариваете с человеком, вы не просите отдельно его левую руку: «Дорогой Василий, точнее его левая рука, сделайте для меня что-то». Если левая рука отдельно от Василия делает для вас что-то, то с Василием всё категорически не в порядке. Да, вы общаетесь через голову, но голова — приемник. Человек он цельный. С командой все точно так же.
Когда я говорю про команду, я спрашиваю: «У вас команда может принять решение? У вас на уровне команды есть обязательства? У вас есть история команды? У вас есть принципы команды? Команда может защитить себя от внешнего мира?»
В психологии это называется «субъектность», человек субъективен, если он может принимать решения и их исполнять. Команда должна уметь принять решение на уровне команды, а не одного человека.
Когда ко мне приходят люди с запросом получить что-то от команды, я первым делом уточню, спрашивал ли этот человек команду. Не ее лидера. В моем мире, который я упорно насаждаю, в аgile-командах нет лидера, они работают как единый организм. И команда является отдельным элементом системы. С командой общаются напрямую.
Когда мы принимаем, что команда тоже человек, становится понятнее, как с ней общаться. Команда обладает всеми психологическими свойствами человека. У команды есть память, коллективные навыки, коллективное поведение. Чем больше общих навыков, тем больше возможность принять решение в одном направлении.
Команда тоже может выгорать. Помните, что команда может вас убить. На собеседовании вы этого не поймёте, но вам нужно это определить за время испытательного срока.
Это не цикл выгорания, на самом деле, это схема взятая из процесса расстройства внимания:
Цикл выгорания:
- Гиперфиксация
- Паттерны и прокрастинация
- Самолечение
- Самобичевание
- Паралич
- Отказ
Гиперфиксация — человек в очень возбуждённом состоянии берёт очень много задач, т.е. идет гиперпредставление о результатах основанное ни на чём, при этом человек вкладывает много энергии и надежд в результат.
Паттерны и прокрастинация — в этом состоянии человек обнаруживает, что некоторые задачи для него неинтересны, некоторые — не несут развития. Иногда задач тупо много. Иногда человек придумывает рефакторинг в нулевой задаче, чаще от скуки. Начинается прокрастинация, потому что задачи ты выбирал на эмоциональном подъеме, а не на логике. И задачи эти никому не нужны. Прокрастинация — логичная штука в такой ситуации. Видите собачка выше немного косая? Она просто одним глазом на чаёк смотрит, а другим на пожар. И не может выбрать, чем же ей заняться.
Самолечение — человек решает, что ему нужно измениться, чтобы выполнить эти задачи. При этом человек не работает со скоупом задач, он пытается менять себя. Человек начинает пить энергетические напитки, перестаёт спать, перестаёт заниматься нерабочими делами, ходить куда-то.
Самобичевание — человек понимает, что ничего не сделает, идёт полный упадок сил. Он думает, что он плохой, никогда у него ничего не получится. У человека полностью заканчивается энергия. Её остатки уходят на то, чтобы с утра встать с кровати.
Паралич — человек перестаёт делать вообще хоть что-то. Возможно даже на работу ходить.
Отказ — идёт полный сброс обязательств. В самых жёстких и запущенных случаях может дойти до самовыпиливания.
И это еще не про депрессию пока, это просто цикл рассеянного внимания, когда вы перебрали с задачами. Основной косяк в том, что в начале цикла принятие решений уже идет на фоне давней историки.
Весь этот цикл накладывается на команду в целом. При чем есть команды, где цикла выгорания — основа рабочего процесса. Если вы попали в команду с такими, вы выгорите 100%, потому что по 6–12 часов будете работать в цикле выгорания.
Цикл выгорания не поэтапны. Этапы не по расписанию идут. Они перемешиваются и накладываются.
К примеру, на этапе самолечения человек, понял, что ему надо выкидывать задачу, но из-за истерики, вместо того, чтобы выкинуть задачу, человек берет новую — гиперфиксация.
С командой так же. Если у вас во время цикла разработки приходит менеджер и пихает новые задачи, не выкидывая старые, вам конец. Люди уйдут. У меня есть знакомый, который вообще программировать перестал. Он, ушел деревяшки пилить, потому что деревяшка конечная — ее видишь целиком.
Суть проблемы в том, что цикл выгорания могут поддерживать на уровне команды и на уровне организации.
Один из вариантов лечения выгорания в скраме — разнос этапов по дням. К примеру, запихиваем гиперфиксацию в планирование. И дальше после не берем задачи. Т.е. мы несколько циклов выгорания заменяем на один, но контролируемый.
Когда у меня спрашивают, скрам плохой или хороший, я объясняю, что он нейтральный. В скраме можно сделать все хорошо, а можно выгореть.
Я говорю про скрам и agile, но вы можете найти этот цикл выгорания в waterflow. И хороший менеджер каскадной системы постоянно выкидывает задачи из каждого этапа, подгоняя скоуп под результат. Я не знаю ни одного проекта дольше месяца, который уложился бы в сроки с полным скоупом.
В цикл выгорания может попасть команда, отдел, компания, предприятие, отрасль. Результаты в цикле выгорания буду случайные и минимальные.
Не факт, что вы сможете помочь человеку, который выгорел, но вы сможете его хотя бы не загонять дальше.
В первую очередь вы должны защитить себя. Многие люди в IT любят свою работу, и терять эту любовь из-за того, что команда горит, обидно.
Я разделяю эффективность и эмоции, хотя заниматься надо обеими вещами, перемешивать их не надо.
Эффективная команда — это сухарь. Мало кому нравится быть железным станком, хотя некоторые находят в этом свою прелесть.
Эмоции — это то, что склеивает команду. Эмоции вы не контролируете. Часто команду склеивают негативные эмоции. К примеру, противодействие навязанному циклу выгорания может сильно сплотить людей. Я встречал команды, которые писали один тип кода для архитектора, и другой тип кода, чтобы это работало. И на код-ревью отправляла первый тип. Оно работало.
Делаем работу эффективной
Wiley не вся работает на моем подходе. У нас есть несколько вариантов как двигаться, мы каждый пробуем свое, у нас такое пространство есть.
Выносим коммуникацию наружу
Команда — это расстояние между людьми. Простейший пример технической коммуникации — коллективное владение кодом и вытекающие оттуда договоренности.
У многих нормальных компаний эта часть коммуникации уже вынесена наружу. Ты можешь прийти, посмотреть в код и понять, как люди общаются, какие у них паттерны.
Когда мне говорят, что программисты замкнутые… программисты говорят каждый день с «железным чурбаном» на человеческом языке. Попробуйте попросить холодильник для вас что-то сделать. А программисты так каждый день делают.
Программисты очень хороши в обмене информацией, это логичные и эффективные люди. Но другая сторона, в классической схеме менеджмента, применяет давление через эмоции. В коде нет эмоции. Ты можешь испытать эмоции от кода, но из самого кода эмоции вынуты. Код или работает или нет, и общение в основном о том, с каким качеством он работает.
Убиваем электронную почту
Электронная почта — способ связи двух человек. На третью итерацию уже никто не будет читать историю переписки в письме. Если письмо вылезает за один экран — за
первым экраном его никто никогда не читает. Начинается потеря информации: сделайте саммари, саммари — это обобщение, кого-то забыли добавить в рассылку, в итоге никто не помнит, почему приняли такое решение.
Общение только в команде
Спасение — мессенджеры. Умные люди, типа программистов, привыкли искать причины принятых решений. А еще они могут что-то забывать. Так что всем нужна полная история и доступ к ней. Так что общайтесь только через каналы.
Если вопрос конкретно к Василию, задавать его нужно на уровне команды. Все видят слова Василия, воспринимают их как дополнение к своей картине мира, если хотят уточнить или оспорить — могут это сделать прям там же. Если потом Василию надо объяснить, что произошло, он просто даст ссылку на эту точку переписки. Ни у кого нет копии письма с другим ответом или решением.
Если в команде идет обсуждение один на один, возникают три лишних митинга. Первый, встреча двоих людей. Второй, встреча этих двоих людей со всей командой, с целью объяснить им свое решение. Третий, по итогам, т.к. откуда у тех двоих возникло решение команда всё равно не поняла и сделала в результате вообще ни то.
Обращение в команду дает общедоступные референсы с аргументами всех решений по проекту. Начали так делать — сократили время общения в 3 раза.
Создаем паттерны
Что это может быть. У вас есть частые события, о которых надо знать больше, чем одному члену команды. Вот прямой паттерн:
В одной из команд идет версия деплоя на тип сервера. Паттерн однозначно описан, в нем есть ссылки на всё, что может пригодиться, он понятен как программисту, так и менеджеру, он подходит всем, его даже во внешнюю среду можно отправить.
Когда идет такое объявление, у людей не возникают вопросы, обсуждать нечего.
Через месяц после создания этого паттерна, мы деплоились на прод по лайку. Продукоунер поставил лайк — оно ушло на прод. Никаких подписей или обсуждений.
Второй паттерн — наименование. Кода здесь ноль, продукоунеру надо посмотреть, что там твориться. Если здесь не ноль, продукоунер не принимает участие в принятии решения деплоя.
Паттерн нужен, чтобы снизить суету на рутинные вещи.
В примере выше, 6 команд на одном пайплайне сидит, таких сообщений может быть 6 в день. Никого они не трогают. Люди просто прочитали, всем понятно, день закончился, мы по паттернам посчитали, что происходит.
Как это создать. Берете самое часто повторяющееся действие, описываете подробно и кидаете в словарь. Создавайте словарь на проект. Паттерн обсуждаемая вещь, может в любой момент измениться по общему соглашению. Через время вы это автоматизируете, Jenkins, что хотите, и не будете думать о них.
Главное, канал команды доступен для всей компании. Когда кому-то нужно узнать, какие деплои и как часто были в команде, мы не делаем отчет. Мы отправляем в канал, там все деплои есть.
Раньше, чтобы произошла «стрелочка», мы тратили 3 недели: согласования, подписи. Сейчас это происходит за 30 секунд. Я просто договорился, что мы на уровне всей компании однозначно читаем этот паттерн.
Такие же паттерны есть на все: на билды, на создание инкримента, на «пожалуйста, оставьте мастер в покое». Это все описано в Confluence, она для этого и стоит.
Когда приходит новый человек, его в первую очередь обучают словарю, чтобы он понимал, что происходит и как мы общаемся.
Я так остановился на паттернах, потому что это самая эффективная идея оказалось. Time to market сократился с 2 месяцев до 2 недель после их внедрения.
Внедряем культуру общения
Когда мы выносим рутинные, всем надоевшие кусочки работы и автоматизируем их, у людей остается время, чтобы что-то придумывать. Но чтобы вместе что-то придумать, надо уметь общаться.
Интерпретации
В русском языке почти у каждого слова есть по два значения, и каждое значение можно описать еще двумя словами. Когда мне говорят «детальный бизнес реквайермента», я смеюсь вслух. Я понимаю цифры, их трудно интерпретировать иначе. Если написано не цифрами, с большей вероятностью вас поймут неправильно.
Редуцируем все интерпритации. Никаких решений устно. Если вы не можете записать решение — это плохое решение.
Все спорные моменты заносите в словарь, чтобы люди одинаково понимали, как и что называется. Не оставляйте место для двусмысленности.
Используйте только данные, а не выводы. Выводы или округлены, или неполные, или трансформированы или вообще неверные.
Храните данные в одном месте и накладывайте на них фильтры. Простейший фильтр — поиск в мессенджере.
Вся информация по производственному процессу, соглашениям, коммуникации у нас лежит в Jira. Время на встречи, обсуждения сократилось очень сильно. Мы все берем информацию из одного источника, просто каждый ее нарезает как ему надо. Человек создает по себя фильтры и не требует с других отчеты. В результате менеджеры могут работать с командой, а не составлять бумаги. Менеджеры перестают работать как передатчики информации, и начинают работать как настройщики.
Аргументация
Если человек пишет код и понимает, что такое логика, он все равно может не понимать, что такое логика в речи. Логика в речи не ограничивается if — else.
В аргументации все является гипотезой. Нет никакого «знания». Особенно о прошлом. В прошлом был определенный контекст, определенная ситуация. Любая фраза является предложением что-то попробовать. Вопрос в затратах ресурсов на «попробовать».
Уважение. Люди должны высказать много мнений. Если у вас есть одно решение одной проблемы, то оно плохое, даже если оно хорошее. Вам не с чем сравнивать. Оно ни плохое и ни хорошее, оно единственное. Добивайтесь, чтобы хотя бы два решения появилось. Часто одно решение бывает, когда тимлид передавил всех.
Психологическая безопасность
Команда должна поддерживать возможность каждого высказаться. Так, как они могут. Многие люди не говорить не умеют, они принимать аргументы не умеют. Я работал с тимлидами, которые стали тимлидами, потому что им зарплату надо было поднять. Их основной прием работы был «я тебя не слышу».
Тут иногда помогают очень простые вещи, вроде мячика — у кого мячик. тот и говорит. У меня мячик — я говорю, и только после того, как я передал тебе мячик, ты можешь высказаться.
Психологическая безопасность строится из возможностей, из обучения, из понимания, что в команде нет иерархии.
Многие люди не высказываются, т.к. думают, что их мнение глупое. А оно просто второе, третье или четвертое по порядку. В момент высказывания мнения равнозначны. Мы потом на них критику нанесем, сначала просто скажи.
По крайней мере, когда человек начнет высказываться, станет понятно, чего он не знает. И отлично, его научить можно. Ищите незнание, так вы поможете людям расти. Поднимайте нижний уровень.
Психологическая безопасность на уровне команды, на уровне менеджмента, на уровне предприятия.
Принимайте любое мнение и уважайте неправоту. Более того, любое улучшение в 80% случаев провалится, мы это знаем, но готовы экспериментировать.
Словарь
В экстремальном программировании словарь позволяет именовать классы, модули, системы однозначно, поддерживать структуру кода, чтобы его однозначно понимали, и переносить эти термины на уровень продукта.
Очень хороший словарь одними и теми же словами объясняет функционал для клиента и то, что написано в коде. Плюс это код как документация.
Словарь экономит время. Как только возникает ситуация с двусмысленностью — вы дополняете словарь.
НИКАКИХ СООБЩЕНИЙ КАПСОМ И АЛЕРТОВ111!!!11!!! ОДИНОДИН
Идиотская манера, думать, что тебя не слышат. В каналах должно быть соглашение на чтение и ответ. Писать как выше, можно только когда прод упал. Пока все бизнес-процессы работают, никакой проблемы нет.
Так обычно пишет менеджер, который спешит. Запомните, если в команду пришел человек, который спешит — это его проблема. Команда никуда не спешит, у нее все хорошо и идет производственный процесс. Отправляйте в лес за такие сообщения. Люди очень быстро воспитываются.
(из зала) Есть еще странные люди, которые не могут сформулировать мысль целиком и пишут по 1 слову в сообщении!
У меня бывали кейсы, человек начинал так писать в чаты, когда у него возникали реальные психологические проблемы, он болел. Так что отнеситесь с уважением. В случае скрама, скрам мастер должен с этим человеком поговорить и узнать, все ли у него в порядке.
Это была оооочень скучная часть. Эффективность не работает, но она позволяет поднять прозрачность в команде, чтобы видеть, что происходит в команде.
Приведу метафору (она спорная). Когда вы варите суп, то как вы закидываете ингредиенты основывается не только на том, сколько суп варится., но еще и на том, что суп не должен переставать кипеть, чтобы он варился.
У вас должна варится команда. При добавлении в команду информации, людей, или при уходе людей из команды, суп должен варится. Люди придут и уйдут. Вы же знаете, программист вышел в фейсбук, получил два предложения о работе.
Команду надо организовывать так, чтобы она спокойно работала, могла потерять или приобрести человека, получить или потерять знания. Для этого все коммуникации мы выводим отдельно от людей и делаем видимыми.
Чтобы диагностику можно было сделать, и понять, что с деплоями, что с бэком, что с фронтом, что с мобилкой. По любому моменту все знают, где посмотреть информацию.
Еще хорошая привычка, когда человеку приходит письмо напрямую, он его выкладывает в канал.
Не работает, потому что команду склеивает не эффективный процесс. Это не человеческая фигня, это станочки и железочки.
Почему проблемы с удаленкой. Когда налаживают эффективные процессы, команда очень успешно им сопротивляется. Креативность у людей запредельная, когда они хотят обмануть систему.
Люди склеиваются в коридорах, по дороге на обед, организуя другие чатики. Склейка команды идет вне производства. Наша задача — оставить место под эмоцию, чтобы ее направить на улучшения, а не на противодействие процессам. И удаленка убивает это пространство для «склейки».
Я где-то читал, что самый хороший программист работает (придумывает) 2 часа в день, на большее просто сил не хватает. В остальное время ты полируешь код, гоняешь через всякие штуки. Постоянно придумывать что-то новое ты не можешь, так что в оставшееся время или рутиной заниматься, а если ты умный человек, то уже придумал, как рутину автоматизировать и сидишь ворон считаешь. Я вот предпочитаю умных.
Про agile есть хороший вопрос: «Я закончил всю работу двухнедельного спринта за неделю. Че вы со мной сделаете?» Я вот ничего с тобой не сделаю. Других так же научи делать.
По этому, т.к. у вас больше нет коридоров с чаями, вам придется их организовывать
Утрамбовываем позитивные воспоминания
Есть такой термин «ретроспектива», ее и в скраме, в agile проводят, много где. Зачем. Чтобы вспомнить, что было хорошего. И на основе хорошего сформировать позитивный опыт. Так что хвалите.
Я видел людей, которые считают, что никто не должен расслабляться. Так это не менеджер, это просто чувак, который всех напрягает.
Когда все хорошо — вы говорите хорошее. Когда всё провалилось — вы тоже говорите хорошее. В ретроспективе нет слова «плохо». Есть то, что получилось хорошо, и то, что мы можем изменить.
Я часто вижу, как упускают эту важную часть и делают ретроспективу без набора воспоминаний, что было.
Нормальная ретроспектива идет часа 2, а если это большая команда, человек на 80–100, то вообще весь день. И это все делается для того, чтобы собрать воспоминания, чтобы команда осознала, что у нее много позитивного опыта.
Это тоже помогает против выгорания. Когда вы говорите только про плохое, люди и запомнят только плохое, даже если они сделали много хорошего.
Место поплакать и посмеяться
В вашей коммуникации должно быть место для фигни. Несколько каналов, где люди занимаются фигней. Официально. Котиков постят, новости обсуждают. Это просто посмотреть, у вас люди вообще живые. Некоторые думают, что люди там слишком много времени проведут. Ха! Да команду, которая по морали проседает, в такой канал на пинках не загонишь. Запости мемчик, завлеки людей, это тоже работа.
Поплакать и посмеяться — это еще про психологическую безопасность. Люди боятся на работе глупости говорить. Покажите официальное место, где от них совсем ума не ожидают. Это нормально.
Быть примером
Я чуть-чуть рассказать про эффективную составляющую, чуть-чуть про эмоциональную. Вам надо им постоянно балансировать.
Независимо от вашей роли, есть хороший agile-прием — будьте примером.
Вернемся к самому первому пункту, о котором я говорил: Я вижу ненормальных. Это абсолютно ужасно подойти к человеку и сказать: «Тебе психолог нужен». Как минимум, это бестактно. Лучше создавать культуру. Сказать: «Ребят, я записался к психологу. Очень интересно. Вот что бывает. Давайте обсудим».
Через обсуждения вы внедряете, что в этой команде ходить к психологу нормально, в этой команде полезно говорить о проблемах и просто служите примером. Это будет стоит вам оплаты психолога. И вам полезно и команде. Пробуйте все новое сначала на себе, не пытайтесь поэкспериментировать над другими.
Задача скрам-мастера поддерживать это. Если человек что-то предложил — среагируйте, примите новое, поддержите. Если вы постоянно предлагаете что-то новое и команда встречает это сопротивлением — пора уходить.
За время испытательного срока, поймите ваши рамки и возможности. Если они нулевые, то такая команда вас погубит.
При чем я общался со многими менеджерами и наблюдал за их работой. Все как один говорят, что у них пространство для свободы действия. Посмотришь, одному можно говорить, а второму, как только рот открыл — мешок на голову.
Равноценность — основа. Нет «я лучше, ты хуже» ни по какому методу.
Так вы можете избежать выгорания в команде, создать команду, которая вам нужна. Вы сможете говорить, а это — снова лечения любого психологического заболевания.
У вас есть методика оценки, на какой стадии выгорания находится команда?
Я обычно устанавливая итерацию и смотрю, насколько успешно и стабильно команда ее выполняет. Т.е. я просто смотрю на объем взятой и сданной работы, без перенесения сроков. Не знаешь что делать, делай инкремент. Команда в раздрае не доносит до финиша 80%. У нормальной команды обычно комитмент от 80 до 100%.
Еще сигнал — когда один человек в команде на третий день спринта говорит «я все сделал». Тут надо настраивать на помощь другим.
Все в команде разные, кто в команде следит за выгоранием, если там не руководителя?
Команда. В скрам-гайде 2020 года есть хорошее выражение о том, чем занимаются инженеры «поддерживают друг друга как профессионалы». Это задача каждого члена команды, поддержать другого, дать знания, дать возможность выражения и помочь, если что-то случилось.
Хорошо настроенная команда заметит, поймет, что у человека что-то случилось и поможет решить это.
В моем мире agile этим занимается скрам-мастер. Но стоит помнить, что если ты не специалист, то ты никак не можешь дать психологическую оценку.
Я не требую от скрам-мастера или от участников команды быть психологом. Я, во-первых, рекомендую на уровне компании привлекать психолога, как человека, к которому можно сходить, посмотреть что это. А во-вторых, вести об этом разговоры в компании.
В любом случае, опытные люди в депрессии, отлично имитируют прекрасное эмоциональное состояние. Вы их не поймаете.
Плюс производственная компания — не санаторий. Поддержка других людей — способ качать эмоциональную составляющую. Профилактика выгорания — поддержка команды, где есть человеческие отношения. Это решение на уровне руководства и всей компании, что люди должны быть в разуме. И это хорошее решение.
А если есть цель и спринт короткий? Не будет ли команда замалчивать проблему? Ведь пока человек окончательно не выгорел, он эффективно работает.
Хорошо настроенная команда, с хорошими отношениями внутри и здоровым отношением к результату, смотрит друг за другом постоянно. Если один из команды внезапно стал вагоном и другие его тащат, эти другие к нему приходят и спрашивают, что случилось. Это командная ответственность.
Если как менеджер, ты настроил, что ты принимаешь такие проблемы из команды, команда начинает понимать, что можно тебе такую проблему отнести. Когда у тебя 10 человек в команде и 1 плохо, это минимум 3 заметят. И важно, чтобы те, кто заметил, просигнализировали тебе.
У меня были такие отличные команды, которые сами подходили и разговаривали. Не пишется код — давай поймем почему.
Понимаешь ты участие в инкременте или нет — отличный маркер. Не принимаешь — давай разбираться. Команде не выгодно замалчивать проблему — им придется решать чужие задачи за ту же зарплату.
Если человек уже выгорел. Как его заменить?
Для этого отдельные процедуры есть. Команда должна уметь принимать и отпускать людей. Без травмы.
Это распределение знаний, это практики приема в команду, вроде парного программирования, чтобы быстро включить человека в работу. Плюс словарь, паттерны.
Изменения в составе почти всегда болезненные, но надо понимать, что люди будут приходить и уходить.
Плюс если человек выгорел, не надо его выгонять. Договоритесь, что ему просто надо поставить инкремент. Пусть снизит продуктивность, ему надо выправить уровень производства. Может опасити человеку понизить надо.
Команда выполняет роль агента, но в коммерческом мире. Важно не только, чтобы человеку было хорошо, но чтобы ему было хорошо и он мог креативно участвовать в процессе производства.
У нас самый большой продукт делает 9 команд. Релиз — это ад. Как вы смогли с 2 месяцев до 2 недель сократиться?
Лечение конкретного случая — конкретный случай. У нас около 10 больших поездов, в каждом много проектов и в каждом разная ситуация. Но у нас было стремление. Мы поставили цель уменьшить time to market, с конечными инкрементами, мы в конце каждой операции должны иметь возможность идти в любую сторону. Систему спроектировали хорошо и мы смогли к этому быстро прийти.
В системах с большим легаси, спроектированных давно, несколькими людьми, со спагетти-кодом внутри, надо искать свой метод. И экстремальное программирование и в devops можно уйти. Главное — есть проблему маленькими кусками. Когда я вижу людей, которые внедряют devops культуру и первые проект, который они делают — проект на 2 года по пайплайну. Ну. В добрый час.
Найдите части системы, который можно оптимизировать, части, которые можно покрыть автоматами. На эту стрелку я год потратил. Definitional done — это полное покрытие автоматическими тестами всей системы на каждый релиз идет.
С командой лучше в мессенджере, чем через почту. А как с заказчиками?
Если вы можете пустить заказчика во внутренний канал, и это вас не затормозит — это счастье. Но некоторые заказчики могут начать давать свои рекомендации, и больше тормозить, так что с кем-то реально стоит общаться только через почту. Хотя заказчика тоже можно воспитывать.
Как найти индикаторы выгорания в распределенной команде?
Это сложно. Я стараюсь смотреть на результаты. Плюс много общаться с людьми один на один. У меня есть принцип — давать как можно меньше советов. Слушать. Я просто задаю вопросы и благодарю человека за ответы.
Еще, мы на удаленке заметили, что люди стали перерабатывать, когда паттерны пошли в 2 часа ночи. Мы ввели тему: здороваться по утрам и прощаться вечером. У нас вся команда работает в один временной промежуток. Если с тобой попрощались — иди отдыхай, до утра тебе никто не ответит. Как в офисе, когда люди начинают уходить и ты вспоминаешь, что рабочий день кончился.
У нас офис закрывается в 22–00. Не понятия ночной работы. Была ситуация, когда прод падал и человек снаружи сидел в машине подключался к вай-фаю. После этого мы сделали так, что ночью прод не падает.
Вот у вас продуктовая команда, а что делать аутсорсерам? Если я выгорел на аутсорсе из-за постоянной смены команды…
… то найдите себе продуктовую команду, вы же сами на свой вопрос ответили.
Как организовать чатики? Они же плодятся по любому поводу.
Я могу дать паттерн, который мы используем.
Каналы нужны, чтобы понизить количество митингов и встреч. Если есть митинг, вы заводите на него канал.
Есть команда, есть community of practice (cop), в каждой команде есть бэк, фронт, тестирование. На каждую команду канал, на каждый слой канал. Орагнизающий по CoP-ам канал development, чтоб если не знаешь, куда спросить, то туда. Есть еще general — там только про работу с продом пишут. Еще по фидбэку канал on duty — одна из команд всегда в нем дежурит, их задача не решать проблемы, а роутить их. Еще есть отдельный канал по аляртам всяким и канал под херню.
Любую проблему можно решить за час. Если не решили — плохо сформулировали.
Задачи обсуждаются только в джире, не в канале. По работе — все в джире, по развитию — в каналах. Экстренное событие — тоже в каналах.
Был какой-то кейс Тинькова, где разработчика уволили за то, что он постил мемасики. У тебя в практики были случаи, когда человек только мемасиками занимался весь день?
Я не могу объяснить никакие решения главного Тинькова, который прям с этой фамилией. Ну, ты работаешь в офисе, где ходит человек, который может сказать ты никто, а я все. Это такой человек.
Плюс я не видел этих мемасиков. Могло быть дело в контенте.
Но целый день мемасики постить — серьезная работа. Не каждый так сможет. Кстати, иногда черный юмор — маркер для этапа паралича. Если раньше такого не было, и вдруг человека понесло — надо прийти и поговорить.
Как понять и выскочить из этапов выгорания?
На гиперфиксации важно не добирать. Разрешить себе брать задачу только на этапе планирования. Потом нельзя, до завершения этапа.
С паттернами и прокрастинацией — придумать себе удовольствие. Сделать по-другому то, что можно сделать по-другому. У некоторых разработчиков есть проблема абс
