Евгений Хренов — Заказная разработка и Vendor Lock

• Заказная разработка - удобный инструмент для привлечения экспертов и оптимизации стоимости разработки.  

• Вендерлок - бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика.  

• Признаки вендерлока: непрозрачность, сложность, юридические и политические трюки.  

• Особые условия в пользу одной из сторон контракта.  

• Блокировка привлечения других поставщиков.  

• Отсутствие ограничений на патенты, лицензии и права собственности.  

• Отсутствие условий передачи артефактов, знаний, он холт-периода.  

• Запрет на переход специалистов от вендера к заказчику.  

• Организация инфраструктуры: сурсконтрол, норидж, сервис инвай.  

• Доступ к исходникам, доменным именам, контрактам с поставщиками услуг.  

• Владение всей инфраструктурой.  

• Избежание доступа подрядчика в продакшн инвай.  

• Заказчик должен контролировать прозрачность и контроль над системой, чтобы избежать непрозрачности и локеров.  

• Прозрачность должна быть строго контролирована подрядчиком, даже если нет экспертизы.  

• Избегать экзотических решений, серебряных пуль, ноу-хау и моно-вендерских команд.  

• Избегать систем с непрозрачным взаимодействием компонентов.  

• Избегать внутренних конфликтов и оверкалифов.  

• Заказчик должен проводить внутреннее тестирование и приемочное тестирование.  

• Приемочное тестирование должно быть на стороне заказчика.  

• Заказчик должен знать, как работает его продукт и хранить базу приемочных тестов.  

• Заказчик должен согласовывать целевую архитектуру каждого релиза.  

• Заказчик должен понимать обоснование архитектурно значимых решений и вероятных альтернатив.  

• Заказчик должен выделять время на рефакторинг и баги.  

• Заказчик должен следить за кодом и проверять соответствие кода заявленным архитектурным диаграммам.  

• Заказчик должен планировать работы над снижением импакта от известных проблем.  

• Заказчик должен основывать гипотезы на метриках и статистических данных.  

• Заказчик должен прописать контракт о том, что архитектура должна строиться на основании стандартов разработки и инфраструктуры.  

• Архитектура должна строиться на стратегическом представлении концепта продукта.  

• Заказчик должен понимать, что если он передумал, он должен заплатить за это.  

• Заказчик должен согласовывать каждое решение, если оно укладывается в стратегическое представление продукта.  

• Компании, которые избавлялись от вендер-лока, контролировали ситуацию, нанимали экспертов и добивались прозрачности процессов разработки.  

• Важно владеть эксплуатацией, быть собственником оборудования и среды, отслеживать процессы интеграции компонентов и узкие места.  

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

• Сложность невозможно уничтожить, даже если декомпозировать систему на микросервисы.  

• Важно организовать свою инфраструктуру, автоматизировать процесс дипломмента и уметь заменять проблемный микросервис.  

• Если перемешивать вендеров, проектное управление должно быть на стороне заказчика.  

• Лучше всего согласовать формат работ подрядчика в виде рамочного договора с допниками на каждый релиз.  

• Важно автоматизировать тестирование и описать тестовый сценарий в допнике.  

• Если часть сервиса остается у заказчика, а часть у подрядчика, важно организовать поддержку пользователей и мониторить состояние сервиса.