Agile

Выступление Антона Исанина, руководителя центра качества «Альфа-Банка», набрало максимальное число позитивных отзывов участников конференции «Agile, DevOps и ITIL – инструменты цифровизации», проведенной издательством «Открытые системы». Сокращение вывода новых продуктов на рынок до пяти дней с помощью подходов DevOps – результат, заслуживающий уважения.

Основная проблема водопадной модели заключается в том, что процессы проходят ужасно медленно. Между участниками команд порождается множество недопониманий, и конечный результат ухудшается. В случае Agile изменения происходят по-прежнему медленно – они занимают пусть и не месяцы, но все равно десятки дней. А главное – команда по-прежнему не чувствует рынка, остаются «стены» между владельцем продукта и разработчиками. Сочетание подходов Agile и DevOps позволяет обеспечить максимальную чувствительность к рынку и минимизировать длительность пути к удовлетворению потребностей клиента в некоторых случаях до пяти дней.

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

Успеть за возможностями

С точки зрения бизнеса все просто: DevOps нужен для того, чтобы максимально приблизиться к клиенту и его потребностям. В традиционном водопаде расстояние от клиента до команды разработчиков велико, и ИТ-специалисты, занимающиеся разработкой, не имеют тесной связи с рынком. Когда продуктологи осознают необходимость вывода на рынок нового продукта, они долго это обсуждают, выделяют менеджера продукта, менеджера проекта из ИТ-службы. Между ними есть непонимание, они говорят на разных языках, и это порождает дефекты – отклонения системы от реальных потребностей клиентов и пожеланий бизнес-заказчиков. Менеджер проекта набирает для разработки решения аналитиков, разработчиков, тестировщиков. Взаимодействие между ними тоже не идеально, на каждом этапе добавляются дефекты. В итоге продукт выводится в эксплуатацию в лучшем случае спустя год и получается далеким от первоначальной задумки.

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

Антон Исанин, руководитель центра качества «Альфа-Банка»: «DevOps позволяет быть ближе к клиенту, а если мы понимаем клиента, то понимаем, как заработать деньги, и это уже половина успеха. Вторая половина успеха – максимально быстро удовлетворить эти потребности»

«Если мы хотим не просто удержаться на плаву, но и развиваться, отвечать требованиям акционеров, нам тоже приходится меняться», – говорит Исанин.

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

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

«Есть нюанс: при таком подходе команда готова оперативно внедрять решения, но между ней и отделом продаж по-прежнему стена», – констатирует Исанин. Люди уже готовы к изменениям согласно agile-манифесту, который говорит, что изменения приветствуются, что они важнее следования изначальному плану. Тем не менее расстояние до рынка все равно остается существенным, между владельцем продукта и скрам-командой есть непонимание. Отдельно следует отметить отношения со службой сопровождения, с которой возникают трения относительно архитектурных вопросов и ответственности за надежность.

Разрушение стен и объединение людей в рамках единой команды – необходимый шаг для перехода к DevOps. Такая конфигурация хороша тем, что расстояние от команды разработчиков до клиента заметно сокращается. Чем больше посредников между разработчиками и клиентом, тем сложнее понять, что ему нужно, на каждом этапе возникает эффект испорченного телефона. Гораздо лучше дать возможность всей команде «слушать» рынок и думать, как принести клиенту пользу.

«Команда должна быть целиком сфокусирована на рынке. Чем больше барьеров мы устраним между рынком и командой, тем больше вероятность коммерческой состоятельности банка», – говорит Исанин.

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

«Мы минимизируем путь к удовлетворению клиента, меняемся быстро – за дни. В случае agile-команд время создания продукта сокращается до 20 дней. Подход DevOps сокращает цикл разработки до 5 дней», – подчеркивает Исанин. Когда все необходимые действия зависят от единой команды, заинтересованной в результате, удается избежать потери времени на самых разных этапах проекта.

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

Мельче, но быстрее

«Чтобы быстро выпустить продукт на рынок, задачу надо раздробить. Есть простая связь: чем лучше удается дробить ценность, доставляемую клиенту, тем ощутимее эффект. И чем мельче получаются кусочки, тем лучше работает автоматизация», – уверен Исанин. DevOps превращается в непрерывный поток маленьких кусочков продуктов, которые едут по автоматическому конвейеру.

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

В «Альфа-Банке» автоматизация процессов разработки была начата с процессов тестирования.

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

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

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

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

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

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

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

«Ставя во главу угла технический подход, компании упускают то главное, что на самом деле скрывается за цифровой трансформацией, – указал главный аналитик компании Altimeter Брайан Солис. – Организации в целом и руководители их ИТ-служб в частности попадают в так называемую технологическую ловушку. По сути они пытаются возвести новую постройку на старом фундаменте».

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

1. Цифровая трансформация – это на самом деле трансформация человека

Когда несколько лет назад Шамим Мохаммед стал директором ИТ-службы в компании-ретейлере CarMax, торгующей подержанными автомобилями, он думал прежде всего «не о трансформирующих технологиях, а о том, как надо будет проводить преобразования … с тем чтобы все двигались в правильном направлении и с нужной скоростью».

Эти же самые мысли были и у директора ИТ-службы компании TGen Джеймса Лоуи, который одной из главных задач трансформации бизнеса считает своевременное приобретение и укрепление работниками навыков, необходимых для проведения соответствующих изменений. «Зачастую темпы технологических изменений вступают в конфликт с уровнем профессиональной подготовки сотрудников, – заметил он. – Залогом истинной цифровой трансформации являются увлеченные, любознательные и мотивированные люди».

Несколько лет назад в компании Pitney Bowes решили повнимательнее присмотреться к ведущим технологиям, используемым в десяти функциональных областях, включая мобильную сферу, данные, аналитику, машинное обучение, API, SaaS и формирование пользовательского восприятия. «Для успешного продвижения вперед нашей организации наряду с четкой технической стратегией нужна была еще и стратегия в отношении людей», – вспоминает старший вице-президент Pitney Bowes по вопросам технологий и электронной коммерции Джеймс Фейруэзер.

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

Этот сдвиг мышления помог компании совершить рывок вперед. «За прошедшие 10 лет мы сделали 80 приобретений, смогли укрепить связи, сформировать новые взаимоотношения и добиться того, чтобы сотрудники получше узнали друг друга», – отметил Фейруэзер.

