Трансформация
бизнеса

Для начала — информация для скептиков, убеждённых, будто в научно-техническом прогрессе Россия «отстала навсегда». Ничего подобного! Самые авторитетные мировые эксперты подчёркивают высокий уровень цифрового проникновения в нашей стране, а многие из них даже отдают ей пальму первенства. Удивительно, но именно крупные компании продемонстрировали инновационный дух и выиграли. А рынок, как лавина, сдвинулся за ними. Стоило это очень дорого (для первых всегда всё дорого), но результаты по бизнесу все окупили.

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

Мы начинали как раз в девяностых, когда в стране массово появлялись коммерческие банки, а с ними и запросы на автоматизацию банковских процессов. Сначала не слишком активно, поскольку банки занимались преимущественно спекулятивными операциями, но со временем, с появлением и развитием классического банкинга, вырос спрос на программное обеспечение core banking, то есть на автоматизацию всего, что связано с учётом данных обо всех банковских продуктах: кредитах, депозитах, расчётах и т. д.

Надо сказать, что российский рынок разработчиков программного обеспечения для финансового сектора развивался очень быстрыми темпами. Довольно скоро выявились сильные софтверные компании, предлагавшие рынку вполне зрелые решения. Хотя все мы учились «на ходу», но учились хорошо. Так что через несколько лет перестали чувствовать себя новичками на рынке. Тут, конечно, помогли банки-заказчики, которым требовались всё более продвинутые решения. И часто такие, какими не могли похвастать даже заслуженные и опытные западные банки. В этом, кстати, наша компания убедилась на собственном опыте, опыте банковского клиента.

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

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

Но, несмотря на высокий уровень зрелости отечественных решений, то были всё-таки «внутренние» системы, ориентированные на банковского сотрудника как конечного пользователя. А тем временем во всём мире вместе с развитием технологий назрели большие изменения, и настойчиво стал заявлять о себе новый пользователь, массовый и очень требовательный — клиент банка.

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

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

Впрочем, банки-инноваторы сообразили, куда ветер дует, за несколько лет до того, как рынок громко заявил о своих требованиях. Сначала действовали «на ощупь»: кто-то попробует на розничном рынке интернет для частного клиента. Другой предлагает решения для sms-оповещений на мобильный телефон (ни о чём другом речь ещё не шла, первый iPhone появился лишь в 2007 году). Третий развивает карточный бизнес, навешивая на него всякие привлекательные «фишки». Но всё это были довольно робкие шаги, хотя каждую новинку рынок воспринимал с энтузиазмом — но и некоторым опасением, как всё, доселе неизвестное.

В любом случае, до поры до времени и банки, и вендоры фокусировали внимание всё-таки на core banking. Главным в тандеме «банк-клиент» оставался, как и раньше, банк: именно он диктовал клиенту условия и правила игры. А разработчики, само собой, следовали заданному банками курсу. Правда, все хором говорили о том, что банковский бизнес поворачивается лицом к клиенту. Но никакого крутого поворота не ощущалось. Банки совершали небольшие вежливые шаги в ответ на самые острые запросы рынка. Больше было деклараций, меньше — намерений и совсем мало — конкретных изменений. А раз банки не меняются, то и вендоры делают мало. Без заказчика, без его потребностей и, наконец, без денег ничего не происходило.

Один из первых «звоночков» раздался как раз в 2007 году, когда в России появился новый и довольно-таки нахальный банк «Тинькофф Кредитные Системы (ТКС)», заявивший о себе как о «банке без отделений», ориентированном на карточный бизнес. Интересные модели дистанционного обслуживания к тому времени уже были — например, американский банк Wells Fargo. Там же, в США, получил широкую известность монолайнер Capital One, специализировавшийся на банковских картах. Но для России обе модели по ряду причин казались тогда не самыми перспективными.

Помнится, на рынке посмеивались над тем, сколько сил и средств — и с каким скромным результатом — ТКС вкладывает в прямую адресную рассылку, настойчиво предлагая всем и каждому оформить кредитную карту. Только за 2008 год банк разослал не меньше восьми миллионов предложений, а «заглотили наживку», по разным данным, лишь от 1,5 до 3% адресатов (хотя в абсолютных цифрах это не так уж мало). Однако ТКС не сдавался и продолжал «пригласительную» акцию вплоть до 2010-го. Параллельно с этим в 2008 году заработал интернет-банк, а в 2009-м ТКС начал принимать вклады и выпускать дебетовые карты.

Сегодня Тинькофф Банк (так он называется с 2015 года) признан одним из лучших инновационных банков. Известно, что многое они стали делать первыми. Другим, в том числе крупным банкам, оставалось — ну, может, не завидовать, но во всяком случае — набирать технологический темп. И уже не только для того, чтобы похвастать своими технологиями — скорее, для сохранения клиентской базы. Другими словами, Тинькофф Банк стал триггером для развития digital banking в российской банковской системе. Хотя, конечно, лидеры рынка тоже много для этого делали, но нужен был именно такой «спусковой крючок».

Время от времени различные источники публикуют списки самых инновационных банков, и почти неизменно первые строчки занимают Сбербанк, Альфа-Банк и Тинькофф Банк. И все три банка предпочитают программное обеспечение in-house — разработанное собственными силами. Это сильно изменило рынок. Другие банки стали подхватывать этот тренд: мол, раз кто-то смог, то и у нас получится. Поэтому профессия программиста стала нынче особенно популярной: многие крупные банки создают свои большие команды разработчиков (от нескольких тысяч и более специалистов), тратят огромные деньги (десятки миллиардов рублей) — и часто с сомнительным результатом. Причём все делают практически одни и те же ошибки, которые потом приходится исправлять. Об этом я расскажу чуть позже, а пока посмотрим, чем стремление банков к разработкам in-house обернулось для вендоров.

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

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

С другой стороны, в 2013 году политика регулятора резко ужесточилась, в результате чего клиентская база компаний, заточенных на обслуживание банков, стала таять, как снег весной. Так, только за три года (2015 - 2017) количество клиентов нашей компании сократилось на 40%, а вместе с этим сократились доходы от сопровождения и развития продуктов, внедренных у этих клиентов.

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

