Про моду, гибкость и жизнь
В последнее время мода на гибкие технологии, что называется, пошла в массы. Топ-менеджеры верят, что «гибкость – это путь в завтра», а ИТ и не только поддерживают это утверждение. Давайте посмотрим, насколько гибкие технологии могут быть применены в обычной жизни обычной компании.
Начнем с традиционного для гибких технологий сегмента: ИТ. И рассмотрим несколько составляющих ИТ: разработку, поддержку и «инфраструктурное хозяйство», внедрение, финансы.
Разработка
С разработкой вроде бы все понятно. В том смысле, что гибкие методологии родом как раз из этого сегмента. Но... Всегда ли они применимы в реальной жизни? Честный ответ: нет, и еще раз нет. Почему? Наша культура (имеется в виду культура предпринимательства) живет в парадигме «срок-результат». Гибкие же методы разработки явно тяготеют к проектам типа time & material (или, как их иронично называют, «любой каприз за ваши деньги»). Предприниматель же склонен платить за результат, вне зависимости от методологий, спринтов, гибкости и т. д. «Я хочу, чтобы к такой-то дате мы имели новую систему отчетности. Бюджет вот». Где тут, простите, хотя бы намек на гибкость?
Не спорю: она может быть внутри. Разработка по спринтам, освоение объема в зависимости от скорости... Это все «под капотом». Снаружи – жесткий срок.
К чему это приводит? Не знаю, как вы, а я составлял план спринтов и прикидывал план реагирования, если что-то пойдет не так. Потому что есть жесткая финальная дата. Более того, для компаний, которые имеют дело с госзаказом, гибкость разработки, на мой взгляд, вообще противопоказана. Слишком разные сущности – жесткий госконтракт и гибкая разработка.
Кроме того, для нормальной, полноформатной гибкой разработки нужно одно ключевое, магическое условие – постоянный контакт с заказчиком. А много вы видели заказчиков, готовых выделить одного из своих ключевых специалистов на почти непрерывное общение с разработкой? Я – нет.
Все ли так грустно? Нет. Встречаются заказчики (как правило, внутренние) и проекты, которые могут и хотят работать «по-гибкому». Но их мало. Очень мало.
Поддержка
А вот в ИТ-поддержке точно есть простор для гибкости. Там она заложена с момента основания. Вал заявок, непрерывная приоритизация, выявление закономерности, устранение корневых причин. В вакансиях на специалистов ТП обычно пишут «умение работать в условиях постоянно меняющихся приоритетов». Да, там нет спринтов. Но техподдержка –это не разработка, там нет MVP в полном понимании данного термина. Зато есть микро-mvp по отношению к каждой заявке. И именно техподдержка может и должна быть по-настоящему гибкой без ущерба для контрактов, бюджета и т. д.
Инфраструктура
Следующий аспект работы ИТ – инфраструктура. Ее развитие, поддержка и переконфигурирование. При всем желании тут, как правило, «чистый водопад», потому что, например, какая может быть гибкость в поднятии кластера серверов или прокладке кабеля? Правильно, никакой. Точно регламентированные работы, полностью подконтрольные затраты... Строгое бюджетирование. И никак иначе.
Внедрение. Здесь, конечно, можно как-то «прикрутить» аджайл, но результат, скорее всего, будет очень далек от идеального. Причина очень проста: внедрение любой системы обычно подразумевает следование некоему плану. А план, в общем случае, входит в противоречие с аджайл, потому что «удовлетворенность пользователя выше изначального плана». Это, безусловно, так, и прекрасно применимо в случае аджайл-разработки, когда продукт может быть гибко подстроен или даже кардинально изменен в процессе внедрения. Но для внедрения информационной системы, которая уже есть и чьи доработки могут и не состояться, аджайл больше вреден, чем полезен.
Финансы
Аджайл в ИТ-финансах... Наверное, он возможен, если есть достаточно большой запас свободных денег, который при необходимости может быть направлен на нужды ИТ. Но в жизни я такого не встречал ни разу. Классическая картина – бюджет на квартал, в лучшем случае допускаются обоснованные превышения. Все. Вся гибкость только в манипуляциях статьями. Сколько потратил, сколько сэкономил, и на что конкретно израсходованы средства.
В общем, картина получается такая, что далеко не все «аджализируется» столь быстро, как хотелось бы.
Скрам
Существует еще один момент, и его надо иметь в виду, говоря о гибких методологиях в целом: есть гибкие методологии, которые работают (пусть на ограниченной выборке, но работают), а есть их интерпретации. Например, такая вещь, как скрам-митинг, не должна превышать по времени 15–30 минут. А на деле может и час, и два. Смысл такого митинга в какой-то момент начинает стремиться к нулю: все уже забыли, с чего он начался, а некоторые озадачились вопросом, что они тут вообще делают.
Ну и если про скрам, то там есть условие: команда кросс-функциональна, то есть работает четко по спринтам. Увы. При разработке сложных систем часто требуется большой объем аналитики, который никак не «уложить» в один спринт с разработкой. Так или иначе это ограничение обходится (я, например, выводил аналитиков в отдельную команду, занятую тем, что готовила аналитику на следующий спринт разработки), но... формально так делать не рекомендуется. Кстати, тестирование тоже может оказаться за границами спринта, хотя в моем опыте это все-таки происходило гораздо реже, чем в случае с аналитикой.
Самое сложное – увязать в одну систему жесткие сроки и гибкость. Хотя эта задача вполне решаема, о чем я писал в статье «Agile и «водопад», или История одного изменения»[1],
А если же посмотреть чуть дальше ИТ, то есть на бизнес, окажется, что ситуация очень напоминает ИТ. Скрам в бухгалтерии даже не рассматривается – скорее всего, налоговая не оценит подготовку декларации по спринтам. Можно, наверное, внедрить скрам и подобные ему методологии в производство при условии, что это небольшое производство, с нефиксированным ассортиментом выпускаемой продукции. Еще в юридическом отделе и hr он вполне может прижиться. Но вот чтобы сразу вся фирма, целиком – не видел ни разу. В этом смысле для меня очень интересно наблюдать за смелым экспериментом Сбербанка по аджайл-трансформации. С одной стороны, мой опыт говорит, что для подобной структуры данная трансформация – сверхзадача и «есть риск, что не потянет», а с другой – Сбербанк смог измениться, пройдя непростой путь от банка, который все не любят, до банка с достаточно человеческим лицом. Да и отдельные подразделения внутри банка (как минимум в разработке) уже используют аджайл, что внушает определенный оптимизм.
***
Общий вывод из сказанного: аджайл, скрам и любые другие модные и «хайповые» вещи применять можно и нужно, только четко понимая, зачем это делается, что получится «на выходе» и сколько будет стоить переход. Потому что логика Портоса («я дерусь потому, что дерусь») хорошо работает в фильме, но очень ограничена в реальной жизни. Особенно когда по итогам «драки» нужно получить прибыль.
[1] IT Manager № 155, декабрь 2016.
Опубликовано 03.02.2019