2. Придерживайтесь ориентированного на клиентов подхода

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

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

Прежде всего они ориентируются на клиентское восприятие.

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

3. Формируйте новые команды

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

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

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

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

Аналогичного подхода придерживаются и в компании – поставщике сельскохозяйственного оборудования John Deere, где руководство составило план реализации перспективного проекта умного подключенного предприятия. На одной из фабрик компании было организовано пространство Foundry площадью 650 квадратных метров с более низкими, чем обычно, столами, с тем чтобы людям удобнее было общаться. Там предполагалось собирать новые команды и изучать agile-методологии при содействии экспертов, которые проводили бы сотрудников через полный цикл разработки.

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

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

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

«В прошлом нас считали центром затрат, – указал Джаярам. – Теперь же нам отводится роль пробивного тарана. Впервые в истории John Deere мы возглавили процесс. Мы приняли врученный нам мандат».

4. В процессе внедрения технологий укрепляйте взаимодействие

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

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

Усилия, направленные на укрепление взаимодействия, окупают себя. «Делясь практическим опытом, мы выявили типичные сбои, возникавшие в процессе операционной деятельности, – отметил Фейруэзер. – Нам удалось распространить свою практику на все команды, улучшив и скорректировав их совместную работу».

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

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

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

«Конечно, у нас были скептики, – заметила вице-президент GE Commercial и подключенной цифровой экосистемы digitalTHREAD Кейт Гутовски. – Но, если мы нацелились провести какие-то преобразования, равняться на таких людей не стоит».

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

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

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

6. Вырабатывайте менталитет стартапа

В 2014 году к купленному AT&T оператору добавилась вновь приобретенная компания Cricket Wireless. Две конкурировавшие друг с другом организации требовалось преобразовать в единого крупного игрока национального масштаба.

Подобно John Deere и CarMax, Cricket Wireless взяла на вооружение модель Agile. Все силы были приложены к тому, чтобы действовать быстро и добросовестно.

«По мере укрупнения организаций в них выделяются различные группы, что приводит к информационной разобщенности, – отметил вице-президент и ИТ-директор Cricket Wireless Дарин Морроу. – Разрушать вырастающие стены помогают менталитет стартапа и укрепление взаимодействия между отдельными командами».

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

7. Добивайтесь от руководства дополнительных полномочий

Проведенный Altimeter опрос показал, что только 40% компаний создают наделенный необходимыми полномочиями управляющий комитет, ответственный за организационную трансформацию.

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

После этого Джаярам пошел к руководству и представил план интеллектуального подключения и agile-методологии.

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

– Esther Shein. 7 habits of highly effective digital transformations. CIO. November 6, 2017

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

Андрей Заварзин Возраст: 39 лет Послужной список: 2016 – настоящее время Сбербанк, директор дивизиона «Массовая персонализация» 2012 – 2016 Сбербанк, СТО/CIO различных направлений 2010 – 2012 «Альфа-Банк», директор дирекции Business Intelligence 2008 – 2010 Авиахолдинг «Волга-Днепр», директор по ИТ 2004 – 2008 «ЛУКОЙЛ-Информ», советник генерального директора 1999 – 2004 Академия ФСБ, преподаватель факультета прикладной математики Образование: Академия ФСБ, ИКСИ («прикладная математика») РЭА им. Плеханова («стратегический менеджмент») Финансовая академия при Правительстве РФ. Бизнес-школа

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

Это действительно очень интересная трансформация. И очень динамичная. За тот период, что я в Сбербанке, мы прошли уже четыре стадии! В 2012 году я пришел в «Сбербанк Технологии» (ИТ-дочку Сбербанка) на должность начальника управления в департамент клиентских отношений и наблюдал все проходившие изменения непосредственно в ходе своего карьерного роста.

Идея создания департамента клиентских отношений в «СберТехе» была в том, чтобы централизовать управление ИТ-развитием в интересах конкретного блока (бизнес-блока или обеспечивающего), потому что тогда в «СберТехе» никто не отвечал перед конкретным членом правления Сбербанка за результат всех своих проектов, не отслеживал взаимосвязи между ними. Я отвечал за все проекты операционного блока, и моим визави была его руководитель Ольга Канович. Такая модель управления очень понравилась правлению, и вскоре ее решили расширить. Теперь ИТ-директор блока (CIO) должен был отвечать не только за ИТ-проекты, но и за все ИТ-роли – архитектуру, аналитику, разработку, проектное управление, тестирование, внедрение, сопровождение. А раз так, то это должна была быть роль в центральном аппарате, а не в ИТ-дочке. Так ИТ начали постепенно проникать в основной бизнес.

В дальнейшем я был назначен CIO всех обеспечивающих блоков – к операционному блоку прибавились безопасность, управление кадрами, стратегия. Мы выстраивали процессы не только развития, но и сопровождения, заключали соглашения об уровне обслуживания (SLA). Эта модель тоже «взлетела», и мы пошли дальше – ввели должность Chief Technology Officer. Произошло создание блока «Технологии» на базе блока ИТ и операционного блока, а СТО стал отвечать не только за ИТ, но и за операционную деятельность, одновременно накапливая ресурсы и экспертизу по сквозным бизнес-процессам. Так я стал СТО розничного бизнеса. Чтобы решать задачи, я мог внедрять ИТ или ручные процессы, балансируя скорость, стоимость и качество. По задумке, СТО должен был стать чуть ли не вторым человеком в бизнесе, так как глубоко понимал процессную составляющую всех направлений.

И здесь пришел Agile – пришел весьма стремительно. В январе 2016-го мы первый раз съездили с референс-визитом в голландский финансовый конгломерат ING, а уже в сентябре 2016 года Герман Оскарович дал старт Agile в новом офисе на Кутузовском (мы этот офис называем Agile home). Идея, что бизнес на самом деле и есть ИТ (и наоборот), означала, что все действующие лица должны перемешаться. И в такой модели роли CIO или CТO уже не требовалось. Для меня это стало не угрозой для карьеры, а новой возможностью. Я получил новое назначение – возглавил дивизион «Массовая персонализация», который отвечает за розничные данные, моделирование, персональные предложения во всех каналах, вторичные продажи и телемаркетинг. На мой взгляд, это самая интересная область бизнеса.

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

