7 Кругов IT-Ада

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

1. Круг: Бездна Архаичных Знаний

Грех: Гордыня основателей («Только мы понимаем эту магию!»)
Пытки:

• Новые рабы (разработчики) 3 месяца расшифровывают древние скрижали (код без документации)

• Каждый баг — ритуал вызова духов (разбор кода с оракулами-старожилами)

• Уход одного «жреца» парализует всю систему

Надпись на вратах: «Оставь надежду, всяк сюда входящий без git blame»

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

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

Не стоит пытаться обернуть в документацию все. Зачастую требуется достаточный минимум для вашего проекта. Критерием достаточности может стать вопрос «Если завтра я уйду в отпуск/заболею/уволюсь, смогут ли другие разобраться с моей работой без меня?»

2. Круг: Река Забвения (Онбординг)

Грех: Лень систематизировать знания
Пытки:

• Новички блуждают в лабиринте переписок в почте, чатов и устаревших wiki-страниц

• Наставник говорит: «Просто посмотри, как мы это делали в 2018-м» (коммит удалён)

• 50% новобранцев бегут, не выдержав когнитивного диссонанса

Особенность: Воды реки стирают память — через месяц стажёр забывает, зачем он здесь

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

У вас может быть мудрый наставник, который расскажет о всех перипетиях проекта, но для этого придется, во-первых, отвлечь его от текущей работы, а во-вторых есть ненулевая вероятность, что данный процесс придется повторять многократно. Для начала стоит обратиться к предыдущему пункту по поводу документации. Это может очень сильно упростить вход нового сотрудника.

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

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

3. Круг: Вулкан Хаотичных Деплоев

Грех: Жадность (экономия на DevOps)
Пытки:

• Полночные ритуалы (ручные деплои через ssh, а еще лучше ftp)

• Жертвоприношения (rollback последней рабочей версии)

• Хор демонов (оповещения в Sentry) звучит без остановки

Лозунг круга: «Сначала задеплоим — потом помолимся»

Споры, разговоры и дискуссии на эту тему не умолкают уже который год.

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

Не важно, выделено ли у вас для этого отдельное подразделение и отдельные специалисты, либо этим занимаются ваш ведущий разработчик с системным администратором, в вашей компании данный процесс есть и кто-то его взял на себя. Если релизы у вас происходят, но этим никто не занимается, значит просто вы не знаете кто именно это делает! И в тот момент когда вы вычислите, кто именно этот «невидимый герой», можно задаться вопросом «А достаточно ли качественно это происходит?» Если релизы и деплои происходят безшовно и незаметно для вас, а главное для конечного пользователя — возможно самое время похвалить людей которые это делают. Закажите им пиццу или просто скажите «Спасибо!» Если же каждый релиз превращается в игру в русскую рулетку с 5-ю патронами в барабане, то стоит обратить внимания на этот процесс. 

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

4. Круг: Чумной Город Техдолга

Грех: Алчность (быстрое зарабатывание любой ценой)
Пытки:

• Здания (классы) рушатся от легкого ветра (изменений требований)

• Чумные доктора (рекрутеры) шепчут: «У нас зп выше, но работать придётся здесь»

• Единственная аптека (команда рефакторинга) всегда закрыта «на спецоперацию»

Правила выживания: Не трогай старые стены (legacy-код) — чума вырвется наружу

«У нас никогда нет времени сделать нормально, но всегда есть время переделывать»

Любой написанный код становится Legacy в момент попадания в Git (либо сведения в мастер).

Все, что когда-то было «временным решением» и не было отрефакторено копит массу потенциальных проблем.
Извечный вопрос в том, что бизнес всегда будет хотеть больше, быстрее и «вчера», а команда, в попытке сделать если не «идеально», то «хорошо», тратит больше времени. По этой причине большинство MVP и прототипов становятся рабочими версиями и обрастают функционалом, хотя изначально не были рассчитаны на это. 

Зачастую на этом этапе основными защитниками команды и здоровья проекта должны выступить СТО с отрядом тимлидов и донести бизнесу важность рефакторинга.
Одним из вариантов является выделение определенных ресурсов команды для систематического решения проблем с техдолгом.
Возможно выделить отдельных специалистов, но в таком случае вы имеете риски того, что эти люди будут жить в отрыве от основной команды и процесса разработки, что повлечет за собой неактуальность их изменений.
Для начала договоритесь сколько времени от общего пула вы готовы тратить на техдолг. По своему опыту скажу, что желательно, чтоб эта цифра была в разрезе 10-20% от общего объема работ команды в случае запущенности проекта.
Есть вариант не доводить до критической массы объем техдолга, но для этого должна быть высокая техническая культура и регулярная гигиена проекта.

