Если бы Ахиллес был ИТ-директором, его сгубил бы самообман. Непреложная уверенность в том, что ИТ-служба и бизнес-подразделения действуют согласованно, информационная безопасность пуленепробиваема, а все проекты реализуются вовремя, стала бы его «уязвимой пятой». А между тем, обманывая себя, ИТ- руководители закладывают мину замедленного действия и создают предпосылки для грядущих катастроф.
Обманываем мы себя не потому, что сознательно хотим установить неверные приоритеты, принять неправильные решения и двигаться к неверной цели, а потому, что выдавать желаемое за действительное намного проще, чем реально оценивать все происходящее в мире.
Давайте рассмотрим девять ситуаций, в которых ИТ-директор обманывает не подчиненных или коллег по бизнесу, а самого себя.
Иллюзия № 1. Мы ориентируем ИТ на бизнес.
Добиться соответствия своих действий целям бизнеса. Звучит настолько впечатляюще, что многие ИТ- руководители выстраивают процессы управления ИТ таким образом, чтобы обеспечить эту согласованность.
Жаль, что на практике согласованно работают очень мало предприятий, причем независимо от своей величины. Декларирование соответствия целям бизнеса используется, как правило, для того, чтобы успокоить игроков, имеющих большой политический вес, или выстроить для себя систему расчетов между подразделениями...
Да-да, именно расчетов между подразделениями. В ИТ-службе готовы браться за любые задачи и обещать все что угодно, но лишь до тех пор, пока ее проекты финансируются.
При таких внутренних расчетах ИТ-служба пытается добиться прежде всего согласованности с бюджетом бизнеса. И если это соответствует его целям, то хорошо, а если нет, пусть голова об этом болит у кого-то другого.
Иллюзия № 2. Единственная причина обновления программного обеспечения обусловлена реализацией в новой версии важных ценностей бизнеса.
Это не просто звучит убедительно, а принимается как руководство к действию. Явно, что ИТ-директор, проводящий такую политику, ориентирован на бизнес (и соответствие его целям) и его никак нельзя обвинить в тратах на технологии ради самих технологий.
Более того, при таком раскладе ИТ-бюджет можно сокращать, поскольку нет необходимости в средствах на поддержание актуальных версий.
Однако ИТ-директор, придерживающийся таких взглядов, либо никогда не переживал провальных модернизаций из-за перескакивания через несколько технологических поколений, либо ему успешно удавалось переложить вину за возникший хаос на кого-то другого.
Обновления программного обеспечения требуют профилактического обслуживания. Платить за него в любом случае придется либо сейчас, либо позже. Но откладывание на потом приведет к тому, что все станет значительно сложнее и дороже.
Иллюзия № 3. Реализация большого и важного проекта не укладывается в сроки? Перейдем сразу к следующему этапу и завершим его, как было намечено по графику.
Вот как обычно развиваются события.
Бизнес-сценарий. Здесь все тонко. Непосредственной причиной катастрофы могут стать действия кого угодно. Но, по сути, все менеджеры ведут себя одинаково еще с тех времен, когда об электронных таблицах никто и слыхом не слыхивал: пока окупаемость превышает минимально допустимый уровень, они продолжают убеждать себя в том, что все их предположения так или иначе верны.
Требования и спецификации. Оценка требований и спецификаций обычно и является той стадией, на которой происходят неприятности. Чем масштабней проект, тем больше в нем неизвестных ложных посылов, каждый из которых приводит к дальнейшему усложнению ситуации. Этап разработки требований и спецификаций всегда длится долго, но в этом-то как раз нет ничего страшного. Все понимают, что чем тщательнее выполнялось проектирование, тем меньше времени понадобится для написания программного кода и тестирования. Потратив больше времени сейчас, мы сэкономим его в дальнейшем.
Планирование. После согласования всех вопросов с бизнес-клиентами ИТ-служба приступает к обратному планированию и, начиная с даты завершения проекта, движется назад, намечая для себя приемлемые сроки. Руководитель проекта отчаянно крутит и вертит имеющимися у него ресурсами и параметрами до тех пор, пока расписание не начнет выглядеть правдоподобно. По крайней мере, настолько, чтобы никому не пришло в голову вдаваться в его детали.
Желтый уровень. Это состояние проекта, при котором отставание от сроков становится настолько существенным, что никакого пути к спасению уже нет, но при этом до сдачи остается еще немало времени и отрицание проблем по-прежнему подменяет собой реальность. Когда проект переходит в такую стадию, ловкие менеджеры начинают действовать в двух направлениях. Во-первых, они сокращают продолжительность тестирования. Проект вновь возвращается в зеленый статус (и тот же оттенок приобретают лица людей, работающих над ним).
А во-вторых, начинают подыскивать себе работу, пока проваленный проект еще не погубил их репутацию.
Тестирование первого уровня. Здесь качество, считавшееся отличным, снижается до достаточно хорошего. При отсутствии четких стандартов и наличии определенного политического влияния даже самый плохой код можно пропихнуть в производство.
Тестирование второго уровня. Вы всегда проводите тестирование, и причем весьма тщательно. Единственный вопрос, выполняется ли тщательное тестирование до или после того, как программное обеспечение уйдет в производство.
Схождение с рельсов. Новый ИТ-директор останавливает неминуемое крушение поезда. Его предшественник винит во всем руководителя проекта. А руководитель проекта посещает форумы Института по управлению проектами с той же обреченностью, с какой люди, испытывающие болезненную тягу к спиртному, приходят на собрания общества анонимных алкоголиков.
Иллюзия № 4. Мы придерживаемся методологии ITIL.
Это может показаться придиркой, но «придерживаться» ITIL невозможно. ITIL – это библиотека инфраструктуры ИТ, как терпеливо объясняют ее сторонники всем, кто готов слушать.
В ITIL перечислены направления, в которых применение ИТ целесообразно. Там не описано, как добиться этой целесообразности, равно как нет рекомендаций ITIL на все случаи жизни.
Между тем есть много ИТ-директоров, для которых «соблюдение ITIL» эквивалентно созданию приличной сервисной службы (или, по крайней мере, переименованию службы поддержки в «сервисную службу») и формированию консультативного совета по изменениям, который будет располагаться между разработчиками приложений и обслуживающим персоналом. В этом случае и те и другие будут апеллировать к консультативному совету, а не друг к другу.
Иллюзия № 5. Мы исповедуем agile-разработку.
В мире есть много ИТ-организаций, уже перешедших от разработки приложений методом водопада к одному или нескольким вариантам agile-проектирования либо находящихся в процессе такого перехода.
Но на каждого, кто действительно придерживается методологии agile, приходится с десяток других, отдающих предпочтение «гибко-водопадному» комбинированию, избегающих строгого выполнения формальных правил Scrum и полностью игнорирующих сам дух гибкой трансформации.
Те же, кто избежал гибко-водопадной ловушки, движутся в ином направлении. Их уделом становится не гибкость, а бессистемность, навязываемая зачастую по указке «водопадника», который убежден в том, что усилия по продвижению гибкого проектирования обречены на провал, и делает все для того, чтобы так и случилось.
Иллюзия № 6. Мы придерживаемся DevOps.
Ничего подобного. Вы не придерживаетесь даже agile-проектирования. И удосужились ли прочесть все то, что было написано ранее?
Ну хорошо, соглашусь с тем, что при всей шумихе вокруг DevOps сторонники этого подхода не являются изобретателями взаимодействия. Гибкое проектирование – реальное, а не гибко-водопадное – способствовало реальному взаимодействию задолго до появления DevOps, хотя справедливости ради следует признать, что разработчики не больно-то взаимодействуют с персоналом, занимающимся обслуживанием.
Вот что DevOps добавляет в гибкое проектирование.
Во-первых, в состав команды разработчиков входят и системные администраторы. Никто не хочет ждать окончания построения среды и решений консультативного совета по внесению программных изменений. Во-вторых, автоматизация сегодня присутствует повсюду, и это хорошо. Пытаться управлять программными изменениями вручную при нынешних темпах их развития – просто глупо.
Третий момент связан с DevOps, а не с другими вариантами гибкого проектирования и уж, конечно, не с водопадной методологией. Дело в том, что программное обеспечение находится в состоянии постоянного развертывания (deployable). Нет, нет, не deplorable (в плачевном виде), а deployable. Наряду с многочисленными неудобствами для большинства сторонников гибкой разработки это означает, что DevOps и Scrum не являются полностью совместимыми. Kanban работает лучше.
Иллюзия № 7. У нас есть культура обслуживания клиентов.
Слышите смешок, доносящийся из службы поддержки … ой, простите, сервисной службы. Это сотрудники вашей сервисной службы делятся друг с другом историями про тупых пользователей - никакой культуры обслуживания! Потому что культура начинается с уважения.
Впрочем, это неважно, ведь когда культура есть, ИТ-директор считает, что весь бизнес является его клиентом.
Очень плохая идея. Она ведет к нездоровой концепции платежей между подразделениями – отличной возможности растратить время и энергию на споры о счетах ИТ-службы, а заодно и исчерпать доверие к ней.
Если вам до сих пор непонятно, почему «культура обслуживания клиентов» является плохой идеей, посмотрите, что произойдет, когда вы удалите слово «клиентов».
ИТ-директор должен воспитывать в ИТ-службе культуру обслуживания.
Как узнать, есть ли у вас эта культура или нет? Если вы по-прежнему слышите рассказы об идиотах-пользователях, значит, ее нет.
Иллюзия № 8. Наша информационная безопасность на высоте
Помните о гибких водопадах и наборе галочек? Вместо того, чтобы помогать контролировать процесс, очень часто увлекаются простановкой галочек, и это превращается в самоцель. Сфере информационной безопасности это тоже присуще, особенно если дело касается сертификации выполнения нормативных требований.
На ум здесь сразу приходит стандарт безопасности, касающийся платежных карт. Можно припомнить, что в Target в 2013 году потеряли около 40 млн клиентских записей, несмотря на соответствие всем стандартам отрасли платежных карт. И это далеко не единственный пример потери данных компаниями, прошедшими проверку на соответствие требованиям информационной безопасности.
Если ИТ-директор полагает, что информационная безопасность у него на высоте, он, очевидно, ошибается. Сохранить все в приличном виде удается обычно как раз тем, кто озабочен наличием брешей в своей системе безопасности.
Иллюзия № 9. Наш процесс управления ИТ гарантирует реализацию только тех проектов, которые имеют высокую ценность для бизнеса
Давайте опять вернемся к соответствию целям бизнеса.
Управление ИТ предполагает, что финансирование будет обеспечено лишь проектам, обладающим наибольшей ценностью для бизнеса. Но независимо от того, насколько хорошо продуман проект, реализацией его будут заниматься те же самые люди, действия которых не слишком согласуются друг с другом.
Таким образом окончательные решения становятся еще и предметом торга и выстраивания личных взаимоотношений.
Сюда следует добавить и еще одну неприятную деталь: проекты, цель которых заключается в сокращении расходов, будут приоритетнее, чем проекты, направленные на увеличение доходов. Почему? Сокращение расходов бизнес может контролировать. Если все идет по плану, расходы будут сокращаться.
Увеличение же доходов требует от клиентов того, чего вы хотите. А они зачастую этого не делают. И вы не можете им приказывать, а вынуждены пытаться убеждать.
Какой же вывод можно сделать? Если вы в чем-либо уверены, то почти наверняка ваша уверенность ошибочна. И если, будучи ИТ-директором, вы готовы записать в свой актив девять перечисленных пунктов (или каких-то других), задайте себе простой вопрос: почему? И постарайтесь на него ответить.
– Bob Lewis. 9 lies CIOs tell themselves. CIO. August 21, 2017