Но прежде, чем что-то (а тем более многое, как мы намеревались) менять, надо было ответить на вопрос: а для чего мы всё это затеваем? Нет, в общем ответ понятен — чтобы компания не только жила, но и развивалась. Конечно, так может сказать любая компания. Нам же требовался вполне конкретный ответ на вопрос: как и что сделать, чтобы мы были нужны рынку? Особенно в ситуации, когда наиболее продвинутые банки, на запросы которых мы всегда ориентировались, предпочли искать новые пути самостоятельно.

Ответ пришёл почти сразу: во-первых, надо иметь правильное видение, быть очень увлечёнными и хорошо ориентироваться в трендах рынка, во-вторых, делать всё очень быстро — бизнес наших клиентов ждать не может, и, в-третьих, наши продукты и проекты должны быть дешевле, чем они обошлись бы банку по модели in-house. Намного дешевле — в разы, а лучше в десятки раз.

Легко сказать… Конечно, свою миссию, миссию вендора — делать быстро, хорошо и дёшево — мы и без того отлично понимали. Но одно дело работать на устоявшемся рынке, где всё, в общем-то, известно наперёд, когда можно рассчитать и силы, и средства. И совсем другое — когда всё меняется с небывалой прежде скоростью, и трудно предугадать, какая идея придёт в голову клиенту завтра. Причём и позаимствовать-то идеи неоткуда — новых продуктов не предлагали не только российские, но и зарубежные разработчики.

Ощущение, а вслед за ним и понимание того, что нынешний период роста и стабильности, мягко говоря, не вечен, пришло к нам во вполне благополучном и спокойном 2006 году. Правда, конкуренты не дремали, и было ясно, что опасна даже не потеря темпа (как раз это нам в ту пору не грозило), а размытость перспективы.

И тогда мы разработали стратегию на 2006 - 2010 годы. Это была большая работа, в которую мы были глубоко погружены и которой увлечённо занимались много месяцев.

Мы вдруг (для многих компании это стало неожиданностью) решили отказаться от спокойной жизни и ринулись в неизвестность. Хотя нет, «ринулись» — не то слово. Конечно, были у нас и бурные споры, и мозговые штурмы. Однако, если взглянуть со стороны, жизнь шла своим чередом: писали код, тестировали, внедряли, анализировали и снова писали…

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

К счастью, финансовое положение компании давало возможность тратить время, силы и немаленькие деньги на поиск. Размер инвестиций в период с 2006 по 2015 годы превысил 50 миллионов долларов. Для нашей компании и для рынка это было беспрецедентно много. Но больше всего нам нужны были уверенность и терпение — всегда ведь есть искушение бросить, раз не получается, и вернуться к уже испытанному временем, к известным рынку продуктам, потихоньку доводя их до совершенства. Собственно, этим мы тоже занимались. А параллельно ездили на конференции и форумы, изучали выводы и прогнозы Gartner и других аналитических компаний, следили за тем, что происходит на мировом рынке информационных технологий. И по всему выходило, что движемся мы в правильном направлении.

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

И тогда стало ясно, что надо переносить фокус внимания на регулирование производства и выстраивание новой системы управления. Явных предпосылок к этому не было: в лидерской группе мы занимаем прочное положение, авторитет на рынке высокий, заказчиков не теряем, прибыль получаем. С чего, казалось бы, дёргаться?

Однако в какой-то момент мы поняли: по-старому больше не получается, буксуем. Со стороны, может, и не заметно, но для нас — очевидно.

Словом, классическая революционная ситуация. Перемены на рынке её лишь усугубляли.

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

Инвестировать в будущее надо не на пике успеха, а раньше — на подъёме. Когда, во-первых, хорошо просматривается ближайшая перспектива, и она позитивна. А во-вторых, когда есть, что называется, «лишние» деньги. Понятно, лишними они никогда не бывают. Но вот замечена за людьми такая особенность — когда у нас появляются деньги, мы стремимся их потратить на что-то необязательное: резко повысить дивиденды, оклады и премии, купить новую мебель и оборудование, устроить роскошный корпоратив и так далее.

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

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

Причины недоверия могут быть разными. Например, рынок не готов к новому, а вы обогнали время — и это здорово, у вас образовался задел на завтра, а то и послезавтра. Значит, есть смысл работать над этим дальше, выделив определённые ресурсы. Бывает и другое: скажем, вы предложили незрелое, сырое решение — тоже не катастрофа, есть стимул его доработать.

Надо иметь в виду, что сегодняшние инвестиции в будущее сразу не отобьются. Скорее всего, в текущей ситуации эти вложения будут убыточными — как получилось, например, у нас. За три года (2015 - 2017) мы инвестировали в семь клиентских проектов больше миллиарда рублей (с убытками от 100 до 200 миллионов рублей на проект), внедряя инновационные продукты. Успех пришёл позже, но мы бы его не достигли, не рискни мы тогда этим миллиардом. Другое дело, что риск всё-таки был осознанным.

У ИТ-компаний, разрабатывающих софт для банковской сферы, есть своя особенность — ни одно решение не может появиться «в кабинете», в отрыве от рынка. Даже не от рынка, а от совершенно конкретного заказчика, от конкретного проекта внедрения. Чем плотнее вы работаете с клиентами, чем внимательнее к ним прислушиваетесь, тем выше ваши шансы на успех. Надо не просто знать свой рынок, необходимо ощущать его дыхание и движение. А для этого нужно делать свою работу вместе со своими клиентами, «в полях», на их территории, сообща добиваясь истинной зрелости решений.

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

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

Но ведь с производством программных продуктов — то же самое, если это, конечно, не кустарная мастерская на одного «холодного» сапожника. Выстроить и наладить производство очень сложно, и на порядок труднее — сделать его эффективным и результативным. Как ни парадоксально, сплочённая команда из 50-ти человек часто способна сделать больше и лучше, нежели собранная «с бору по сосенке» тысяча программистов, даже очень грамотных и опытных. Более того, любой многочисленный коллектив, по сути, неуправляем. В компании Hewlett-Packard когда-то признали, что подразделение численностью более 500 человек не эффективно. И стали делить разросшиеся структуры на независимые друг от друга подразделения численностью 200 - 300 сотрудников.

