Портал №1 по управлению цифровыми
и информационными технологиями

Туннельный эффект

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

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

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

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

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

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

  1. Существует конфликт интересов поставщика сервиса и его потребителей. 
  • С одной стороны у нас есть интересы наших потребителей (объединю в этот термин потребителей и заказчиков), и эти интересы для нас имеют первоочередный приоритет. Весь подход основан на user stories, которые говорят нам: какие выгоды получит наш любимый пользователь от выполняемого изменения.
  • С другой стороны, у нас есть product/process owner, который в идеале имеет некоторое видение своего продукта, которое может отличаться от пользовательских ожиданий. Но тем оно и ценно, т.к. это видение способно формировать эти самые ожидания.
  1. В жизни сервиса могут возникать ситуации, когда эволюционных изменений будет недостаточно. Это может происходить из-за того, что:
  • За несколько лет накопился неустранимый технический долг, апологеты будут возражать, что такого происходить не должно, но в реальном мире это возможно. Решение стало сплошной заплаткой сплетенной из костылей разных лет, базы данных clipper более не подддерживаются, и т.д., по еще тысяче причин.
  • За несколько лет недофинансирования (бизнес конечно считает иначе) продукт или услуга перестает отвечать ожиданиям и дешевле купить новое и готовое и начать с этой точки, чем довести существующий продукт до требуемого состояния. Или требуется новая функциональность, которая не совместима со старой архитектурой.
  • Бизнес может говорить о том, что для него длишком дорого держать и кормить прорву разработчиков, от которых он же будет очень сильно зависеть.Для него, это люди, которые непрерывно делают что-то малопонятное со слабо доказуемой полезностью (на это конечно тоже есть возражения, да). По его оценкам стоимость разработчиков SAP и интегратора в конечном итоге выйдет дешевле, т.к. их участие будет все же ограниченным, чем этот нон-стоп карнавал "хипстеров". Ведь даже если бизнес ничего не будет прямо сейчас просить, разработчики будут заниматься рефакторингом, чтобы сделать быстрее-легче-тоньше (6 сигма и все-все-все), чтобы обосновать свою нужность, нет?
  1. Некоторые вещи (и процессы и продукты) могут быть запущены и использованы только блочно (архитектурно или на основании нормативных ограничений), а значит в эволюционном течении будут пороги различной величины и опасности.

Формируется настойчивое ощущение, что в реальном мире отказаться от "бимодального" IТ будет нельзя. 

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

Обращаюсь к коллегам, которые используют agile для проектов с большим месштабом и множеством заинтересованных лиц, вроде внедрение новой БАС, переход с одной ERP на другую, внедрение СМЭВ, расскажите как вы это делаете. Какого размера ваши ступеньки, они же существуют?

Что делать когда компоненты вашей услуги покупные и вы их только эксплуатируте (и мы видим много таких ИТ-служб), это тоже Agile?

Не переплачивает ли бизнес за непрерывное возведение самописных высокорискованных (фактор зависимости) велосипедов, если сравнивать с публичными промышленными решениями?

Сегодня очень многие говорят про Agile, но даже если у вас IaaS, кто-то должен эти серверы запросить, закупить, физически привезти, руками смонтировать, обеспечить кондиционирование и энергоснабжение (ChgM 🙂 ), подключить к управляемой сети и включить в умный вычислительный grid. И только после этого начнeтся "continious deployment", "infrustructure as a code" и прочие радости.

Что-то у меня сегодня "день скептика" и я порождаю больше вопросов чем ответов. Поделитесь пожалуйста вашим опытом или видением.

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM