Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [13]

В 2015 г. технический директор ING Тео Фризвейк обратился к нам за помощью в создании новой системы управления для контакт-центров. Тео руководит 40 инженерами, которые обеспечивают функционирование контакт-центров, используемых более чем 10 000 работниками службы поддержки ING по всему миру. На протяжении многих лет ING росла за счет приобретения банков. Все они использовали разные системы управления контакт-центрами. В общем, у ING оказалось 17 видов таких систем, разработанных разными софтверными компаниями. Поддержка этой мешанины превратилась в кошмар. «Девять месяцев в году нам приходилось заниматься разработкой обновлений просто потому, что поставщик перестал поддерживать старую версию ПО, а обновление одного компонента тянуло за собой обновление другого компонента, затем еще одного, и еще… и так до бесконечности», – говорит Тео.

Мало того, что такой букет устаревшего ПО был головной болью для инженеров-программистов, но это также означало, что 38 млн клиентов банка не обслуживались на должном уровне. Долгое время, когда существующее программное решение не имело необходимой функциональности, они реализовывали другое решение, в результате штаты контакт-центров ING непомерно раздулись. Руководство хотело, чтобы команда Тео выбрала одного поставщика решений для контакт-центров и сделала его единым для всей компании, но Тео предложил руководству другую идею: почему бы вместо покупки еще одной монолитной системы в надежде на улучшение ситуации не позволить его команде построить с нуля собственную систему для контакт-центров? Ее можно было бы достраивать по мере необходимости для решения возникающих проблем или для тестирования новых идей. Это потребовало бы вложения средств, но в конечном счете позволило бы ING стать более гибким, что как раз и было одним из главных приоритетов. Руководство ING поначалу отнеслось к предложению без особого любопытства, если не со скептицизмом.

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

На первый взгляд это казалось безрассудством: ПО для контакт-центров не очень привлекательно в разработке, но невероятно сложно. Такое ПО продают компании вроде Avaya и Genesys, имеющие глубокие корни в телекоммуникационной отрасли. Они десятилетиями создавали контакт-центры и съели на этом собаку, а тут какие-то разработчики из ИТ-отдела банка утверждают, что могут создать кое-что получше, чем эти специализированные гиганты.

Мало того, Тео поклялся, что его команда сможет создать ПО для контакт-центров целиком и с нуля быстрее, чем банк выберет поставщика и развернет его ПО, причем за меньшие деньги. Но главное, в этом случае ING будет владеть кодом, так что разработчики смогут улучшать систему так часто, как потребуется. В случае необходимости можно предоставлять пользователям новый код хоть каждый день, а не ждать, пока коммерческий поставщик отправит обновление, что случается один-два раза в год.

Тео сделал это смелое предложение не на пустом месте – в его основе лежало серьезное исследование. В 2014 г. он начал отслеживать новые софтверные компании вроде Twilio, продающие не готовые приложения, а своего рода строительные блоки, которые разработчики могут комбинировать и создавать собственные приложения (я рассматриваю этот сдвиг на рынке ПО в главе 2).

В 2015 г. Тео и его коллеги отправились в Сан-Франциско для участия в конференции SIGNAL нашей компании Twilio. Они интересовались, можно ли использовать продукты Twilio для создания ПО для контакт-центра. Несколько месяцев спустя команда инженеров Twilio прилетела в Амстердам и провела трехдневный форум с инженерами банка ING. «Мы просто проработали несколько сценариев, которые были вполне осуществимы в идеальном мире, но сложны для реализации в старом мире, – говорит Тео. – За три дня удалось создать гораздо больше, чем можно было ожидать. Это вселило в нас энтузиазм. Мы убедились, что можем создать ПО для контакт-центра и перейти к архитектуре с интерфейсом прикладного программирования и микросервисами».

Этот опыт придал Тео смелости, и он изложил идею руководству. Вполне возможно, она была не столь безумной, какой казалась на первый взгляд, но все равно граничила с авантюрой. На подобных идеях погорело немало ИТ-специалистов в старом мире. Это еще одна причина, по которой крупные компании так неохотно меняются и продолжают отставать от стартапов. Все дело в склонности высшего руководства «искать виноватого» и нежелании тех, кто отвечает за технологии, рисковать. Самой безопасной ставкой всегда было сотрудничество с каким-нибудь крупным коммерческим продавцом ПО. Конечно, такое ПО может быть неидеальным. Но когда что-то идет не так, виноват продавец, а не вы. Лица, принимающие решения в техническом отделе, прекрасно знают, что покупка очередного готового программного пакета – это ужасный шаг. Они знают, что компания должна радикально меняться. Но кого это волнует? Проще и безопаснее просто забыть об этой проблеме. Пусть проблемой займется другой сотрудник.