Производство — это не только технологии управления людьми. Это автоматизация процесса производства, которая позволяет удешевить, сократить сроки и обеспечить качество процесса создания продуктов. Это архитектурные принципы и надзор, для того чтобы отдельные части можно было собрать в единое целое. Это средства разработки и технологии. Это проектные практики. Это технологии оценки трудозатрат и повышения эффективности. Это правила, принципы и ценности, которым следуют лидеры и их команды. Это программы обучения и мотивации. И многое, многое другое, без чего машина производства программных продуктов не поедет. Короче говоря, производство надо выстраивать, а на это требуются не недели, не месяцы — годы. «Диасофт» через два года будет отмечать 30-летие, и все эти годы мы строили производство. И продолжаем строить, потому что останавливаться никак нельзя.

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

Теперь немного о двухскоростной архитектуре. Компания Gartner ввела этот термин в 2012 году. Если упростить объяснение до схемы, суть в том, что в системе есть два «этажа», два слоя.

Нижний — core banking, где учитывается всё, что можно и нужно учесть. Именно в этом слое расположены Главная книга и все продуктовые системы. В классическом варианте, когда клиенты ходили в банк, этого было достаточно. Сотрудники банка работали в этих системах - открывали счета, делали проводки. Удобные были эти системы или нет, не имело большого значения. Клиенты контактировали с сотрудниками банка, а не с системами автоматизации.

Верхний слой - цифровая омниканальная платформа, построенная на основе принципов управления процессами банка. Любой банковский продукт можно представить как процесс его получения. И многие звенья этого процесса можно автоматизировать, но для работников банка работа всё-таки остаётся. В рамках цифровой трансформации подключаются разные каналы, в которых клиенты сами могут получать продукты и услуги. Gartner утверждает, что в идеале вся работа людей (сотрудников и клиентов) должна быть перенесена в верхний слой. Так проще управлять банком, совершенствовать и создавать банковские продукты. И обеспечивать высокую, конкурентную скорость изменений.

Если в нижнем слое менять что-то ещё недавно можно было редко (пару раз в год, например), то для верхнего «этажа» и неделя порой — много. В идеале, надо бы так: утром пришла в голову идея, а вечером новинка уже в распоряжении клиента. Мечта, конечно, но почему бы и не помечтать?

Третья ошибка связана с недооценкой нового технологического стека — микросервисов. Этот набор программ для разработки и управления конечными (прикладными) программными продуктами был создан (и продолжает активно развиваться) как раз для того, чтобы ускорять верхний «этаж». Простой пример: есть, скажем, программа (сервис), которая обрабатывает кредитные заявки. Появилась нужда в новой версии, обновлении продукта. Раньше это превращалось в сложную историю: чтобы обновить продукт, надо было выбрать технологическое окно, остановить систему, поставить обновление и снова запустить процесс. Сейчас вы просто создаёте обновленную версию и упаковываете её в контейнер. Дальше уже не ваша забота — специальная программа сама развернёт новый сервис, сотрёт устаревшую версию (после того, как будет обработана последняя заявка), развернёт необходимое количество копий сервиса (если образовалась очередь заявок), перезапустит сервис на новом сервере (если что-то сбоит). Всё это обеспечивает беспрецедентную надёжность, простоту и скорость работы. Это уже не хайп. Это уже объективная реальность, без которой невозможно обойтись в решении актуальных задач бизнеса.

Четвёртая ошибка получила удивительно широкое распространение. Речь идёт о поддержке мультиканальной (отдельные решения для разных каналов), а не омниканальной (единое цифровое пространство) архитектуры. Если мы хотим строить цифровой банк, то должны с самого начала ориентироваться на создание единого цифрового пространства. Каналы — это возможность доступа к банковским продуктам и услугам, и клиенты используют те каналы, которые удобны и доступны в конкретный момент и в любом месте. Хотим сделать перевод — пользуемся телефоном или компьютером (если он у нас под рукой). Или делаем это в банке (потому что есть лимит), или звоним в сall сenter (возможно, по той же причине). Можем получить кредит там, где покупаем товар (в Marketplace), даже не понимая, что его даёт банк. Банковский продукт может быть сложным — «начинаться» в одном канале и «заканчиваться» в другом.

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

Пятая ошибка (хотя, по существу, с неё надо было бы начинать этот печальный список) — абсолютное невнимание к культуре. Питер Друкер как-то сказал: «Культура съедает стратегию на завтрак». То есть компания проснулась, умылась — привела свои процессы в порядок, взялась за выполнение стратегии — и сразу (на завтрак) культура её съела. Каждому подходу к управлению соответствует своя культура. Самые распространённые и хорошо работающие культуры в современных организациях — это культуры силы и правил. Проблема состоит в том, что новые подходы к разработке программных продуктов и новые проектные практики (Agile, OKR) нуждаются в культурах результата и согласия. Без этого они не эффективны. А преобразование культуры организации сложнее, чем преобразование управленческих практик, но делать это нужно параллельно.

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

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

Увы, не получится. Каждый, кто когда-либо имел дело с любыми системами, знает: чем больше отдельных независимых компонентов, тем труднее собрать их в единое, цельное, работоспособное решение. Мне кажется, даже особо и объяснять не нужно, почему. Разработка серьёзного софта несколько отличается от рисования сайта по шаблону. И требует командной, согласованной работы большого количества участников. А ещё — широкой экспертизы, профессионального опыта, знания рынка и глубокого изучения бизнеса заказчиков. Всё это требует времени и ресурсов. А стартапам этого, по определению, не хватает. Что у них есть, так это смелость, незашоренность и здоровая доля нахальства. В принципе, такие ребята могут неплохо работать в команде. Могут создать отдельные решения, которые станут прорывом. Но делать ставку на финтех-стартапы как на локомотив цифровой трансформации я бы всё же не стал.

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

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

Коротко говоря, в цифровых схемах информация по-другому кодируется. Если аналоги разрабатываются вручную, то с «цифрой» неразрывно связана автоматизация всего и вся. И если аналоговый сигнал непрерывен и потому подвержен различным влияниям (сравните качество изображения в аналоговом и цифровом ТВ: сравнение будет явно в пользу «цифры»), то дискретный цифровой сигнал практически не реагирует на внешние помехи. Полагаю, такого краткого объяснения достаточно, чтобы понять, почему человечество столь естественно и быстро привыкло к «цифре». Скорость, качество, точность, огромный потенциал развития — кто же станет отказываться от хорошего?

