За что хвататься первым? (TxG)
Вытаскиваю из живого ревью проекта. Вот есть проект, проект живой в продакшне, в проекте абсолютно точно бардак.
Какие три вопроса следует адресовать, и что конкретно получить, прям с самого начала анализа и погружения в разруливание бардака.
Я не могу палить детали проекта (NDA, как обычно), это живой чужой зарубежный проект, но могу поделиться подходом. Как бы я это делал, и почему так.
Первое: команда
Любой проект и продукт, вообще что угодно в этом мире, делают люди. Вот с людей и начнем. Какие у нас есть роли, какая у людей специализация. Какие зоны ответственности и экспертиза. Какой опыт. Как они принимали решения, и как собираются это делать в моменте — то есть, как устроена логика принятия решений в их голове и в существующей ситуации.
Есть ли у нас кто-то, кто принимал ключевые решения (какие? почему такие?), есть ли у нас вообще люди с экспертным знанием технического визионера «вот это мы будем делать вот так»? Потому что именно их решения сделали всю конструкцию такой, какая она есть сейчас. Это не хорошо и не плохо, пока что, потому что вот есть система — живая и работает, значит их технические решения и опыт вполне себя оправдали.
Лично мне потребуется для начала понять, с кем и как мы тут работаем. В то же время, с обратной стороны, люди должны тоже привыкнуть к практике и мысли, что кто-то задает им вопросы и — важно — искренне хочет их выслушать и услышать ответы. Правильных и «неправильных» ответов и вопросов на этом этапе не бывает (и об этом тоже надо людям донести).
Есть ли люди и команды, которым недостает экспертного знания, людей, возможностей? Каких, в какой связи и в какой сфере?
Есть ли какие-то части системы, где «лучше не трогать» и швабра держит потолок — иными словами, высокорисковые части, про которые знает команда (первый вопрос все еще про людей, а не про технику).
Какие-то слепленные части где на красных глазах (чьих) и бессонных ночах принимались какие-то ситуативные решения?
Как это всё проверяется, кем и в каких случаях?
В какую часть системы (и команды) потребуется для начала заглянуть поглубже и найти понимание с людьми — Саша М, привет! — чтобы лучше понимать логику и контексты. Что от кого можно ожидать, а что, напротив, нам не светит?
Что надо получить: ключевые акторы, зоны ответственности, важные и ключевые куски экспертизы. Записная книжка со списком, кто что знает и куда ходить (куда все ходят) в сложных случаях.
Потому что нам туда придется ходить. Зачем додумывать недостающее, если (для начала) можно просто пойти и спросить.
Второе: структура системы
Если со старта заявлено, что у нас бардак — логично, что актуальной документации или вовсе нет, или она не актуальная ни разу, или она где-то живет какими-то кусками. Если бы было всё просто и круто, меня бы не позвали. Но все-таки: какие у нас есть хотя бы очевидные части большой системы? Из чего она состоит, как внутри себя взаимодействует.
Есть ли у нее различные варианты, окружения, рабочие площадки / развернутая инфраструктура, какая. Как эти части были спроектированы — даже если они отрастали «естественным путем», все равно у него была какая-то логика и потребность. Если есть неочевидные решения, какой за ними бекграунд и идея, как так получилось — обычно тут расскажут важное.
Как в системе передаются знания о ее частях и решениях? Любой ответ годится. Вслух, в чатах, в вики, в ADR. В исходном рабочем коде, наконец. Кто выступает источником знаний, кто потребителем — и в каких ситуациях.
Операционная поддержка системы как организована, кем, и как выполняется? Есть ли процессы и инструменты относительно применения обновлений (выкатки изменений, деплоя), средства контроля на инфраструктуре? Чья она, кстати, в чьей зоне ответственности.
Как организовано управление изменениями. Как технические решения и рабочие артефакты становятся частью рабочего контура. Кем они оцениваются, проверяются на качество и на соответствие требованиям (есть ли review и какой). Какой вообще путь от абстрактной хотелки до конкретного живого финального изменения.
Если у нас «нет документации», это точно не катастрофа. Потому что вот, у тебя есть живая работающая система, максимально честный источник правды — потому что она живая и работает. А поскольку она работает, вот с нее и будем начинать.
Что надо получить: карта системы, или хотя бы «рисунок карты» (ц). Неидеальную, но уже стартовую модель взаимосвязей. С огрызками знаний и их источников, в тех местах где они есть. Чтобы потом дополнять недостающее и синхронизировать с реальностью (и прояснять мутные моменты, там-то всё важное и выяснится).
Третье: метрики и наблюдаемость
Как конкретно в любой момент мы узнаём (или должны узнать), что наша система работает нормально, и всё с ней хорошо?
Есть ли у нас какие-то инструменты для общей оценки этого факта. Мониторинг, алертинг, метрики производительности. Куда это всё смотрит, на какие данные полагается. В каком объеме. Есть ли там бизнесовые измерения (количество пользы в минуту), или это чисто технический мониторинг.
Для любого абстрактного изменения, как мы принимаем решение и как понимаем, стало нам жить лучше, или стало хуже?
Кроме бизнесовых метрик, есть ли какие-то части системы которые должны остаться живыми и работоспособными вообще в любой умозрительной ситуации — ? Как мы это узнаём? Есть ли SLA и граничные значения, что мы себе позволить можем, что не можем.
Как и в каких частях нашего зоопарка принимается решение о бизнес-приоритетах. Приоритет фич, приоритет стабильности, приоритет перфоманса, или (часто) какая-то мешанина из всего этого, с внутренней взвешенной балансировкой. Какой балансировкой, почему именно такой.
Что надо получить: по-хорошему инструментарий для оценки работоспособности — когда/если пойдем ломать, будем это делать не вслепую. В плохом случае ничего этого нет но, для старта, мы уже будем знать, «где конкретно этого нет» и значит надо прикрутить/сделать/заполучить. В совсем плохом варианте мы все равно получим список узких мест и бутылочных горлышек, которые ни фига не наблюдаемые, но объективно важны — потому что там болит. А это уже весьма дофига для старта.
Метрики, особенно бизнесовые, тесно связаны с бизнес-требованиями. Которые разумеется есть, и которые (также разумеется в бардаке) хрен где описаны. И это хорошая точка, чтобы начать их собирать в кучу, прописывать и нормально формулировать.
Если ребята разрешат, может еще что-то вводное-стартовое из их проекта вытащу, для наглядного примера.