Выбор архитектурного подхода зависит от задачи, а не от моды на технологии. Для небольшого портала или отдельного блока подходит простая структура с минимумом сервисов, для крупной системы с несколькими ролями пользователей и десятками сценариев — более модульный подход, при котором отдельные части можно развивать и обновлять независимо друг от друга.
Хороший пример продуманной архитектуры — личный кабинет агента и клиента страховой компании «Дело Жизни». Агенты продавали полисы «в поле» и собирали данные клиентов в Excel-файлах — раздельно и без единой логики. Мы спроектировали систему так, что 90 % функциональности настраивается из административной панели без участия программистов: новые статусы договоров, поля анкет и сценарии агент может добавлять сам. От старта проекта до запуска прошло 6 месяцев, а решение получило награду Workspace Digital Awards.
Архитектуру мы всегда обсуждаем с заказчиком на этапе аналитики: рассказываем, из чего складывается система, какие есть ограничения и точки роста, чтобы решение по стеку и структуре принималось осознанно, а не постфактум.
Отдельная задача архитектуры — заранее продумать интеграции. Личный кабинет и мобильное приложение почти никогда не живут отдельно от остальной IT-инфраструктуры компании: их нужно связать с 1С, CRM, платёжными сервисами или внешними системами учёта. Если эти связи не заложены на этапе проектирования, а добавляются потом, систему приходится частично переделывать — поэтому на брифинге мы отдельно спрашиваем, с чем ещё должна работать будущая система.
Вместе с архитектурой прорабатываем сценарии для каждой роли пользователей: агента, клиента, администратора, бухгалтера — у каждого свои задачи и свой набор экранов, и смешивать их в одном универсальном интерфейсе не имеет смысла. В личном кабинете «Дело Жизни» интерфейс агента и интерфейс клиента — принципиально разные экраны с разной логикой, хотя оба работают с одними и теми же данными о договорах. Такое разделение мы закладываем ещё на этапе прототипирования, до начала программирования, и проверяем на прототипе с реальными сценариями пользователей, прежде чем передавать макеты в разработку.
Разработка программного кода
Разработку мы ведём на реальном, проверенном стеке: для мобильных приложений — Kotlin для Android, Swift и Objective-C для iOS, Flutter для кроссплатформенных решений; для веба — PHP на серверной части, JavaScript на фронтенде, в отдельных проектах — Angular. Выбор языка и фреймворка обсуждаем на брифинге и привязываем к задаче: нагрузке, срокам, необходимости работать с функциями устройства. Нативная разработка на Kotlin и Swift даёт полный доступ к камере, геолокации и биометрии, а Flutter экономит бюджет, когда нужно выпустить приложение сразу на iOS и Android без двух отдельных команд.
Код пишет команда, которая знает контекст проекта от аналитики до релиза, а не подрядчик, получивший только техническое задание. Для личного кабинета ТСК Мосэнерго мы разработали систему с данными по счётчикам, автоматической генерацией и оплатой счетов и интеграцией с 1С и эквайрингом — такая связка требует аккуратной работы с данными на бэкенде, а не только удобного интерфейса на экране. Расчёт начислений, статус оплаты и передача показаний счётчиков должны сходиться без расхождений, а любая ошибка в этой цепочке напрямую превращается в звонок в поддержку — поэтому такую логику мы выносим в отдельные, тщательно протестированные модули.
Документация — обязательная часть разработки: она описывает функциональность системы, чтобы заказчик или новая команда могли развивать проект дальше, даже если через несколько лет потребуется расширение или доработка другими силами.
При работе с кодом мы используем систему контроля версий и регулярные код-ревью внутри команды: это не бюрократия, а способ держать качество кода одинаковым независимо от того, какой разработчик пишет конкретный модуль, и быстро находить проблемное место, если что-то в системе начинает работать некорректно.
Тестирование ПО
Тестирование идёт на каждом этапе разработки, а не только перед релизом. QA-специалисты проверяют не только то, что функции работают по отдельности, но и то, как система ведёт себя при реальных сценариях использования — с несколькими ролями пользователей одновременно, с большим объёмом данных, при плохой связи у мобильных пользователей.
Отдельное внимание — сценариям с деньгами и документами. В личном кабинете ТСК Мосэнерго автоматическая генерация и оплата счетов проверяется особенно тщательно: ошибка в расчёте или интеграции с эквайрингом напрямую бьёт по деньгам клиента и по доверию к системе. Для решений вроде личного кабинета «Дело Жизни» мы дополнительно проверяем сценарии для агентов «в поле» — на медленном мобильном интернете, с прерыванием соединения.
После выявления ошибок тестирование повторяется до тех пор, пока система не станет стабильной, а не считается формально пройденным после одного прогона. Это увеличивает срок разработки на старте, зато сокращает количество инцидентов после запуска — именно там, где цена ошибки для бизнеса выше всего.
Мы тестируем и то, как система ведёт себя при первом реальном использовании: например, при переносе данных из старых Excel-файлов или таблиц в новую систему — как это было при запуске личного кабинета «Дело Жизни», когда агентам нужно было перенести накопленную клиентскую базу без потерь. Миграция данных — отдельный этап, который мы всегда закладываем в план проекта заранее, а не решаем по остаточному принципу в последний момент: потерянная или задвоенная запись о клиенте на старте работы новой системы стоит бизнесу заметно дороже, чем лишний день на аккуратный перенос.
Управление проектами разработки
Управление проектом начинается с заявки и брифинга: фиксируем задачи, сроки и критерии приёмки. Дальше — концепция: состав работ, архитектура, оценка — и старт после подписания договора. Внутри проекта мы работаем итерациями: показываем промежуточные результаты, а не только финальную сдачу, чтобы заказчик мог скорректировать направление, пока это не стоит переделки всей системы.
Роли в команде распределены чётко: менеджер проекта координирует работу аналитика, дизайнера, разработчиков и тестировщика, отслеживает сроки и бюджет и остаётся основной точкой контакта для заказчика на всём протяжении проекта. Для проекта «Дело Жизни» такой подход позволил уложиться в 6 месяцев от старта до запуска — несмотря на то, что систему нужно было построить с нуля и настроить интеграции для агентской сети.
Модель сотрудничества выбираем под проект: Fixed Price для чётко описанной первой версии, Time & Materials — когда требования уточняются по ходу разработки, Retainer — для систем, которые нужно постоянно развивать выделенной командой. На брифинге мы обсуждаем не только задачу, но и то, какая модель управления подойдёт вашему проекту лучше всего.
Отдельный принцип управления — прозрачность хода работ. Заказчик видит прогресс по задачам, а не получает отчёт только в конце этапа: это позволяет вовремя заметить, если приоритеты сместились, и скорректировать план без потери времени и бюджета. Для проектов вроде ТСК Мосэнерго, где система напрямую связана с деньгами клиентов через оплату счетов, такой контроль на каждом шаге особенно важен — цена управленческой ошибки здесь выше, чем в обычном портале с информационным контентом.