Между прочим, лет 15 — 20 назад спрос на ИТ был довольно-таки скромным. Главным образом их использовали в финансовой сфере, в базовых бизнес-системах, ну, и, само собой — интернет-сайты и электронная почта. Сейчас же, когда мы говорим о цифровой трансформации, то имеем в виду, что трансформировать надо уже не только экономику, но и медицину, образование, государственные службы. Да что перечислять — она должна охватить все без исключения сферы жизни и деятельности человека, создать единое цифровое пространство, где не будет места информационному хаосу.

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

Теперь, когда мы согласились с тем, что мир глобально и быстро меняется, а цифровая трансформация неизбежна, давайте разложим предпосылки к ней, так сказать, «по полочкам».

Совершенно ясно, что выжить в турбулентном и куда-то спешащем мире можно лишь в том случае, если сумеешь управлять изменениями, которых требует дело, каким занимаешься (вряд ли есть смысл замахиваться на управление глобальными переменами — они всё-таки объективны).

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

В стабильном мире система измерений вызрела. Она позволяет уверенно отделять плохой результат от хорошего и направлять управленческие усилия на достижение лучшего результата. В быстро меняющейся среде система измерения обычно ломается. Мы, менеджеры, оказываемся в управленческом вакууме. Часто вынуждены опираться на качественные, а не количественные оценки (например, на энтузиазм людей). Всё это приводит к разрушению системы координат, к неспособности сообща двигаться в одном направлении и, в конечном счете, к провалу.

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

Вот, собственно, мы и подошли к тому, что нужна цифровая трансформация.

Как минимум, надо так организовать процессы, технологии и продукты, чтобы перенести бизнес в цифровое пространство. Здесь уже многое сделано, и уже есть отрасли, которые далеко продвинулись в этом направлении. Остальным приходится догонять — а никуда не денешься.

И лучше с этим не затягивать, потому что следующий этап — сделать данные, то есть «цифру», основой управления. И это — задача-максимум. Пути и способы её решения уже подготовлены: есть развитая аналитика, есть big data, мощные хранилища данных. Теперь надо учиться всем этим пользоваться.

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

Поскольку трансформация нашей компании уже имеет свою историю (по сути, мы приступили к ней ещё в 2006-м), есть смысл выделить три ключевых принципа, которые мы положили в основу изменений.

Первый и главный принцип — осознанность.

Нельзя просто сказать себе: с понедельника начинаю новую жизнь. То есть сказать-то можно, только в понедельник ничего не произойдёт. Прежде, чем что-то менять, полезно сначала подумать: во-первых, что именно менять, во-вторых, зачем это делать, и, в-третьих, чего мы от изменений ждём.

Чтение умных книг в данном случае может помочь лишь отчасти. Да и то, только тогда, когда ты сверяешь чьи-то идеи или рекомендации с собственным опытом — практику ничем не заменишь. Есть страновые особенности, отраслевые, в конце концов, специфика конкретной компании. Многие набивали себе синяки и шишки, пытаясь перенести в свой бизнес точь-в-точь, без адаптации, опыт какой-то зарубежной фирмы или иностранного банка. И, как правило, терпели неудачу. Известна же поговорка: что русскому хорошо, то немцу — смерть. И наоборот. Это не про баню, а про менталитет. Если вы заставите своих сотрудников распевать перед началом работы гимн компании, как это принято в японских корпорациях, вас в лучшем случае не поймут…

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

Такой вот строгой порядок: пилотирование — осознанность — масштабирование. Выработанный опытным путём, он может быть выражен ещё более простой формулой: от практики, через анализ — к синтезу.

Второй принцип — конструктивность намерений.

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

Другое дело, что надо инициировать именно конструктивные, созидательные намерения. «Что-то мне не очень нравится, как мы живём…» — это ни о чём. Если включить голову, можно понять, что именно не нравится и почему. Тогда следующим шагом станет реальное и конкретное желание изменить ситуацию к лучшему. И можно будет приступить к выработке программы необходимых действий. Это, по существу, и называется конструктивными намерениями.

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

Нам в «Диасофт» в этом смысле повезло (наверное, точнее будет сказать, что мы добились такой атмосферы) — в команде достаточно «конструктивистов», способных смотреть на жизнь непредвзято. И не просто помечтать о чём-то лучшем, но и сделать что-то для этого лучшего, причём — что невероятно важно — они готовы отвечать за свои действия и за результат.

Третий принцип — ответственность.

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

Уровень ответственности зависит от двух составляющих: от уровня ответственности конкретного сотрудника (в психологии это называется «внутренний локус контроля») и от культуры организации (насколько она терпима к ошибкам). И на то, и на другое можно влиять, повышая уровень ответственности внутри организации.

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

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

Никаких частичных решений, никаких пробелов трансформация бизнеса не терпит. Начнёте менять одно, и оно потянет за собой всё остальное. Надо быть к этому готовым. Например, вы начали разрабатывать новый продукт. Скорее всего, потребуется применять более современные технологии, с которыми прежде вы не имели дела. Это повлечет за собой изменения в производстве и проектных практиках. Всё это потребует огромных затрат на разработку и внедрение новой корпоративной среды, в которой работают инженеры компании. Далее потребуются изменения структуры и системы управления. А это, в свою очередь, повлечёт за собой изменения принципов управления персоналом, системы мотивации и базовых ценностей компании. Новый продукт — новые принципы продаж и новые навыки продавцов. Всё меняется, и поэтому важно развивать компетенции всех и во всём. Требуются новые программы обучения, время на их разработку и освоение. И любой из перечисленных компонентов трансформации неразрывно связан со всеми другими, так что оставлять какой-то из них «на потом» — значит, получить в итоге не реальные преобразования, а самую банальную профанацию.

И ничего нельзя упустить, о чём-то забыть. Более того, всё надо делать фактически одновременно, поскольку пропасть в два приёма не перепрыгивают.

