Что делать клиентам в отсутствии технологической экспертизы

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

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

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

Два вида разрывов, которые создаёт сложность

1. Информационный разрыв между клиентами и командами разработки

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

• Что на самом деле делает команда?
• Почему “банальная” фича может внедряется месяцами?
• Как оценить адекватность бюджета необходимого на реализацию конкретного функционала или поддержку решения?
• Кому верить?

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

2. Дефицит компетенций у исполнителей

Спрос на e-commerce-разработку растёт, а число квалифицированных специалистов сильно ограничено. В итоге разработку зачастую ведут специалисты, которые делают свои первые шаги в создании сложных высоконагруженных систем: пишут первое в своей жизни подобное приложение, впервые выкатывают продукт в облако или сталкиваются с реальным Continuous Delivery. Даже давно известные подходы такие как ООП, SOA и CI на практике часто реализуются крайне посредственно. Многие команды учатся по ходу, а не применяют уже отточенные навыки. Как следствие — рост технического долга и падение качества.

В условиях технологической сложности клиент изначально находится в уязвимом положении. Исполнитель сознательно или неосознанно может скрывать свою неэффективность за фасадом сложности, в то время как клиенту приходится распутывать клубок технических терминов и аргументов. Чтобы разобраться в том, что именно ему предлагают, ему необходимо потратить время и усилия, которых у него часто нет. И даже в случае возникновения подозрений в адекватности предлагаемых решений у него нет объективных инструментов для оценки компетентности исполнителя. И таких примеров масса:

• Затягивание сроков: «Мы не можем внедрить дополнительный метод оплаты, пока не перепишем модуль биллинга». Но это может быть отговорка, за которой стоит неумение интегрироваться или ошибки в проектировании архитектуры решения.
• Переусложнение архитектуры: «Давайте внедрять микросервисы», в то время когда монолитная архитектура с запасом соответствует потребностям бизнеса и легче поддерживается.
• Обоснование бюджета: Чем сложнее стек — тем труднее заказчику понять, что реально важно, а что нет.

В результате компания платит не за создаваемую ценность, а за фреймворки, процессы и обещания. Это ловушка, особенно в проектах, зависимых от быстрого Time to Market.

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

Лучшее, что может сделать заказчик в данной ситуации, это сосредоточиться на результатах, а не на средствах их достижения.

• Привязывайте оплату к результатам, а не к обещаниям.
  Оплачивать функциональность, которую можно увидеть, использовать и проверить. Не платить месяцами за инфраструктуру, фреймворки и процессы без реального результата.
• Изучать внутренности проекта.
  Существуют доступные инструменты анализа качества кода. Если в проекте много копипаста, высокая сложность или методы на сотни строк — это плохой сигнал.
• Общаться со всей командой а не только с аккаунтом.
  Даже если отсутствует понимаете терминов, стиль общения подскажет, есть ли у команды понимание происходящего. Компетентность в большей степени требует не энциклопедических знаний, а умение учиться и адаптироваться. Главное чтобы обучение было осознанным, а не методом тыка.
• Требовать чётких ответов.
  В программировании много “чёрно-белого”: код работает или нет, сборка запускается на каждый коммит или нет. Размытые ответы — признак ухода от сути. Ответ «не знаю» — нормален. Ответ «возможно», «это зависит» без предложения вариантов или если всё сводится к «ну, это сложно» является отчетливым сигналом к тому, чтобы насторожиться.
• Делать независимый аудит
  Независимая экспертиза кодовой базы или архитектуры помогает вскрыть избыточность, дублирование, слабые места. Особенно полезно, если в планах масштабирование платформы или вероятность смены исполнителя.

Вывод

В e-commerce слишком много на кону, чтобы игнорировать разрушительное влияние сложности. Внимание к результатам, прозрачность в коммуникации и регулярная техническая валидация — вот инструменты, которые позволяют бизнесу управлять проектами, а не быть их заложником. Тот, кто держит фокус на бизнес-результатах, может выстроить более выгодные для себя условия, даже не разбираясь в тонкостях технологий.

Сложность не победить. Но её можно поставить себе на службу.