Про "туннельное зрение" и том, почему чинить очевидные проблемы - не всегда хорошо. Одна из классных особенностей курса, который я тут пилю - это домашки, которые не про тесты "выбери правильный ответ" или задачи из цикла "напиши тест-план". Это про мысленные эксперименты и обсуждение того, как и почему можно действовать в тех или иных ситуациях. Я немного подробнее рассказывал про это в более ранних постах. Помимо того, что это в целом даёт пространство для мыслей "как можно" и "почему так", это ещё и подсвечивает разные интересные штуки, которые потом классно разбирать вместе с участниками. Про одну из таких штук и поговорим сегодня. Когда мы приходим на новый проект, вокруг нас обычно целое многообразие странных решений, проблем и всевозможного бардака. В ситуации, когда перед нами возникает очевидная проблема, у многих куа инженеров и лидов включается "туннельное зрение" - увидел проблему, сфокусировался на решении, не увидел всё остальное. Команда релизится без регрессионных и смоук-тестов. Вместо хоть сколько-то формализованных критериев качества - субьективные ощущения "вот сейчас кайф". Роли и зоны ответственности размазаны и вообще не понятно как применяются, и т.д. и т.п. Но что вообще плохого в том, что бы решать проблему, которую видишь (и в большом количестве случаев даже знаешь как решить)? Проблема в том, что здесь легко упустить ряд деталей. 1. Базовая база: а точно ли это вообще проблема? Возможно, дело не в том, что тот или иной подход плох, не работает и являет собой проблему, а в том что мы привыкли работать по другому, в то время как бизнес и команду это все полностью устраивает? Это не столько про мантру "работает - не трогай", сколько про то, что процессы могут быть разными, далеко не все что мы видим как "проблему" действительно является таковой. 2. А почему это работает именно так? Зачастую мы - далеко не первые в компании, кто увидел эту проблему и пытался её решить. Существующий процесс это не просто какой-то бардак, который никто раньше не замечал, а результат Н-ного количества попыток решения проблемы (или других проблем). Возможно, у команды просто не было кого-то, кто точно знал как решить проблему (а мы то точно знаем). Или мы упускаем какие-то детали контекста и происходящего, которые мешают сделать лучше. 3. А точно ли эту проблему нужно решать? Существующие решения создают риски и ограничения - это плохо масштабируется, это даёт слабую прогнозируемость результатов и т.д Вместе с этим они могут нести и бенефиты, ценные для компании и команды. Моментальные деплои без каких-либо регрессионных проверок могут уронить продакшен, но дают возможность быстро проверять гипотезы и собирать фидбэк на реальных данных. Неформализованные критерии качества делают процесс непрозрачным и сложно масштабируемым, но дают возможность опираться на "видение" и экспертизу участников, которые могут быть конкурентным преимуществом. Профит от "кривых" процессов может легко перевешивать все минусы и риски, которые они несут. Решение, которое будет срезать и то, и другое - нанесёт больше вреда, чем пользы. 4. Нужно ли эту проблему решать сейчас? Есть ли менее очевидные, но более болезненные точки процессов, заслуживающие больше внимания? Имеет ли это значение сейчас или будет актуально через два года, а сейчас и так нормально? Готова ли команда менять этот кусок процессов и в том масштабе, в котором это кажется нужным? Как это мэтчится с тем, что от нас ждёт команда и бизнес? Любая лидершип роль - это не только про способность "придумать", спроектировать и внедрить решения. Но и про умение действовать в условиях существующих ограничений, расставлять приоритеты и грамотно их обосновывать. Поэтому "действительно ли нужно это делать сейчас" - не менее важный вопрос, чем "как эту проблему решать". Всё это не значит что решать очевидные проблемы - плохая практика и лучше поискать что-то менее "бросающееся в глаза". Часто эти проблемы - хорошая отправная точка для дальнейших изменений. Но здесь