Agile

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

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

Шаг № 1. Почистить ИТ-организм — провести входной аудит

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

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

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

Шаг № 2. Обеспечить простую и недорогую масштабируемость ИТ-инфраструктуры: гибридные схемы и сайзинг ресурсов в IaaS

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

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

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

Эти ИТ-сервисы дают возможность собрать и проанализировать объективные данные о том, хватает ли ресурсов. А если уже не хватает или не будет хватать через какое-то время (скажем, через две недели), то каких именно и сколько. Необходимая для этого информация автоматически стекается в сервис в режиме реального времени, а на выходе появляются рекомендации: какие ресурсы и когда надо докупить, а от каких можно безболезненно отказаться. Это позволяет предприятию своевременно и оптимально перераспределять затраты на облако и гарантированно избегать неприятной ситуации, когда ресурсов вдруг не хватило и бизнес начал простаивать. Также можно получить представление о том, когда и на сколько сократить потребление ресурсов, если, скажем, произошел сезонный или внезапный спад деловой активности. Или если часть пользователей либо какие-то сервисы были переброшены в другой ЦОД.

Шаг № 3. Поддержать высокую изменчивость — начать непрерывный ИТ-аудит

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

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

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

Шаг № 4 (дополнительный). Обеспечить постоянное взаимодействие команд на проектах по цифровой трансформации

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

Сегодня наилучшим способом преодолеть этот давний «камень преткновения» является выстраивание горизонтальных связей между командами в виде системы процессов, дополненной современными средствами коммуникации «для данного случая» (ad hoc). Если организация решает внедрить технологии управления Agile, нужно тщательно выбрать конкретную методику, настроить соответствующие процессы (чемпион здесь — Scrum) и уделить большое внимание компетенциям участников. В любом случае (даже если перехода на Agile нет) помогает формирование небольших рабочих DevOps-групп под проекты (в том числе и по цифровой трансформации). В эти группы входят представители каждой из вышеперечисленных команд. Однако всем им нужна общая информационная среда и доступ к постоянно обновляющейся информации в ней — о состоянии всего проекта и его составных частей. Чтобы каждый мог наблюдать и анализировать одни и те же тренды, осуществлять правильные и своевременные корректирующие действия. И не каждая команда — только по своему участку, а совместно, по общему ходу проекта. DevOps-группы в проектах цифровой трансформации должны стать потребителями объективных данных об информационных системах и инфраструктуре, чтобы своевременно принимать взвешенные и правильные для компании решения.

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group.

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

«У нас постоянно идут новые проекты, и в компании до сих пор существует дух стартапа. По моему мнению, нашего взрывного роста никогда не произошло бы, если бы мы не пришли к заветам, заложенным в Agile», — рассказал Андрей Ревяшко, ИТ-директор интернет-магазина Wildberries, на конференции «Agile, DevOps, ITSM 2018», организованной издательством «Открытые системы». Масштабы роста магазина впечатляют: сейчас Wildberries обрабатывает в среднем 240 тыс. заказов в день, то есть более одного заказа в секунду.

«Период полураспада» и «задачи-пустышки»

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

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

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

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

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

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

Логика, воля и эмоции

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

«Мы решили присмотреться к опыту NASA, в свое время заказавшего исследование, призванное помочь собрать группу астронавтов, неконфликтных по отношению друг к другу. Согласно данной методологии, в каждом человеке заложено примерно 16 функций. Их соотношение четко говорит о поведении людей и их совместимости», — утверждает Ревяшко. Подобный подход можно применять и в обычных компаниях при подборе сотрудников, чтобы собрать крепкую команду, которая не подводит бизнес, имеет взаимопонимание с ним, а ее участники не конфликтуют между собой. Однако выделение в человеке 16 функций приводит к появлению более 700 психотипов. Это тяжело: при всей мощи этой методологии, порог вхождения в нее очень высок.

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

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

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

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

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

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

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

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

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