Есть такая практика — измерять качество жизни неким средним уровнем. Это начинается ещё с пресловутого «среднего балла» в школе, а может, и раньше.

Так вот, в бизнесе номер под названием «средний балл» не проходит. В бизнесе всё необходимо мерить по нижнему баллу, а если твой бизнес на "троечку", то у тебя мало шансов выскочить наверх. Зато скатиться к "неуду" и вылететь с поля — полная возможность. Компания по всем параметрам, кроме одного-единственного, вроде бы на всех парах идёт вперёд, но как раз «единственный» и может в любой момент свести все усилия к нулю.

Мы же знаем историю компании Sun Microsystems, которая делала поистине великие продукты, вот только не умела их хорошо продавать. Причём продукты эти и теперь вовсю используются. Но под брендом Oracle. А компании Sun уже нет.

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

Водопадный, или каскадный, метод в проектном управлении — самый популярный и до недавнего времени считавшийся наиболее логичным. Впрочем, и сегодня его адептов — большинство, в отличие от последователей agile, о котором речь впереди.

Название говорит само за себя — этот метод делит весь проект на отдельные этапы, следующие один за другим, подобно водным каскадам. Шаг влево или назад запрещён, всё строго последовательно. У нас это выглядело примерно так: сначала довольно долгий и муторный этап согласования с заказчиком его требований. Затем намечается проект — объём, сроки, стоимость. После чего к делу подключаются разработчики, за ними — тестировщики, проверяющие продукт, и далее следует процесс собственно внедрения, как правило, с параллельной отладкой программы. Ну, и, само собой, дальнейшая поддержка — это прямая обязанность вендора.

Казалось бы, какие могут быть претензии к столь стройной методологии? Всё разложено по полочкам, для каждого этапа обозначены точка старта и срок завершения. Тем не менее, недостатки есть. Во-первых, уж очень долгая история получается. Во-вторых, манёвр, по сути, под запретом, а значит, нет гибкости. И, в-третьих — размытая ответственность. Помните, как в знаменитой репризе Аркадия Райкина: «У нас узкая специализация… К пуговицам претензии есть? — Нет, пришиты насмерть, не оторвёшь!». Вот эта «узкая специализация» часто и становится в нашем деле слабым звеном.

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

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

И поэтому, в конце концов, мы пришли к agile, хотя у этого подхода, наверное, до сих пор больше противников, нежели поклонников, причём вторые со временем превращались в первых. Возможно, потому что попытки подробно описать этот подход и раскрыть его содержание порой напоминали философские трактаты. И потому, что большинство тех, кто решил его применять, прочтя Agile manifesto, останавливались на неких внешних атрибутах метода. А потом страшно удивлялись, что ничего не получается: «Ерунда этот agile!». Но и Waterfall ведь тоже не работает в современных условиях!

Не могу сказать, что команда «Диасофт» поняла и приняла agile с ходу и с овациями. Нет, пришлось буквально ломать — сначала себя, потом менеджмент, а вместе с ним — весь коллектив. Из-под «водопада» оказалось не так легко выбраться. Это ведь тоже в природе человека — мы прикипаем к каким-то вещам настолько прочно, что отрывать приходится, как говорится, «с мясом». Тем более, когда эти привычные вещи ничем таким себя вроде не скомпрометировали, наоборот даже — с их помощью компания вышла в лидеры рынка. Зачем же от добра добра искать?

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

Приступив к освоению agile, мы быстро поняли, что менять придётся очень много.

Отношение к agile в профессиональной среде в то время (да и сейчас) колебалось от неумеренных восторгов до горького разочарования. Но мы сделали ставку на эту систему управления и очень скоро поняли, что структура компании, как бы она нам ни нравилась, ей не соответствует. Что и понятно — ведь она была заточена под «водопадный» подход, в соответствии с которым компания была поделена на центры компетенций — большие, по 100 — 200 человек, коллективы, которые занимались своим, относительно узким направлением: разработкой, аналитикой, тестированием, архитектурой, внедрением, сопровождением и менеджментом проектов. На конкретные проекты собиралась команда, на время объединявшая специалистов каждого из центров компетенций.

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

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

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

Как раз в то время у нас прижились командные практики типа «один к десяти» (практики управления сотрудниками) и «один к пяти» (проектные практики). Мы считали и считаем, что непосредственно под командой одного руководителя (например, в отделе) должно быть порядка десяти человек. И руководитель должен общаться со своими подчинёнными не только в рамках общих собраний, но и «лицом к лицу — один на один», обсуждая разные, преимущественно производственные темы (проблемы, компетенции, задачи, развитие), но и не только (ценности, ответственность, личное). Мы прекрасно осознаем, что всё в компании делают люди, что именно они являются самой большой ценностью. Так оно есть и всегда будет. Поэтому сводить всё общение в коллективе к производственным темам и в рамках общих собраний — не по-нашему. Это к тому, что переход на принципиально иную модель управления и радикальная смена структуры не коснулись нашей фундаментальной системы ценностей, заложенной, кстати, задолго до «водопада», фактически, на старте компании. Но о ценностях — в свой черёд, а пока поговорим об agile.

Я уже довольно подробно рассказал, почему мы вынуждены были отказаться от «водопада» — для новых задач он оказался слишком жёстким и неповоротливым. До тех пор, пока предыдущий этап не закончен, к следующему приступать нельзя. Тестировщик выявил ошибку? Значит, начинаем всё сначала. Немудрено, что между начальным периодом анализа и завершающим, периодом интеграции, проходят не месяцы, а годы. Когда речь идёт не о продаже «коробочных» продуктов, а о проектах (а мы занимается именно проектами внедрения на базе собственных разработок), такая потеря темпа может привести к прямым убыткам. Так что для нас смена модели управления стала «вопросом жизни и смерти».

Документ, известный как Agile manifesto, появился в 2001 году. Выглядит он, надо сказать, очень красиво, хотя кому-то покажется чересчур «романтичным». А ещё кто-то жаждал получить некий сборник рецептов — как конкретно, пошагово, работать над проектом. Однако ничего подобного в манифесте нет. Зато есть перечень ценностей, которые его авторы считают ключевыми.

