Восемь рекомендаций по развитию архитектурного подхода в ИТ-команде
1. Смотреть на картину целиком
Главное правило, которое поможет мыслить с точки зрения ИТ-архитектуры: всегда выходите за пределы конкретных задач и даже текущего состояния проекта, думайте о перспективах его развития. Если проект реализуется в связке с каким-то другим, это необходимо учитывать. И даже если мы говорим про отдельные, абстрактно существующие ИТ-проекты, которые живут в рамках одного бренда или компании, основные принципы построения пользовательского пути в них должны сохраняться. Когда разработка не внутренняя, а заказная, на этапе подготовки погружайтесь в экосистему заказчика и комплексно анализируйте особенности их проектов, чтобы сохранить преемственность не только с точки зрения code-style, но и ряда логических блоков. Пример хорошо работающей экосистемы — «Яндекс», где все нужные данные автоматически подтягиваются в новом продукте и вам не надо по пять раз вносить номер своей платежной карты, чтобы, например, купить билеты в кино или оформить подписку на футбольные трансляции.
2. Ориентироваться на пользователя
Разработка всегда строится с фокусом на пользователя. Уже на этапе подготовки первичного брифа мы ставим себя на его место и продумываем весь пользовательский опыт. Если будете ориентироваться только на ТЗ, не сможете построить рабочее архитектурное решение. Это очень распространенная ошибка, особенно заметная в проектах, которые неожиданно становятся успешными и начинают масштабироваться или обрастать дополнительным функционалом. Из-за непродуманности они не обладают гибкостью и при любой модификации разваливаются или тормозят, вызывая раздражение из-за скорости работы и необходимости постоянно скачивать патчи. Мы, как и большинство команд заказной разработки, иногда сталкиваемся с тем, что расширение функционала проекта занимает раза в два больше времени, чем могло бы, если бы мы подумали заранее. Легче на старте проекта отвлечься от тз и предусмотреть возможный пользовательский сценарий, чем потом страдать от головной боли при очередной переделке всей топологии базы данных и системы логирования.
3. Строить прогнозы
Однажды при разработке проекта благотворительной инициативы мы с командой не учли возможный объем прямого трафика с главной страницы «Яндекса», потому что не ждали такого успеха. После этого случая я взял за правило всегда продумывать три возможных сценария нагрузки на продукты: оптимистичный, нейтральный и пессимистичный.
Не предусмотреть нагрузку на проекте и поймать большой кранч это, конечно, действенный способ навсегда запомнить, что жизнь приложения или сервиса не ограничивается моментом его запуска. Но можно избежать этого опыта, приучив команду думать, как проект будет жить и развиваться в дальнейшем. Как с точки зрения дизайна и пользовательского пути, так и с точки зрения логистики трафика и серверных мощностей.
Введите регулярные мозговые штурмы, чтобы предсказывать возможные проблемы и искать их решение. Прорабатывая архитектуру проекта, нужно всегда прикидывать, как сайт или приложение будет вести себя в любом из сценариев и исходя из этого масштабировать серверные и архитектурные решения.
4. Выстраивать коммуникацию
Почти всегда в работе над проектом участвует несколько смежных команд, и между ними очень важно настроить коммуникацию. Ошибкой будет думать, что каждый отдел отвечает только за свои конкретные задачи — на самом деле его внутренние решения могут спровоцировать проблемы в проекте, и, чтобы избежать этого, нужно заранее создать прозрачную коммуникацию. Например, при запуске рекламной кампании несогласованность маркетинга и ИT часто приводит к тому, что во время акций сайты компаний перестают работать из-за объема трафика, а это часто становится причиной потери лояльности к бренду. Такое происходит постоянно: сайт одного косметологического ретейлера упал на день Святого Валентина, сайты авиаперевозчиков каждый раз падают при старте распродаж, а порталы известных брендов регулярно ложатся во время очередного «дропа» лимитированной коллекции. Очень часто выдержать всю нагрузку бывает невозможно, но своевременная коммуникация помогает хотя бы минимизировать ущерб.
5. Работать над ошибками
Повторюсь, работа над проектом не заканчивается запуском. Сегодня проведение ретроспектив давно стало правилом хорошего тона, так же как закрытие задач в таск-трекере с понятными комментариями. Пренебрегать этой практикой — значит не иметь возможности получить качественную обратную связь по проекту. Мы с командой всегда проводим ретроспективы и анализируем объем и источники трафика. Этот завершающий этап не занимает много времени, но помогает сделать важные выводы, учесть ошибки и выработать правила, которые помогут в будущих проектах. Подобные встречи становятся еще эффективнее, если пригласить на них коллег из других отделов и обсудить, удалась ли коммуникация на проекте и что можно предпринять, чтобы улучшить ее в будущем. Главное здесь — придерживаться постулата «мы слушаем, но не осуждаем», чтобы встречи не скатывались в перепалку.
6. Помнить о данных
Уделяйте внимание данным, которые вы храните и обрабатываете в течение и после сдачи проекта. Это может быть информация о конкретном запуске, анализ экосистемы или знания о пользователе. Систематизируйте данные и сделайте их доступными для других подразделений. Это поможет избежать ситуаций, распространенных в финтех-компаниях: параллельные подразделения не делятся данными друг с другом и задают пользователям вопросы, на которые уже должны знать ответ. Например, мне регулярно звонят из банков и предлагают услуги, которыми я уже годами пользуюсь. Такие звонки самый короткий путь к потере лояльности клиента.
7. Проводить проверки
Моя практика показывает, что даже большие и проработанные проекты не застрахованы от утечки данных просто потому, что на этапе разработки не создается достаточное количество решений для защиты кода. Для перечисления всех случаев утечек не хватит этого материала - подобное случается повсеместно. Важно помнить о том, с данными какого рода вы работаете и какие риски они содержат не только для бизнеса, но и для приватности ваших пользователей. Все помнят крупный слив данных из «Яндекс.Еды», раскрывший информацию об адресах пользователей и повлекший множество проблем.
Отличное решение — устраивать в команде хакатоны и проводить багхантинг, мотивируя сотрудников искать слабые места проекта. Можно даже пообещать призы за поиск ошибок и предложить другим командам также присоединиться к проверке. Всегда лучше дать сотрудникам, лояльным компании, возможность все проверить и устранить проблемы до выпуска, чем потом столкнуться с недовольством пользователей.
8. Использовать наработки
Создайте внутренний репозиторий решений, которые можно повторно использовать на других проектах. Это могут быть элементы кода, техника, гайдлайны. Постоянно актуализируйте такую базу и обращайтесь к ней при работе над новыми проектами. Это сэкономит вам пару недель на решение некоторых задач, даже в случае разработки на заказ. Адаптировать и интегрировать существующие решения всегда быстрее, чем написать с нуля.
***
Выстраивание архитектурного мышления начинается на старте проекта. Изменения в работе происходят в момент, когда каждый член команды выходит за рамки своей конкретной задачи и узкой экспертизы, начиная воспринимать проект как сложную многоуровневую структуру. Такой подход не только позволяет создавать функциональные и продуманные работы, способные сохранять гибкость при масштабировании, но и характеризует вас и вашу команду как профессионалов, которые подходят с интересом ко всем проектам.
Опубликовано 01.04.2025