«В 2016 году явственно возникла проблема с разработкой новых видов продукции. Посмотрев вокруг, мы увидели, что были очень медленными — не только по сравнению с зарубежными компаниями, но даже с российскими конкурентами», — говорит Сухарев. Наиболее проблемным был показатель time to market — новые продукты выводились на рынок очень долго, в среднем 2–2,5 года, и иногда к моменту своего появления часть из них оказывались ненужными. Видя все это, люди сильно разочаровывались в своей работе, теряли веру в себя. С этим надо было что-то делать. Еще один нюанс — это критичность ошибок: в металлургии они обходятся очень дорого, так как минимальная партия нового товара составляет 350 тонн.

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

Период адаптации

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

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

В 2016 году в «Северстали» было запущено два пилотных проекта по разработке продукта в новом формате. Взяв за основу методику Scrum, собрали две небольшие кросс-функциональные команды по четыре-пять человек в каждой, в их работе использовались все типичные атрибуты: спринты, стендапы, обзоры, скрам-мастера. Сразу стало заметно, что работа пошла лучше, хотя люди были задействованы в проектах всего на 20–30%. Но даже эти первые эксперименты дали заметный эффект, и разработка ускорилась в 2–3 раза. Немаловажно, что новые методы взаимодействия оценили и сами участники команд. Как следствие, 2017 год ознаменовался резким ростом таких проектов: появилось около 25 команд.

«На проблемы, существовавшие на первых этапах, не обращали внимания из-за эйфории. Тем не менее впоследствии они сильно проявились, и основная из них — снижение управляемости», — отмечает Сухарев. Когда команд стало много, началась путаница, исчезла прозрачность, стало непонятно, в каких направлениях идет «движуха». Второй блок проблем — дискомфорт, обусловленный участием сотрудников в нескольких командах. Люди были вынуждены по несколько раз посещать стендапы, планирования, обзоры. В 2018 году было решено переконфигурировать работу команд, организовав их в виде потоков создания ценности (value stream). Запустить работу первой такой команды очень помогли эксперты ScrumTrek.

Командная игра

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

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

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

Спринты для топ-менеджмента

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

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

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

Взращивая самоорганизацию

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

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

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

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

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

Эти пять шагов ведут к появлению в команде ростков самоорганизации. За ними в дальнейшем придется так же бережно ухаживать.

«Несмотря на все наши ошибки и проблемы, мы видим, что место для Agile в производстве есть», — резюмирует Сухарев. Сейчас показатель времени создания новых продуктов сократился вдвое — до 1–1,5 года, а их число достигло 70. Но самое главное — стало понятно, что есть огромные возможности для дальнейших улучшений.

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

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

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

«Agile нужен не для того, чтобы писать код быстрее, а чтобы делать больше полезного. Делать в целом меньше, но лучше», — говорит Капусткин.

Стремление сделать побыстрее зачастую заводит команду в тупик. Продуктовая команда эффективна ровно настолько, насколько она в состоянии поставлять бизнес-ценности. И тут очень важен баланс между показателями «достаточно хорошо, чтобы пользоваться» (good enough) и «время вывода на рынок» (time to market). Эти два параметра имеют смысл только в связке друг с другом, то есть разработчики должны сделать софт в максимально сжатые сроки, не потеряв по дороге общий смысл. «Если мы выдаем по три функции в неделю, c вероятностью 90% ни одна из них не несет реальной ценности», — уверен Капусткин.

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

Каким образом повысить эффективность разработки путем изменения уровня осознанности в команде, Капусткин расскажет на конференции «Agile, DevOps, ITSM — инструменты и опыт реальных проектов цифровой трансформации», которую издательство «Открытые системы» проведет 23 октября 2018 года. Год за годом Капусткин дотошно протоколирует свою работу с командами и систематизирует свои наблюдения. В результате на свет появилась четырехуровневая модель, с которой познакомятся участники конференции.