В своё время этот список меня, признаться, зацепил. Скорее всего, потому, что мы в компании, по сути, исповедовали те же ценности, и они для нас исключительно важны.

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

Для каждой работы формируется отдельная команда, от семи до десяти человек, в неё входят специалисты всех направлений. Так как мы компания-вендор, то наши команды формируются всегда вокруг программного кода и связанных с ним артефактов (постановок, тестов, документации и прочее). Команда является в хорошем смысле хозяином кода и отвечает за его «здоровье». Это один из важнейших базовых принципов производства. Никто не должен и не может без участия команды что-то делать с кодом (даже клиенты).

Если задача большая, то создаётся много команд и отдельно стоит вопрос, как объединить усилия множества команд в единое целое.

На каждый двухнедельный спринт формируется список задач. Это делают аналитики совместно с заказчиками. А вот уже внутри спринта команда работает методом, похожим на «водопадный»: от проекта — к программированию, затем — тестирование и так далее. Результат каждого спринта — версия продукта, превосходящая предыдущую, вполне работоспособная и несомненно полезная, которую можно и нужно показать заказчику. После этого снова проводится совещание по плану, где на следующий спринт нередко добавляются корректировки и дополнительные задачи. Поэтому от спринта к спринту основная задача может видоизменяться, и финишный продукт порой серьёзно отличается от начального представления.

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

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

Надо сказать, разочарованные в agile считают, что все эти совещания и стендапы — сплошь говорильня и потеря времени. Есть и другие критики, уверенные в том, что независимость команды во внутренней организации — прямой путь к дисциплинарному хаосу.

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

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

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

Снова повторю: разрушать структуру, выстроенную под «водопад», было очень обидно. Только и оставлять её без изменений было нельзя. Тем более, что, хотя приживался agile в компании довольно хорошо, масштабировать его на старой структуре было бы невозможно. Мы это поняли, в том числе и глядя на чужие ошибки. Однако разобрать сложившуюся, стройную и выверенную структуру в полторы тысячи человек, а затем скомпоновать совершенно по-новому (не перетасовать, а именно скомпоновать) не так-то просто.

Главной нашей задачей было не растерять на новом отрезке пути то ценное, чего удалось достичь в предыдущие годы. Прежде всего — атмосферу, которая сложилась в «Диасофт» за четверть века. Она ведь не сама собой возникла — в своё время мы перестраивали структуру как раз для того, чтобы больше заниматься именно людьми, растить их, обучать, помогать им развиваться. Мы собирали людей из продуктовых центров в центры компетенций, с задачами которых они справились отлично. Что ж, пришло время — и мы вернули их в продуктовые центры, только теперь уже как сотню команд, заточенных под agile. Центры компетенций остались, но уже в другой численности — от семи до десяти человек по каждому направлению. И с чёткой задачей: они не только отвечают за развитие технологий тестирования, аналитики или архитектуры, но и разрабатывают правила, без соблюдения которых не может работать ни одна команда. То есть прямых подчинённых у этих центров вроде бы и нет, но их влияние на производственный процесс огромное. При той независимости, которая дана командам, правила необходимы, причём весьма жёсткие, без них может просто возникнуть хаос.

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

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

Принятие решений (в том числе таких основательных) у нас обычно проходит в три этапа.

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

Быть может — и даже наверняка — в другой компании всё сложилось бы по-иному. Думаю, в нашем случае сработала та особая атмосфера, которую мы создавали годами. В её основе — прежде всего, взаимное доверие. При таких перестройках порой возникают серьёзные проблемы. Часто личного характера. Кто-то теряет ответственность, кто-то — подчинённых, а у кого-то для новой ответственности не хватает навыков. Но если люди видят, что руководители действуют по-честному, готовы прислушиваться к их мнению, понимать страхи и учитывать интересы, естественное сопротивление новому сходит на нет.

Мы — единая команда, и менеджерам, как воздух, необходима поддержка сотрудников, поэтому мы готовы всё подробно «разжёвывать», объяснять, как именно будет реализовано решение, какие могут быть плюсы и минусы. На сам факт принятия решения это уже, конечно, не влияет, но нюансов бывает много, и надо действовать гибко. Люди должны верить в то, что мы готовы нивелировать потери и неудобства, найти каждому человеку место, где он будет полезен и где ему будет интересно. А мы должны на это доверие отвечать конкретными действиями.

Вот на эту перестройку структуры у нас ушёл практически весь 2018 год. Казалось бы, столь серьёзная ломка должна несколько подорвать силы компании. Но вышло точно наоборот — этот год стал самым успешным за всю историю «Диасофт». В первую очередь, конечно, это результат перехода на осознанный agile, который стал эффективным и очень естественным для нашей команды подходом. На его внедрение люди ответили просто-таки невиданным трудовым энтузиазмом.

Если помните, в числе типичных ошибок трансформации я выделил пренебрежение к культуре. Для нас культура — вопрос не «гуманитарный», а самый что ни на есть производственный. Без трансформации культуры — производства, управления, личности — нечего и думать о каких-то принципиальных переменах к лучшему. Да и вообще — о развитии.

В основе построения корпоративной культуры лежит простой тезис: всё в этом мире делают люди. И всё, на самом деле, зависит от них.

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

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

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

Хотя, если вы забьёте в поисковую строку браузера слова «культура согласия», Интернет выдаст вам в сотнях вариантов примерно такую формулу: это культура мозговых штурмов, креативных сессий и творчества. О сотрудничестве — ни слова. Кстати, может быть, именно поэтому о том же agile многие думают как о бесконечных словопрениях?

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

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

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

Меняя структуру под agile, мы, по существу, корректировали саму среду, где другими становятся и принципы оценки. Привычный критерий: работаешь хорошо — молодец, а как дела у остальных, тебя не касается, — в этой среде не работает. С другой стороны, если в твоей команде все молодцы, тебе, вроде бы, уже и совестно работать плохо. То есть речь идёт о выработке культурного кода более высокого уровня, когда ценности команды становятся важнее, чем личные. Это, собственно, и есть культура согласия.

