3 подписчика
Относиться к легаси-процессам так же, как к легаси-коду
Согласно прямому переводу, легаси, это то, что досталось нам в наследство. Не всегда это что-то устаревшее и сложно-поддерживаемое. Но всегда не до конца понятное. А, значит, нам страшно что-то трогать, чтобы оно не сломалось. Обычно мы называем так систему, модуль, блок или класс, который был спроектирован до вас. Часто нам кажется, что спроектирован плохо, из-за того, что мы не знаем предпосылок к принятию тех или иных решений. Сюда может относиться и ситуация, когда проект сделан на устаревших или плохо понятных команде технологиях. Ведь, несмотря на понимание работы на уровне бизнес-фич, команда может не понимать, что происходит «под капотом». Ошибкой будет называть «легаси» просто плохой код. Или код, который когда-то был нужен для чего-то одного, а теперь используется для другого.
А что с процессами? Абсолютно то же самое. Если есть какой-то процесс, цель и предпосылки к проектированию которого утеряны, то это легаси. Например, вы пришли в команду, где запланирована еженедельная встреча «Ретроспектива», на которой обсуждаются то текущие проекты, то происходит публичный код-ревью, то происходят архитектурные споры. Первое желание, которое у вас будет — убрать такую встречу, ведь вам непонятно зачем ее сделали и какую проблему она решает. Но будет и страх: а вдруг команда, все же, потеряет что-то ценное. Вот он — настоящий легаси процесс.
Другой пример. В команде, куда вы пришли, по каждой маленькой фиче пишется огромный дизайн-документ. Включающий в себя не только предпосылки к ее реализации, но так же и исследование всех возможных решений. При этом даже самая мелкая правка занимает недели. Возможно, этот процесс избыточен, но вы не уверены до конца, ведь не знаете весь командный контекст.
Любой процесс, который непонятен и кажется не эффективным попадает в эту категорию. Ежедневный утренний стендап на полтора часа, внутри командный архитектурный комитет, код-ревью всей командой, написание ридми для каждого сервиса, согласование каждой новой ручки с ИБ и так далее. Я вовсе не говорю, что эти процессы плохие. Они могут быть как полностью бесполезны, так и жизненно необходимы — все зависит от конкретной компании, команды и деталей реализации. Я предлагаю не выбрасывать такие процессы сразу. Но и не сохранять их, как карго-культ. А отнестись так же, как мы относимся к легаси-коду.
Изолировать
То есть взять под контроль все внешние взаимодействия. Если отнестись к любому процессу, как к блек-боксу, то станет очевидно, что у него есть что-то на «входе» и что-то на «выходе». Вот эти входные и выходные артефакты и решения стоит описать. Обсудить с командой и взять под контроль.
Покрыть тестами
Тестом процесса может быть и просто ответ на вопрос «что мы получили», и сравнение форматов артефактов, и анализ соответствия ответа на «зачем мы это делаем» реальному результату. Для начала стоит убедится, что при одинаковых данных на входе — мы получаем известный результат на выходе. Иначе, мы не учли влияние еще какого-то фактора. После этого можно сделать результаты более очевидными. Например, складывать все артефакты в одном месте и проверять, что они одного формата. Нужны и интеграционные тесты — как процесс влияет на общие показатели. Далее можно протестировать краевые случаи, перфоманс процесса, устойчивость к изменениям, например, к отпуску ключевого сотрудника.
Изменять
Только после этого, я предлагаю приступать к изменениям. От сокращения времени на встречу, до полной отмены код-ревью. Важно, что за счет покрытия тестами, мы не потеряем результаты процесса. И увидим его влияние на общие показатели. Плавно, не значит медленно. Со всеми пунктами вполне можно уложиться в две-три итерации процесса.
Хорошо изолированный процесс можно не трогать несколько месяцев и не боятся, что он сломается сам по себе. Хорошо покрытый тестами, можно менять, не опасаясь неожиданных последствий. Ну а плавный подход к изменениям поможет убедиться, что это действительно имело смысл и не имеет негативных последствий.
3 минуты
28 июня 2023