Четыре шага к эффективности

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

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

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

Диапазон применимости

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

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

На верхнем уровне управления эффективность оценивают, как правило, по выполнению финансовых показателей. Но где-то умеют сопоставлять результаты работы продуктовых команд с финансовыми показателями, а где-то царит метод «палец-пол-потолок». Cистемный подход и подход «цели и ключевые результаты» (objectives & key results, OKR) в качестве альтернативы классическим KPI на практике встречается нечасто.

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

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

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

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

О подходе к расстановке приоритетов в задачах, выработанном в компании «М.Видео и Эльдорадо», можно узнать на конференции «Agile, DevOps, ITSM — инструменты и опыт реальных проектов цифровой трансформации», которую издательство «Открытые системы» проведет 23 октября 2018 года. Опыту ретейлера будет посвящен доклад, подготовленный руководителем продуктового офиса «М.Видео и Эльдорадо» Ириной Марчевой. Доклад называется «Дюжина разгневанных заказчиков: как расставить приоритеты?». А пока Марчева рассказала, что привело к появлению такого подхода.

- В какой момент ИТ-подразделения из утилитарного инфраструктурного обеспечения превратились в ценнейший бизнес-ресурс? Когда и почему это произошло в вашей компании?

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

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

- Почему этот ресурс дефицитен? Компания же может нанять больше ИТ-специалистов?

Эффективность — в балансе. ИТ — очень дорогой ресурс, и наём большого количества разработчиков не означает, что они принесут большую ценность компании. У нас ведь нет задачи реализовать все идеи, которые приходят в голову бизнес-пользователям. По принципу Парето, 20% действий дают 80% результата, и наоборот. Мы всегда ищем баланс ИТ-ресурсов и бизнес-идей.

- Что именно стало предметом конкуренции и в чем она выражается?

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

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

Только в центральном офисе объединенной компании (бренды «М.Видео» и «Эльдорадо») сейчас работают около 1,5 тыс. человек. Почти у каждого есть свои цели, и все обращаются к одному ресурсу. Эту проблему мы и постарались решить.

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

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

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

Еще одна причина — высокая интегрированность бизнес-процессов внутри компании. Чем крупнее и старше компания, тем более сложные и интегрированные процессы в ней возникают. На стыке нескольких функций рождаются новые роли и направления, как это было в свое время с «продуктологами» (Product Owner) и руководителями по цифровой трансформации (Chiеf Digital Officer, CDO). Уже понятно, что нельзя управлять в вакууме просто маркетингом, логистикой или ИТ, новые сложные интегрированные процессы требуют иного подхода.

Компания растет, процессы усложняются, вызывая перестройку в ИТ и… борьбу за ресурсы.

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

Поэтому важно было найти понятные принципы приоритизации и договориться, чтобы они были для всех прозрачны. Это была совместная командная работа ИТ, бизнеса и проектного офиса. За основу мы взяли модель Weighted Shortest Job First (WSJF) и принцип вычисляемых значений работ, когда в приоритете оказывается задача, приносящая максимальную ценность компании и при этом стоящая меньше всего в реализации. Иными словами, если выбирать между одной задачей с возможным получением прибыли 10 руб. и двумя задачами с прибылью по 5 руб., но которые можно решить быстрее, надо брать в реализацию последние. Поскольку следует учитывать не только затраченное время и возможный доход, который компания потенциально могла бы получить, но и «упущенную выгоду», то есть ту выгоду, которую компания не получит, если задача не будет внедрена уже сейчас. Мы не просто взяли этот принцип, а разработали собственную методологию, позволяющую оптимально принимать решения именно в нашей компании. Модель послужила фундаментом, который мы потом нарастили с учетом внутренних особенностей компании.

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

