УправлениеИТ в бизнесе

Про моду, гибкость и жизнь

Александр Башкиров | 03.02.2019

Про моду, гибкость и жизнь

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

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

Разработка

С разработкой вроде бы все понятно. В том смысле, что гибкие методологии родом как раз из этого сегмента. Но... Всегда ли они применимы в реальной жизни? Честный ответ: нет, и еще раз нет. Почему? Наша культура (имеется в виду культура предпринимательства) живет в парадигме «срок-результат». Гибкие же методы разработки явно тяготеют к проектам типа time & material (или, как их иронично называют, «любой каприз за ваши деньги»). Предприниматель же склонен платить за результат, вне зависимости от методологий, спринтов, гибкости и т. д. «Я хочу, чтобы к такой-то дате мы имели новую систему отчетности. Бюджет вот». Где тут, простите, хотя бы намек на гибкость?

Не спорю: она может быть внутри. Разработка по спринтам, освоение объема в зависимости от скорости... Это все «под капотом». Снаружи – жесткий срок.

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

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

Все ли так грустно? Нет. Встречаются заказчики (как правило, внутренние) и проекты, которые могут и хотят работать «по-гибкому». Но их мало. Очень мало.

Поддержка

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

Инфраструктура

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

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

Финансы

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

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

Скрам

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

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

Самое сложное – увязать в одну систему жесткие сроки и гибкость. Хотя эта задача вполне решаема, о чем я писал в статье «Agile и «водопад», или История одного изменения»[1],

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

***

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

 




[1] IT Manager № 155, декабрь 2016.



Разработка ПО

Темы: Бизнес в цифре

Журнал: Журнал IT-Manager [№ 01/2019], Подписка на журналы


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Мысли вслух

Мы много и часто говорим о том, что "ИТ меняют наш мир". Посмотрим, как это происходит в Китае с применением конкретных инструментов и затрагивает сотни миллионов человек.
Согласно прогнозам Gartner, к 2022 г. 75% организаций, использующих инфраструктуру как сервис (IaaS), будут реализовывать продуманную мультиоблачную стратегию, в то время как в 2017 г. доля таких компаний составляла 49%.
Все жалуются на нехватку времени. Особенно обидно, что его не хватает на самые важные вещи. Совещания, созвоны, подготовка внутренних отчетов, непонятно, насколько нужных, но которые начальство требует так, как будто это именно то, ради чего мы работаем.

Компании сообщают

Мероприятия

VI Конференция ЦИПР-2021
Нижний Новгород, ул. Совнаркомовская, дом 13, «Нижегородская Ярмарка»
15 000 руб
23.06.2021
Выставка «EXPO-RUSSIA KAZAKHSTAN 2021»
Республика Казахстан
23.06.2021 — 25.06.2021
10:00–18:00
ЖКХ Будущего. Актуальные вопросы и решения
ОНЛАЙН
10 500 руб
24.06.2021 — 25.06.2021
10:00–18:00