Разработка и сопровождение ПО

Разработка и сопровождение ПО в голове заказчика часто склеены в одно: «сделайте и чтобы работало». В договорах это разные обязательства. Разработка создаёт согласованный контур. Сопровождение сохраняет его живым, когда меняются ОС, API банков, налоговые форматы, сотрудники и объём данных. Без сопровождения даже отличный релиз через год становится хрупким экспонатом.

Статья для тех, кто запускает внутреннюю систему, клиентский кабинет или приложение и думает, что поддержка «как-нибудь сама». Не сама.

Зачем сопровождение, если «мы уже приняли акты»

Потому что окружение не подписывало ваш акт. Магазины требуют новые API. Браузеры режут cookie. 1С обновляется. Сертификаты истекают. Библиотека получает уязвимость. Сотрудник теряет телефон с сессией. Сопровождение — это очередь таких событий плюс мелкие улучшения, которые нельзя копить год до «большой фазы 2».

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

Что обычно входит в пакет поддержки

• Канал заявок и регламент приоритетов: простой / деградация / вопрос.
• Исправление дефектов в принятом контуре.
• Обновления зависимостей и закрытие известных уязвимостей по согласованному окну.
• Мониторинг доступности и ошибок, если это включили в объём.
• Консультации администраторов заказчика.
• Мелкие доработки в лимите часов — с явной фиксацией, что вышло за лимит.

Не входит по умолчанию новый модуль, новая интеграция, переписывание с нуля, обучение всей компании продажам, контент-маркетинг. Это отдельные оценки. Путаница «поддержка должна сделать маркетплейс» разрушает и SLA, и дружбу.

Модели: часы, подписка, дежурство

Пакет часов гибок, но заканчивается в самый жаркий месяц. Подписка спокойнее для планирования, если объём предсказуем. Дежурство 24/7 дорого и нужно не всем: складу в одну смену достаточно рабочего окна. Выбирайте по цене простоя, не по статусу «как у банков».

Для приложений в сторах в пакет часто входят сборки под новые iOS/Android и ответы модерации. Без этой строки «сопровождение сервера» не спасёт клиент, который не ставится на новые устройства.

Передача в сопровождение: чек-лист

1. Репозиторий, ветки, CI, доступы у заказчика.
2. Инструкция деплоя и отката.
3. Карта интеграций и владельцев с той стороны.
4. Список секретов в менеджере, не в чате.
5. Бэкапы и проверка восстановления хотя бы раз.
6. Известный долг: что отложили сознательно.

Если этого нет, сначала аудит и инвентаризация, потом SLA. Иначе вы подписываете ответственность за чёрный ящик. Безопасность контура — безопасная разработка ПО.

Ошибки заказчика в поддержке

Молчать о инцидентах неделю и требовать «вчера». Вести доработки в обход бэклога голосом директора. Не давать доступ к логам «из соображений секретности» и одновременно требовать мгновенной диагностики. Не обновлять контент и винить систему. Смена приоритетов каждую неделю без пересмотра лимита часов.

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

Когда сопровождение не нужно

Не нужно для одноразового лендинга акции, который сознательно выключат. Не нужно, если система законсервирована и нет пользователей. Не нужно покупать 24/7 на внутренний календарь совещаний. Нужно честно назвать режим: «архив» или «живая эксплуатация».

Следующий шаг

Оцените цену простоя главного сценария. Соберите чек-лист передачи. Разделите в бюджете «новые функции» и «жизнь системы». С этим разговором оценка поддержки становится предметной.

Обсудить контур разработки и ведения — Grevin, grevin.info@mail.ru, контакты. Услуги: ПО, приложения.

Инциденты: как не тушить всё как «горит»

Сопровождение без приоритетов превращается в вечный аврал. Критично: простой главного сценария, утечка данных, порча финансовых документов. Средне: деградация скорости, ошибка редкой роли. Низко: косметика, пожелание «было бы удобно». Если директор всё метит красным, красное обесценивается и команда выгорает. Таблица приоритетов — часть договора, не «давайте по ситуации».

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

Обновления, окна и страх «сломать прод»

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

Зависимости с истёкшей поддержкой — отдельный риск сопровождения. Их надо видеть в бэклоге как техдолг с ценой, не как стыд. Иначе однажды обновление станет проектом разработки, хотя в бюджете была только «поддержка».

Мониторинг, который полезен, а не шумит

Считайте ошибки, время ответа, длину очереди, доступность критичного URL, падения мобильного клиента. Не собирайте 400 дашбордов «на всякий случай». Алерт должен будить человека, который может починить, и не должен орать на каждую 404 от бота. Раз в квартал чистите алерты: иначе дежурство их игнорит.

Логи без персональных данных в открытом виде. Ротация. Доступ по ролям. Это пересекается с безопасной разработкой и не является «роскошью для банков». Утечка логов из панели мониторинга — частый бытовой инцидент.

Как сменить подрядчика сопровождения без простоя

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

Услуга создания контура — разработка ПО, клиенты — приложения. Закупка поддержки без аудита — лотерея. Аудит как отдельная услуга честнее «сразу SLA на неизвестное».

Дорожная карта техдолга в сопровождении

Сопровождение без видимого техдолга врёт. Заведите список: устаревшие библиотеки, ручные деплои, места без тестов, скрипты «на сервере у Василия». Каждому элементу — цена риска и оценка работ. Раз в квартал выбирайте кусок в лимит часов. Иначе долг всплывёт как авария и съест весь пакет поддержки плюс нервы директоров.

Заказчику этот список нужен не чтобы ругать команду, а чтобы понимать, почему «просто поменять текст» иногда требует обновления платформы. Прозрачный долг снижает подозрения в саботаже. Непрозрачный долг рождает желание сменить подрядчика, что само по себе проект. См. передачу контура выше и выбор подрядчика.

Обучение второй линии и документация для людей

Сопровождение устойчиво, когда не один человек умеет выкатить релиз. Короткие инструкции: откат, продление сертификата, повтор очереди, как отличить простой банка от бага. Запись экрана на 10 минут полезнее романа. Нового администратора заказчика прогоните по чек-листу на стенде, не на проде в пятницу.

Документация API для смежных команд — часть ведения, если у вас несколько подрядчиков. Протухшая спецификация плодит интеграции «как получится». Обновляйте её вместе с релизом, не «когда-нибудь в Confluence». Это стык с проектированием.

Финансы сопровождения: предсказуемость против сюрпризов

Пакет часов с отчётом по задачам подходит, когда объём прыгает. Фикс в месяц — когда система спокойная и вы хотите предсказуемый P&L. Смешение без правил («фикс, но мы ещё вот это») снова спор. Вынесите крупные доработки в отдельные оценки. Пользователь не обязан понимать разницу — обязан понимать владелец продукта на вашей стороне.

Инфраструктура (хостинг, SMS, карты, пуши, мониторы) — отдельная кубышка. Путать её с часами разработки опасно: внезапно «поддержка подорожала», хотя подорожал трафик карт. Разделяйте счета. Для клиентских приложений сюда же лицензии сторов и устройств теста. Ориентиры создания — сколько стоит создать приложение.

Минимальный договор сопровождения на одной странице

Предмет: какие системы и какие среды. Канал заявок. Приоритеты и сроки реакции. Что считается новой разработкой. Лимит часов или фикс. Отчётность. Репозиторий и доступы заказчика. Окно обновлений. Порядок инцидента. Срок и выход: как забрать знания. Если страница не собирается, вы ещё не готовы покупать поддержку — сначала инвентаризация. Если собирается, можно сравнивать цены без самообмана «у них дешевле, потому что магии больше».

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

Когда сопровождение должно включать мобильные сборки

Если в эксплуатации есть клиент в сторе, пакет ведения без сборок — дырка. Новые iOS и Android не спрашивают ваш бюджет. Заложите окно на проверку на двух-трёх устройствах, подпись, модерацию, заметки релиза. Иначе «сервер жив, приложение не ставится» станет вашим инцидентом без исполнителя. Напишите это в предмете сопровождения явно. Клиентский процесс — процесс разработки приложений, создание — стоимость создания.

То же для сертификатов пуш и карт. Они истекают внезапно для тех, кто не завёл календарь. Сопровождение — это ещё и календарь секретов, не только баг-трекер. Без календаря вы узнаете об истечении от пользователей, не от мониторинга.

Сопровождение как очередь фактов, не как настроение чата

Каждая заявка: симптом, среда, роль, шаги, ожидание. Без этого дежурство гадает. С этим видно повторы и можно закрыть причину, а не симптом. Научите первую линию заказчика этому шаблону за час. Он окупается с третьего инцидента. Добавьте запрет править прод «по телефону без карточки». Иначе сопровождение снова станет героизмом Василия, а договор — фикцией. Шаблон — часть услуги ведения, его можно вложить в регламент с первого месяца.

Отчёт сопровождения, который можно показать директору

Ежемесячно: сколько инцидентов по приоритетам, что закрыто, что ушло в новую разработку, какой техдолг взяли, какие сертификаты истекают в горизонте 90 дней. Без этого «мы вас ведём» нельзя проверить. С отчётом услуга ведения становится наблюдаемой. Это короткий стандарт, его можно вписать в договор как форму, а не как эссе подрядчика.

Частые вопросы