У нас есть ключевые направления, которые развиваются всегда, — например, электронная коммерция, мобильность. Эти команды работают по Agile постоянно. Кроме того, в прошлом году мы запустили пилот: временно собрали под определенные направления бизнеса кросс-функциональне команды, названные Value Stream, которые в дальнейшем могут стать постоянными. Тем самым мы попытались сгладить конкуренцию, потому что продуктовые комитеты и скоринговая модель позволяют сделать процесс прозрачнее, хотя и не решают всех проблем. И это помогло снизить остроту проблемы, так как Value Stream — выделенные команды и за ресурсы не конкурируют другие функциональные бизнес-подразделения. В текущем году эксперимент расширили: теперь у нас две кросс-функциональные команды. Но мы планируем выделять специальные команды только на те области, где необходимо сфокусироваться на данный момент.

- Как влияет конкуренция за ИТ-ресурсы на процессы управления ИТ — ITSM?

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

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

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

- В чем изюминка вашего подхода к приоритизации задач?

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

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

- Каких результатов вы добились с помощью этого подхода?

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

- О чем вы расскажете участникам конференции и о чем вам было бы интересно услышать?

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

А мне лично интересно, как устроен портфель продуктов в других компаниях и как компания определяла для себя, что есть продукт. Общего понимания этого понятия пока нет.

Мнения об Agile до сих пор разнятся: одни считают эти методики «серебряной пулей», другие же заявляют о полной их бесполезности. В рамках конференции «Ночь на Ивана Купалу», организованной клубом ИТ-директоров «я-ИТ-ы», Михаил Кудашев, руководитель компании «Реалайз» (выделившееся ИТ-подразделение производителя ювелирных изделий SOKOLOV), рассказал о своем опыте использования гибких методик. Он полагает, что каждая команда должна идти своим путем — эффективный Agile у каждого свой и зависит от мировоззрения человека. В штате «Реалайз» 80 сотрудников, объединенных в семь команд: шесть команд работают по Scrum и одна — по Kanban. Кудашев рассказал о становлении в компании гибких методик, поиске взаимопонимания с бизнесом и пользе открытых зарплат.

— Зачем потребовался переход к Agile, какие были проблемы?

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

Источник: sokolov.ru/sokolov-life/production/

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

Найти правильный ориентир нам очень помог визит в Сбербанк. Мы посетили их Agile Home, посмотрели на него своими глазами. И хотя нас не везде пустили, многое нам действительно понравилось. И тогда было принято решение идти тем же путем.

Роль Сбербанка в этой истории действительно велика. В 2015 году я начал говорить о необходимости перемен, но меня не слышали. И вот годом позже, когда Герман Греф дважды громко произнес слово Agile, ситуация изменилась. В 2017 году мы уже запустили первый пилот. Наша команда по автоматизации производственных процессов работает уже больше года, остальные появились чуть позже. То, что Греф на широкой публике употребил слово Agile, не только вывело его из разряда чуть ли не ругательных, но и повлияло на восприятие этих идей бизнесом.

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

— Вероятно, на практике все оказалось сложнее.

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

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

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

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

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

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

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

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

— Эти различия в работе — вынужденная мера или осознанный шаг?

Вы же знаете: строительные инструменты стандартные, а вот то, что сделано с их помощью, может быть очень разным — всё зависит от того, в чьи руки эти инструменты попадают.

Команды включают от 5 до 10 человек. Это живые люди, они неодинаковые. Мы не можем всех заставить ходить строем. Есть особенности и в людях, и в продуктах, и в аудитории, на которую мы работаем.

— Как изначально воспринимался проект внутри ИТ и как он воспринимался бизнесом? Ведь любые изменения порождают сопротивление…

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

Надо не подавлять сопротивление, а демонстрировать успешность продвигаемого подхода.

— Что требовалось изменить, где были самые серьезные барьеры?

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

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

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

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

— Как Agile стыкуется с другими популярными подходами — гибким графиком и удаленной работой? Складывается впечатление, что это противонаправленные тенденции.