«Сбербанк накрыло волной цифровой трансформации, и все те математические и технические знания, которые у меня накопились, стали абсолютно востребованными в основной деятельности банка»

Правомерно ли говорить о цифровой трансформации организации без изменения ее бизнес-модели?

Действительно, трансформация может быть, что называется, Disrupt. Это наиболее радикальный вариант – изменение бизнес-модели. Но можно говорить и о Change – трансформации внутренних процессов, когда они принципиально меняются.

Например, бизнес-модель Сбербанка, касающаяся выдачи кредитов, не поменялась. Еще в 2008 году был принят курс на то, что у нас должна быть самая лучшая риск-служба. Мы сделали очень качественный полуручной процесс. Профессиональные сотрудники проверяли документы и принимали решение о выдаче кредитов. У нас действительно была лучшая система управления рисками, мы хорошо определяли, кому следует давать кредиты, а кому – нет. Дальше началась эра больших данных, и ручной труд стал замещаться алгоритмами. При этом качество нашего портфеля продолжает расти. Бизнес-модель не менялась, просто один из процессов, который был полностью ручным, стал полностью цифровым. Один из моих совместных проектов с департаментом рисков – «Ноль полей в анкете». Мы не должны заставлять нашего клиента ждать и тратить лишнее время.

Что касается мобильных приложений, то они, я считаю, в традиционном виде будут постепенно умирать. Клиенты все больше предпочитают взаимодействовать с виртуальным ассистентом, а не самостоятельно вносить данные. Если раньше у нас был лозунг Mobile first, то теперь – Artificial Intelligence first, и все, что мы делаем, должно восприниматься через призму анализа данных. Тенденция очевидна: все большая доля поисковых запросов в Google происходит посредством голоса, и дальше она будет расти как снежный ком. Пока виртуальные помощники, конечно, «сырые», но развиваются очень быстро.

Agile в Сбербанке, который благодаря усилиям Германа Грефа стал широко известен даже далеким от ИТ людям, – это в первую очередь скорость и гибкость или это больше ориентация на потребности бизнеса?

Скорее, речь нужно вести о результате. Этот подход позволяет добиться того, что нужно. Заметьте, не «того, что хотели», а «того, что на самом деле нужно», так как изначальная цель вполне может в ходе проекта поменяться. Однако не менее важны культурные изменения в работе.

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

«Если людей из разных подразделений усадить вместе, они начинают работать совершенно по-другому. У них появляется удовольствие от работы – так называемый фан. Когда айтишники сталкиваются с реальными клиентами и задачами, с реальной ответственностью за то, что делают, и видят конечный результат работы, все меняется»

Удовольствие от работы имеет и оборотную сторону. Если в ИТ-департаменте были недостаточно эффективные люди и это мало кого заботило, то agile-команда, взявшая на себя определенные обязательства, каждые две недели должна отчитываться за спринты. Если рядом сидит ничего не делающий балласт, то многие вспоминают фразу Атоса перед дракой с гвардейцами кардинала: «А потом скажут, что нас было четверо», – и команда самоочищается.

Неужели всё так просто – сели вместе и начали «получать удовольствие»? Не все к этому бывают готовы. И как быть с раздуванием штата? Для организации такого масштаба это критично...

Да, может показаться, что создание самодостаточных agile-команд способствует раздуванию штата. Но, когда в «СберТехе» работают 10 тыс. человек, разобраться, кто из них лишний, возможности нет. А вот когда мы их пересаживаем в отдельные команды, то, во-первых, сразу видно, кто работает, а кто – нет, и шлак отсеивается. Во-вторых, видно, сколько погонял-руководителей приходится на одного конкретного исполнителя. Выясняется, что столько руководителей не нужно, и происходит сокращение численности.

Сокращение также происходит за счет людей, не принимающих новые подходы. Например, у меня на протяжении долгих лет был личный кабинет, а сейчас я сижу в открытом пространстве в шумоподавляющих наушниках. Перемены, прямо скажем, непростые. В ING нам сказали, что при переходе в Agile они практически одномоментно потеряли 30% персонала. По моей оценке, Сбербанк покинуло поменьше народа, но тоже ощутимо. Надо сказать, что позитивных примеров гораздо больше. Ключевые соратники перестроились, набрали команды и сейчас показывают удивительные результаты.

Если говорить о более низком уровне, то где-то получилось перестроиться сразу, где-то нет. Я уже полгода пытаюсь решить задачу, как подружить в рамках единой команды исследователей данных, CRM-менеджеров и людей, занимающихся маркетинговыми кампаниями. Они не очень-то доверяют друг другу. Готовлю их, чтобы избежать потрясений, показываю плюсы и минусы. Для этого я использую институт agile-коучей, часто работающих как психологи. Они следят за климатом и помогают правильно скомбинировать людей.

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

Какие эффекты и последствия имело слияние ИТ с бизнесом?

Один из самых трудных вопросов, когда мы переходили на Agile, был такой: «Кто ответит за надежность?» Именно с надежностью ассоциируется Сбербанк. Развивая функциональность команды, мы поняли, что за надежность бизнес-сервиса должна отвечать именно команда, занимающаяся этим продуктом, а не только централизованная ИТ-служба. Часть служб, функций по поддержке той или иной конкретной системы передается в agile-команду, отвечающую за ее развитие.

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

ITSM – это именно про надежность и стабильность работы. Сейчас часть функций, отвечающих за это, перенесена в agile-команды. Мы, проверяя себя, задавали вопрос, кто пойдет «на ковер» в голландский парламент (у ING, как и у Сбербанка, около 50% доли местного рынка), если случится простой системы, – ИТ-директор или кто-то другой. Как выяснилось, ответственность лежит на руководителе, контролирующем продукт, – это product owner, central product owner или лидер трайба (трайбы – названия подразделений в методологии Agile. – Прим. ред.). Это особенность культуры – больше нет конфликта между развитием и сопровождением систем, жестких границ и непримиримых позиций. Есть команда, которая сама решает свои проблемы и, естественно, проблемы клиентов.

Фото: Сбербанк

Правильно ли противопоставлять классический ITSM, фокусирующийся на качестве, и гибкие методики? Возможно ли их подружить?

