Про активность 🚀 Достаточно часто проекты с историей производят впечатление полного трешака в коде и архитектуре. А ведь ещё пару-тройку лет назад это были проекты «с нуля», но чуда почему-то не произошло. И хотя команда имела все шансы применить лучшие практики, но так ими и не воспользовалась. В результате даже простые доработки происходят с трудом, а количество инцидентов только растет. И причины у этого всегда одни и те же. 😎 Best practice для слабаков На всех собеседованиях спрашивают знание паттернов разработки и проектирования. Но вот когда дело доходит до реальных задач, то применять их зачастую не спешат. То же самое касается и процессов «здорового IT». Критически важные практики, например, груминги и ревью, игнорируются в надежде сэкономить время. В результате проект постепенно заходит в тупик. 😬 Не согласен, но промолчу Для принятия оптимальных решений важны командные обсуждения, где каждый высказывает свою точку зрения. При этом часто даже не согласные люди проявляют пассивность. Кто-то не хочет затрачивать энергию на убеждение коллег, а кто-то не верит в возможность повлиять на итоговое решение. В итоге риски принятия ошибочных решений значительно возрастают. 🥳 Будем жить дружно Это ещё одна вариация на тему осознанной пассивности, которая вопреки ожиданиям лишь вредит проекту. При этом основная мотивация здесь - сохранить хорошие отношения. Кто-то соглашается на любые сроки и требования бизнеса. Кто-то не оставляет комментариев коллегам на ревью. А кто-то не идет к смежникам с неудобными вопросами. В моменте это удобно, а в долгую - однозначто, фейл. 🫣 Моя доработка с краю Подход «и так сойдет» губителен для проекта вне зависимости от его причин. Самыми распространенными являются выгорание, желание быстрее сделать задачу, недооценка сложности, да и просто поверхностное отношение к работе. Подобный подход закладывает в проект бомбу замедленного действия, которая может проявить себя в самый неподходящий момент и привести к значительным потерям времени или денег. 🥱 Так исторически сложилось Такой ответ можно услышать на вопросы о работе "систем с историей". Понятно, что в их работе могут быть части, не покрытые документацией. Проблема в другом - как правило, такой ответ означает нежелание в этом разбираться. Логика примерно такова. Мы отвечаем только за свои доработки, а в том, что было до нас, разбираться не будем. Подобный подход приводит к инцидентам и багам из-за внесения доработок в функционал с не до конца понятным поведением. Вывод При работе над любыми проектами, как новыми, так и с историей, необходимо проявлять проактивность. Компромиссы же в этих вопросах будут стоить командам большого количества времени, нервов и сил. Поэтому ни в коем случае не стоит поддаваться иллюзиям, что пассивность - это выигрышная стратегия. В реальности все получается с точностью до наоборот. Часто ли вы сталкиваетесь с подобным на проектах? TeamLead говорит | Александр Романов