Итак, у вас на руках «полыхающий» проект — сроки задержаны настолько, что заказчик всерьез задумывается о закрытии проекта. Или регулярно взрывающийся production не дает сфокусироваться на новых задачах а то и спать по ночам. Или вы впервые видите этот проект, но вообще-то ему уже пара лет, просто изначальная команда куда-то пропала. Или все это произошло разом, а вы здесь чтобы с завтрашнего дня взять ситуацию в свои руки и за пару месяцев показать существенный сдвиг.
На прошедшей в апреле конференции TeamLead Conf 2021 я поделился своим опытом, как вытащить проект из пожара и обойтись без человеческих жертв. Под катом моя история, а если предпочитаете смотреть — вот запись выступления.
Чему же уделить внимание, если мы понимаем, что наш проект в опасном положении?
Две области для присмотра понятны из названия статьи: нужно спасти сам проект и сделать это без человеческих потерь в виде выгорания. Также есть третья очень важная область, из-за которой могут быть обнулены все наши усилия по спасению проекта — коммуникации. Если мы доведем взаимодействие с заказчиком до того, что он потеряет веру в успех проекта, то он его просто закроет. И это значит, все наши усилия и сверхусилия пропали даром. Также, если в команде постоянные конфликты, и люди увольняются — вряд вас ждет успех. В общем, коммуникации — это настолько важная область, что с нее мы и начнем.
И интересный момент в чем... Вообще-то по всем трем этим областям человечество уже накопило огромное количество знаний о том, как «правильно». Но в ситуации стресса, когда под нами стул горит, почему-то это «правильно» даже не вспоминается — мы действуем по наитию, а то и вовсе на голых эмоциях.
Причина такого поведения в том, что при стрессе мозг находится в режиме «бей или беги», он не склонен принимать взвешенные, аналитические решения. И, чтобы выйти из этого состояния, нужна какая-то катапульта. Какое-то заклинание, которое позволит прекратить происходящий сейчас треш и быстро вернуться в нормальное состояние. Что-то типа стоп-слов у садомазохистов.
И я для себя такие «стоп-слова» нашел. Я выбрал базовые законы из других профессиональных областей — очень краткие, очень емкие, несущие в себе много смысла — и вспоминаю их в ситуациях, когда становится «горячо». Это помогает вернуться в спокойное состояние и принять взвешенное, рациональное решение.
Эти законы мы сегодня и обсудим. По одному для каждой из областей:
Осознав это, он принял абсолютно верное решение: «Буду делегировать». И вот, появляется очередная задача, где требуется коммуникация с заказчиком и наш тимлид передает ее самому боевому и коммуникабельному разработчику. Проходит день — задача не сделана. Второй — то же самое. На третий день тимлид напрягается, ведь он уже дважды напоминал о задаче.
Но, проанализировав ситуацию, он подумал: «Сейчас и так тяжело, итерация съехала, все загружены. Если еще и я приду со своими претензиями, то обидится парень. Уволится еще. Нафиг надо». И наш тимлид молча делает задачу сам.
Проходит год. Наш тимлид всё так же работает пресс-секретарем, а тот самый разработчик приходит к нему и говорит: «Я увольняюсь, у меня тут нет никакого роста»...
И причина этого недовольства была у меня на руках — проект находился в нерабочем состоянии. Буквально, на проде сообщения приходилось проталкивать по шине руками, чтобы нужные процессы завершались.
Я сделал несколько попыток договориться с ПМ-ами проекта (у нас их было двое) о том, чтобы перепроектировать «фундамент» системы. Но успеха мне добиться не удалось.
И вот тут я сделал свою самую большую ошибку — перешел в режим героя. Я размышлял так: «Мы спасем это проект и все зарефакторим! Я готов тратить на это свои вечера и выходные, но мы все сделаем! А когда доделаем, то бизнес поймет, какие же мы на самом деле молодцы..».
Так я и начал действовать. А исходный конфликт с ПМ-ами оставил без внимания.
Но, чтобы подобный тлеющий конфликт начал полыхать, достаточно делать... ничего. И это то, что я и решил делать — ничего. В итоге конфликт перерос в личностный и общение стало очень токсичным. Позже отношения пришлось перезапускать: эти ПМ-ы ушли на другие проекты, а у нас появился новый ПМ. С ним уже все пошло хорошо, но понимаете, я могу в этой ситуации оправдываться как человек, но как тимлиду мне тут гордиться совершенно нечем — отношения с заказчиком были развалены.
Вот такие вот две истории.
Первый закон экологии гласит:
Это в чистом виде эффект бабочки: незначительное изменение может привести к очень серьезным и непредсказуемым последствиям.
И этот феномен уже давно вышел за пределы экологии. Сегодня он используется во множестве других направлений науки и получил название «сложная система». Фондовый рынок, иммунная система человека, психика человека, социум — все это примеры «сложных систем». Они не поддаются описанию алгоритмами, они «нетерпимы» к внешнему управлению, эксперименты с ними неповторяемы, а то и вовсе опасны.
Понимаете, между «простыми» и «сложными» системами есть очень существенная разница. Когда мы бьем кием по бильярдному шару, то мы не ждем ядерного взрыва. Но, когда мы подходим с очень мудрым советом к раздраженному коллеге, то спектр возможных сценариев становится гораздо шире — он непредсказуем. И совсем не факт, что мы сможем понять, из-за каких событий прошлого сейчас наш коллега среагировал именно так, а не иначе. Потому что психика человека это сложная система.
И коммуникации, как совокупность психик, тоже являются сложной системой, в которой могут происходить подобные эффекты.
Давайте вернемся к историям про тимлида-пресс-секретаря и про мой конфликт с ПМ-ами.
Но когда конфликт превращается в личностный, то начинаются проблемы. И часто это происходит даже при том, что у обеих сторон исключительно добрые намерения. Почему же так получается?
И, если фактов у какой-то из сторон конфликта не хватает, то это никак не мешает составить историю. Просто она будет гораздо дальше от реальности.
Так и получается, что тимлид делегировал задачу, но впоследствии сделал ее сам. И не поговорил с разработчиком чтобы не конфликтовать, из добрых побуждений... Но вместо этого начинает копиться череда недомолвок, в результате которых тимлид избегает делегирования совсем, а разработчик решает, что ему больше не дадут тут расти.
Аналогично с моим конфликтом с ПМ-ами. У них в голове история о том, что мы — засранцы, которые ничего не делают и только создают проблемы. А у нас в голове история, что мы — герои, которые спасают положение. При этом у ПМ, например, годовые KPI про которые они нам не говорят. А мы не рассказываем насколько действительно плохи дела потому, что пытаемся «сохранить лицо». И как мы можем в такой ситуации о чем-то договориться? Да никак. После каждого рабочего «столкновения» истории в наших головах все дальше расходятся друг от друга, пока каждый не решит, что на противоположной стороне очевидный вредитель.
Подобные истории всегда начинаются с какой-то маленькой неопределенности. Кто-то что-то недосказал по «политическим причинам». Или кто-то что-то стерпел, опасаясь конфликта. Или мы приняли пограничное решение, которое не можем озвучить другой стороне. И эти недосказанности усиливаются со временем, потому что наш мозг так устроен — если ему не хватает фактов, то он сам себе придумывает историю.
Что означает открытость? Насколько это возможно, уберите из вашей работы любую политику, попытки «держать лицо», пограничные решения типа «рефакторинг замазывать в бизнес-задачи». Все правила, по которым вы работаете, должны быть общедоступны. Вы должны быть в состоянии сказать о них любому участнику процесса. А в идеале каждый должен не только знать ваши правила, но и разделять их ценность. Классический пример — принятие бизнесом ценности автотестов.
Также вам поможет открытость личного характера. Если вы чувствуете, что кто-то разговаривает через зубы, что-то терпит — проанализируйте ситуацию и спокойно проговорите ее вместе. Не придумывайте за вторую сторону, начните с простого: «я чувствую, что что-то идет не так, давай это обсудим?».
Ведь это супер-умение — в самом начале конфликта открыто и дружелюбно все проговорить, устранить все неопределенности. После этого все понимают ситуацию одинаково, открыты друг к другу и настроены на боевой лад. Открытость устраняет неопределенности и у мозга становится меньше поводов придумывать истории.
Но даже если мы будем максимально открыты, неопределенности все равно будут возникать. Ведь мы находимся внутри супер-сложной системы. Поэтому мы добавляем второй компонент — постоянную обратную связь. Она поможет нам быстро прорабатывать возникающие неопределенности и выравнивать ожидания.
Вы сидите в одной лодке и плывете в одну сторону. У вас всего лишь сбился ритм маха веслами и вам нужно открыто поговорить об этом, пока ситуация не зашла слишком далеко. Поэтому, когда готовите обратную связь, вспомните, что перед вами человек у которого, добрые намерения, как и у вас.
Если разработчик прикипел душой к выбранной реализации и вы боитесь, что даже обсуждение фактов будет принято на личный счет — не говорите о том, как плохо. Обсудите как вы представляете себе «хорошо», как вы мечтаете, чтобы стало в будущем. Это поможет уйти от личных претензий и сформулировать понятные actionable идеи, которые помогут улучшить ситуацию.
Попробуйте действовать подобным образом и вы увидите, что привычка давать конструктивную обратную связь распространяется во все стороны. Так вы научите этому всех участников процесса.
В завершение части про коммуникации повторюсь, любая неопределенность — это сигнал для вас как тимлида, будьте любопытны к ним. Это не значит быть затычкой в каждой бочке. Просто уделите внимание ситуациям, когда кто-то что-то недоговаривает, кому-то некомфортно. Подобная чуткость позволит вам построить продуктивные, дружелюбные и открытые отношения.
Если долгов становится слишком много, то они начинают пожирать слишком много нашего внимания. И мы поступаем так же, как при проблемах с финансовыми долгами — выкраиваем некоторое количество ресурсов на «возврат» долгов.
Допустим, мы поняли, что наш проект погряз в долгах и договариваемся с бизнесом тратить 20% времени на техдолг. Это не очень много, но на самое важное хватит. И мы строим плотный, солидный план технического развития проекта на год и стартуем с намерением отдать все долги.
Похожим образом действует бизнес. Мы «отжали» у него 20% времени, но запросы на фичи от этого не уменьшились. Поэтому мы договариваемся уплотнить график поставки и на этот раз действовать без проволочек.
И вот, у нас получился совместный план, допустим, на квартал:
В точности как с финансовыми долгами — мы посчитали ресурсы в нашем распоряжении, поделили их на поддержание актуальных потребностей и на возврат долгов, построили четкий график.
И с этого момента метафора с финансовыми долгами перестает работать. Дело в том, что когда мы рассчитались по финансовому долгу, то на этом история заканчивается. Банк забывает про нас, а мы забываем про него.
Но с нашей работой ситуация обстоит иначе. Потому что любую интеллектуальную, творческую работу мы выполняем в цикле Деминга, состоящем из 4 фаз: PLAN, DO, CHECK и ACT.
Как мы делаем типичную задачу? Сначала мы декомпозируем (PLAN), затем кодим (DO), далее тестируем (CHECK) и раскатываем на прод (ACT). Аналогичным образом мы составляем стратегические планы и согласуем их с коллегами, проектируем архитектуру приложения и проводим ее review с командой. Даже атомарный commit мы выполняем в те же четыре действия. То есть цикл Деминга вложен, он работает на задачах любого уровня.
Но почему он называется «цикл»? Дело в том, что после выполнения всех четырех этапов замыкается петля обратной связи. Например, мы видим упавшие тесты или слышим мнение коллеги на code review, слышим мнение бизнеса или получаем отзыв пользователя. И вот здесь и зарыта собака. Потому что после получения обратной связи нам часто нужно будет сделать еще что-то, прежде чем считать задачу действительно завершенной. Это характерно для любой творческой, интеллектуальной работы.
Например, вы часто видели, чтобы дизайн-макет принимался с первого раза?
То же самое происходит при разработке новых фичей. Мы проводим ряд экспериментов и постоянно собираем обратную связь, чтобы максимально уточнить смысл фичи и принести максимальную пользу. Или то, как мы проводим рефакторинг — в начале мы имеем лишь общее представление о результате, к которому хотим прийти. Но по мере движения вперед, погружения в принимаемые технологии, картина становится все яснее.
То есть, чтобы действительно сделать работу до конца, мы должны провести несколько циклов. И мы не можем в самом начале предсказать сколько этих циклов будет. Мы не знаем, сколько багов найдет QA и что коллеги скажут на Code review.
Конечно, иногда мы не получаем обратную связь:
Полагаю, что нет. Мне тоже. Так вот, ситуация «требования постоянно меняются», которую мы так не любим — это признак того, что задача действительно нужна и полезна. Мы проходим множество витков цикла Деминга и готовы тратить такое множество усилий, чтобы получить наилучший результат в конце. И проблема не в том, что этих витков много, а в том что мы к этому не готовы.
А теперь, со знанием о цикле Деминга, давайте вернемся к нашему доблестному календарному плану. Теперь мы понимаем, что каждая задача это лишь первый виток цикла Деминга:
А через три месяца дела будут обстоять примерно так:
Причем заметьте, это еще идеалистичная картина... На ней нет ни одного пожара и ни одной срочной задачи. За целый квартал ни одной срочной задачи. Вы вообще можете себе такое представить?
Есть ли способ предотвратить крушение нашего плана? Да, мы можем делать задачу только в том объеме, который был изначально запланирован, а весь фидбек «зарубать» и ставить в очередь будущих доработок:
Это поможет нам быть ближе к изначальному плану. Но, если мы будем так делать все время, то бизнес начнет всё считать в Excel вместо того, чтобы приходить к нам с задачами. А клиент найдет другой продукт вместо того, чтобы предлагать нам новые фичи и с радостью их получать.
Естественно, в обе эти крайности мы впадаем редко и используем комбинированный подход. Поэтому в конце квартала у нас и изначальный план провален, и куча задач еще не доделана. Ну и будем реалистичны, пожары и срочные задачи тоже внесли свою лепту:
И каждая такая недоделанная задача — это еще один долг. То есть мы хотели избавиться от долгов, а их стало еще больше.
Думаю, многие из вас видели результаты работы хирургов, которые эту этику нарушили. Но уродливые губы — это еще не самое страшное. Ведь иногда под риском здоровье и даже жизнь пациента. Если он нездоров, его организм может не вынести серьезную операцию.
То же самое справедливо для нашего проекта. Если на нем постоянно происходят пожары, он уже «нездоров». Затевая глобальные перемены (например, «Нам нужен Continuous Delivery!»), вы начнете революцию, с которой сами не справитесь. Возьмете такую огромную задачу, что невозможно представить даже порядок количества циклов Деминга, который понадобится чтобы уверенно сказать, что мы закончили. При пожарах лучше действовать обратным способом:
Одним прекрасным утром мы заметили, что данные в БД на production испорчены.
Теперь вся команда судорожно смотрит в логи, смотрит в данные, смотрит в код и пытается понять, что же произошло. И в какой-то момент мы понимаем — на прод просочился баг, который данные испортил. Теперь нужно поднимать вчерашний бэкап (если он у нас есть), финансовый день компании потерян, имиджу компании нанесен урон.
Конечно, не хотелось бы, чтобы в будущем такая ситуация повторилась.
Уже в момент тушения пожара, когда совсем не похоже, что что-то идет по плану, у нас есть ориентир — оставить на устранении инцидента минимум участников. То есть убрать состояние, когда вся команда бегает и судорожно пытается помочь — по факту все бегают и стукаются лбами. Поэтому оставляем на инциденте минимум участников, а остальные возвращаются к нормальной работе.
Далее, когда пожар потушен, нам нужно проанализировать ситуацию и найти системное решение, за счет которого подобное больше никогда не повторится. Или повторится, но с гораздо меньшим уроном для нас.
Стоит признать, когда мы делаем первые шаги по спасению пожарного проекта, на вопрос «почему это случилось, что у нас не так?» ответом часто будет «Да %$&!! Всё не так!!!». У нас тестов нет. У нас всего один QA на 10 разработчиков и он зашивается. Бизнес никогда не смотрит сделанную задачу на тестовой среде. Зато как только раскатаем на production — тут же приходит и говорит, что все надо переделать. Еще и раскатываем вручную периодически, портя окружение. В общем, «плохо все».
Именно здесь наша задача — локализовать. Не пытаться искать универсальные решения в духе «Нам нужно переходить на DevOps!» или «Нам нужен Continuous Delivery!». Сейчас наша задача найти максимально локализованное решение.
Если вдуматься, то каждый из стикеров-проблем — это отсутствующая петля обратной связи. Например, тесты нам сообщают: «все хорошо, продолжай в том же духе». Или наоборот: «подожди, что-то не так! Проверь, прежде чем двигаться дальше». Аналогично, петлями являются прошедший или упавший билд, информация от QA о результате тестирования, обратная связь от бизнеса.
Получается, всех этих петель обратной связи у нас нет. Мы доставляем новый функционал до прода вслепую, с минимумом проверок. И сейчас наша задача создать всего одну петлю обратной связи. Но самую эффективную и самую дешевую. Какой из вариантов петли выбрать? В данном случае мы возьмем юнит тесты, потому что из всех проблем они левее всех в цепочке поставки. Это вообще неплохой ориентир при принятии решений
Вдобавок, решение «слева» нередко еще и самое дешевое в реализации. Написать юнит-тесты это действительно дешевле, чем даже следующая фаза — ручная проверка QA после каждого изменения.
Итак, из всего вороха проблем мы нашли одного кандидата на реализацию — написать тесты. Но это все равно слишком большая задача. Через какой срок мы получим петлю обратной связи, что теперь наша система прикрыта тестами достаточно надежно? Через полгода, год? Это слишком долго.
Поэтому опять локализуем — для начала покрываем тестами самый критичный функционал. Выбираем буквально несколько классов, пишем несколько юнит-тестов. А что будет дальше — решим на следующем витке цикла Деминга.
И хорошо бы еще на фазе PLAN понимать, что станет нашей петлей обратной связи. Почему? Потому что мы неизбежно будем ошибаться, пока ищем системные решения. Мы не можем не ошибиться ни разу. Мы должны ошибаться дешево и быстро, отбрасывая неэффективные решения до того, как мы вложили в них кучу усилий. Именно поэтому стоит с самого начала понимать, как мы проверим, что запланированные действия имели смысл.
Итак, нашей фазой DO было написать несколько тестов. На фазе CHECK мы должны проверить, что эти тесты действительно что-то проверяют, они написаны качественно, мы учли пограничные сценарии. Лучший способ провести такую проверку вам хорошо знаком — Code review.
Но давайте немного усложним пример. Давайте представим, что мы сидим в стареньком SVN и у нас нет инструментов для Code Review.
Значит, нам нужно подобрать новый инструмент, согласовать с бизнесом закупку лицензий, купить железо (или переехать в облако), смигрировать наши исходники в новую систему и т.д. Дело запахло еще одним огромным циклом Деминга. И для задачи «написать несколько тестов» это, очевидно, перебор. Решение нужно снова локализовать.
Зачем нам вообще Code review? Чтобы кто-то кроме автора посмотрел на тесты. Может вручную просмотреть коммиты и написать замечания коллеге в мессенджере? Пожалуй, так себе идея... Как насчет парного программирования? Да, эта техника до сих пор спорная. Но сейчас, в данной конкретной ситуации, это процедурно дешевле, чем внедрять новый CI. Поэтому для этой задачи мы займемся парным программированием. Дальше посмотрим, но сейчас парное программирование — самый «дешевый» вариант петли обратной связи.
Итак мы напишем тесты и проверим их. Потом покроем тестами еще немного критичного функционала, и еще…
Рано или поздно наступит время для фазы CHECK «большого» витка. Для этого подходит ретроспектива с командой. Мы написали тесты уже для нескольких задач, накопился приличный test suite. Давайте оценим, стало ли лучше с тестами? Помогает ли нам парное программирование писать тесты хорошо? Не пора ли делать первые шаги в сторону CI? На все эти вопросы мы можем ответить себе на ретроспективе.
Но ведь каждая из этих привычек — это петля обратной связи. Они помогают нам понимать, что мы движемся в нужную сторону. Причем это эффективные и короткие петли обратной связи.
Поэтому, если у вас получится удержать эти еще не созревшие привычки на фоне пожара — это будет огромным успехом, пусть все и началось с крохотной задачи «написать несколько тестиков».
И обязательно поделитесь этим успехом с командой и бизнесом. Да, мы не даем больших обещаний, но зато мы их выполняем. Да, у нас есть сложности на проекте, но мы с каждым разом, с каждой неделей, с каждым решением, делаем ситуацию лучше. Осознание этих моментов отлично работает и на повышение доверия, и на мотивацию в команде.
Итак, начав с малого, повторяйте цикл Деминга, пока решение действительно не заработает. Удерживайте фокус, пока не будете уверены, что вы «отдали долг» окончательно. И только тогда переходите к следующему. Не создавайте себе еще больше долгов!
Вообще, предыдущие две части уже сильно помогут с вопросом выгорания. Если на проекте нет конфликтов, мы редко сидим в офисе до ночи, чувствуем, что занимаемся правильным делом и идем в нужную сторону — это уже сильно упрощает ситуацию. Но даже когда все хорошо, могут происходить ситуации, ведущие к выгоранию. Но что, если пожар закончился, но мы все равно периодически чувствуем, что подбираемся к опасной границе выгорания?
Прежде всего, давайте обсудим первое правило йога. Если вы придете на йогу как на духовную практику, то первым, про что вам расскажет мастер, будет правило «Ахимса»— или «невреждение, ненасилие», в том числе по отношению к себе.
Если же йога вас интересует как фитнес, то, придя в фитнес-центр, вы услышите от тренера лайфхак, который будет большим упрощением того же правила Ахимса:
Во-первых, работая над проектом, как и в йоге, мы ни с кем не соревнуемся. Мы здесь находимся, чтобы сделать мир лучше, что себя сделать лучше. Поэтому не надо надрываться. Просто делайте свое дело и старайтесь ловить кайф от происходящего. Это самый продуктивный способ работы в долгосрочной перспективе.
Но в правиле йога есть еще одна связь с состоянием выгорания. Как вы считаете, почему, приходя на йогу, мы узнаем о правиле «Ахимса» (или его упрощении) еще до самого первого занятия? Зачем тренер начинает именно с этого?
Суть в том, что он таким образом передает вам ответственность за ваше же состояние. И это справедливо и для выгорания:
Поймите, что никакой руководитель, никакой департамент заботы или отдел персонала не сделает эту работу за вас. Ваше состояние — это только ваша ответственность.
Довольная частая ситуация у начинающего тимлида — наваливается столько задач, что наступает паника. И круглосуточно работать не помогает. Первый мой совет — прочитайте «Джедайские техники» Максима Дорофеева. Это просто must have. После прочтения этой книги я заметил, что справляюсь с большим количеством задач. Но стресс из-за их количества по-прежнему остался. Этот вопрос решила вторая книга — «Антитайм-менеджмент» Николая Додонова. Максим Дорофеев в «Джедайских техниках» ссылается на нее очень много раз, и эта книга стоит отдельного прочтения. Там описывается, как работает наш мозг в состоянии стресса, перегрузок. А также что происходит после того, как мы поработали в режиме надрыва, и как спокойно в такой ситуации действовать. Для меня эта книга сняла все вопросы по поводу эмоционального напряжения, поэтому очень ее рекомендую.
Вторая причина выгорания начинающего тимлида связана с тем, что раньше вы получали довольно четкие вводные в виде задач. А теперь создавать эти вводные — ваша задача. И поначалу это может очень непривычно. Совет тут очень простой — дайте себе время привыкнуть. Это просто другой режим работы мозга, он перестроится. Договоритесь сами собой: «2 месяца я просто работаю, просто делаю дело. Если через 2 месяца будет все еще плохо, там и буду принимать решение. Сейчас же просто привыкаю». Заодно обдумайте, что произойдет, если вы сделаете откат? Часто после возврата из лида в разработку люди увольняются, потому что это эмоционально тяжело. Дальше вы переходите в другую компанию, снова показываете себя и получаете предложение стать тимлидом. Снова наступать на те же грабли? Поэтому, если вы в принципе рассматриваете для себя карьеру тимлида, то просто дайте себе время привыкнуть. Скорее всего, мозг перестроится. Если нет, через 2 месяца и подумаете над этим. И этот совет полезен не только тимлидам, но и при росте в CTO, директора по разработке, для любой новой и сложной для нас роли.
Когда мы занимаемся разработкой, то у нас есть довольно четкий цикл: мы берем в работу задачу, реализуем, тестируем, раскатываем и видим результат. Если у нас еще с культурой все хорошо, то от бизнеса получаем фидбек, какие мы молодцы. И на этом все: мы довольны, доза дофамина получена, мы готовы брать следующую задачу. У тимлидов таких задач практически нет, в наших задачах почти всегда отсутствует момент завершения. Не бывает такого, что вы берете задачу «Мотивация команды», оцениваете ее в 2 дня и потом: «Оп! Готово, у нас больше никогда не будет проблем с мотивацией».
Многими своими задачами мы занимаемся постоянно. И, когда приуныли, может возникнуть чувство, что вы как белка в колесе, занимаетесь одним и тем же, а результата никакого нет. Тут два совета.
Первое: отслеживайте прогресс, мы про это уже в пластической хирургии поговорили.
Второе: спрашивайте обратную связь сами. Даже если вы получите негативную обратную связь, это все равно будут действия, которые вы можете предпринять, чтобы сделать лучше.
Также спроецируйте это состояние на свою команду и поймите, что без обратной связи тяжело всем людям. Находясь в информационном вакууме и не получая обратную связь, продолжать что-то делать могут только одержимые. Абсолютное большинство людей в такой ситуации просто сдувается. Поэтому не жалейте обратной связи для своей команды, делитесь ею и научите команду делать то же самое.
Это самая сложная история. Если чувствуете, что подгорает, то разберитесь с тем, какая у вас мотивация. Зачем вы вообще здесь находитесь? Чего вы добиваетесь? Вы хотите делать классный продукт и делать так, чтобы ваша команда гордилась своей работой? Или вы пришли сюда строить карьеру и сейчас для этого какое-то сверхусилие совершаете? И та, и другая мотивация имеет право на жизнь. Но когда вы строите карьеру или рассчитываете на премию за сверхусилия, то ваша мотивация очень сильно привязана к тому, что вы рассчитываете получить от окружающего мира. И если после перегруза не получить ожидаемого, это может разрушить вашу мотивацию в ноль. Я знаю нескольких людей, которые после надрывных забегов в расчете на премию вообще из профессии вышли.
Эта история реально сложная. Я сам всегда считал, что я идейный и для меня главное — создаваемая ценность. И только в 2016 году я сам про себя понял: «Все-таки нет, Федор, иногда ты действуешь совсем по-другому».
Еще важно отметить, что вашу мотивацию очень хорошо видно со стороны. И экологичный руководитель в здоровой компании просто не даст вам делать карьеру с такой мотивацией. Про это есть очень интересная статья Уилла Ларсона, рекомендую.
Подводя итог ко всему разделу: помните, что ваше внутреннее состояние — это ваша ответственность. Это ситуация как в самолете: сначала вы надеваете маску на себя и только потом на своего ребенка. Потому что если вы не позаботитесь о себе, то ни о проекте, ни о команде вы позаботиться уже не сможете. Ситуация, когда тимлид пашет как проклятый, из-за этого не высыпается, разговаривает через зубы с командой и «гавкает» на заказчика — это не к добру. Поэтому в первую очередь проявите заботу к себе.
Оказавшись в сложной ситуации, позаботьтесь о том, чтобы у вас была возможность спокойно подумать, оценить ситуацию целиком и только потом перейти к действиям. Если вы дадите себе возможность спокойно рефлексировать, то все нужные мысли придут к вам в голову сами. На этом у меня все. Спасибо, что дочитали!
habr.com
На прошедшей в апреле конференции TeamLead Conf 2021 я поделился своим опытом, как вытащить проект из пожара и обойтись без человеческих жертв. Под катом моя история, а если предпочитаете смотреть — вот запись выступления.
План действий при пожаре
Разумеется, желательно иметь план действий поконкретнее, чем на картинке выше.Чему же уделить внимание, если мы понимаем, что наш проект в опасном положении?
Две области для присмотра понятны из названия статьи: нужно спасти сам проект и сделать это без человеческих потерь в виде выгорания. Также есть третья очень важная область, из-за которой могут быть обнулены все наши усилия по спасению проекта — коммуникации. Если мы доведем взаимодействие с заказчиком до того, что он потеряет веру в успех проекта, то он его просто закроет. И это значит, все наши усилия и сверхусилия пропали даром. Также, если в команде постоянные конфликты, и люди увольняются — вряд вас ждет успех. В общем, коммуникации — это настолько важная область, что с нее мы и начнем.
И интересный момент в чем... Вообще-то по всем трем этим областям человечество уже накопило огромное количество знаний о том, как «правильно». Но в ситуации стресса, когда под нами стул горит, почему-то это «правильно» даже не вспоминается — мы действуем по наитию, а то и вовсе на голых эмоциях.
Причина такого поведения в том, что при стрессе мозг находится в режиме «бей или беги», он не склонен принимать взвешенные, аналитические решения. И, чтобы выйти из этого состояния, нужна какая-то катапульта. Какое-то заклинание, которое позволит прекратить происходящий сейчас треш и быстро вернуться в нормальное состояние. Что-то типа стоп-слов у садомазохистов.
И я для себя такие «стоп-слова» нашел. Я выбрал базовые законы из других профессиональных областей — очень краткие, очень емкие, несущие в себе много смысла — и вспоминаю их в ситуациях, когда становится «горячо». Это помогает вернуться в спокойное состояние и принять взвешенное, рациональное решение.
Эти законы мы сегодня и обсудим. По одному для каждой из областей:
- Здоровые коммуникации — Первый закон экологии
- Спасение проекта — Этика пластической хирургии
- Защита от выгорания — Первое правило йога
Часть 1. Как построить экологичные коммуникации
Для начала расскажу две истории для контекста. Обе реальные, но моя — только вторая.История первая
Один молодой тимлид работал на кипучем проекте. Он постоянно зашивался и ничего не успевал. В какой-то момент он осознал, что всё, чем он занят — это таскает информацию от команды к бизнесу, от бизнеса к аналитикам и от аналитиков снова к команде. То есть он работает этаким тимлидом-пресс-секретарем и никакой полезной работы не делает.Осознав это, он принял абсолютно верное решение: «Буду делегировать». И вот, появляется очередная задача, где требуется коммуникация с заказчиком и наш тимлид передает ее самому боевому и коммуникабельному разработчику. Проходит день — задача не сделана. Второй — то же самое. На третий день тимлид напрягается, ведь он уже дважды напоминал о задаче.
Но, проанализировав ситуацию, он подумал: «Сейчас и так тяжело, итерация съехала, все загружены. Если еще и я приду со своими претензиями, то обидится парень. Уволится еще. Нафиг надо». И наш тимлид молча делает задачу сам.
Проходит год. Наш тимлид всё так же работает пресс-секретарем, а тот самый разработчик приходит к нему и говорит: «Я увольняюсь, у меня тут нет никакого роста»...
История номер два
Самый «горячий» из моих проектов достался мне через два года после его старта. Вновинку проект был не только мне — вся команда была сформирована заново. Но у проекта уже была история, и с самого начала работы к нам была сформирована справедливая и понятная претензия: «Слишком долго, слишком мало. И непонятно, почему так долго и так мало».И причина этого недовольства была у меня на руках — проект находился в нерабочем состоянии. Буквально, на проде сообщения приходилось проталкивать по шине руками, чтобы нужные процессы завершались.
Я сделал несколько попыток договориться с ПМ-ами проекта (у нас их было двое) о том, чтобы перепроектировать «фундамент» системы. Но успеха мне добиться не удалось.
И вот тут я сделал свою самую большую ошибку — перешел в режим героя. Я размышлял так: «Мы спасем это проект и все зарефакторим! Я готов тратить на это свои вечера и выходные, но мы все сделаем! А когда доделаем, то бизнес поймет, какие же мы на самом деле молодцы..».
Так я и начал действовать. А исходный конфликт с ПМ-ами оставил без внимания.
Но, чтобы подобный тлеющий конфликт начал полыхать, достаточно делать... ничего. И это то, что я и решил делать — ничего. В итоге конфликт перерос в личностный и общение стало очень токсичным. Позже отношения пришлось перезапускать: эти ПМ-ы ушли на другие проекты, а у нас появился новый ПМ. С ним уже все пошло хорошо, но понимаете, я могу в этой ситуации оправдываться как человек, но как тимлиду мне тут гордиться совершенно нечем — отношения с заказчиком были развалены.
Вот такие вот две истории.
Почему так происходит и причем тут экология?
Первый закон экологии гласит:
У любого действия есть побочные эффекты. Например, если в лесу перестрелять всех волков, то зайцы съедят наш урожай. Потом они съедят всю растительность в поле, начнется эрозия почвы, погибнет лес и вскоре уже вся территория опустеет.
Это в чистом виде эффект бабочки: незначительное изменение может привести к очень серьезным и непредсказуемым последствиям.
И этот феномен уже давно вышел за пределы экологии. Сегодня он используется во множестве других направлений науки и получил название «сложная система». Фондовый рынок, иммунная система человека, психика человека, социум — все это примеры «сложных систем». Они не поддаются описанию алгоритмами, они «нетерпимы» к внешнему управлению, эксперименты с ними неповторяемы, а то и вовсе опасны.
Понимаете, между «простыми» и «сложными» системами есть очень существенная разница. Когда мы бьем кием по бильярдному шару, то мы не ждем ядерного взрыва. Но, когда мы подходим с очень мудрым советом к раздраженному коллеге, то спектр возможных сценариев становится гораздо шире — он непредсказуем. И совсем не факт, что мы сможем понять, из-за каких событий прошлого сейчас наш коллега среагировал именно так, а не иначе. Потому что психика человека это сложная система.
И коммуникации, как совокупность психик, тоже являются сложной системой, в которой могут происходить подобные эффекты.
Давайте вернемся к историям про тимлида-пресс-секретаря и про мой конфликт с ПМ-ами.
- Тимлид делегировал задачу и не получает результат в ожидаемое время. Очевидно, его представления конфликтуют с представлениями разработчика о том, как делать эту задачу.
- У ПМ есть претензия к нашей «скорости». Мы не можем стать быстрее, не потратив сначала время на перепроектирование. Но мы не можем договориться, потому что надо «быстро и прямо сейчас».
Конфликт это всегда или точка роста или способ найти оптимальное решение в условиях ограниченных ресурсов. Например, наши баттлы с ПМ-ами о том, сколько взять в работу техдолга и бизнесовых фич. Если это здоровый конфликт, то его результатом станет оптимальный баланс задач, обеспечивающих и долгосрочное развитие проекта, и текущую доставку ценности бизнесу.
Но когда конфликт превращается в личностный, то начинаются проблемы. И часто это происходит даже при том, что у обеих сторон исключительно добрые намерения. Почему же так получается?
Наш мозг рассказывает нам истории
Дело в том, что наш мозг, наше левое полушарие, не умеет работать с изолированными фактами. Мы неизбежно связываем имеющиеся факты в логичную (как нам кажется) историю и действуем в соответствии с ней.И, если фактов у какой-то из сторон конфликта не хватает, то это никак не мешает составить историю. Просто она будет гораздо дальше от реальности.
Так и получается, что тимлид делегировал задачу, но впоследствии сделал ее сам. И не поговорил с разработчиком чтобы не конфликтовать, из добрых побуждений... Но вместо этого начинает копиться череда недомолвок, в результате которых тимлид избегает делегирования совсем, а разработчик решает, что ему больше не дадут тут расти.
Аналогично с моим конфликтом с ПМ-ами. У них в голове история о том, что мы — засранцы, которые ничего не делают и только создают проблемы. А у нас в голове история, что мы — герои, которые спасают положение. При этом у ПМ, например, годовые KPI про которые они нам не говорят. А мы не рассказываем насколько действительно плохи дела потому, что пытаемся «сохранить лицо». И как мы можем в такой ситуации о чем-то договориться? Да никак. После каждого рабочего «столкновения» истории в наших головах все дальше расходятся друг от друга, пока каждый не решит, что на противоположной стороне очевидный вредитель.
Подобные истории всегда начинаются с какой-то маленькой неопределенности. Кто-то что-то недосказал по «политическим причинам». Или кто-то что-то стерпел, опасаясь конфликта. Или мы приняли пограничное решение, которое не можем озвучить другой стороне. И эти недосказанности усиливаются со временем, потому что наш мозг так устроен — если ему не хватает фактов, то он сам себе придумывает историю.
Как построить здоровые коммуникации?
Чтобы построить здоровые коммуникации есть всего два простых правила: открытость и постоянная обратная связь.Что означает открытость? Насколько это возможно, уберите из вашей работы любую политику, попытки «держать лицо», пограничные решения типа «рефакторинг замазывать в бизнес-задачи». Все правила, по которым вы работаете, должны быть общедоступны. Вы должны быть в состоянии сказать о них любому участнику процесса. А в идеале каждый должен не только знать ваши правила, но и разделять их ценность. Классический пример — принятие бизнесом ценности автотестов.
Также вам поможет открытость личного характера. Если вы чувствуете, что кто-то разговаривает через зубы, что-то терпит — проанализируйте ситуацию и спокойно проговорите ее вместе. Не придумывайте за вторую сторону, начните с простого: «я чувствую, что что-то идет не так, давай это обсудим?».
Ведь это супер-умение — в самом начале конфликта открыто и дружелюбно все проговорить, устранить все неопределенности. После этого все понимают ситуацию одинаково, открыты друг к другу и настроены на боевой лад. Открытость устраняет неопределенности и у мозга становится меньше поводов придумывать истории.
Но даже если мы будем максимально открыты, неопределенности все равно будут возникать. Ведь мы находимся внутри супер-сложной системы. Поэтому мы добавляем второй компонент — постоянную обратную связь. Она поможет нам быстро прорабатывать возникающие неопределенности и выравнивать ожидания.
При этом очень важно давать и негативную обратную связь тоже. И это сложно делать. Тем более сложно давать негативную обратную связь руководителю или заказчику. И еще сложнее, когда мы находимся под давлением или к нам есть претензии. Но делать это необходимо, потому что если мы не даем обратную связь, мы обречены терпеть происходящее — мы сами лишаем себя возможности изменить ситуацию к лучшему.
Как давать негативную обратную связь
На самом деле это совсем не сложно, если соблюдать несколько простых правил.Не рубить с плеча
Если произошла «горячая» ситуация, то сначала найдите время, чтобы спокойно, в тишине все обдумать и как следует подготовиться. Если вас подмывает прямо сейчас всё высказать и доказать что вы правы — вспомните формулировку Первого закона экологии, она напомнит вам о последствиях подобного поступка.Вера в добрые намерения
В процессе подготовки обратной связи верьте в добрые намерения. Оцените ситуацию реалистично. Вы делегировали разработчику задачу и она не сделана. Каковы шансы, что этот разработчик саботажник? Или с PM у вас постоянные конфликты насчет задач. Каковы шансы, что PM лично вас недолюбливает и целенаправленно вам гадит, жертвуя проектом? Эти шансы почти всегда равны нулю.Вы сидите в одной лодке и плывете в одну сторону. У вас всего лишь сбился ритм маха веслами и вам нужно открыто поговорить об этом, пока ситуация не зашла слишком далеко. Поэтому, когда готовите обратную связь, вспомните, что перед вами человек у которого, добрые намерения, как и у вас.
Безоценочность
Еще один компонент хорошего негативного фидбека — безоценочность.И делать это несложно. Обсуждайте произошедшие события, а не человека. Не «ты сделал плохо», а «сейчас то-то плохо».
Если разработчик прикипел душой к выбранной реализации и вы боитесь, что даже обсуждение фактов будет принято на личный счет — не говорите о том, как плохо. Обсудите как вы представляете себе «хорошо», как вы мечтаете, чтобы стало в будущем. Это поможет уйти от личных претензий и сформулировать понятные actionable идеи, которые помогут улучшить ситуацию.
Безоценочность работает и для вас
В любой сложной ситуации у вас те же права, что и у других. Как бы вы ни ошиблись — вы заслуживаете обратную связь, а не моральный прессинг. Об этом стоит вспомнить, например, если вас вызвали «на ковер» к руководителю. Это очень, очень сложно, но попытайтесь развернуть беседу так, чтобы услышать какие-то actionable вещи — действия, которые вы сможете выполнить, чтобы улучшить ситуацию.Безоценочность ≠ безнаказанность
Это еще один момент, который стоит явно проговорить. Иногда мы наказываем людей и даже прощаемся с ними. Но делаем это только в одном случае — если у человека не было добрых намерений. Или если ему было все равно. Во всех остальных случаях и ваш коллега, и вы сами, имеете право именно на обратную связь, а не на моральное давление.Попробуйте действовать подобным образом и вы увидите, что привычка давать конструктивную обратную связь распространяется во все стороны. Так вы научите этому всех участников процесса.
В завершение части про коммуникации повторюсь, любая неопределенность — это сигнал для вас как тимлида, будьте любопытны к ним. Это не значит быть затычкой в каждой бочке. Просто уделите внимание ситуациям, когда кто-то что-то недоговаривает, кому-то некомфортно. Подобная чуткость позволит вам построить продуктивные, дружелюбные и открытые отношения.
Часть 2. Как вытаскивать проект из пожара
Вообще для ситуации, когда на проекте постоянно полыхают пожары, уже есть устоявшаяся метафора — долги. Например, один из уже привычных нам терминов — техдолг.
Если долгов становится слишком много, то они начинают пожирать слишком много нашего внимания. И мы поступаем так же, как при проблемах с финансовыми долгами — выкраиваем некоторое количество ресурсов на «возврат» долгов.
Допустим, мы поняли, что наш проект погряз в долгах и договариваемся с бизнесом тратить 20% времени на техдолг. Это не очень много, но на самое важное хватит. И мы строим плотный, солидный план технического развития проекта на год и стартуем с намерением отдать все долги.
Похожим образом действует бизнес. Мы «отжали» у него 20% времени, но запросы на фичи от этого не уменьшились. Поэтому мы договариваемся уплотнить график поставки и на этот раз действовать без проволочек.
И вот, у нас получился совместный план, допустим, на квартал:
В точности как с финансовыми долгами — мы посчитали ресурсы в нашем распоряжении, поделили их на поддержание актуальных потребностей и на возврат долгов, построили четкий график.
И с этого момента метафора с финансовыми долгами перестает работать. Дело в том, что когда мы рассчитались по финансовому долгу, то на этом история заканчивается. Банк забывает про нас, а мы забываем про него.
Но с нашей работой ситуация обстоит иначе. Потому что любую интеллектуальную, творческую работу мы выполняем в цикле Деминга, состоящем из 4 фаз: PLAN, DO, CHECK и ACT.
Как мы делаем типичную задачу? Сначала мы декомпозируем (PLAN), затем кодим (DO), далее тестируем (CHECK) и раскатываем на прод (ACT). Аналогичным образом мы составляем стратегические планы и согласуем их с коллегами, проектируем архитектуру приложения и проводим ее review с командой. Даже атомарный commit мы выполняем в те же четыре действия. То есть цикл Деминга вложен, он работает на задачах любого уровня.
Но почему он называется «цикл»? Дело в том, что после выполнения всех четырех этапов замыкается петля обратной связи. Например, мы видим упавшие тесты или слышим мнение коллеги на code review, слышим мнение бизнеса или получаем отзыв пользователя. И вот здесь и зарыта собака. Потому что после получения обратной связи нам часто нужно будет сделать еще что-то, прежде чем считать задачу действительно завершенной. Это характерно для любой творческой, интеллектуальной работы.
Например, вы часто видели, чтобы дизайн-макет принимался с первого раза?
То же самое происходит при разработке новых фичей. Мы проводим ряд экспериментов и постоянно собираем обратную связь, чтобы максимально уточнить смысл фичи и принести максимальную пользу. Или то, как мы проводим рефакторинг — в начале мы имеем лишь общее представление о результате, к которому хотим прийти. Но по мере движения вперед, погружения в принимаемые технологии, картина становится все яснее.
То есть, чтобы действительно сделать работу до конца, мы должны провести несколько циклов. И мы не можем в самом начале предсказать сколько этих циклов будет. Мы не знаем, сколько багов найдет QA и что коллеги скажут на Code review.
Конечно, иногда мы не получаем обратную связь:
- Если задача тривиальная. Например, поправить опечатку
- Если мы пропустили петлю обратной связи. Информация может прилететь и позже, как кирпич в затылок. Например, мы обнаружим баг, который уже 2 недели портит данные на production.
- Если задача просто никому не нужна.
Полагаю, что нет. Мне тоже. Так вот, ситуация «требования постоянно меняются», которую мы так не любим — это признак того, что задача действительно нужна и полезна. Мы проходим множество витков цикла Деминга и готовы тратить такое множество усилий, чтобы получить наилучший результат в конце. И проблема не в том, что этих витков много, а в том что мы к этому не готовы.
А теперь, со знанием о цикле Деминга, давайте вернемся к нашему доблестному календарному плану. Теперь мы понимаем, что каждая задача это лишь первый виток цикла Деминга:
А через три месяца дела будут обстоять примерно так:
Причем заметьте, это еще идеалистичная картина... На ней нет ни одного пожара и ни одной срочной задачи. За целый квартал ни одной срочной задачи. Вы вообще можете себе такое представить?
Есть ли способ предотвратить крушение нашего плана? Да, мы можем делать задачу только в том объеме, который был изначально запланирован, а весь фидбек «зарубать» и ставить в очередь будущих доработок:
Это поможет нам быть ближе к изначальному плану. Но, если мы будем так делать все время, то бизнес начнет всё считать в Excel вместо того, чтобы приходить к нам с задачами. А клиент найдет другой продукт вместо того, чтобы предлагать нам новые фичи и с радостью их получать.
Именно здесь причина того, как много проектов, переписанных с нуля, загнулись. Они отключились от внешнего мира, от обратной связи, чтобы всё переписать. Но когда они вернулись на рынок, они уже никому не нужны.
Естественно, в обе эти крайности мы впадаем редко и используем комбинированный подход. Поэтому в конце квартала у нас и изначальный план провален, и куча задач еще не доделана. Ну и будем реалистичны, пожары и срочные задачи тоже внесли свою лепту:
И каждая такая недоделанная задача — это еще один долг. То есть мы хотели избавиться от долгов, а их стало еще больше.
Что же делать?
Мораль истории такова:Поэтому в случае пожаров вместо «финансового» подхода стоит действовать в соответствии с этикой пластической хирургии:
Думаю, многие из вас видели результаты работы хирургов, которые эту этику нарушили. Но уродливые губы — это еще не самое страшное. Ведь иногда под риском здоровье и даже жизнь пациента. Если он нездоров, его организм может не вынести серьезную операцию.
То же самое справедливо для нашего проекта. Если на нем постоянно происходят пожары, он уже «нездоров». Затевая глобальные перемены (например, «Нам нужен Continuous Delivery!»), вы начнете революцию, с которой сами не справитесь. Возьмете такую огромную задачу, что невозможно представить даже порядок количества циклов Деминга, который понадобится чтобы уверенно сказать, что мы закончили. При пожарах лучше действовать обратным способом:
Берите в каждый момент времени только одно и самое горящее, самое критичное. Остальное может подождать. Если вы распылитесь, то не сделаете вообще ничего.
Как это работает на практике?
Давайте разберем пример и оценим, что делать на разных этапах цикла Деминга. Мы не будем строить многоуровневую схему действий, а просто обсудим ориентиры — что делать на фазе Plan, что на фазе Check и т.д.Одним прекрасным утром мы заметили, что данные в БД на production испорчены.
Теперь вся команда судорожно смотрит в логи, смотрит в данные, смотрит в код и пытается понять, что же произошло. И в какой-то момент мы понимаем — на прод просочился баг, который данные испортил. Теперь нужно поднимать вчерашний бэкап (если он у нас есть), финансовый день компании потерян, имиджу компании нанесен урон.
Конечно, не хотелось бы, чтобы в будущем такая ситуация повторилась.
Фаза PLAN — локализация
Этап PLAN у нас проходит под девизом локализации.Уже в момент тушения пожара, когда совсем не похоже, что что-то идет по плану, у нас есть ориентир — оставить на устранении инцидента минимум участников. То есть убрать состояние, когда вся команда бегает и судорожно пытается помочь — по факту все бегают и стукаются лбами. Поэтому оставляем на инциденте минимум участников, а остальные возвращаются к нормальной работе.
Далее, когда пожар потушен, нам нужно проанализировать ситуацию и найти системное решение, за счет которого подобное больше никогда не повторится. Или повторится, но с гораздо меньшим уроном для нас.
Стоит признать, когда мы делаем первые шаги по спасению пожарного проекта, на вопрос «почему это случилось, что у нас не так?» ответом часто будет «Да %$&!! Всё не так!!!». У нас тестов нет. У нас всего один QA на 10 разработчиков и он зашивается. Бизнес никогда не смотрит сделанную задачу на тестовой среде. Зато как только раскатаем на production — тут же приходит и говорит, что все надо переделать. Еще и раскатываем вручную периодически, портя окружение. В общем, «плохо все».
Именно здесь наша задача — локализовать. Не пытаться искать универсальные решения в духе «Нам нужно переходить на DevOps!» или «Нам нужен Continuous Delivery!». Сейчас наша задача найти максимально локализованное решение.
Если вдуматься, то каждый из стикеров-проблем — это отсутствующая петля обратной связи. Например, тесты нам сообщают: «все хорошо, продолжай в том же духе». Или наоборот: «подожди, что-то не так! Проверь, прежде чем двигаться дальше». Аналогично, петлями являются прошедший или упавший билд, информация от QA о результате тестирования, обратная связь от бизнеса.
Получается, всех этих петель обратной связи у нас нет. Мы доставляем новый функционал до прода вслепую, с минимумом проверок. И сейчас наша задача создать всего одну петлю обратной связи. Но самую эффективную и самую дешевую. Какой из вариантов петли выбрать? В данном случае мы возьмем юнит тесты, потому что из всех проблем они левее всех в цепочке поставки. Это вообще неплохой ориентир при принятии решений
Для цепочки поставок почти всегда работает правило, что решать проблемы нужно максимально «слева», как можно раньше. Чем раньше мы отловим ошибку — тем дешевле ее устранение. Локально поправить исходники после прогона юнит-тестов действительно дешевле, чем поднимать вчерашний бэкап на проде.
Вдобавок, решение «слева» нередко еще и самое дешевое в реализации. Написать юнит-тесты это действительно дешевле, чем даже следующая фаза — ручная проверка QA после каждого изменения.
Итак, из всего вороха проблем мы нашли одного кандидата на реализацию — написать тесты. Но это все равно слишком большая задача. Через какой срок мы получим петлю обратной связи, что теперь наша система прикрыта тестами достаточно надежно? Через полгода, год? Это слишком долго.
Поэтому опять локализуем — для начала покрываем тестами самый критичный функционал. Выбираем буквально несколько классов, пишем несколько юнит-тестов. А что будет дальше — решим на следующем витке цикла Деминга.
DO
На фазе DO у меня нет универсальных советов, это всегда детали реализации. И вряд ли мне стоит учить вас писать тесты. Вы как никто знаете, что и в соответствии с какими принципами стоит сделать на вашем проекте.CHECK
Фаза CHECK — это наша внутренняя петля обратной связи. Мы должны проверить, что шаг, сделанный на фазе DO, был сделан в нужную сторону и нужной ногой.И хорошо бы еще на фазе PLAN понимать, что станет нашей петлей обратной связи. Почему? Потому что мы неизбежно будем ошибаться, пока ищем системные решения. Мы не можем не ошибиться ни разу. Мы должны ошибаться дешево и быстро, отбрасывая неэффективные решения до того, как мы вложили в них кучу усилий. Именно поэтому стоит с самого начала понимать, как мы проверим, что запланированные действия имели смысл.
Итак, нашей фазой DO было написать несколько тестов. На фазе CHECK мы должны проверить, что эти тесты действительно что-то проверяют, они написаны качественно, мы учли пограничные сценарии. Лучший способ провести такую проверку вам хорошо знаком — Code review.
Но давайте немного усложним пример. Давайте представим, что мы сидим в стареньком SVN и у нас нет инструментов для Code Review.
Значит, нам нужно подобрать новый инструмент, согласовать с бизнесом закупку лицензий, купить железо (или переехать в облако), смигрировать наши исходники в новую систему и т.д. Дело запахло еще одним огромным циклом Деминга. И для задачи «написать несколько тестов» это, очевидно, перебор. Решение нужно снова локализовать.
Зачем нам вообще Code review? Чтобы кто-то кроме автора посмотрел на тесты. Может вручную просмотреть коммиты и написать замечания коллеге в мессенджере? Пожалуй, так себе идея... Как насчет парного программирования? Да, эта техника до сих пор спорная. Но сейчас, в данной конкретной ситуации, это процедурно дешевле, чем внедрять новый CI. Поэтому для этой задачи мы займемся парным программированием. Дальше посмотрим, но сейчас парное программирование — самый «дешевый» вариант петли обратной связи.
Итак мы напишем тесты и проверим их. Потом покроем тестами еще немного критичного функционала, и еще…
Рано или поздно наступит время для фазы CHECK «большого» витка. Для этого подходит ретроспектива с командой. Мы написали тесты уже для нескольких задач, накопился приличный test suite. Давайте оценим, стало ли лучше с тестами? Помогает ли нам парное программирование писать тесты хорошо? Не пора ли делать первые шаги в сторону CI? На все эти вопросы мы можем ответить себе на ретроспективе.
ACT
Итак, последняя фаза. Время оценить результаты и решить, что делать дальше. Если выбранное решение сработало, то все просто — о проблеме можно забыть навсегда. Но, к сожалению, этот исход не самый частый. У нас есть еще два вариантаЕсли решение не сработало
Стоит честно признаться себе, что мы ошиблись и перестать вкладывать силы в неверное решение, перейти к поиску другого. Но бросайте явно, а не спускайте неудачную задумку на тормозах. В частности, уведомите свое окружение, что решение оказалось нерабочим и вы будете искать другое. Иначе может получиться, что вы кому-то обещали светлое будущее, потом активность стухла, а в известность вы никого не поставили. Будете выглядеть как прокрастинаторы, а то и саботажники. По сути этот совет — отсылка к открытости, которую мы обсуждали в разделе про коммуникации.Если стало лучше, но нужно продолжать
Это частый в случае системных решений исход. И сложный, потому что он означает, что нам нужно сформировать новую командную привычку. Например, мы поняли, что писать тесты полезно. Это означает формирование целых трех новых привычек для команды:- Писать тесты
- Делать code review (проверять качество тестов)
- Проводить ретроспективы (проверять, все ли хорошо с тестами и с code review)
Но ведь каждая из этих привычек — это петля обратной связи. Они помогают нам понимать, что мы движемся в нужную сторону. Причем это эффективные и короткие петли обратной связи.
Поэтому, если у вас получится удержать эти еще не созревшие привычки на фоне пожара — это будет огромным успехом, пусть все и началось с крохотной задачи «написать несколько тестиков».
И обязательно поделитесь этим успехом с командой и бизнесом. Да, мы не даем больших обещаний, но зато мы их выполняем. Да, у нас есть сложности на проекте, но мы с каждым разом, с каждой неделей, с каждым решением, делаем ситуацию лучше. Осознание этих моментов отлично работает и на повышение доверия, и на мотивацию в команде.
Итак, начав с малого, повторяйте цикл Деминга, пока решение действительно не заработает. Удерживайте фокус, пока не будете уверены, что вы «отдали долг» окончательно. И только тогда переходите к следующему. Не создавайте себе еще больше долгов!
Часть 3. Выгорание, или первое правило йога
Вообще, предыдущие две части уже сильно помогут с вопросом выгорания. Если на проекте нет конфликтов, мы редко сидим в офисе до ночи, чувствуем, что занимаемся правильным делом и идем в нужную сторону — это уже сильно упрощает ситуацию. Но даже когда все хорошо, могут происходить ситуации, ведущие к выгоранию. Но что, если пожар закончился, но мы все равно периодически чувствуем, что подбираемся к опасной границе выгорания?
Прежде всего, давайте обсудим первое правило йога. Если вы придете на йогу как на духовную практику, то первым, про что вам расскажет мастер, будет правило «Ахимса»— или «невреждение, ненасилие», в том числе по отношению к себе.
Если же йога вас интересует как фитнес, то, придя в фитнес-центр, вы услышите от тренера лайфхак, который будет большим упрощением того же правила Ахимса:
Какое это имеет отношение к выгоранию?
Во-первых, работая над проектом, как и в йоге, мы ни с кем не соревнуемся. Мы здесь находимся, чтобы сделать мир лучше, что себя сделать лучше. Поэтому не надо надрываться. Просто делайте свое дело и старайтесь ловить кайф от происходящего. Это самый продуктивный способ работы в долгосрочной перспективе.
Но в правиле йога есть еще одна связь с состоянием выгорания. Как вы считаете, почему, приходя на йогу, мы узнаем о правиле «Ахимса» (или его упрощении) еще до самого первого занятия? Зачем тренер начинает именно с этого?
Суть в том, что он таким образом передает вам ответственность за ваше же состояние. И это справедливо и для выгорания:
Даже если инструктор будет рядом во время тренировки, он не может чувствовать, как там внутри ваша коленная связка. И это не его обязанность. Это ваша задача — контролировать свое внутреннее состояние. И то же самое с выгоранием. Проверяйте самого себя, заботьтесь о себе и периодически проверяйте: «Как я сам? Как дела? Может, стоит передохнуть? Может, меня беспокоит какая-то проблема, но я ей не уделяю внимания?»
Поймите, что никакой руководитель, никакой департамент заботы или отдел персонала не сделает эту работу за вас. Ваше состояние — это только ваша ответственность.
Советы для начинающих тимлидов
Если гнетет количество задач
Довольная частая ситуация у начинающего тимлида — наваливается столько задач, что наступает паника. И круглосуточно работать не помогает. Первый мой совет — прочитайте «Джедайские техники» Максима Дорофеева. Это просто must have. После прочтения этой книги я заметил, что справляюсь с большим количеством задач. Но стресс из-за их количества по-прежнему остался. Этот вопрос решила вторая книга — «Антитайм-менеджмент» Николая Додонова. Максим Дорофеев в «Джедайских техниках» ссылается на нее очень много раз, и эта книга стоит отдельного прочтения. Там описывается, как работает наш мозг в состоянии стресса, перегрузок. А также что происходит после того, как мы поработали в режиме надрыва, и как спокойно в такой ситуации действовать. Для меня эта книга сняла все вопросы по поводу эмоционального напряжения, поэтому очень ее рекомендую.
Раньше были четкие вводные, а теперь ничего непонятно
Вторая причина выгорания начинающего тимлида связана с тем, что раньше вы получали довольно четкие вводные в виде задач. А теперь создавать эти вводные — ваша задача. И поначалу это может очень непривычно. Совет тут очень простой — дайте себе время привыкнуть. Это просто другой режим работы мозга, он перестроится. Договоритесь сами собой: «2 месяца я просто работаю, просто делаю дело. Если через 2 месяца будет все еще плохо, там и буду принимать решение. Сейчас же просто привыкаю». Заодно обдумайте, что произойдет, если вы сделаете откат? Часто после возврата из лида в разработку люди увольняются, потому что это эмоционально тяжело. Дальше вы переходите в другую компанию, снова показываете себя и получаете предложение стать тимлидом. Снова наступать на те же грабли? Поэтому, если вы в принципе рассматриваете для себя карьеру тимлида, то просто дайте себе время привыкнуть. Скорее всего, мозг перестроится. Если нет, через 2 месяца и подумаете над этим. И этот совет полезен не только тимлидам, но и при росте в CTO, директора по разработке, для любой новой и сложной для нас роли.
Отсутствует момент «закрытия»
Когда мы занимаемся разработкой, то у нас есть довольно четкий цикл: мы берем в работу задачу, реализуем, тестируем, раскатываем и видим результат. Если у нас еще с культурой все хорошо, то от бизнеса получаем фидбек, какие мы молодцы. И на этом все: мы довольны, доза дофамина получена, мы готовы брать следующую задачу. У тимлидов таких задач практически нет, в наших задачах почти всегда отсутствует момент завершения. Не бывает такого, что вы берете задачу «Мотивация команды», оцениваете ее в 2 дня и потом: «Оп! Готово, у нас больше никогда не будет проблем с мотивацией».
Многими своими задачами мы занимаемся постоянно. И, когда приуныли, может возникнуть чувство, что вы как белка в колесе, занимаетесь одним и тем же, а результата никакого нет. Тут два совета.
Первое: отслеживайте прогресс, мы про это уже в пластической хирургии поговорили.
Второе: спрашивайте обратную связь сами. Даже если вы получите негативную обратную связь, это все равно будут действия, которые вы можете предпринять, чтобы сделать лучше.
Также спроецируйте это состояние на свою команду и поймите, что без обратной связи тяжело всем людям. Находясь в информационном вакууме и не получая обратную связь, продолжать что-то делать могут только одержимые. Абсолютное большинство людей в такой ситуации просто сдувается. Поэтому не жалейте обратной связи для своей команды, делитесь ею и научите команду делать то же самое.
Разберитесь со своей мотивацией
Это самая сложная история. Если чувствуете, что подгорает, то разберитесь с тем, какая у вас мотивация. Зачем вы вообще здесь находитесь? Чего вы добиваетесь? Вы хотите делать классный продукт и делать так, чтобы ваша команда гордилась своей работой? Или вы пришли сюда строить карьеру и сейчас для этого какое-то сверхусилие совершаете? И та, и другая мотивация имеет право на жизнь. Но когда вы строите карьеру или рассчитываете на премию за сверхусилия, то ваша мотивация очень сильно привязана к тому, что вы рассчитываете получить от окружающего мира. И если после перегруза не получить ожидаемого, это может разрушить вашу мотивацию в ноль. Я знаю нескольких людей, которые после надрывных забегов в расчете на премию вообще из профессии вышли.
Эта история реально сложная. Я сам всегда считал, что я идейный и для меня главное — создаваемая ценность. И только в 2016 году я сам про себя понял: «Все-таки нет, Федор, иногда ты действуешь совсем по-другому».
Еще важно отметить, что вашу мотивацию очень хорошо видно со стороны. И экологичный руководитель в здоровой компании просто не даст вам делать карьеру с такой мотивацией. Про это есть очень интересная статья Уилла Ларсона, рекомендую.
Подводя итог ко всему разделу: помните, что ваше внутреннее состояние — это ваша ответственность. Это ситуация как в самолете: сначала вы надеваете маску на себя и только потом на своего ребенка. Потому что если вы не позаботитесь о себе, то ни о проекте, ни о команде вы позаботиться уже не сможете. Ситуация, когда тимлид пашет как проклятый, из-за этого не высыпается, разговаривает через зубы с командой и «гавкает» на заказчика — это не к добру. Поэтому в первую очередь проявите заботу к себе.
Выводы
Давайте подведем итоги. Сегодня мы рассмотрели три закона:- Первый закон экологии, который учит нас, что маленькие события могут приводить к большим последствиям. Поэтому, работая с людьми, стоит действовать вдумчиво и аккуратно, а не ломать дрова. Более того, стоит самому проявлять внимание к маленьким неопределенностям, прояснять их и строить продуктивные и дружелюбные отношения. И это требует от нас определенной степени сознательности.
- Этика пластической хирургии научила нас, что лучше начинать с малого, но всегда доводить до конца. Не стоит хвататься за все проблемы разом, потому что так мы не исправим ничего. И такой подход тоже требует сознательности и обдуманности при принятии решений. Особенно, при локализации решений до действительно необходимого минимума.
- Первое правило йоги учит нас, что мы сами отвечаем за свое состояние. Оно учит нас заботиться о себе, прислушиваться к своему внутреннему состоянию. Йога — это в принципе про сознательность и рефлексию, это уже очень высокая степень осознанности.
Если вдуматься, то в мире, в принципе, нет профессий, где склонность пороть горячку и ломать дрова была бы хорошим качеством. Есть такая поговорка: «Худшее время для решения что поесть — когда ты уже голоден». Аналогично можно сказать про стресс: «Худшее время для решения как действовать — когда ты уже в стрессе».
Оказавшись в сложной ситуации, позаботьтесь о том, чтобы у вас была возможность спокойно подумать, оценить ситуацию целиком и только потом перейти к действиям. Если вы дадите себе возможность спокойно рефлексировать, то все нужные мысли придут к вам в голову сами. На этом у меня все. Спасибо, что дочитали!
Закалка тимлида: как вывести проект из пожара, не сгореть самому и не спалить команду
Итак, у вас на руках «полыхающий» проект — сроки задержаны настолько, что заказчик всерьез задумывается о закрытии проекта. Или регулярно взрывающийся production не дает сфокусироваться на новых...
habr.com