Страна советов | Выпуск март | 2018

«БОСС» в помощь | Обмен опытом | Босс №03 2018
Текст | Анастасия САЛОМЕЕВА

В центре внимания мартовского выпуска «Страны советов» — методология agile.

Наши респонденты отвечали на следующие вопросы:

1. Какое значение в вашей компании имеет agile по сравнению с традиционными методами планирования?

2. В какой мере использование agile является порождением современных информационных систем?

3. Какой круг задач помогает решать agile, в каких ситуациях она неприемлема?

4. Какие типичные ошибки совершают компании в применении agile?

Вадим ЧАЛЫШЕВ, руководитель лаборатории agile компании «ОМК-ЦЕС» (входит в состав Объединенной металлургической компании):

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

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

3. Основные задачи, которые нам помогает решать применение гибких методологий, — управление ожиданиями за счет короткого цикла обратной связи, сокращение сроков реализации проекта.
Однако есть ситуации, при которых agileметоды неэффективны. К примеру, при высокой стоимости возможных изменений. Яркий пример — строительство и инфраструктура. Изменение требований способно привести к дополнительным финансовым затратам (заменить закупленное оборудование или перезалить фундамент).
Еще один критерий — жесткое соблюдение требований законодательства/регламентов/инструкций/контрактов. Если в силу этих требований мы должны придерживаться строгой последовательности выполнения этапов работ, то гибкие методологии не приносят ощутимых плюсов по отношению к классическим.

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

Ондрей ГРИХ, ведущий эксперт департамента инноваций и технологий Банка Хоум Кредит:

1. Банк достаточно долго присматривался к новым подходам управления и разработки. Около двух лет назад мы создали несколько команд, которые начали активно «прощупывать» эту тему. Сейчас у нас есть команды, действующие исключительно в agile-парадигме и реализующие ряд как банковских продуктов, так и продуктов для внутреннего клиента. Количество задач, реализуемых в парадигме agile, органично растет. На данный момент около 15% задач осуществлятся agile-командами.

2. Agile в свое время появилась как best practise существующих на тот момент практик ИТ-разработки (XP). И одновременно впитала лучшие производственные практики вне ИТ (канбан из автомобильной индустрии). Хотя, безусловно, одним из самых важных импульсов появления agile явилась потребность в более быстрой и точной реакции на изменения в производстве ИТ-продуктов. Конечно, эта потребность имелась всегда, но именно в начале 2000-х разрыв между скоростью и гибкостью бизнеса и отставания ИТ-производства стал критичным.

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

4. Самая распространенная ошибка, наверное, мнение о том, что agile касается только ИТ, а другие подразделения (маркетинг, продукты, клиентский сервис и т.д.) она не затрагивает. Это полное непонимание agile-подхода, который меняет методы работы ВСЕХ подразделений, задействованных при реализации задачи. Еще одна ошибка — это использование agile как модного инструмента, но без внедрения необходимых изменений в подход к работе.

Татьяна ИГУМЕНШЕВА, директор по маркетингу компании «Атак Киллер»:

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

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

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

4. Обеспечение доступности, целостности и конфиденциальности информации является целью разработчиков систем ИБ. Большинство проникновений в информационные системы происходит из-за уязвимостей — случайных или намеренных недостатках системы, позволяющих злоумышленникам выполнить те операции, которые не планировали разработчики. Не делать ошибок — сложная, а в программировании практически невыполнимая задача. Для предотвращения таких ошибок в эксплуатации есть специальные циклы тестирования в классическом подходе — после окончания разработки продукт отдается в лабораторию. Однако что делать в agile, когда изменения постоянны и непрерывны, а время исследования приложения на уязвимости больше времени изменения? Когда скорость важнее качества? Предположим, мы обнаружили, что в веб-страницу маркетинговой акции можно поместить зловредный код. Что в этом случае важнее: выпустить приложение безопасным или начать как можно раньше продавать наш товар? Исправление может занять неделю, а для компании каждый лишний день — это дополнительные расходы на хранение.
При скоростях agile уже нет возможности разделять разработку и безопасность — сначала функционал, потом безопасность. Решение — это встраивание безопасности в сам процесс разработки. Слишком поздно тестировать код, когда он готов, надо тестировать его в процессе написания. Изменился код, 5 секунд проверки — и вот рекомендации, что делать. Именно для этого работают эксперты в области ИБ: аналитики, программисты, тестировщики, — чтобы ваше программное обеспечение было безопасным при любой, даже agile-разработке.