Agile и ITSM вовсе не являются конкурентами. Совершенно не нужно их противопоставлять, надо брать из каждой модели лучшее и комбинировать, важно уйти от поклонения какой-либо одной методологии. Да, ITSM изначально фокусируется на эксплуатации систем (Run), а Agile – на изменениях (Change), но в современном мире Run становится частью Change.

Кстати, ITSM – замечательный подход, который я уже второй раз применяю там, где раньше им даже не пахло. Я перестраиваю работу бизнес-подразделения в соответствии с ITSM, потому что требуется управлять инцидентами и проблемами. Это два базовых процесса для любого руководителя, не только ИТ.

В 2012 году, когда меня принимали на работу в Сбербанк, я проходил собеседование с двумя членами правления – тогдашним руководителем блока ИТ Виктором Орловским и руководителем операционного блока Ольгой Канович. Орловский спросил меня, какие управленческие инструменты я использую, мы начали это обсуждать. Он рассказал про свои – например, модель типологии менеджеров Адизеса. Я – про свои, в том числе о том, как применял ITSM в «Альфа-Банке» для решения совершенно нетипичной задачи – повышения качества информации.

Я пришел в «Альфа-Банк» руководить дирекцией Business Intelligence – это была очередная попытка уйти из ИТ. Весь банк с недоверием относился к той информации и отчетности, которую выпускала наша дирекция. Финансовые директора блоков говорили, что не могут управлять бизнесом. Например, невозможно мотивировать клиентских менеджеров на продажи, если результат не соответствует реальности. Такие недоверие и недовольство отражали объективное положение дел, но в каждом случае были очень субъективными. Претензии к отчетности предъявляли телефонными звонками, гневными письмами и т. д. Я перевел все претензии к отчетности в службу поддержки и создал соответствующую группу разбора. Через пару месяцев мы точно знали, в каких строках отчетности содержатся ошибки, каковы причины этих ошибок, кто из людей находит реальные ошибки, а кто «спамит» и перекладывает на других ответственность за свои плохие продажи. Я с удивлением увидел, что самые большие ошибки дают не технологии, а сбои на стыках процессов. Через полгода ситуацию удалось полностью выправить. Я не слышал до этого, чтобы кто-то применил ITSM для выпуска управленческой отчетности.

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

Про agile-трансформацию, начатую в 2016 году, слышали все. А с марта 2017 года наступила ее вторая, менее разрекламированная стадия – переход на DevOps. Что реально изменилось?

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

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

Андрей Заварзин, директор дивизиона «Массовая персонализация» Сбербанка: «У меня на протяжении долгих лет был личный кабинет, а сейчас я сижу в открытом пространстве в шумоподавляющих наушниках»

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

Мы сейчас строим новую платформу – системы фронт- и бэк-энд, а также хранилище данных – стандартные крупные ИТ-компоненты для любого банка. И, строя каждый из них, мы закладываем технологическую возможность использования DevOps. При этом половина систем – унаследованные, их мы по возможности «дотачиваем», чтобы DevOps стал возможным.

Итак, ITSM в бизнесе – уже пройденный этап, его эффективность доказана. А DevOps в бизнесе?

Да, у меня ситуация еще интереснее, чем в ИТ-службах. Наш дивизион занимается управлением розничными данными, их анализом и формированием кампаний. У нас есть много различных ролей: инженеры по данным; аналитики, просчитывающие результаты кампаний; классические исследователи данных, строящие глубокие модели; специалисты по кампаниям в реальном времени, строящие инфраструктуру для создания автоматических предложений в контексте жизненных ситуаций. Есть и более традиционные специалисты по статическим кампаниям, занимающиеся вопросами CRM и управления рисками.

Эти люди раньше сидели в отдельных «колодцах». А мне нужно «шить костюм», демонстрировать клиентам ценность, и ценность дает именно комбинация всех ролей. Как и в случае с ITSM, я использую Agile иногда вообще не там, где можно ожидать. В тех случаях, когда идет речь о работе с данными, все относительно традиционно: есть бизнес-специалисты и ИТ-специалисты, они объединяются в команды и строят компоненты клиентского профиля. Но параллельно с ними работает слой анализа кампаний – это полностью бизнесовые роли, и я их тоже комбинирую, формируя эффективные команды.

Конечно, подход DevOps – полностью айтишный: он заключается в том, что необходимо иметь возможность оперативно протестировать функциональность, отследить обратную связь. Я делаю «бизнес-DevOps»: например, у нас есть гипотеза относительно того, какие предложения будут хорошо восприняты клиентом. Мы берем выборку из тысяч людей (в Сбербанке это можно себе позволить) и делаем автоматизированную систему, чтобы специалист настроил параметры кампаний и на следующий день уже видел результаты. В этом случае можно поправить параметры и мгновенно запустить следующую итерацию. Таким образом, DevOps применяется в абсолютно бизнесовых процессах. Раньше такого никогда не делали – специалист может пропилотировать модель, она пройдет по всей стране и соберет отклик, и на следующий день будет видно, на правильном ли мы пути.

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

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

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

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

Иллюзия № 1. Мы ориентируем ИТ на бизнес.

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

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

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

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

Иллюзия № 2. Единственная причина обновления программного обеспечения обусловлена реализацией в новой версии важных ценностей бизнеса.

Это не просто звучит убедительно, а принимается как руководство к действию. Явно, что ИТ-директор, проводящий такую политику, ориентирован на бизнес (и соответствие его целям) и его никак нельзя обвинить в тратах на технологии ради самих технологий.

Более того, при таком раскладе ИТ-бюджет можно сокращать, поскольку нет необходимости в средствах на поддержание актуальных версий.

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

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

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

Вот как обычно развиваются события.

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

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

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

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

А во-вторых, начинают подыскивать себе работу, пока проваленный проект еще не погубил их репутацию.

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

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

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

Иллюзия № 4. Мы придерживаемся методологии ITIL.

Это может показаться придиркой, но «придерживаться» ITIL невозможно. ITIL – это библиотека инфраструктуры ИТ, как терпеливо объясняют ее сторонники всем, кто готов слушать.

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

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

Иллюзия № 5. Мы исповедуем agile-разработку.

В мире есть много ИТ-организаций, уже перешедших от разработки приложений методом водопада к одному или нескольким вариантам agile-проектирования либо находящихся в процессе такого перехода.

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

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

Иллюзия № 6. Мы придерживаемся DevOps.