Сейчас много говорят о так называемых «бирюзовых» компаниях, построенных (если принять терминологию Фредерика Лалу) на трёх принципах: эволюционная цель, целостность и самоуправление. Лично мне пока с такими компаниями сталкиваться не приходилось, и как цель «бирюзовость» выглядит очень привлекательно, но для нашей компании это, по-видимому, ещё очень далекий этап развития.

Сознаю, что вы вправе спросить: а когда же будет, собственно, про бизнес? На чём зарабатываете, если всё время что-то строите и перестраиваете?

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

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

Попытки использовать «одноразовую» модель — продал продукт и на том успокоился — едва не привели знаменитую фирму Adobe Systems к катастрофе. Много лет они продавали очень популярный продукт — Photoshop, отлично известный как профессионалам, так и любителям. Продукт действительно качественный, что и помогло Adobe выдавить с поля битвы практически всех конкурентов. Но в какой-то момент рынок насытился, и мощный поток продаж превратился в хилый ручеёк. Нет, не потому что пользователям пытались всучить старьё: Adobe Systems готовил новые, всё более совершенные версии, но меня, например, вполне устраивали прежние, как устраивали они и большинство потребителей. В итоге, Adobe Systems оказалась под угрозой краха.

Наверное, им пришлось бы смириться с поражением, которым, как ни парадоксально, обернулся их громкий успех, но спасли бурное развитие информационных технологий и переход на другую модель продаж. Adobe разработала более совершенную версию продукта, отвечающую новым требованиям рынка, и… перестала продавать Photoshop. Отныне программой можно пользоваться только на правах аренды — или подписки, называйте как угодно. Photoshop теперь в «облаке», хочешь — подключайся. Вроде бы ничего не изменилось. Какая разница, откуда скачивать на свой компьютер программу: с флешки, с сайта или из «облака». Но фишка в том, что никаких новых версий Adobe больше не предлагает, зато регулярно выпускает обновления. Иными словами, Adobe Systems упаковала свой продукт как сервис — и выиграла.

Подобная подписная, или арендная, модель становится всё более популярной. Например, компании Oracle и SAP объявили о том, что переходят во всех своих конечных решениях с 2025 года на «облако». То есть отдельных поставок программных продуктов и обновлений больше не будет. Будет только подписка. Но не будет и скачиваний. Не нужно будет создавать собственную инфраструктуру. Данные будут храниться в «облаке». В этом большой плюс. Но если мы работаем в России и существуют известные санкции, то отключить нас от системы и убить наш бизнес можно будет одномоментно. Это большой минус.

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

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

И тут вновь проявился Тинькофф Банк — с предложением индивидуальных инвестиционных счетов (ИИС) частным клиентам. Правильно расценив рыночную ситуацию, он предложил финансовый инструмент тем, кто располагает лишь небольшими свободными деньгами — то есть подавляющему большинству. И банк не ошибся — интерес к ИИС сразу же оживил инвестиционный рынок. Не удивительно, что очень скоро к нам в компанию стали приходить клиенты с одной и той же просьбой: сделать, как в Тинькофф Банке. Пойди мы на поводу у пессимистов, заранее заявивших о замораживании этого направления бизнеса, пришлось бы развести руками…

Другой пример — цифровая платформа. Проблемы проблемами, а конкуренция в борьбе за клиента нешуточная. Надо переносить продукты и сервисы в цифровые каналы, совершенствовать качество банковских продуктов и скорость обслуживания (например, принимать решение по авто- и потребкредитам в течение десяти минут) и даже в отделениях работать по-новому. Делать это можно только в архитектурной модели: не предъявлять невыполнимые требования к развитию учётных систем, а внедрить цифровую скоростную омниканальную платформу и бежать в ногу со временем. Сделав в своё время ставку на компонентную архитектуру, мы оказались, что называется, в нужное время в нужном месте. Хотя надежды эти оправдались не сразу — хорошо помню, как скептически банки отнеслись к первым нашим предложениям. Аргументы были однообразные: если это так здорово, как вы говорите, такие приложения были бы у всех…

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

Третий пример — микросервисный стек технологий. Мы точно были не первыми. После десяти лет глобальных инвестиций в новые технологии (в Java, в цифровую платформу, в двухскоростную архитектуру, в компонентный подход) трудно разглядеть новое и действительно важное. Очень хочется верить, что это очередной хайп и он пройдёт. И мы пожалели, что в этом вопросе не начали раньше других. Это действительно прорывные технологии, к которым рынок повернулся лицом, без которых не видно будущего. И нам пришлось догонять. Потому что мы живем в мире, где правит клиент. Он платит и, как следствие, заказывает музыку. А эти технологии (при правильном их применении) действительно создают новые ценности, такие как беспрецедентная надёжность приложений, непрерывность обслуживания клиентов и скорость внесения изменений.

Нас не смущает то, что нередко нам приходится на лету подхватывать чужие идеи, в том числе (пожалуй, прежде всего) выдвинутые банками-инноваторами. Не будем забывать, что реализация таких идей требует больших денег и не по силам многим игрокам рынка, а миссия вендора — предоставлять качественный, но дешёвый продукт. Причём не вдвое дешевле, чем получилось бы in house, а во много, в десятки раз дешевле. И такая возможность у нас есть — за счёт тиражирования, экспертизы и налаженного производства.

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

Именно многолетняя работа в жёстких условиях и дала нам бесценный опыт, необходимый для организации высокоэффективной и результативной работы. И этим опытом мы готовы делиться. Сейчас на рынке появился термин Team as a Service, который пришёл на смену People as a Service. Дело в том, что «люди как сервис», даже обладающие очень высокими компетенциями, в современных условиях не дают необходимого результата. Заказчики всё больше склонны переносить ответственность за результат вовне, а не брать её на себя. Для этого нужны команды, объединённые опытом работы, лидерством, практиками управления, производственной средой и культурой. И это то, что есть у нас, что становится всё более и более востребованным.

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

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

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

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

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

Было бы странно такой «оцифрованной» стране как Россия не задумываться об экспорте отечественных решений. К сожалению, технологический провал 1980 — 1990-х сформировал у нас своего рода комплекс неполноценности. И совершенно напрасно. Бывая на международных выставках и мероприятиях, мы видим, что российский ИТ-сектор интересен за рубежом. Но, к сожалению, санкционный режим пока не позволяет нам работать с европейскими странами, зато Азию мы уже начали осваивать. Что, на самом деле, быть может, сулит даже большие перспективы, учитывая взрывной рост азиатских экономик.

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