5. Круг: Логово Героя-Одиночки

Грех: Зависть («Я сделаю это лучше всех!»)
Пытки:

• Единственный рыцарь (senior dev) сражается с драконом (продакшн-багами)

• Остальные томятся в темнице (ждут code review 2 недели)

• Когда рыцарь падает (увольняется) — королевство (компания) погружается во тьму

Надпись на щите: «Системы? Нет, только мой меч (спагетти-код)»

К сожалению, подобная ситуация встречается во многих компаниях. Причины возникновения разные, но все они основаны на организационных и структурных ошибках и нежелании исправлять их последствия.
В первую очередь стоит определить в каких точках происходит эффект «бутылочного горлышка» для процессов. Можно ли делегировать решение этих вопросов? Каким образом можно распределить знания между всему участниками команды?
Если этот вопрос оставить без внимания, то вы получите bus-фактор во всей его красе.
Конечно еще ни одна, хоть немного стабильная компания не закрылась после ухода одного сотрудника. Но в любом случае это даст большую просадку в производительности на какой-то период времени.
А хуже Героя-Одиночки только Герой-Одиночка осознавший свою незаменимость. В таком случае высока вероятность роста токсичности и тирании с его стороны, что еще больше усугубляет ситуацию.

6. Круг: Болото Бесконечных Митингов

Грех: Чревоугодие (пожирание времени)
Пытки:

• Пленники (разработчики) тонут в трясине (ежедневных 4-часовых планерках)

• Тени (менеджеры среднего звена) проводят ритуалы (роадмапы на 5 лет вперед)

• Единственная пища — грибы (Jira-тикеты), растущие прямо на болоте

Закон болота: «Чем дольше обсуждаем — тем дальше дедлайн»

«Лучший митинг — тот, которого не было»

Стремление к большому количеству созвонов и митингов присуща многим компаниям. 

Одним из способов донести их бесполезность и нецелесообразность — обратить внимание на их стоимость. Если вы собираете 10 дорогостоящих сотрудников для выбора дизайна кнопки, то эта кнопка автоматически поднимается в цене в разы. Соберите варианты и направьте их письмом, а после создайте опрос «Какой из вариантов вам больше понравился» Регламентируйте встречи по времени, используйте адженду, назначайте на каждую встречу ответственного фасилитатора. То время пока длится встреча все участники могли выполнять свои обязанности и принести больше пользы общему делу. Еще один хороший инструмент «Дни тишины». Понятное дело, что для того же проджект-менеджера это неприемлемая техника, но разработчику это даст «глоток свежего воздуха» и время спокойно поработать. Касаемо же «роадмапов на 5 лет вперед» — мало в какой компании это применимо на самом деле, так как бизнес это подвижная среда и обстоятельства могут меняться каждые несколько месяцев.

7. Круг: Ледяное Озеро Тщетных KPI

Грех: Лицемерие («Главное — отчитаться!»)
Пытки:

• Демоны (топ-менеджмент) заставляют считать песчинки (ненужные метрики)

• Ветер (отчётность) вымораживает душу (креативность команды)

• На дне озера — скелеты проектов, «выполнивших KPI, но провалившихся»

Надпись на льду: «Здесь замёрзли все, кто верил в то, что мы поменяем мир»

А что вы меряете в своих метриках? Результат или объем усталости? Ваша цель работы результат или достижение метрики?
Лучшая профилактика — не доводить до состояния, когда KPI становятся самоцелью. В здоровой корпоративной культуре метрики — это как приборная панель в самолёте: они не управляют полётом, но помогают вовремя заметить проблемы. 

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

Хороший тест — спросить: «Если этот показатель изменится, какой конкретный результат мы получим?». Если ответа нет — метрику в утиль. Выделите 20% времени аналитиков не на сбор данных, а на их осмысление.

Путеводная звезда для грешников

Чтобы избежать вечных мук:

1. Оживите знания (документируйте, комментируйте код, проводите knowledge sharing)

2. Постройте мосты через реку (структурированный онбординг)

3. Укротите вулкан (CI/CD, автоматизация)

4. Разрушьте чумной город (регулярный рефакторинг)

5. Создайте армию вместо героев (перекрестное обучение)

6. Осушьте болото (time management для митингов, не нужно создавать «еще одну встречу, которая могла быть письмом»)

7. Растопите лёд (осмысленные метрики вместо отчётности ради отчётности)

P.S. Если узнали свой офис — возможно, вы уже в аду. Но выход есть — только через чистилище реформ и планомерную работу над ошибками!