Яков ГОЛЬДФАРБ, генеральный директор компании по разработке решений для сегмента корпоративного туризма «Аэроклуб ИТ»:

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

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

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

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

Светлана ГАЦАКОВА, директор департамента корпоративных информационных систем ALP Group:

1. Наша компания использует agile-методики как один из двух вариантов управления проектами внедрения и обеспечения жизненного цикла ERP-решений высокой сложности. А второй вариант — это основанное на методологии PMBoK традиционное управление проектами с детализацией задач и их взаимосвязей, анализом критического пути, оптимизацией использования ресурсов, бюджетированием. Хочу подчеркнуть, что в обоих случаях речь идет не об ограниченных экспериментах в небольших пилотных проектах, а о полномасштабных промышленных внедрениях. Фактически в нашей компании обе методики сосуществуют на равных, заказчик сам выбирает ту, которая ему больше подходит. Насколько я знаю, в отношении адаптации agile мы находимся несколько впереди состояния отечественного рынка ERP-решений. Опираясь на этот опыт, считаем, что сегодня agile (в сочетании с DevOps) — это одна из главных точек роста и трансформации всего российского сегмента ERP.

2. Потребности в agile формируют не информационные системы (ИС) как таковые, а быстроменяющиеся условия их существования. С одной стороны, ИС стали критически важными для любой организации (и эта зависимость продолжает углубляться). С другой — требования бизнеса меняются все быстрее: то, что еще вчера казалось несущественным или удаленным во времени, вдруг становится первостепенно важным. Вот несколько примеров, имеющих прямое отношение к agile: переход к импортонезависимому ПО; курс на цифровизацию отечественной экономики и цифровая трансформация предприятий; тесное взаимодействие предприятий в рамках кластеров и деловых сетей; переход организаций на менеджмент, основанный на анализе объективных данных (data-driven management, или DDM). Конечно, есть и технологические предпосылки agile, но они вторичны.

3. Agile позволяет приспособить систему управления предприятием и функциональность конкретных элементов ИС к высокому уровню изменчивости бизнес-среды и технологического ландшафта. В каждый момент организация фокусируется на том, что считает наиболее важным. И практически сразу получает и приращение ценности в этих направлениях, и обратную связь. Дальше все зависит уже от способности правильно вычленить главное. Хотя, даже если произошла ошибка, заметить и исправить ее можно гораздо быстрее (и дешевле), чем при традиционном управлении проектами. Это большое преимущество agile. Однако за него приходится платить неопределенной длительностью и стоимостью всего проекта. Но если иметь в виду не отдельный проект, а весь жизненный цикл ИТ-решения, то ясно, что и при традиционном управлении ИТ-проектами расходы и длительность тоже размываются, просто они разносятся по разным проектам.
По существу, agile принципиально неприемлема только в одном случае: если организация устроена так, что до запуска любого проекта требуется согласовать, утвердить и зафиксировать содержание работ, точные сроки завершения проекта внедрения, а также суммарные расходы на него. При этом и заказчик, и исполнитель понимают, что при современном темпе изменчивости организаций и их бизнес-среды эти цифры, несмотря на кажущуюся точность, неизбежно оказываются довольно условными. Разумеется, исполнитель все сделает качественно и в срок. Однако внедрение сложной ERP-системы вполне может растянуться на несколько лет, а за это время многие требования организации фактически поменяются. И, понимая это, проектная группа, объединяющая представителей заказчика и исполнителя, все же будет вынуждена точно соблюдать букву утвержденного плана.

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

Валерий АНДРЕЕВ, заместитель директора по науке и развитию компании «ИВК»:

1. Agile не имеет широкого распространения в среде основных заказчиков «ИВК» — силовых структур и госсектора. Госструктуры и оборонный сектор расходуют бюджетные деньги и не станут ими рисковать. Они должны точно знать, какой результат хотят получить, чтобы не оказаться в ситуации нецелевого использования государственных средств, поэтому работают по проверенной временем советской схеме: «Техническое задание — реализация». Они не поймут, если мы предложим реализовать дорогостоящий проект методами agile: начать с ТЗ «в три строчки», а затем двигаться вперед мелкими шажками, опытным путем, без изначальной уверенности, что движемся в правильном направлении. Они выбирают «ИВК» как компанию, которая отточила свое мастерство в oldschool, годами создает и наращивает платформу, образованную пулом собственных разработок.
Однако, несмотря на то что сегодня компания не работает по agile, мы способны организовать разработку и таким методом. Не исключаю, что это случится в обозримом будущем, поскольку agile весьма созвучна требованиям построения цифровой экономики: динамика, инновационность, адаптивность.

