Новый сервис может сэкономить время, но через полгода стать системой, от которой уже не отказаться. Там будут жить данные, настройки, интеграции и привычный процесс. Уйти станет слишком дорого: нужно выгрузить информацию, восстановить связи, переучить людей и какое-то время оплачивать старую систему.
Разбираемся, какие три важные вещи стоит проверить до договора или пока идёт пилот.
Новый сервис может сэкономить время, но через полгода стать системой, от которой уже не отказаться. Там будут жить данные, настройки, интеграции и привычный процесс. Уйти станет слишком дорого: нужно выгрузить информацию, восстановить связи, переучить людей и какое-то время оплачивать старую систему.
Разбираемся, какие три важные вещи стоит проверить до договора или пока идёт пилот.
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Зависимость от сервиса растёт, когда в нём остаётся всё больше данных и решений, а путь наружу никто не проверял. NIST относит переносимость данных и приложений к ключевым условиям, которые помогают избежать привязки к конкретному поставщику. В дорожной карте NIST отдельно сказано о данных, метаданных, форматах и протоколах переноса между облачными сервисами.
Права на данные в договоре важны, но сами по себе не решают задачу. Команде нужно понимать, что она получит технически: записи, файлы, метаданные, связи между объектами, историю изменений. И в каком формате.
Попросите поставщика показать полный экспорт на пилоте. Лучше выгрузить тестовый набор самостоятельно, чем довольствоваться ответом «да, это возможно». Если для обычной выгрузки нужно писать в поддержку, это ограничение стоит учесть в решении и в договоре.
Слова «есть API» ещё ничего не гарантируют. Для работы с данными важны документация, ограничения по запросам, доступность нужных сущностей, массовые операции, вебхуки и правила изменения API.
На небольшом тестовом наборе лимиты могут быть незаметны. Проверьте выгрузку на объёме, близком к рабочему, и заранее оцените, сколько времени займёт перенос всей базы.
У подписки есть не только цена входа. В расчёт стоит включить настройку сервиса, перенос данных в будущем, время команды, параллельную работу двух систем и возможные платежи за экспорт или трафик.
До подписания договора зафиксируйте право на получение данных, формат выгрузки и срок доступа после окончания подписки. Так условия выхода станут частью решения о сервисе, а не темой для последнего дня контракта.
Команде нужно понимать, кто может сделать опасное действие и получится ли потом восстановить картину произошедшего.
SSO и двухфакторная аутентификация полезны, но они не показывают, насколько аккуратно разведены права. Проверьте отдельно экспорт всей базы, удаление данных, изменение настроек безопасности и управление пользователями.
Принцип минимальных привилегий означает, что пользователь получает только те полномочия, которые нужны для его задачи. Так его определяет NIST. Создайте на пилоте обычный и администраторский аккаунты, затем попробуйте выполнить чувствительные операции от имени каждого. Если разница между ролями почти не видна, риск придётся компенсировать дополнительными ограничениями или вынести в решение о выборе сервиса.
Журнал аудита нужен тогда, когда кто-то изменил критичное поле, удалил запись или выдал себе доступ. В стандарте NIST для систем, которые работают с контролируемой несекретной информацией, в запись аудита включают отметку времени, идентификатор пользователя или процесса, описание события и источник запроса. Там же предусмотрена защита журнала от несанкционированного изменения и удаления. Для обычного SaaS это полезный ориентир, а не обязательный универсальный набор полей.
На демо попросите показать конкретный сценарий: пользователь меняет критичное поле, а затем удаляет запись. Так вы увидите не название раздела в интерфейсе, а реальные события, срок хранения истории и ограничения тарифа.
«Поддержка 24/7» мало что говорит о критическом инциденте. Важнее, кто примет обращение ночью, как работает эскалация, когда подключается инженер и где всё это закреплено в договоре.
Проверьте поддержку на тестовых данных. Задайте технический вопрос или воспроизведите безопасный сценарий ошибки. Смотрите не только на скорость ответа, но и на то, понимает ли специалист контекст и предлагает ли рабочий способ решения.
У SaaS бывают сбои. Команде стоит заранее договориться, как она работает во время недоступности, а не выяснять это в день инцидента.
Сначала определите собственные требования к восстановлению. В руководстве NIST RTO — максимальное время недоступности до неприемлемого ущерба для процесса, а RPO — момент, до которого нужно восстановить данные после сбоя. Проще говоря: сколько времени команда готова работать без сервиса и какой период данных допустимо потерять.
Затем сравните эти требования с SLA, резервированием, резервными копиями и процедурами восстановления поставщика. Запишите, как команда продолжит работу при длительной недоступности — например, в течение восьми часов: где лежит последняя выгрузка, кто принимает решение и каким временным процессом пользуются сотрудники.
Демо показывает удобные сценарии. Пилот нужен, чтобы проверить границы сервиса.
За время пилота сделайте четыре вещи:
Эти действия займут меньше времени, чем последующая миграция, если сервис окажется неподходящим.
Пилот помогает проверить один сервис. Если нужно собрать требования от нескольких команд, сравнить поставщиков и объяснить решение руководителю, пригодится более системный метод.
Agile Technology Selection for Smarter Decisions на Coursera — семичасовой курс среднего уровня с 17 модулями и 17 заданиями. Он посвящён бизнес-кейсу, измеримым критериям успеха, совместной сценарной оценке, сравнению и переговорам с поставщиками.
Подойдёт продакт-менеджерам, ИТ-стратегам, специалистам по закупкам и другим участникам выбора технологии. Курс проходит на английском языке.
Software Product Management Specialization от University of Alberta — более широкий трек для тех, кто постоянно работает с продуктовым процессом. Это серия из пяти курсов примерно на четыре недели при нагрузке десять часов в неделю. В ней есть Agile-практики, требования, взаимодействие с клиентом и итоговый проект на реалистичных сценариях.
Достаточно базового понимания разработки программного обеспечения; опыт программирования не обязателен.
Точечно добрать отдельную тему можно на Udemy: управление продуктом, работу с поставщиками или выбор технологий. Такой формат пригодится, если не нужен длинный трек.
До подписания договора проведите тестовый экспорт и опишите, как команда продолжит работу при длительной недоступности сервиса. Эти две проверки быстро переводят разговор с поставщиком от впечатлений после демо к конкретным техническим и договорным условиям.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.