Ничего подобного. Вы не придерживаетесь даже agile-проектирования. И удосужились ли прочесть все то, что было написано ранее?

Ну хорошо, соглашусь с тем, что при всей шумихе вокруг DevOps сторонники этого подхода не являются изобретателями взаимодействия. Гибкое проектирование – реальное, а не гибко-водопадное – способствовало реальному взаимодействию задолго до появления DevOps, хотя справедливости ради следует признать, что разработчики не больно-то взаимодействуют с персоналом, занимающимся обслуживанием.

Вот что DevOps добавляет в гибкое проектирование.

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

Третий момент связан с DevOps, а не с другими вариантами гибкого проектирования и уж, конечно, не с водопадной методологией. Дело в том, что программное обеспечение находится в состоянии постоянного развертывания (deployable). Нет, нет, не deplorable (в плачевном виде), а deployable. Наряду с многочисленными неудобствами для большинства сторонников гибкой разработки это означает, что DevOps и Scrum не являются полностью совместимыми. Kanban работает лучше.

Иллюзия № 7. У нас есть культура обслуживания клиентов.

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

Впрочем, это неважно, ведь когда культура есть, ИТ-директор считает, что весь бизнес является его клиентом.

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

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

ИТ-директор должен воспитывать в ИТ-службе культуру обслуживания.

Как узнать, есть ли у вас эта культура или нет? Если вы по-прежнему слышите рассказы об идиотах-пользователях, значит, ее нет.

Иллюзия № 8. Наша информационная безопасность на высоте

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

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

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

Иллюзия № 9. Наш процесс управления ИТ гарантирует реализацию только тех проектов, которые имеют высокую ценность для бизнеса

Давайте опять вернемся к соответствию целям бизнеса.

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

Таким образом окончательные решения становятся еще и предметом торга и выстраивания личных взаимоотношений.

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

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

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

– Bob Lewis. 9 lies CIOs tell themselves. CIO. August 21, 2017

Существенная часть аgile-трансформации – изменение культуры. Гибкой следует делать всю организацию целиком. Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка», рекомендует руководителям, которые хотят построить гибкую организацию, запастись терпением и быть аgile, а не внедрять его. Таков был главный посыл его выступления на форуме ITMF 2017, организованном издательством «Открытые системы».

– Зачем вы хотите стать agile?

Чтобы быстро запускать новые идеи и делать так, чтобы клиентам это очень нравилось.

– С чего у вас все началось?

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

Agile, DevOps и Scrum – это зачастую дорого. Но на уровне правления мы решили, что нам важнее скорость запуска продуктов и уровень удовлетворенности клиентов.

– Почему дорого, если вы экономите время. Ведь время стоит денег?

Но размер команды-то меняется... Например, за развитие фронт-офисных систем отвечает команда из 50 человек, у нее 30 заказчиков. В этих системах обслуживаются кредиты, депозиты и другие банковские продукты. Если мы строим продуктовую команду, нам нужны разработчики, хотя бы по два на каждый продукт. То же самое с тестировщиками и поддержкой, которые нужны в каждой команде. То есть штат растет, и надо понимать для чего это.

– Рост штата не компенсируется повышением скорости?

Затраты растут, но мы ожидаем, что и прибыль вырастет – благодаря тому, что мы делаем быстрее и больше, фокусируемся на удовлетворении потребностей клиентов. Когда целями являются time-to-market, клиентский опыт (customer experience) и повышение индекса потребительской лояльности (net promoter score, NPS), то аргумент «дорого» отходит на второй план.

Вот, к примеру, такая ситуация. Бизнес-заказчик спрашивает, когда для него сделают нужную ему доработку, а ему отвечают: вот очередь твоих коллег, приходи через месяц или докажи, что твоя задача – самая приоритетная. Вариант нанять еще 10 человек и сделать работу за месяц не проходит, потому что нет возможности наращивать расходы на ИТ. Количество запросов от заказчиков очень высоко, и если не увеличить число разработчиков, то нужные продукты будут получены только к 2028 году.

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

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

– Сколько у вас команд сейчас и сколько предполагается в будущем?

Раньше у нас была одна команда из 50 человек и псевдогибкость – релизы мы выдавали не чаще раза в месяц. Теперь ее разбили на 10 команд поменьше, убрали очередь заказчиков. Сервисных команд сейчас 25, а продуктовых будет не менее 50.

– Внедрить гибкий подход вы пытались неоднократно. Когда наступил переломный момент?

До 2013 года предпринимались попытки внедрить аgile «снизу вверх», а в 2014-2015 годах – привнести его извне. В 2016 году председатель правления банка вышел на совет директоров и сказал, что хочет построить agile-организацию. C тех пор все изменилось, agile-команда стала не айтишной, а полнофункциональной, в нее вошли управляющие директора, которые отвечают за кредитные и некредитные продукты в ретейле. Они почувствовали все преимущества гибкости и теперь сами ее хотят. Поменялось и то, как мы внедряем agile. Мы внедряем его не по плану, а по Scrum.

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

В связи с этим возникает множество вопросов. Как работают проекты? Какие нужны метрики? Как меняется роль топ-менеджеров?

– На каких проектах происходило внедрение agile?

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

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

Когда CPO (Chief Product Owner) это попробовал, то стал самым главным поборником всей этой истории, потому что понимает, чем заняты его сотрудники каждый день, почему это столько стоит, и отдачу начинает получать через месяц. Мы быстро тестируем идеи и начинаем зарабатывать сразу. А если это не нужно, то понимаем это не через три года, а через месяц и перестаем тратить деньги.

– В перспективе вы откажетесь от проектного управления или будете комбинировать его с agile? Какие ограничения agile вы видите?

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

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

– Банк по сути жесткая структура, как он может быть agile? Как можно сочетать жесткость и гибкость?

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

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

– Помимо поддержки руководителя компании, какие еще условия должны выполняться, чтобы agile был эффективен?

Без поддержки руководства трансформация просто невозможна. И вся корпоративная бюрократия должна ее поддерживать. Корпоративные ценности должны соответствовать agile, а если не соответствуют, то их надо менять.

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

Cистема корпоративного обучения также подвергается изменениям, особенно если она была построена на таких вещах как ITSM или PMBOK.

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

– Что вы посоветуете ИТ-руководителям, которые хотят внедрить agile?

