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

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

Давайте рассмотрим девять ситуаций, в которых ИТ-директор обманывает не подчиненных или коллег по бизнесу, а самого себя.

Самообман № 1. Мы ориентируем ИТ на бизнес

Добиться соответствия своих действий целям бизнеса. Звучит настолько впечатляюще, что многие ИТ- руководители выстраивают процессы управления ИТ таким образом, чтобы обеспечить эту согласованность.

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

При таких внутренних расчетах ИТ-служба пытается добиться прежде всего согласованности с бюджетом бизнеса. И если это соответствует его целям, то хорошо, а если нет, пусть голова об этом болит у кого-то другого.

Самообман № 2. Единственная причина обновления программного обеспечения обусловлена реализацией в новой версии важных ценностей бизнеса

Это не просто звучит убедительно, а принимается как руководство к действию. Явно, что ИТ-директор, проводящий такую политику, ориентирован на бизнес и его нельзя обвинить в тратах на технологии ради самих технологий.

Более того, при таком раскладе ИТ-бюджет можно сокращать, так как нет необходимости в средствах на поддержание актуальных версий.

Однако ИТ-директор, придерживающийся таких взглядов, или никогда не переживал провальных модернизаций из-за перескакивания через несколько технологических поколений, или мог переложить вину за возникший хаос на другого.

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

Самообман № 3. Реализация важного проекта не укладывается в сроки? Перейдем сразу к следующему этапу и завершим его, как было намечено по графику

Вот как обычно развиваются события.

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

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

Планирование. После согласования всех вопросов с бизнес-клиентами ИТ-служба приступает к обратному планированию и, начиная с даты завершения проекта, движется назад, намечая для себя приемлемые сроки. Руководитель проекта крутит и вертит имеющимися у него ресурсами и параметрами до тех пор, пока расписание не начнет выглядеть правдоподобно.

Желтый уровень. Состояние проекта, при котором отставание от сроков становится настолько существенным, что пути к спасению уже нет, но при этом до сдачи остается еще немало времени и отрицание проблем по-прежнему подменяет собой реальность. Ловкие менеджеры начинают действовать в двух направлениях. Во-первых, они сокращают продолжительность тестирования. Проект вновь возвращается в зеленый статус... А во-вторых, начинают подыскивать себе работу, пока проваленный проект еще не погубил их репутацию.

Тестирование первого уровня. Здесь качество, считавшееся отличным, снижается до достаточно хорошего. При отсутствии четких стандартов и наличии некоего политического влияния даже самый плохой код можно пропихнуть в производство.

Тестирование второго уровня. Вы всегда проводите тестирование, и весьма тщательно. Но выполняется ли тщательное тестирование до или после того, как ПО уйдет в производство?

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

Самообман № 4. Мы придерживаемся методологии ITIL

«Придерживаться» ITIL невозможно. ITIL – это библиотека инфраструктуры ИТ, как терпеливо объясняют ее сторонники.

В ITIL перечислены направления, в которых применение ИТ целесообразно. Там не описано, как добиться этой целесообразности, как нет и рекомендаций ITIL на все случаи жизни.

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

Самообман № 5. Мы исповедуем agile-разработку

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

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

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

Самообман № 6. Мы придерживаемся DevOps

Вы не придерживаетесь даже agile-проектирования!

При всей шумихе вокруг DevOps сторонники этого подхода не являются изобретателями взаимодействия. Agile-проектирование – реальное, а не гибко-водопадное – способствовало реальному взаимодействию задолго до появления DevOps, хотя следует признать, что разработчики не больно-то взаимодействуют с персоналом, занимающимся обслуживанием.

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

Третий момент связан с DevOps. Дело в том, что ПО находится в состоянии постоянного развертывания (deployable). Наряду с многочисленными неудобствами для большинства сторонников agile-разработки это означает, что DevOps и Scrum не являются полностью совместимыми. Kanban работает лучше.

Самообман № 7. У нас есть культура обслуживания клиентов

Слышите смешок, доносящийся из службы поддержки... ой, простите, сервисной службы? Это сотрудники вашей сервисной службы делятся друг с другом историями про тупых пользователей – никакой культуры обслуживания!

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

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

ИТ-директор должен воспитывать в ИТ-службе культуру обслуживания.

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

Самообман № 8. Наша информационная безопасность на высоте

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

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

Если ИТ-директор полагает, что информационная безопасность у него на высоте, он, очевидно, ошибается. Сохранить все в приличном виде удается обычно тем, кто озабочен наличием брешей в своей системе безопасности.

Самообман № 9. Наш процесс управления ИТ гарантирует реализацию только тех проектов, которые имеют высокую ценность для бизнеса

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

Таким образом, окончательные решения становятся еще и предметом торга и выстраивания личных взаимоотношений.

Сюда следует добавить и еще одну неприятную деталь: проекты, цель которых заключается в сокращении расходов, будут приоритетнее, чем проекты, направленные на увеличение доходов. Почему? Сокращение расходов бизнес может контролировать. Увеличение же доходов требует от клиентов того, чего вы хотите. А они зачастую этого не делают. И вы не можете им приказывать, а должны пытаться убеждать.

***

Какой же вывод можно сделать? Если вы в чем-либо уверены, то почти наверняка ваша уверенность ошибочна. И если, будучи ИТ-директором, вы готовы записать в свой актив перечисленные пункты, задайте себе простой вопрос: почему? И постарайтесь на него ответить.

 

− Bob Lewis. 9 lies CIOs tell themselves. CIO. August 21, 2017