Поддержка программного обеспечения, сопровождение и доработка

Поддержка программного обеспечения — это работа, которая держит продукт живым после релиза: исправление ошибок, обновления под новые версии платформ, наблюдение за сбоями, безопасность и развитие функций. JEEKSSHIRE 24 сопровождает свои продукты сама и берёт на поддержку проекты заказчиков, в том числе написанные другими командами. Начинаем с чтения кода и разбора того, что происходит на самом деле, а затем предлагаем понятный план.

Что входит в поддержку программного обеспечения

Сопровождение — не дежурство «на всякий случай», а регулярная работа с продуктом. Состав зависит от проекта, но обычно в него входит:

• исправление ошибок, найденных пользователями, сотрудниками или по оповещениям;
• наблюдение за работой: оповещения о сбоях, журналы, резервные копии и проверка их восстановления;
• обновление зависимостей и закрытие найденных уязвимостей;
• адаптация под новые версии iOS, Android, macOS, Windows и браузеров;
• доработка программного обеспечения: новые функции, экраны, интеграции и отчёты;
• выпуск сборок и публикация обновлений в магазинах приложений;
• поддержание описания того, как продукт устроен и как его выпускать.

Кому нужна поддержка и доработка приложений

Чаще всего к нам приходят с одной из четырёх ситуаций:

• продукт запущен, а команда, которая его делала, ушла или занята другим;
• приложение работает, но каждое обновление что-то ломает, и непонятно почему;
• нужно развивать продукт: новые функции, языки, платформы или интеграции;
• ОС, магазины приложений или платёжные сервисы поменяли правила, и продукт пора обновить.

Если продукт ещё только задуман, начните со страницы Разработка ПО на заказ или с разработки MVP: поддержку проще заложить с первого релиза, чем добавлять потом.

Как мы берём проект на сопровождение

1. Знакомство с задачей. Выясняем, что болит сейчас, кто пользуется продуктом и что считается сбоем.
2. Получение доступов. Репозиторий, серверы, магазины приложений, сервисы оплаты и почты — составляем список и проверяем, что всё действительно у заказчика.
3. Аудит кода и инфраструктуры. Читаем код, собираем проект с нуля, смотрим зависимости, резервные копии и то, как идут релизы.
4. План работ. Разделяем найденное: что чинить в первую очередь, что переписывать, а что лучше оставить как есть.
5. Наблюдение. Настраиваем оповещения о сбоях и резервные копии, чтобы о проблеме узнавали вы от нас, а не от клиентов.
6. Регулярная работа. Заявки, приоритеты и релизы идут по согласованному порядку; каждый релиз — только из зелёного состояния проверок.

Что получает заказчик

• продукт, который обновляется и не отстаёт от новых версий платформ;
• исходный код и права на него остаются у вас; доступы — на вашей стороне;
• актуальное описание того, как продукт устроен и как его выпускать;
• настроенные оповещения о сбоях и резервные копии;
• понятную историю изменений: что сделано, зачем и в каком релизе;
• одну команду для поддержки и развития, без передачи работы на сторону.

О том, что стоит проверить при передаче проекта и какие документы запросить, подробно написано в разборе Приёмка проекта и передача.

Наш пример: как мы сопровождаем свои продукты

У JEEKSSHIRE 24 больше десяти своих продуктов в проде, и все их обслуживает та же команда, что их написала. Поэтому поддержку мы знаем не по договору, а изнутри.

Wallet — кошелёк для оплаты иностранных цифровых сервисов на Mac, Windows и в браузере, на четырёх языках, включая арабский. Платёжный контур требует аккуратных обновлений: заказы исполняются через очередь со статусами и автоматическими возвратами, а суммы считаются на сервере.

Legal — редактор документов с ИИ, с версиями для Mac и Windows и интерфейсом на 184 языках. Каждое обновление проходит сборку, линт и тесты до выкатки, а настольные версии выходят рядом с веб-версией.

Сайт JEEKSSHIRE 24 мы тоже ведём сами: четыре языковые версии собираются генератором из одного источника, поэтому правка попадает во все языки без ручного переноса.

Типы работ: исправление, адаптация, улучшение, профилактика

В отрасли сопровождение принято делить на четыре типа. Они помогают договориться о приоритетах и о том, что считать срочным.

Если проект достался от другой команды: аудит кода и передача

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

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

Мы ищем причину проблемы, а не прикрываем её сверху. Поэтому код не обрастает заплатками, и стоимость поддержки со временем снижается, а не растёт.

Модернизация устаревшего ПО и обновление платформ

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

Сюда же относятся перенос приложения на новую версию iOS или Android, подпись и нотаризация настольных версий и добавление языков, включая вёрстку справа налево. Для настольных продуктов подробности — на странице приложений для macOS и Windows, для веба — веб-приложений. Если сомневаетесь, обновлять систему или заменить её готовым сервисом, посмотрите разбор Заказная разработка или готовое решение. Обсудить ваш проект можно через форму заявки.