Первым делом – запастись терпением. Каждую неделю мы рассказываем про аgile на разных уровнях – и этого все равно недостаточно. Мы занимались DevOps полтора года, много и активно вкладываясь, но казалось, что ничего не происходило. Однако спустя полгода вдруг что-то начинает появляться как бы само. Мозг у людей быстро не поменяется, надо несколько лет рассказывать одно и то же.

С точки зрения agile в ИТ мы лидеры среди европейских подразделений банка, но с точки зрения бизнеса мы только в начале пути, хотя по сравнению с другими организациями у нас большой прогресс. Мы поняли, что такое продукт, каковы полномочия «собственника» продукта, и к концу 2017 года запустим множество продуктовых команд по Scrum. А дальше будем долго «докручивать» всю бюрократическую обвязку и долго-долго менять мышление.

Владимир Тихомиров, который руководит ИТ-департаментом «Ингосстраха» с 2009 года, рассказал о том, как цифровые технологии трансформируют отрасль, бизнес компании и ее ИТ-службу.

Что изменилось в страховом бизнесе под влиянием технологий? Можно ли сегодня говорить о цифровой трансформации отрасли?

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

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

Владимир Тихомиров Возраст: 57 лет Образование: Московский инженерно-физический институт (1982), инженер-системотехник (специальность «АСУ»), аспирантура Послужной список: 1997 – настоящее время СПАО «Ингосстрах», различные должности, сейчас – директор департамента ИТ 1996 – 1997 РАКБ «Москва», начальник отдела 1994 – 1995 ВАО «Интурист», главный системный программист 1987 – 1993 МИФИ, кафедра АСУ, младший научный сотрудник, научный сотрудник

Вы наблюдаете ИТ-эволюцию «Ингосстраха» вот уже 20 лет. Какие наиболее важные изменения произошли за последнее время?

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

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

В какие организационные преобразования выливается рост значимости ИТ-службы?

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

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

Какая методология гибкой разработки применяется в компании?

Мы не пытаемся внедрить какую-то конкретную методологию, а экспериментируем, ищем подходы. В этом нам помогает опыт наших подрядчиков, которые консультируют и обучают нас.

Уже полгода у нас работают три команды по методике Scrum. Этот вариант, конечно, более затратный, он требует больше персонала, чем традиционный подход, но зато дает резкое сокращение времени вывода продукта на рынок – time to market. По сложным большим задачам мы сократили время разработки в два раза, а по мелким – до десяти раз.

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

«Аgile применим не только в ИТ. На уровне компании в целом также внедряются новые подходы для решения комплексных задач»

Какие ограничения в применении agile-подхода вы видите?

Быстрое создание и внедрение новой технологии имеет отдаленные по времени негативные последствия – появляются проблемы с архитектурой, непроработанные решения, сделанные на скорую руку. Scrum дает отличный эффект для команды, разрабатывающей ПО с нуля. Когда такой подход масштабируется на большой коллектив разработчиков, который занят комплексной доработкой большой системы, проявляются его минусы, и основной из них – упущение архитектурной проработки. Кроме того, когда разрабатываемое решение обрастает функционалом в течение нескольких лет, на создание нового функционала сил команды уже не хватает. Поправить дело можно, только вводя много Scrum-команд и организуя между ними эффективное взаимодействие. Ну а каждая связь – это расходы, и они с ростом числа вовлеченных людей растут экспоненциально.

Для решения этих проблем существует методология управления большим количеством agile-команд в крупных корпоративных проектах – Scaled Agile Framework, SAFe. Чтобы соблюдалась общая концепция системы, действия команд периодически синхронизируются, вводится бизнес-процесс согласования архитектурных решений и иерархия архитекторов, которые эти решения согласуют.

То есть разработку нужно несколько замедлить, чтобы избежать проблем в будущем?

Нет, скорость не снижается. Но с появлением иерархии и управленцев растут накладные расходы.

Вы примеряете на себя эти нововведения?

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

Против мошенников

Артем Литвин, заместитель директора департамента ИТ компании «Ингосстрах» Фото: Роберт Каримов

Снизить трудоемкость борьбы с мошенничеством в автостраховании и добровольном медицинском страховании «Ингосстраху» помогают экспертные системы.

Как рассказал Артем Литвин, заместитель директора департамента ИТ компании «Ингосстрах», при регистрации договор или убыток автоматически проходит проверку в экспертной системе на основе заданных правил. Практически в реальном времени выявляются подозрительные сведения, которые могут указывать на различные мошеннические схемы. Тем самым значительно облегчается контроль при большом объеме информации.

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

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

Какого рода задачи решают команды agile?

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

Уже в текущем году планируем запустить еще семь Scrum-команд, а со временем их будет около 20. Поскольку все они работают над одной информационной системой, им потребуется довольно плотно взаимодействовать. Поэтому нас и заинтересовала методология SAFe, ведь синхронизация трех команд и десяти – это разные управленческие задачи.

В разработке основной ИТ-системы «Ингосстрах» по-прежнему опирается на собственные силы?

Мы опираемся на систему собственной разработки, но развиваем ее не только своими силами, участие подрядчиков примерно равно нашему. Это позволяет более гибко управлять объемом ресурсов, когда появляются срочные внеплановые задачи или начинает расти поток требований бизнеса. Схемы взаимодействия с подрядчиками разные, это могут быть либо проекты разработки комплексных решений, либо передача отдельных задач.

В условиях кадрового голода привлечение подрядчиков часто позволяет быстрее решать срочные задачи. Но мы пробуем и альтернативные варианты: в прошлом году на базе филиалов в Перми и Иркутске открыли два удаленных центра разработки и сопровождения, которые подчиняются ИТ-департаменту в головном офисе. Благодаря более низким расходам на зарплату и эксплуатационные услуги, мы выигрываем 20-30% стоимости разработки. Кроме того, наличие ИТ-специалистов в других городах отчасти решает вопрос расширения времени поддержки пользователей и клиентов.

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

Технологии доступны всему рынку. А какие из них способны обеспечить компании конкурентные преимущества?

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

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

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

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

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

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

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

Что этому мешает? Вам нужны специалисты по data science в штат?

Вне всякого сомнения! Это сейчас очень серьезная проблема, найти таких специалистов крайне сложно, так что выращиваем своих.

Каковы основные направления развития ИТ в «Ингосстрахе» сегодня?