Не всегда людей можно физически усадить в один офис. Однако именно от их совместной работы получается максимальная отдача. Если люди распределены, то нельзя сказать, что Agile неприменим вовсе. У меня есть удаленные сотрудники, находящиеся в разных странах. В этом случае как минимум необходим ежедневный стендап по видеосвязи, к которому подключаются все удаленные сотрудники. У нас на стенах висят скрам- и канбан-доски в аналоговом исполнении, а для удаленных специалистов приходится использовать систему управления, позволяющую всем видеть, что происходит с задачами. Это может быть Jira или Trello. Мы, например, используем Kaiten.

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

— Agile требует высочайшего профессионализма сотрудников, их мотивированности и ориентированности на результат. Где взять столько героев и что делать с остальными сотрудниками?

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

Мы посмотрели на модель Spotify и адаптировали ее для наших целей, назвав «чаптеры» гильдиями и введя в них разряды («грейды»). Сейчас у нас четыре гильдии: разработка фронт-энд, PHP-разработка, 1С-разработка и тестирование. В каждом блоке до 14 разрядов, от которых, в числе прочего, зависит зарплата. На каждом из них необходимо владеть определенными навыками, и не только техническими. Начиная с определенного разряда, играют роль и личные качества (soft skills): насколько человек помогает другим командам, сколько занятий проводит.

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

— Чего реально удалось достичь, каковы результаты?

Результаты есть, но перевести их в цифровые показатели довольно сложно. Два главных показателя — сокращение времени выполнения задач (lead time) и сокращение времени вывода продукции на рынок (time to market). Это очень важно, поскольку раньше у нас задачи могли находиться в очереди и по 500 дней. Еще один значимый показатель — производительность. У каждой команды он свой, но мы смотрим, растет он или нет. Наконец, есть бизнес-метрики, привязанные к каждой команде, — выручка, количество пользователей, количество заказов, конверсия.

Мы видим, что у наших сотрудников хороший уровень владения декомпозицией. Если раньше команда выполняла отдельные задания за 9–12 дней, то сейчас этот срок сократился до 3–4 дней. Задача каждого спринта — отдать заказчику «подарочек», тот функционал, с которым можно работать. Таким образом мы смотрим, эффективна команда или нет.

— В целом ожидания оправдались?

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

Не разнятся ли оценки такой «аджайлизации» со стороны ИТ и бизнеса? Подобные ситуации нередки…

Абсолютно верно. Вы же знаете: можно показать, что компания одновременно и рентабельна, и убыточна — все зависит от личности аналитика. Здесь имеют значение субъективные впечатления: доволен ли бизнес произошедшими изменениями или нет. Если бизнес недоволен, значит, зря все это затеяли или что-то идет не так. Если бизнес доволен, надо искать пути дальнейших улучшений. К счастью, в нашем случае бизнес доволен.

— Были ли неожиданные результаты, на которые не рассчитывали изначально?

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

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

— Каким вам видится будущее?

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

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

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

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

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

С представителями бизнеса на борту

Методологией agile Тонер увлекся три года назад, когда возглавил ИТ-службу штата. От привычной концепции водопада он пришел к совершенно иным принципам гибкого проектирования. Тонер начал с того, что пригласил специалистов с опытом использования ориентированных на гибкое проектирование языков программирования — .Net и Java. А эти люди уже в свою очередь обучили языкам и принципам гибкого проектирования 400 сотрудников ИТ-службы.

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

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

Проблемы формирования культуры agile

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

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

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

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

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

Между тем ИТ-директора и сотрудники ИТ-служб продолжают бороться за соблюдение принципов agile-методологии и полноценное претворение в жизнь методов agile и поддерживающих технологий внутри самой ИТ-службы. По оценкам Уэста, большинство (от 70 до 80%) корпоративных ИТ-служб при реализации программных проектов в той или иной степени используют принципы agile-методологии. В качестве сдерживающих факторов выступают унаследованные технологии и привычка считать ИТ-службу центром затрат, предоставляющим стандартные услуги.

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

