Есть одна идея, которую я часто рассказывал инженерам в последнее время, и я думаю, что она заслуживает более широкой аудитории.

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

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

Важно понимать, каким видом работы вы занимаетесь в данный момент, и думать о
ней соответственно.

Пожары

Когда вы тушите пожар, ваша цель — потушить пожар. Вы хотите совершить минимальные необходимые усилия, чтобы уничтожить огонь и вернуться к долгосрочной стратегической работе. Вы не хотите строить большие сложные системы, которые останутся жить навечно, просто чтобы потушить пожар. Во время аварии вы делаете наколеночные, костыльные, "quick and dirty" решения. Это не значит, что вы должны делать плохую работу. Но вы не должны строить долгоживущую, высокоэффективную систему для тушения этого конкретного пожара.

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

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

Пример

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

Если бы думали о задаче в долгосрочной перспективе, вы возможно сказали бы: "Ну, нам нужна система отслеживания нагрузки на серверах. Мы должны тщательно выбрать хранилище, придумать, как будем обеспечивать точность измерений, как будем мониторить и тестировать систему. Потом нам нужен дизайнер интерфейсов, чтобы графики были понятны пользователям. Понадобятся стандартные пользовательские исследования, и на их основе можно будет спроектировать интерфейс."

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

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

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

Никогда не принимайте долгосрочных решений и не реализуйте стратегические штуки во время пожара.

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

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

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

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

Стратегическая работа

Другой конец спектра (а это именно спектр, а не черно-белое деление) от "тушения пожаров" — это стратегическая работа. У вас есть известная цель, и вы работаете над ее достижением, применяя все принципы проектирования и разработки ПО, заботясь о долговременной перспективе, и вместе с командой выстраивая устойчивую и поддерживаемую систему.

И опять, если вы станете применять методы "тушения пожаров" к стратегической работе, вас ждет катастрофа. Если вы относитесь к каждому проекту как к чрезвычайной ситуации и будете делать его наколеночно/костыльно, потому что он "нужен завтра" (хотя на самом деле нет), все превратится в хаос. На самом деле вы создадите новые пожары! Ваша система будет так плохо спроектирована, что она будет постоянно падать, создавать проблемы, ее будет невозможно поддерживать, и в конце концов все ваше время будет съедено тушением пожаров вокруг вашего плохо спроектированного бардака.

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

Стратегическая работа требует много таких соображений: "Окей, мы понимаем ваши требования. Спасибо, что объяснили, в чем ваши проблемы. Мы построим решение для вас, мы сделаем это правильно, и это займет какое-то время. Не вечность, но какое-то время это займет."

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

Делать то и другое

Если вы применяете вышеприведенные принципы, одна команда (или один человек) может одновременно заниматься и стратегической работой, и пожарами (по крайней мере, в одну и ту же неделю или месяц). Хитрость в том, чтобы делать минимальную работу на пожарах, чтобы все неожиданности были обработаны и бизнес мог продолжать работу, а затем, когда пожары потушены, фокусироваться обратно на стратегической работе.

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

— Макс