Два самых крупных направления – это онлайн и отчетность. Чтобы минимизировать визиты клиентов в офис, мы развиваем онлайн-продажи и онлайн-сервисы как для розничных, так и для корпоративных клиентов, в том числе подачу заявления об убытках, оплату взносов и франшиз через сайт. Отдельно можно выделить e-ОСАГО. У нас заключено уже более 80 тыс. договоров е-ОСАГО.

Надо сказать, что Центробанк все больше обращает внимание на внутренние процессы страховых компаний, в том числе на ИТ и информационную безопасность. Если раньше бесперебойная работа «24 на 7» была лозунгом, то с вводом онлайн-ОСАГО, она стала законодательной нормой. ЦБ требует, чтобы сайты страховых компаний работали с минимальным временем простоев, поддержка осуществлялась круглосуточно, а все действия клиентов на сайте протоколировались.

В 2017 году по требованию ЦБ на страховые компании распространены новые стандарты отчетности и единый план счетов. Существенные изменения учета обязательств и правил взаиморасчетов по договорам потребовали значительной переработки не только бухгалтерского блока, но и страхового. Мы внедрили новый порядок учета с 1 января 2017 года, как требовалось по закону, но доработки будут продолжаться, объем работы колоссальный.

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

Каким образом компания намерена монетизировать Большие Данные, накопленные в информационной системе? Используете ли вы анализ данных соцсетей?

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

Надеемся, что привлечение Больших Данных позволит делать персонализацию тарифов априори (предварительно). В прошлом году мы начали внедрять аналитическую платформу SAS, с ее помощью мы планируем решить ряд задач по сегментации клиентов, оценке и прогнозированию убыточности, выявлению дополнительных тарифных факторов. Например, проанализировав данные кредитных бюро, мы обнаружили зависимость между невозвратностью долгов и убыточностью страхования. Эта часть скоринга уже работает.

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

Методологии agile-разработки программного обеспечения существуют уже достаточно давно, но устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.

«Традиционный подход к заключению соглашений предполагает, что команда разработки может с помощью подробного технического проекта определять, с каким уровнем конкретизации будет конечный продукт, – говорит Дерек Шаффнер, адвокат юридической конторы Mayer Brown. – Согласовываются и указываются основные вехи, условия приемки клиентом и сроки получения выплат. Все это легко отразить в соглашении о разработке, поскольку процесс разработки традиционно носит линейный характер и начинается с детального планирования, после которого идут проектирование, написание кода, тестирование и ввод в эксплуатацию».

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

Однако существуют контрактные механизмы, и заказчики могут ими воспользоваться, чтобы уменьшить неопределенность, сохранив преимущества agile-разработки с ее кооперативным характером. О том, какие меры предосторожности понадобятся, Шаффер рассказал в интервью CIO Magazine.

- В чем главные сложности при составлении контрактов на agile-разработки?

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

- Для agile-разработки сделку с фиксированной ценой заключить не удастся. Как рассчитать расценки при подготовке agile-контракта?

Для agile-разработки ПО больше подойдет контракт, предусматривающий оплату затраченного рабочего времени и материалов (time and materials, T&M), но такой вариант может не устроить финансовый отдел и ИТ-директора. Ведь agile-разработка требует доверия, поскольку нет четких требований, а модель T&M может спровоцировать разработчика брать деньги за максимально большее количество часов.

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

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

- Как именно право на расторжение контракта работает в описанных ситуациях?

Учитывая, что цель каждой итерации – создать работоспособный код, за который оплата осуществляется по принципам T&M, как правило, договор позволяет клиенту прекратить проект в конце любой итерации, обычно без платы за аннулирование заказа. Если клиента не устраивает продукт, созданный за очередную итерацию, он просто может выйти из контракта. Вероятность того, что проект сильно отойдет от спецификаций за одну итерацию, минимальна, поскольку требования определяются в начале каждой итерации так, чтобы продвинуться к цели создания продукта в соответствии с общим замыслом.

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

- Agile-разработка по сути своей является изменчивой. Как заказчику предусмотреть в контракте какие-то вехи еще до начала работы?

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

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

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

- Как заказчику снизить риск текучки сотрудников на проектах, требующих непрерывной работы?

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

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

- При традиционном аутсорсинге разработки приложений поставщик услуг на определенное время дает гарантию того, что продукт будет работать согласно требованиям и любое несоответствие им будет устранено. Можно ли получить такие гарантии при agile-разработке?

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

- Как обговорить права на интеллектуальную собственность с учетом того, что agile-разработка подразумевает активное взаимодействие клиента и поставщика услуг?

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

- Если клиент тратит слишком много усилий на составление соглашения об agile-разработке, может ему не стоит передавать такую разработку вовне?

Соглашение на agile-разработку требует от клиента отказаться от определенной доли контроля и некоторых контрактных инструментов, которые можно было бы применить, если проект собьется с плана. Среди сложностей – необходимость полагаться на доверие, чему скорее всего будут противиться юристы организации-заказчика. Если клиента не устраивают отсутствие контроля и вариативность денежных затрат, то ему для разработки критически важных приложений больше подойдет традиционный подход.

– Stephanie Overby. How to contract for outsourcing agile development. CIO. July 1, 2016

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

Автономность, самосовершенствование и целеустремленность

Одна из отличительных особенностей молодых специалистов поколения миллениума – это потребность в автономном выполнении работы, постоянном совершенствовании и нацеленности на решение определенных задач. «Таким людям нужно видеть свой вклад в успех компаний, где они трудятся, и в развитие всего окружающего мира, – отметил владелец продукта в Scrum.org Дэйв Уэст. – Это одна из причин, по которым инженеры-программисты поколения миллениума проявляют склонность к методологии гибкого проектирования с ее упором на горизонтальное управление, саморегулируемые команды, работу в интересах бизнеса, итерационный подход и возможность быстро адаптироваться к меняющимся запросам и требованиям. Методологии agile были разработаны в 80-е годы для решения именно тех задач, с которыми стремятся иметь дело разработчики поколения миллениума. Они хотят трудиться автономно, заниматься творческой деятельностью, совместно с коллегами решать общие задачи, создавать ценности и видеть результаты своего труда. Мотивирующими факторами для них являются самосовершенствование, превращение в мастеров своего дела и стремление к достижению поставленной цели».

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

