Закалка тимлида: как вывести проект из пожара, не сгореть самому и не спалить команду
Итак, у вас на руках «полыхающий» проект — сроки задержаны настолько, что заказчик всерьез задумывается о закрытии проекта. Или регулярно взрывающийся production не дает сфокусироваться на новых задачах, а то и спать по ночам. Или вы впервые видите этот проект, но вообще-то ему уже пара лет, просто изначальная команда куда-то пропала. Или все это произошло разом, а вы здесь чтобы с завтрашнего дня взять ситуацию в свои руки и за пару месяцев показать существенный сдвиг.
На прошедшей в апреле конференции 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. Выгорание, или первое правило йога
Вообще, предыдущие две части уже сильно помогут с вопросом выгорания. Если на проекте нет конфликтов, мы редко сидим в офисе до ночи, чувствуем, что занимаемся правильным делом и идем в нужную сторону — это уже сильно упрощает ситуацию. Но даже когда все хорошо, могут происходить ситуации, ведущие к выгоранию. Но что, если пожар закончился, но мы все равно периодически чувствуем, что подбираемся к опасной границе выгорания?
Прежде всего, давайте обсудим первое правило йога. Если вы придете на йогу как на духовную практику, то первым, про что вам расскажет мастер, будет правило «Ахимса»— или «невреждение, ненасилие», в том числе по отношению к себе.
Если же йога вас интересует как фитнес, то, придя в фитнес-центр, вы услышите от тренера лайфхак, который будет большим упрощением того же правила Ахимса:
Если при выполнении асаны у вас сжаты зубы — вы слишком стараетесь. И так вы рискуете травмироваться.
Какое это имеет отношение к выгоранию?
Во-первых, работая над проектом, как и в йоге, мы ни с кем не соревнуемся. Мы здесь находимся, чтобы сделать мир лучше, что себя сделать лучше. Поэтому не надо н