«Представьте себе, что вы работаете над двухнедельным спринтом, — рассказывает Уэст. — Вам нужно, чтобы в бизнес-подразделениях быстро принимались связанные с ним решения. А там отвечают, что у них есть дела и поважнее».

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

Продвижение концепции agile. Преимущества и ограничения

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

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

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

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

«Я не говорю, что все мы станем гибкими и будем счастливы, не использую терминологию agile, — признался Гуле. — Я просто говорю, что надо сделать конкретно то-то и то-то, и объясняю, какие выгоды это принесет».

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

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

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

Баланс между ИТ-службой и бизнес-подразделениями

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

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

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

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

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

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

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

— Mary K. Pratt. Moving agile beyond IT: The secret to successful software delivery. Contributing Writer, CIO. AUG 21, 2018

Портал госуслуг (gosuslugi.ru) — крупнейший государственный портал и один из крупнейших в Рунете вообще (12-е место по месячной аудитории). На нем зарегистрировано 77 млн пользователей — почти все совершеннолетние граждане страны, имеющие доступ к Интернету. Как всякая действующая система, портал должен непрерывно развиваться и совершенствоваться, при этом оставаясь постоянно доступным. О том, как порталу удается изменяться, работая при этом в режиме 24х7х365, рассказывает Дмитрий Матвеев, руководитель проектов развития Портала государственных услуг Российской Федерации и мобильного приложения «Госуслуги», а также один из докладчиков практической конференции «Agile, DevOps, ITSM 2018», которую издательство «Открытые системы» проведет 23 октября.

— Для пользователей портал госуслуг — представительство государства в Интернете, сотни услуг и обилие информации. А что там, «за фасадом»?

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

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

— Что мешало сделать это раньше?

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

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

— Как удалось изменить ситуацию, что для этого потребовалось?

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

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

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

— Упомянутые восемь изменений в день — они действительно нужны? Изменений чего? Вряд ли за день появится столько новых услуг или изменений в интерфейсе. Не могут получиться изменения ради изменения?

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

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

— Вы смогли создать концепцию ГосAgile, продавить ее через госструктуры. Как это удалось, какие вопросы возникали?

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

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

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

- В каком направлении портал будет развиваться дальше?

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

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

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

Потому что от портала госуслуг ждут значительно больше, чем просто «госуслуги».

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

— О чем вы будете рассказывать на конференции и о чем вы сами хотите услышать на конференции?

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

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

Гибкие методологии управления ИТ находят все большее признание в страховом бизнесе. Одной из организаций, успешно применяющей эти методики, является государственная страховая компания «Югория». Она обслуживает сегодня свыше 40 тыс. юридических лиц и около 2 млн граждан, предоставляя широкий спектр услуг по 21 виду страхования и перестрахования с использованием более чем 60 различных правил страхования. Особое внимание компания уделяет развитию филиальной сети, которая сейчас состоит из 73 филиалов, более 200 агентств и точек продаж в 50 регионах России. Виталий Шишаев, руководитель отдела внедрения и сопровождения сервисов ГСК «Югория», рассказывает, как с помощью гибких методологий управления ИТ-услугами удается оперативно адаптировать инфраструктуру для удовлетворения запросов бизнеса. Силами объединенных команд, включающих бизнес-пользователей и ИТ-специалистов, обеспечивается развитие компании на высококонкурентном рынке страховых услуг, при этом гармонично сочетаются надежность государственного предприятия и динамичность коммерческой структуры. Виталий Шишаев - один из докладчиков форума ITMF-2018.

– Насколько необходимы сегодня методики Agile в страховом бизнесе?

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

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

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

– В чем главные преимущества коммуникаций внутри объединенных команд?

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

– Каковы главные уроки процесса объединения команд разработки, эксплуатации и бизнеса?

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