Тем не менее, международное продвижение имеет свои законы, и чему-то (на самом деле, многому) приходится учиться на ходу.

ПЕРВОЕ ПРАВИЛО: заходить в страну, не имея в ней партнёра, не имеет смысла. Как и в любой другой сфере, здесь нужны рекомендации. Собственно, ничего удивительного в этом нет, ведь и в России вряд ли бросятся в объятия людям из какой-то новой, неизвестной компании, но охотно поддержат контакт с теми, кто уже работал, например, с крупным банком или серьёзной корпорацией.

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

ПРАВИЛО ТРЕТЬЕ: в команде нужны местные инженеры. И вот это уже о той самой специфике. Языковый барьер в азиатских странах — данность, ибо местный английский тоже весьма специфичен. Но дело не только в разных языках, но и в разных обычаях. К примеру, проект подходит к логическому завершению, и вы предлагаете заказчику: давайте запускаться в ближайший месяц, всё готово. Заказчик вежливо кивает головой, улыбается и… ничего не происходит. Вы не в силах понять, в чём тут дело, пока кто-то опытный, проживший немало лет в этой стране, не объяснит вам, что сейчас, в этом месяце тут начинать дела не принято — плохая примета, фэн-шуй не велит или ещё какой-нибудь религиозный или бытовой обычай. Между тем, местный и лояльный (вы же ему платите за работу) инженер вашей компании заранее подсказал бы вам, когда, как и что надо делать, чтобы всё получилось. Забавно? Может быть. Но, как говорится, со своим уставом в чужой монастырь не ходят.

Есть и другие отличия, которые могут влиять уже не только на тактику, но и на стратегию вашего продвижения. В Индонезии, например, пока не очень приживаются интернет- и мобильный банкинг. А дело в том, что здесь до сих пор в ходу традиционные сберкнижки. Причём не только у старшего поколения, но и у молодёжи. Ну не воспринимают они абстрактные «электронные» деньги, непременно им нужен документ, подтверждающий транзакцию. Разумеется, через какое-то время дело сдвинется, сознание перестроится. В этой стране основной вектор цифровой трансформации направлен на улучшение обслуживания клиентов в отделениях, через создание «единого окна» для всех услуг, подготовки таргетированного (подходящего) предложения конкретному клиенту, быстрого обслуживания без очередей и т. д. и т. п.

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

Только не думайте, будто Азия — территория, «не тронутая цивилизацией». Ещё как «тронутая». И крупные азиатские игроки отлично понимают перспективы проникновения на этот обширный рынок. Хотя, как ни странно, программных решений из Китая на этом рынке не найти. Так же, как и сам Китай не принимает «чужаков» — такое вот взаимное отторжение. Зато сплошь и рядом индийские ИТ-компании — с очень сильным менеджментом, эффективными продажами и… весьма скромной зрелостью решений. Они хорошо умеют подцепить клиента на крючок демпинговыми ценами, настойчиво и агрессивно побуждают его к покупке, а потом — бесконечно, под разными предлогами, повышают стоимость сопровождения.

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

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

В панику впадать, разумеется, не стоит, но трезво оценивать проблему необходимо. А проблема в том, что последние тридцать лет практически всё в нашей стране делается на импортной элементной базе и зарубежном софте. В том числе и отечественные ИТ-разработки — все они на иностранных платформах, той же вездесущей Oracle, к примеру. Глобализация… Собственно, в ней нет ничего плохого. Плохо лишь тогда, когда политика смешивается с экономикой. И в этом смысле задача импортозамещения для России стала сегодня очень актуальной.

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

Но всё не так плохо, как могло бы быть. Десять лет назад было бы намного сложнее. А сейчас происходит технологическая и цифровая революция. Мы все инвестируем в новое поколение продуктов, для того чтобы успешно справляться с вызовами времени. Устаревшее (Legacy) программное обеспечение уже не справляется с новыми задачами. Его всё равно придётся менять на новое.

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

Мир всё больше сдвигается к так называемому открытому программному обеспечению. Оно не иностранное и не российское — код находится в открытом доступе. Если простыми словами, это выглядит так. В Интернете есть различные коды, более или менее сложные, их можно скачать бесплатно. Но пользоваться в таком виде ими небезопасно и критично для бизнеса. Кто-то должен взять ответственность за качество кода. В мире находятся компании, которые это успешно делают, а другие пользуются их услугами. Ярким примером является компания Red Hat, которая была куплена в прошлом году компанией IBM за 28 миллиардов долларов. То есть нет необходимости что-то очень сложное создавать с нуля (это практически невозможно). Необходимо разобраться и взять под контроль то, что уже существует. А это точно по силам и в условиях импортозамещения предстоит сделать российским разработчикам. Многое уже делается. Есть компании, которые взяли под контроль операционную систему Linux. Под контролем и база данных PostgreSQL. Наша компания под брендом Digital Q взяла под контроль целый класс продуктов в микросервисном стеке технологий: Docker, Kafka, Kubernetes и другие. Все эти продукты сертифицированы нашим государством и вошли в реестр отечественного программного обеспечения.

Проделана большая работа: в этом бесплатном коде надо было разобраться (что, поверьте, весьма непросто и требует очень квалифицированных программистов), чтобы иметь возможность вносить коррективы — и взять код под своё управление.

А значит — нести ответственность за эту версию кода, исправлять в нём ошибки, развивать и так далее. Это обязательно, потому что никто не станет работать на коде, лишённом сопровождения, как говорится, себе дороже.

На моих глазах за два десятилетия ушли на вторые-третьи роли, а то и вообще в небытие, десятки компаний. Причины разные, но в чём-то похожие — самоуспокоенность, желание жить на багаже прошлого и неприятие рисков, которые всегда несёт в себе поиск.

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

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

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

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

По существу, сейчас происходит водораздел между «бывшим» и «будущим». И не надо надеяться на то, что можно выбрать более спокойный путь. Обратной дороги нет, так что, если не успеешь сегодня — можешь опоздать навсегда.