Глава Сбербанка Герман Греф в 2016 году заявлял, что компании, не переводящие бизнес-процессы на agile, в ближайшем будущем окажутся лузерами. Время показало, что Герман Оскарович оказался не совсем прав. Точнее говоря, совсем не прав. Лузеров, конечно, предостаточно, но гибкие технологии управления тут совсем ни при чём.
И, несмотря на продолжающийся хайп вокруг инновационных методов управления, понятно, что старая добрая каскадная модель по-прежнему актуальна. К сожалению, agile оказался жизнеспособным только в весьма узких областях, а значит, с ролью волшебной палочки не справился.
В чём проблема – в agile или в российских реалиях? Рассказывает портал profiok.com.
Краткая предыстория
Методология agile появилась в 2001 году с манифеста, подписанного парой десятков независимых разработчиков программного обеспечения. Манифест гласил, что взаимодействие между людьми важнее процессов, работающий продукт важнее детальной документации, условия контракта менее приоритетны, чем сотрудничество с клиентом, а первоначальный план не так важен, как готовность к изменениям.
Стоит отметить, что первоначально agile возник в веб-разработке, то есть там, где у заказчика, как правило, изначально нет чётких требований к проекту. Вы когда-нибудь пробовали сделать сайт? Если да, то наверняка помните, что даже если вы чётко знаете, что вам нужно, всё равно столкнётесь с «непониманием» разработчиков, отталкивающихся от своих инструментов. А когда между клиентом и разработчиком есть непонимание, впереди непростые времена.
В такой ситуации на составление подробного и всеобъемлющего технического задания уходят долгие месяцы, а по ходу разработки, глядя на промежуточный результат, клиент всё равно начинает вносить изменения.
Суть agile в том, что путь к безупречному продукту построен на итерациях. Заказчику показывают некий набросок-прототип, так называемый MVP – minimum viable product, «минимально жизнеспособный продукт». Затем получают обратную связь, немного дорабатывают проект и снова показывают клиенту. Так решаются сразу две задачи: клиент вовлекается в процесс и быстрее определяется со своими пожеланиями, а разработчики на каждой итерации приближаются к созданию конечного продукта. В итоге время разработки значительно сокращается, а удовлетворённость заказчика растёт в разы.
Постепенно нашлись адепты agile, начавшие распространять принципы этой методологии едва ли не на все сферы жизни, включая корпоративное управление и даже личное планирование. Суть одна: путь к достижению глобальной цели делится на короткие отрезки, на которых решаются только приоритетные задачи. Дела, которые не попадают в список приоритетных, остаются «за бортом». К сожалению, за борт попадают и важные вещи, которые просто невозможно разглядеть при столь недалёких стратегических горизонтах.
Стратегическая близорукость
В идеальной модели agile задачи ранжируются по важности и ценности для конечного результата. Но нельзя сбрасывать со счетов человеческий фактор: по факту команда постоянно норовит отправить в небытие те задачи, которыми не хочется заниматься. Программисты начинают делать несложные, но заметные вещи. А то, о чём по каким-то причинам заказчик не спросит, не будет сделано никогда. В результате так называемый «технический долг» (непроработанный код, ненаписанная документация) накапливается как снежный ком, и о качестве итогового продукта говорить уже не приходится.
Да, действительно, в ситуации, когда проект трещит по швам, сроки сорваны, клиент недоволен, наверное, стоит выделить ключевые точки и перейти к краткосрочным итерациям. Но такой подход хорош для экстренных ситуаций, когда нужно быстро «выкатить» заказчику хотя бы какой-то продукт, не думая о качестве.
Поэтому целый ряд экспертов не рекомендует прибегать к agile за рамками чрезвычайных ситуаций, особенно если компания дорожит своей репутацией и строит долгосрочные планы. Более того, на волне agile появилось множество горе-команд, из всей философии взявших на вооружение только «гибкость» подхода. Результат – «сырые» продукты, произведённые кустарным методом.
«К сожалению, когда слышишь, что компания управляется agile-методами, это часто означает, что она просто плывёт по течению, с горем пополам отбиваясь от оперативных задач, – пояснил порталу profiok.com директор Центра экономического развития и сертификации (ЦЭРС ИНЭС) Роланд Шарифов. – В такой компании нет ни полноценной стратегии, ни долгосрочных целей, ни управления рисками. Наверное, можно долгие годы существовать в режиме непрерывной импровизации, но это весьма и весьма утомительно».
Agile и менталитет
Есть и ещё один аспект. Методология Agile опирается на коллективную ответственность разработчиков. Наверное, в командах, где подобрались действительно вовлечённые в общие задачи люди, обладающие к тому же высокой квалификацией, ответственность и правда можно делегировать на нижние уровни. Agile успешно используется во многих ведущих IT-компаниях. Правда, не исключено, что при таком уровне финансового обеспечения и компетенций эффективно работала бы и обычная каскадная модель.
Но в большинстве случаев, увы, приходится рассчитывать на «средних» исполнителей, для которых «отвечают все» часто равносильно «не отвечает никто». Такие сотрудники неизбежно будут принимать решения, которые комфортны не для компании, а для них самих.
Не случайно в 2017 году интернет облетела весёлая картинка, высмеивающая Германа Грефа и его инновационные преобразования в Сбербанке. С одной стороны на картинке изображён Греф, рассуждающий об искусственном интеллекте, блокчейне и методологии agile, с другой – сотрудница Сбербанка, заявляющая клиенту: «Где карту открывали, туда и идите». Ситуацию с перевыпуском карт Сбербанк, надо сказать, исправил вскоре после появления этой карикатуры. Но сути дела это не меняет: пока руководство компании носится с новыми хайповыми идеями, где-то в недрах корпорации что-то буксует.
Где стоит и где не стоит применять agile?
Agile незаменим в стартапах, в небольших командах, занимающихся разработкой, а также при создании инновационных продуктов или в маркетинге, где самого продукта ещё нет, а есть только представление о том, каким он должен быть. Иными словами, там, где можно без ущерба для качества будущего продукта оперировать прототипами будущих решений. Заметим, что это довольно небольшой набор областей.
Если же речь идёт о проектировании и строительстве какого-то инженерного объекта, будь то жилой дом или космодром «Восточный», пожалуй, об agile не стоит даже заикаться. Сложно даже представить, каким получится, например, пассажирский круизный лайнер, если заказчик будет регулярно вносить изменения в проект. И очень хотелось бы посмотреть на человека, который согласился бы сесть за руль автомобиля, представляющего собой MVP. Или попробовать «минимально жизнеспособное» лекарство.
Особый разговор – предприятия и компании, работающие с государственным оборонным заказом (ГОЗ). Здесь тоже никакой agile невозможен в принципе из-за сложных регламентов, длительных процедур и серьёзных требований к качеству конечного продукта. Удел таких компаний – каскадный проектный менеджмент, который отлично зарекомендовал себя для решения самого широкого класса задач, в том числе стратегических.
«Да, действительно, адаптивная модель управления применима далеко не во всех сферах, – уточнил Роланд Шарифов. – Но это вовсе не значит, что, скажем, оборонка закрыта для совершенствования системы управления и не готова гибко реагировать на изменения. Достаточно вспомнить, как новейшее российское оружие совершенствовалось во время специальной операции российских войск в Сирии: инженеры и конструкторы скрупулёзно фиксировали всё, что необходимо доработать. Правда, вряд ли кто-то осмелится утверждать, что до этих событий российские войска были оснащены «прототипами».
Желание постоянно улучшать продукт естественно для любой уважающей себя компании. Но стоит понимать, что гибкие методы, будь то разработка или управление, – вовсе не панацея. В подавляющем числе случаев куда больше толку будет, например, от повышения квалификации сотрудников, модернизации оборудования или повышения операционной эффективности с помощью инструментов бережливого производства. Что же до постоянного совершенствования продукта, то оно должно происходить постоянно и независимо от выбранных управленческих инструментов. Например, ИНЭС уже более пяти лет занимается повышением квалификации руководителей оборонных предприятий. За это время мы переработали и дополнили программу десятки раз, и не ошибусь, если заявлю, что ни один из курсов не совпал в точности с предыдущим, поскольку мы оперативно реагируем на изменения. Но при этом ни одна из программ не была «прототипом». Так что это не agile, а здравый смысл плюс ставка на качество.
А восторженным адептам agile, сетующим на косность и неповоротливость традиционных отраслей, я бы рекомендовал присмотреться к Сбербанку в качестве работодателя: по крайней мере, это снизит вероятность непоправимых последствий от их неудачных экспериментов в критически важных сферах. На мой взгляд, у тех, кто бездумно применяет различные управленческие инструменты, гораздо больше шансов стать лузером, чем у тех, кто десять раз подумает прежде чем хайпануть. Увы, хайп нынче обгоняет разум...»
Для полноты картины читайте публикации profiok.com:
- Управлять, а не пускать на самотёк – ОСК развивает выпуск машиностроительной продукции
- ГОЗ, диверсификация и глобальный контекст: оборонщики повысили квалификацию в ИНЭС
- В чём суть методологии agile? Краткий ликбез
- Руководитель по цифровой трансформации (РЦТ): новый вид управленца? Краткий ликбез
- Что такое блокчейн? Краткий ликбез
- Что такое бережливое производство? Краткий ликбез
Источник: https://profiok.com/news/detail.php?ID=11072#ixzz6ELRjfPor
Свежие комментарии