2. —

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

4. Одна из распространенных ошибок заказчиков — сотрудничество с командами, не имеющими опыта в организации процессов в рамках agile. Для того чтобы минимизировать риски, разработчик должен обладать большим заделом реализованных проектов, которые позволяют ему достигать результатов без непомерных затрат времени и средств. К примеру, иметь портальную платформу, на которой можно построить в интересах заказчика любой сервис — от традиционного до самого экзотического; или платформу СЭД, ERP, CRM и т.п.; владеть репозиторием, на основе которого можно собирать самые разнообразные программные пакеты. Кроме того, разработчику необходимо иметь команду, которая умеет работать в стиле agile.
Если же у разработчика нет подобного бэкграунда, риски разработки резко вырастают. Заказчик обязательно должен понимать это, заключая контракт.
И все же кажется, что новая цифровая экономика с ее динамикой и инновационностью не сможет обойтись без описанного здесь подхода. Это было бы красивое универсальное решение.

Евгений ПУСТИЛЬНИК, старший Scrum-мастер международной ИТ-компании Movavi:

1. Планирование в agile фактически является собранными воедино традиционными методами планирования, никакой магии нет. Просто горизонт традиционного планирования гораздо меньше. Безусловно, в Movavi есть и стратегические планерки, на которых мы обсуждаем отдаленное будущее, но в большей степени фокусируемся на ближайший месяц. Для команд разработки используем Scrum, там процедура планирования вообще практически стандартизирована, и без нее никуда.
А вообще стараемся строить меньше планов и больше проверять. Для этого применяем итеративный подход практически во всех отделах и командах. Ближайший спринт в две недели в Movavi расписан максимально подробно, а дальше уже особо не детализируем — все же может поменяться несколько раз или вообще стать неактуальным.
Да что уж там говорить! Люди сейчас настолько прониклись agile, что стали не только работу планировать, руководствуясь этим подходом, но и жизнь. У некоторых наших сотрудников есть личные Kanban-доски.

2. В каком-то виде, скажем так, agile появилcя давно. Спасибо циклу Шухарта-Деминга за это. Их модель улучшения процессов фактически отражает нынешнюю суть данной идеологии. Но за то, как agile «выглядит» теперь, практически целиком и полностью можно сказать спасибо именно людям из мира информационных систем.
В США различные методологии, базирующиеся на принципах agile, применяли уже в начале девяностых годов ХХ века. Это у нас все фреймворки agile’a стали набирать популярность относительно недавно. Кажется, что сейчас лишь тот, кто вообще не бывает в интернете и не интересуется мировыми трендами, не слышал про agile.
Если раньше agile-подход был характерен практически исключительно для ИТ, то в данный момент на волне как раз вот того самого тренда он применяется во многих компаниях, смежных с ИТ или в принципе не имеющих отношения к информационным технологиям.

3. Думаю, стоит начать с того, что agile — это все-таки в большей степени образ мышления и идеология, чем какой-то инструмент. Если вы сможете перестроиться и, как говорят, не практиковать agile, а быть agile, вы почти наверняка сможете использовать его для решения любых задач. Если более предметно, то очевидно, что этот подход помогает в разработке программного обеспечения. Хотя, так как компаний, которые занимаются исключительно разработкой, в наше время не так много, интересно придумать, как можно масштабировать принципы agile на все, что делает организация.
Movavi, например, активно пользуется agileметодологиями еще и в маркетинге и продвижении своих продуктов. Кроме этого, у нас в компании есть ИТ-школа для детей, и там для работы руководство тоже активно практикует agile. Не удивлюсь, если в скором времени мы начнем использовать его основные принципы в обучении детей, как поступили некоторые школы в США.
Занимательно, но Правительство Новой Зеландии тоже частично «работает по agile». Так что, отвечая на вторую часть вопроса, думаю, что приемлема она в любой ситуации, главное — понять, как правильно подход адаптировать.

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

Надежда МАССЕЛЬ, руководитель проектного отдела BDO Unicon Outsourcing:

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

2. —

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

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

Андрей ШИФРИН, менеджер группы разработки карты рассрочки «Совесть»:

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

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

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

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

Алексей ГОЛОВЧЕНКО, управляющий партнер юридической компании «ЭНСО»:

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

2. Agile, несомненно, порождение эры информационных технологий. Оперативность информации и подталкивает нас к умению маневрировать, к адаптивности своих действий.

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

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

Евгения СЕРИКОВА, заместитель директора по продажам группы компаний AsstrA, менеджер по интегрированным логистическим решениям:

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

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

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

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