– Каков ожидаемый или уже полученный эффект от перехода на Scaled Agile Framework?

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

– О чем вы планируете рассказать 22 мая на IT Management Forum 2018 ?

Об истории трансформации системы управления ИТ нашей компании: о бизнес-контексте и предпосылках принимаемых решений, проблемах, с которыми мы столкнулись, и способах их решений, о командах и организации их взаимодействия. Особо остановлюсь на том, что бы я стал делать по-другому, если бы мы в ГСК «Югория» заново начали проект перестройки работы по методике Agile.

Похоже, гибкое проектирование становится уже вчерашним днем. А как же передовые компании? Они уже перешли на DevOps. Более того, многие разработчики приложений не только не взяли на вооружение agile-технологии, но даже не имели таких намерений.

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

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

Один из главных принципов ИТ формулируется так: покупай, когда можешь, создавай, когда нужно. ИТ-службы лицензируют около 90% всего нового функционала в виде готового коммерческого программного обеспечения (commercial off-the-shelf software, COTS) или программного обеспечения, предоставляемого в виде сервиса (software as a service, SaaS), оставляя на разработку его собственными силами всего 10%.

Scrum, Kanban, Lean Software Development и другие agile-методологии предназначены для создания всего 10% программного обеспечения. При этом 70% своего времени типичный разработчик тратит на поддержку и расширение функционала уже эксплуатируемых приложений и только 30% остается у него для создания новых.

Проведем несложные подсчеты. Agile-проектирование оказывается полезным лишь для 10 из 30% – то есть для 3% приложений, которыми занимаются команды разработчиков.

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

Agile-путь поддержки и улучшений

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

Не нужно сильно всматриваться в очередь, чтобы заметить, насколько все здесь напоминает agile-методологию. Добавляем владельца продукта (человека, отвечающего за его разработку) и начинаем формулировать запросы, представленные в виде пользовательских историй (изложенных на бизнес-языке требований к разрабатываемой системе). Мы проделали это за минуту. Применяем Kanban: владелец продукта определяет приоритеты, а разработчик, выполнив очередное задание с пользовательской историей, переходит к следующему. Накладные расходы минимальны, а работа выполнена.

Agile-разработка COTS

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

Однако agile-технологии можно применять и к COTS. Нужно только учитывать два важных момента.

Первый: внедрение COTS, как на своей территории, так и в виде SaaS, не предполагает разработку программного обеспечения с нуля, а ограничивается одной-двумя настройками. А потому Scrum и Kanban фактически непригодны для решения таких задач.

Второй момент: помимо Scrum и Kanban существуют и другие agile-методологии.

Разработка приложений против внедрения COTS: все начинается с данных

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

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

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

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

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

Что должно делать программное обеспечение

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

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

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

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

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

Огромные расходы и никаких улучшений с точки зрения бизнеса. Зачем?

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

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

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

Двухэтапный проект COTS

Когда бизнес, а не ИТ-подразделение, внедряя COTS, вносит в свою деятельность намеренные коррективы, усилия разбиваются на два этапа: сделать программное обеспечение приемлемым для себя и оптимизировать бизнес.

Первым этапом можно управлять с помощью малоизвестной agile-методологии Conference Room Pilot (CRP). Вот как это работает.

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

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

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

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

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

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

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

Темные стороны agile-проектирования

У agile-проектирования есть недостатки и похуже, чем бесполезность для решения большинства ИТ-задач. Гибкое проектирование направлено на доставку продукта. Независимо от того, идет ли речь о Scrum, Kanban, Lean или о чем-то еще, проект считается завершенным после поставки программного продукта.

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

Весь второй этап CRP направлен на то, чтобы заставить бизнес работать лучше. Внутренние изменения бизнеса заложены в нем изначально.

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

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

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

***

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

– Bob Lewis. Agile’s dark secret? IT has little need for the usual methodologies. CIO. MAR 30, 2018