Многие технические менеджеры и инженеры старого поколения имеют опыт работы в военной сфере и придерживаются стиля управления «сверху вниз». Миллениалы в такой обстановке чувствуют себя неуютно. Эти люди тяготеют к agile-проектированию, где можно постоянно контактировать с представителями бизнес-подразделений. Они знают, что строят, почему их проект имеет более важное значение по сравнению с другими, и обсуждают с сотрудниками бизнес-подразделений идеи и предложения, которые должны способствовать успеху проекта.

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

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

Подготовка к формированию команды

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

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

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

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

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

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

Обратная сторона agile-методологии

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

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

– Sharon Florentine. How agile helps attract and retain millennial tech pros. CIO. Jun 7, 2016

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

Заблуждение 1: Методология agile вносит сложности в бюджет

Как рассказывает Джон Дусет, вице-президент по консультационной деятельности компании Magenic – поставщика заказного программного обеспечения, ИТ-директора весьма далеки от того, чтобы корректировать бюджеты капитальных затрат с учетом agile-проектирования.

Преобразования в стиле agile не окажутся успешными, если в них не будут учтены все аспекты вашей организации. Для того чтобы весь цикл проектирования ПО действительно ускорился, гибкое проектирование должно подкрепляться капитальным, а не операционным бюджетом. Это позволит учесть изменение объемов незавершенных работ.

«Вряд ли ИТ-директору понравится годовой бюджет ИТ-службы в размере 25 млн долл., из которых 15 млн долл. приходится на незавершенную разработку ПО, – подчеркнул Дусет. – Массовый переход на методологию agile можно только приветствовать, но, поскольку бюджеты по-прежнему верстаются исходя из методологии водопада, возникает много трудностей с продуктами и бюджетированием,. Для реального ускорения необходимо внедрять agile-подход, причем в отношении как мэйнфреймов и унаследованных приложений, так и современного ПО и новых продуктов».

Заблуждение 2: Переход к agile-методологии проводится по указанию сверху

«Я не раз сталкивался с ситуацией, когда ИТ-директор из компании, входящей в список Fortune 500, прочитав статью об agile-разработке, сразу загорается этой идеей, – говорит Мэнни Гонсалес, генеральный директор компании Scrum Alliance. – После того как соответствующее указание доходит до одного из ИТ-менеджеров, вызывают нас, приглашают нашего консультанта и пытаются проводить необходимые преобразования. Но это не agile-подход – это указание, исходящее сверху. Мы ощущаем разрыв в знаниях и определенное сопротивление: люди просто не понимают принципов методологии, которую предстоит внедрить в масштабах всей организации».

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

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

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

Заблуждение 3: Переход к agile-методологии прост

«Существует ошибочное представление о том, что переход к agile-методологии прост, – указывает Дэйв Уэст, владелец ресурса Scrum.org. – Принципы и постулаты agile-проектирования легки для понимания, но их сложно реализовать на практике. Необходимо полностью поменять в организации менталитет всех сотрудников снизу доверху, изменить их подход к выстраиванию своей карьеры, к оценке своей работы и своей роли».

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

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

– Sharon Florentine. 3 misconceptions CIOs have about agile. CIO. Apr 25, 2016

Наблюдая изменения, произошедшие в теории и практике проектного управления с 1970-х годов до нынешнего времени, можно увидеть, что различные методологии управления проектами следуют за динамикой изменения той среды, для которой эти проекты реализуются. В 70-е годы – весьма стабильную эпоху – родились ГОСТы. Это не были управленческие документы, их особенностями были ориентация на разработку ИТ-систем с нуля и каскадность проектов. В конце 80-х – начале 90-х годов они модернизировались, заменив или дополнив более ранние стандарты. На рубеже веков ГОСТы сменились западными методиками.

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

От платформ к готовым решениям

Управление проектами в нынешнем понимании возникло в России на рубеже 90-х и 2000-х годов, когда на российский рынок начали выходить зарубежные поставщики ERP-систем и стали проповедовать западную проектную идеологию. С ее помощью вендоры внедряли свои продукты, адаптируя их к российским реалиям. Иногда даже речь шла о создании некой собственной методологии, превосходящей остальные и гарантирующей больший успех проекта. Все внедренцы пытались работать по этим весьма громоздким рекомендациям, и какое-то время у них получалось неплохо.

Однако чем дальше, тем более турбулентной будет становиться бизнес-среда, причем скорость изменений будет нарастать. Это объективный фактор, и с ним бороться бесполезно.

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

«Если в начале 2000-х годов мы говорили о том, что обследование предприятия по западной методологии надо делать быстро, потому что предприятие за время обследования может измениться, то в наше время обследование можно иногда даже не начинать: уже завтра будет бизнесом придумано что-то новое», – констатирует Петров. Все быстро меняется, и это объективная реальность. Нынешняя нестабильность накладывает еще больший отпечаток на происходящее.

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

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

Еще одна тенденция – повышение уровня владения технологиями со стороны бизнес-заказчиков, консьюмеризация ИТ. Бизнес-руководители привыкли, что приобретаемые ими решения начинают работать буквально «из розетки». У каждого есть планшет, за пять минут настройки становящийся полноценным рабочим инструментом. Подобные требования предъявляются и к корпоративным ИТ. Особенно – на что указывают психологи – это выражено у поколения Y.

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

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

Облачный пазл

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

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

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

«Salesforce – один из хороших примеров по-настоящему эффективной платформы. Я знаю компании, которые действительно использовали ее в своей работе без каких-либо изменений», – говорит Петров. Если вести речь о российских решениях, то очень многие компании весьма успешно используют бизнес-сервисы Mail.ru (облачное хранение, календари, средства планирования и корпоративного взаимодействия), «Битрикс24», различные облачные продукты для бухгалтерского учета.

Средства проектирования и управления жизненным циклом продукции, интеграции приложений, аналитики способны обеспечить бизнесу конкурентные преимущества

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

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

Минимизировать бюрократию

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

Первое, что необходимо, – определить бизнес-заказчика проекта и поставить задачу, обеспечив управление изменениями. Критерии целеполагания SMART (specific, measurable, attainable, relevant, time-bounded) не теряют своей актуальности. Цель должна быть конкретной, измеримой, достижимой, значимой и соотноситься с конкретным сроком.

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

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

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

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

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

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

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