Это интересно
- ОКД
- ЗКС
- ИПО
- КНПВ
- Мондиоринг
- Большой ринг
- Французский ринг
- Аджилити
- Фризби
Опрос
Полезные ссылки
РКФ
Все о дрессировке собак
Стрижка собак в Коломне
Поиск по сайту
Семь советов будущему ИТ-директору. Ит директор журнал
9 иллюзий ИТ-директора | Вестник цифровой трансформации
Обманывая себя, руководители ИТ-служб закладывают мину замедленного действия и создают предпосылки для грядущих катастроф.
Если бы Ахиллес был ИТ-директором, его сгубил бы самообман. Непреложная уверенность в том, что ИТ-служба и бизнес-подразделения действуют согласованно, информационная безопасность пуленепробиваема, а все проекты реализуются вовремя, стала бы его «уязвимой пятой». А между тем, обманывая себя, ИТ- руководители закладывают мину замедленного действия и создают предпосылки для грядущих катастроф.
Обманываем мы себя не потому, что сознательно хотим установить неверные приоритеты, принять неправильные решения и двигаться к неверной цели, а потому, что выдавать желаемое за действительное намного проще, чем реально оценивать все происходящее в мире.
Давайте рассмотрим девять ситуаций, в которых ИТ-директор обманывает не подчиненных или коллег по бизнесу, а самого себя.
Иллюзия № 1. Мы ориентируем ИТ на бизнес.
Добиться соответствия своих действий целям бизнеса. Звучит настолько впечатляюще, что многие ИТ- руководители выстраивают процессы управления ИТ таким образом, чтобы обеспечить эту согласованность.
Жаль, что на практике согласованно работают очень мало предприятий, причем независимо от своей величины. Декларирование соответствия целям бизнеса используется, как правило, для того, чтобы успокоить игроков, имеющих большой политический вес, или выстроить для себя систему расчетов между подразделениями...
Да-да, именно расчетов между подразделениями. В ИТ-службе готовы браться за любые задачи и обещать все что угодно, но лишь до тех пор, пока ее проекты финансируются.
При таких внутренних расчетах ИТ-служба пытается добиться прежде всего согласованности с бюджетом бизнеса. И если это соответствует его целям, то хорошо, а если нет, пусть голова об этом болит у кого-то другого.
Иллюзия № 2. Единственная причина обновления программного обеспечения обусловлена реализацией в новой версии важных ценностей бизнеса.
Это не просто звучит убедительно, а принимается как руководство к действию. Явно, что ИТ-директор, проводящий такую политику, ориентирован на бизнес (и соответствие его целям) и его никак нельзя обвинить в тратах на технологии ради самих технологий.
Более того, при таком раскладе ИТ-бюджет можно сокращать, поскольку нет необходимости в средствах на поддержание актуальных версий.
Однако ИТ-директор, придерживающийся таких взглядов, либо никогда не переживал провальных модернизаций из-за перескакивания через несколько технологических поколений, либо ему успешно удавалось переложить вину за возникший хаос на кого-то другого.
Обновления программного обеспечения требуют профилактического обслуживания. Платить за него в любом случае придется либо сейчас, либо позже. Но откладывание на потом приведет к тому, что все станет значительно сложнее и дороже.
Иллюзия № 3. Реализация большого и важного проекта не укладывается в сроки? Перейдем сразу к следующему этапу и завершим его, как было намечено по графику.
Вот как обычно развиваются события.
Бизнес-сценарий. Здесь все тонко. Непосредственной причиной катастрофы могут стать действия кого угодно. Но, по сути, все менеджеры ведут себя одинаково еще с тех времен, когда об электронных таблицах никто и слыхом не слыхивал: пока окупаемость превышает минимально допустимый уровень, они продолжают убеждать себя в том, что все их предположения так или иначе верны.
Требования и спецификации. Оценка требований и спецификаций обычно и является той стадией, на которой происходят неприятности. Чем масштабней проект, тем больше в нем неизвестных ложных посылов, каждый из которых приводит к дальнейшему усложнению ситуации. Этап разработки требований и спецификаций всегда длится долго, но в этом-то как раз нет ничего страшного. Все понимают, что чем тщательнее выполнялось проектирование, тем меньше времени понадобится для написания программного кода и тестирования. Потратив больше времени сейчас, мы сэкономим его в дальнейшем.
Планирование. После согласования всех вопросов с бизнес-клиентами ИТ-служба приступает к обратному планированию и, начиная с даты завершения проекта, движется назад, намечая для себя приемлемые сроки. Руководитель проекта отчаянно крутит и вертит имеющимися у него ресурсами и параметрами до тех пор, пока расписание не начнет выглядеть правдоподобно. По крайней мере, настолько, чтобы никому не пришло в голову вдаваться в его детали.
Желтый уровень. Это состояние проекта, при котором отставание от сроков становится настолько существенным, что никакого пути к спасению уже нет, но при этом до сдачи остается еще немало времени и отрицание проблем по-прежнему подменяет собой реальность. Когда проект переходит в такую стадию, ловкие менеджеры начинают действовать в двух направлениях. Во-первых, они сокращают продолжительность тестирования. Проект вновь возвращается в зеленый статус (и тот же оттенок приобретают лица людей, работающих над ним).
А во-вторых, начинают подыскивать себе работу, пока проваленный проект еще не погубил их репутацию.
Тестирование первого уровня. Здесь качество, считавшееся отличным, снижается до достаточно хорошего. При отсутствии четких стандартов и наличии определенного политического влияния даже самый плохой код можно пропихнуть в производство.
Тестирование второго уровня. Вы всегда проводите тестирование, и причем весьма тщательно. Единственный вопрос, выполняется ли тщательное тестирование до или после того, как программное обеспечение уйдет в производство.
Схождение с рельсов. Новый ИТ-директор останавливает неминуемое крушение поезда. Его предшественник винит во всем руководителя проекта. А руководитель проекта посещает форумы Института по управлению проектами с той же обреченностью, с какой люди, испытывающие болезненную тягу к спиртному, приходят на собрания общества анонимных алкоголиков.
Иллюзия № 4. Мы придерживаемся методологии ITIL.
Это может показаться придиркой, но «придерживаться» ITIL невозможно. ITIL – это библиотека инфраструктуры ИТ, как терпеливо объясняют ее сторонники всем, кто готов слушать.
В ITIL перечислены направления, в которых применение ИТ целесообразно. Там не описано, как добиться этой целесообразности, равно как нет рекомендаций ITIL на все случаи жизни.
Между тем есть много ИТ-директоров, для которых «соблюдение ITIL» эквивалентно созданию приличной сервисной службы (или, по крайней мере, переименованию службы поддержки в «сервисную службу») и формированию консультативного совета по изменениям, который будет располагаться между разработчиками приложений и обслуживающим персоналом. В этом случае и те и другие будут апеллировать к консультативному совету, а не друг к другу.
Иллюзия № 5. Мы исповедуем 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
www.cio.ru
Чтобы стать «супергероем», ИТ-директор должен найти надежного помощника | Вестник цифровой трансформации
Преуспеть в должности ИТ-директора вам поможет верный «оруженосец» — правопреемник, вдумчивый советчик, незаменимый помощник. Расскажем, как выбрать и «воспитать» идеального заместителя.
У Одинокого Рейнджера был Тонто, у Бэтмена – Робин. А Хан Соло без Чубакки просто потерялся бы в космосе.
Подобно супергероям из фильмов, ИТ-директор добивается успеха не в одиночку. Ему нужны опытные ассистенты, могущие подменить начальника, пока тот занят разбирательствами с поставщиками, способные вовремя дать ценный практический совет и позаботиться о том, чтобы стратегические инициативы руководителя шли правильным путем.
Напарник необходим, ведь работа ИТ-директора за последний десяток лет стала намного сложнее. Сегодня ИТ-директор меньше фокусируется на технологиях для текущих задач и больше – на стратегических бизнес-инициативах. В то же время он по-прежнему несет ответственность за работоспособность серверов в условиях практически ежедневных изменений технического ландшафта, когда традиционные разобщенные системы выводятся из эксплуатации и по всей организации внедряются новые технологии.
С одной стороны, ИТ-директор участвует в управлении бизнесом наряду с остальными топ-менеджерами. С другой – сами информационные технологии меняются, вытесняя традиционные роли и заставляя руководителей совмещать различные функции. Наличие заместителя, который возьмет на себя часть работы ИТ-директора, пока тот решает вопросы с другими руководителями, – необходимость для современной организации.
При этом роли и навыки ассистентов могут варьироваться. Лучших заместителей можно было бы разделить на три категории – «очевидный правопреемник», «мудрый советчик» и «незаменимый помощник», условно сопоставив их с популярными киногероями: Уильямом Райкером из «Звездного пути», Тирионом Ланнистером из «Игры престолов» и Пеппер Поттс из «Железного человека».
Очевидный правопреемник (Райкер)
ИТ-директору крупной организации нужен заместитель, способный действовать от имени руководителя, имея все его полномочия, – некто вроде коммандера Уильяма Райкера из сериала «Звездный путь: следующее поколение».
Когда капитан Пикар покидает мостик, на его место заступает Райкер, становясь командиром. Он великодушен, честен, открыт и предан. Он не эгоист, не соперник, а следующий в иерархии, способный взять на себя роль руководителя. Благодаря этим его качествам подчиненные ему доверяют.
Подобно самим ИТ-директорам, успешные заместители, как и Райкер, обычно принадлежат к старшему поколению, обладая обширным опытом и знаниями.
Это далеко не простая должность. Еще десять лет назад «Райкер» беспокоился бы в основном об эксплуатации ИТ, а сегодня его задача сильно усложнилась и включает элементы управления бизнесом. Поиск кандидата на эту роль может оказаться трудным, поскольку одних превосходных технических навыков будет недостаточно.
Для человека, являющегося вашей «правой рукой», важна преданность, ведь вы изо дня в день работаете с ним плечом к плечу. Образ идеального заместителя дополняется честностью и открытостью – качествами, которые демонстрирует, подавая пример, и сам ИТ-директор.
Мудрый советчик (Тирион Ланнистер)
Некоторым ИТ-директорам нужен не потенциальный наследник и не тот, кто способен временно занять место начальника, полностью взяв на себя его обязанности. Им требуются люди с более обширным, чем у них, опытом, которые способны в нужную минуту поделиться знаниями и дать ценный совет.
Консервативные руководители могут по-прежнему предпочитать держаться на верхушке пирамиды, стремясь быть «самыми умными в комнате», однако от подобной самовлюбленности пора отказываться. Чтобы поддерживать необходимый темп развития бизнеса, нужно, напротив, нанимать более мудрых людей, чем вы сами.
Это должен быть кто-то вроде Тириона Ланнистера, «десницы короля» из «Игры престолов», которому было бы некомфортно сидеть на Железном троне, но который охотно нашепчет мудрый совет на ухо монарху.
Потребность в «Тирионе» зависит от масштаба, области деятельности и уровня зрелости вашей компании. Достаточно крупной организации, подобной космическому кораблю «Энтерпрайз», скорее, нужен Райкер. Но в каких-то ситуациях требуется не тот, кто способен занять ваше место, а тот, кто сможет дополнить ваши возможности.
Фактически офису ИТ-директора нередко нужны даже два «Тириона». Один – с деловой хваткой, готовый встречаться с клиентами и обучать другие подразделения компании работать более эффективно, выполняя классическую роль консультанта по ИТ. Другой – идейный лидер, способный делиться техническими знаниями с остальными подчиненными ИТ-директора. В наше время ИТ-архитектура предприятия меняется буквально каждые полгода, а такой человек сможет пропагандировать новые технологии, помогая приучать персонал мыслить в новых категориях. Людей подобного сорта найти чрезвычайно сложно. В качестве примера можно привести компанию Hitachi Vantara, разрабатывающую решения для Промышленного интернета вещей, которой требовался специалист по архитектуре, не только понимающий текущее положение дел в компании, но и способный рекомендовать дальнейшие направления развития. Поиск оказался непростым, но в конечном счете был найден заместитель ИТ-директора с нужными навыками.
Незаменимый помощник (Пеппер Потс)
«Железный Человек» Тони Старк не был бы таковым без Пеппер Потс, которая удерживает на верном пути его самого и компанию Stark Industries. ИТ-руководителю в организации практически любых размеров требуется директор по персоналу или по крайней мере кто-то способный выполнять соответствующие обязанности по совместительству.
Это не обязательно ваш потенциальный преемник, но это должен быть тот, кто будет заботиться об устойчивой работе организации. Некоторые из ИТ-директоров могут считать, что справятся со всем самостоятельно, но такие обычно быстро «перегорают».
Роль директора по персоналу подойдет кому-то не настолько многоопытному, как Райкер, но специалисту с большим потенциалом – возможно, как подготовка для дальнейшего карьерного роста. Этого человека стоит посвящать во все тонкости работы ИТ-директора, не забывая разъяснять стратегическое направление бизнеса. У многих ИТ-директоров есть заместители обоих типов – и «Райкер», и директор по персоналу.
Три главных качества «Пеппер Потс» – прекрасные организаторские навыки, способность сохранять спокойствие в сложных ситуациях и стремление высказывать правду в лицо начальству. Истинная Пеппер Потс не дрогнет, даже когда вокруг все горит и рушится. У нее всегда хватит смелости объявить королю, что он голый.
Людей с подобным сочетанием качеств найти сложнее всего. Обычно в организациях чем выше должность у начальника, тем больше ему боятся говорить правду в лицо. Изменить это можно, специально поддерживая такую среду, в которой люди привыкают объяснять другим, что они делают не так.
Команда заместителей
Для зрелых организаций, вероятно, больше всего подойдет Райкер с учетом того, что планирование преемственности будет особенно важным.
Но компании меняются. ИТ-директор может потратить годы на подготовку преемника, а тот в итоге уйдет, соблазнившись более заманчивым предложением. Поэтому лучше всего стараться развивать всех участников своей команды, чтобы любой из них смог в итоге сменить вас.
Выбирать кого-то одного рискованно, лучше помогать сразу нескольким. А в периоды, когда вы в отпуске, «тушите пожар» у клиента или отсутствуете по другим причинам, лучше чередовать заместителей, поручая им заменить вас, а не назначать одного и того же. Это позволит лучше оценить кандидатов в преемники, понять, насколько они справляются с принятием руководящих решений и контролем над подчиненными в ваше отсутствие. Это тоже необходимый элемент планирования преемственности.
Не менее важно разъяснить роль ваших заместителей прямым подчиненным и всей организации. Стоит объявить, какие из заместителей будут отвечать за принятие решений по тем или иным вопросам. Вообще, думать, что остальные как-то сами догадаются, за что отвечают конкретные заместители, – одна из крупнейших ошибок руководителя. Для дополнительной ясности в некоторых компаниях даже используют нагрудные значки, указывающие, кто отвечает за принятие решений в текущий период времени.
Независимо от того, насколько опытен ваш «номер два», одного заместителя будет недостаточно: успех ИТ-директора обеспечивает его команда. Ему необходим кто-то сведущий во всех новшествах маркетинговых технологий, тот, кто понимает, что делать с клиентскими данными, и кто в состоянии вдохновить сотрудников на ежедневный усердный труд. Кто-то один, как правило, всеми этими способностями не обладает. Поэтому, чтобы успешно вести бизнес вперед, старайтесь собирать вокруг себя носителей всех необходимых качеств.
– Dan Tynan. The secret to being a superhero CIO? A kickass sidekick. CIO. October 30, 2017
www.cio.ru
9 иллюзий ИТ-директора | Вестник цифровой трансформации
Обманывая себя, руководители ИТ-служб закладывают мину замедленного действия и создают предпосылки для грядущих катастроф.
Если бы Ахиллес был ИТ-директором, его сгубил бы самообман. Непреложная уверенность в том, что ИТ-служба и бизнес-подразделения действуют согласованно, информационная безопасность пуленепробиваема, а все проекты реализуются вовремя, стала бы его «уязвимой пятой». А между тем, обманывая себя, ИТ- руководители закладывают мину замедленного действия и создают предпосылки для грядущих катастроф.
Обманываем мы себя не потому, что сознательно хотим установить неверные приоритеты, принять неправильные решения и двигаться к неверной цели, а потому, что выдавать желаемое за действительное намного проще, чем реально оценивать все происходящее в мире.
Давайте рассмотрим девять ситуаций, в которых ИТ-директор обманывает не подчиненных или коллег по бизнесу, а самого себя.
Иллюзия № 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
www.cio.ru
Этот многоликий новый ИТ-директор | Вестник цифровой трансформации
Сегодня обязанности ИТ-директора сложны как никогда независимо от отрасли, будь то связь, производство, авиация, банки, здравоохранение, логистика или что-то еще. Какова же роль нового ИТ-директора в современном мире с его колоссальными объемами Больших Данных, облачными сервисами, господством социальных сетей, оцифровкой предприятий, всеобщим погружением в мобильные устройства и высочайшими рисками?
Традиционно круг топ-менеджеров был довольно тесным: генеральный директор, финансовый, ИТ-директор и директор по безопасности. Но в последнее время передовые предприятия вынуждены распрощаться с традициями. В эпоху всевозможных платформ в виде сервиса и других новшеств, которые приходится осваивать ИТ-директору, команде его прямых подчиненных необходимо измениться, иначе ему придется выполнять работу еще минимум за четверых. Перечислим тех, кто сегодня должен помогать ИТ-директору обеспечивать надежное будущее для предприятия.
Директор по данным
Директора по данным начали появляться в компаниях ряда отраслей, и, как прогнозируют в Gartner, к 2019 году эта должность будет уже в 90% крупных организаций. Но, с учетом новизны, круг задач руководителя на этой позиции еще четко не очерчен. По данным Gartner, число директоров по данным и аналитике с 2014 по 2015 год увеличилось с 400 до 1000. Стандартных указаний по вводу такой должности в компании нет, но аналитики Gartner подготовили примерный план на первые 100 дней работы директора по данным, призванный помочь новым начальникам завоевать авторитет и разъяснить подчиненным свои функции. Помимо задач, связанных с подготовкой, оценкой, планированием, измерениями и разъяснениями, одна из главных функций директора по данным – заставить руководство поверить в возможности данных с точки зрения бизнеса.
Стефан Пер, директор по данным журнала The Economist, разъясняет, насколько это важно: «Когда я получил эту работу, у меня не было ни списка задач, ни цели, ни даже описания самой должности. Я был специалистом по продажам из рекламного отдела, много лет продававшим площади под онлайн- и печатную рекламу, а теперь я «продаю» идею перевода бизнеса на цифровую основу. Сегодня для меня данные – это товар, приводной механизм, сервис. И в конечном счете – сам бизнес. К данным нужно относиться не как к новому источнику дохода, а как к средству укрепления вашей нынешней бизнес-модели».
Директор по Интернету вещей
Согласно опросу «Интернет вещей: риск или выгода», который специалисты Webroot и оператора коммерческих ЦОД IO провели среди 500 топ-менеджеров британских компаний, в 54% организаций собираются в ближайший год нанять директора по Интернету вещей. Но нужна ли такая должность на самом деле? И если да, чем именно будет заниматься такой руководитель, под чьим началом он будет работать и какая роль ему будет отводиться в существующей организационной структуре? На сегодня еще непонятно, как именно будет Интернет вещей применяться на практике, хотя масса пользователей профессиональных соцсетей, следуя последней моде, причисляют себя к «проповедникам IoT». Самое заманчивое в Интернете вещей то, что он может применяться в огромном количестве отраслей. Именно поэтому в столь большом числе организаций пытаются понять, как IoT будет работать на практике и какие задачи в связи с этим стоит возложить на директора по IoT. Скорее всего, прямым начальником руководителя на этой должности будет ИТ-директор, но сама деятельность, связанная с Интернетом вещей, должна в меньшей степени иметь отношение к ИТ и в большей – к преобразованию методов ведения бизнеса в компании.
Манфред Кубе, директор Gemalto по безопасности межмашинной связи, подчеркивает, что должность директора по Интернету вещей будет далеко не простой: «Ее введение в компании стоит рассмотреть, если есть желание в полной мере реализовать потенциал Интернета вещей. Важно, чтобы это происходило под руководством конкретного человека, который бы разъяснял всю полноту перспектив Интернета вещей для остальных – от рядовых сотрудников до генерального директора. У директора по Интернету вещей будет масса обязанностей – от координации обновления программного обеспечения для всевозможных устройств и создания надежной защитной инфраструктуры во взаимодействии с директорами по ИТ и безопасности до согласования бюджета с финансовым директором для обеспечения максимальной окупаемости техники».
Директор по интеграции
У ИТ-директора есть уникальная возможность контролировать интеграцию в масштабе всей организации, ведь ИТ используются во всех отделах компаний и госструктур. Один из важных навыков ИТ-директора – согласование требований ключевых заказчиков в разных структурных единицах с сохранением общей направленности преобразований. Фактически ИТ-директора сегодня становятся директорами по интеграции. Они опираются на свое умение превращать неорганизованные ИТ-службы в оружие стратегического назначения. Когда десятки лет тому назад отделы ИТ только появились, они были в определенной степени независимыми и изолированными от остальных. Сегодня ситуация полностью противоположная: ИТ нужны всем, включая заказчиков, партнеров, поставщиков, внутренние подразделения компании и выездных сотрудников. Если ИТ-директор доверяет руководить интеграцией кому-то еще, это нередко приводит к провалам, проявляющимся в неспособности согласовать деятельность отдела ИТ и бизнеса.
Цифровой директор
Цифровых директоров могут считать либо новыми звездами на небосклоне топ-менеджмента, либо очередной «модной» должностью, которая со временем исчезнет (иногда эту точку зрения разделяют и сами цифровые директора). Обязанности цифрового директора широко варьируются в зависимости от отрасли, места в иерархии и от того, достаточные ли полномочия данный руководитель получил для выполнения порученной задачи. Отчасти роль цифрового директора связана с разработкой стратегии и общего замысла, но есть и элементы руководства текущей деятельностью. Еще один круг задач связан с изменением организационной культуры, цель которого – приучить бизнес-руководителей мыслить категориями современных цифровых технологий. Сегодня ИТ-директорам все чаще приходится переквалифицироваться в цифровых директоров, если на предприятии еще нет отдельного руководителя, занимающего соответствующий пост и подчиняющегося самому ИТ-директору или генеральному.
Продолжение следует...
Мы перечислили далеко не все новые роли, которые приходится брать на себя ИТ-директору. Помимо стандартных обязанностей директора по технологиям и информационной безопасности, есть еще работа руководителя по качеству обслуживания, инфраструктуре, разведке и инновациям. Обязанности ИТ-директора становятся все сложнее, иерархия в технологических отделах – все глубже, а их руководителям приходится выполнять титаническую работу по обновлению компании. Если раньше перемены зависели лишь от оборудования или программного обеспечения, то сегодня факторов гораздо больше и ИТ-директору нужно уметь адаптироваться к изменениям, становиться знатоком в области цифрового бизнеса, инноваций, аналитики и многого другого.
– Salaina Haroon. The New CIO: Chief «Information.. urm What» Officer? IDG News Service . February 21, 2017
www.cio.ru
Семь советов будущему ИТ-директору | Вестник цифровой трансформации
Профессионалы в ИТ-сфере должны понимать взаимосвязь технологий, людей и процессов. Ведь сегодня быть ИТ-директором – это уже совершенно иная работа.
1. Сосредоточьтесь на главном и не отвлекайтесь
Инновации, технологии, стимулирование потребительского интереса и облако – все это отвлекающие факторы, основные же принципы ИТ не изменились. Работая сегодня плотником, вы делаете в принципе все то же, что и Ной во времена, когда строил свой ковчег. Инструменты меняются, а основополагающие принципы – нет. От ИТ-директора требуется внедрять работающие решения в интересах бизнеса, а не демонстрировать свое техническое мастерство.
2. Сопротивляйтесь идеальному решению
Необходимо уяснить, что вы никогда не сможете автоматизировать все на 100%, и к этому не надо стремиться, даже если к вам обращаются с такими просьбами.
К примеру, автоматизация процедуры обмена информацией между двумя системами может обойтись в круглую сумму. Но ведь гораздо проще найти сотрудника, который будет осуществлять обмен данными вручную, затрачивая на это полчаса в неделю. Зачем тратить сотни тысяч долларов на автоматизацию, если за сумму в разы меньшую все то же самое будет делать человек? Возможность автоматизировать те или иные функции еще не означает, что ее непременно нужно воплотить в жизнь.
Инновации нельзя рассматривать сами по себе. В какой-то компании замена унаследованной системы и расширение присутствия в Интернете будут инновационными, а в другой компании, располагающей более свежей системой, – нет. Для тех, кто ходит босиком, любая пара обуви станет инновацией.
3. Обеспечьте общее понимание
Сегодня нельзя быть успешным в ИТ, не понимая бизнес-процессов, для автоматизации которых нужны соответствующие ИТ-функции. Но одного только понимания бизнеса еще недостаточно. Будущие ИТ-лидеры зачастую упускают из виду необходимость критической оценки этого понимания.
Независимо от того, идет ли речь о гибкой разработке или о более жестких требованиях, необходимо выработать общее понимание проблем бизнеса и предлагаемых технических решений со своими коллегами из основных подразделений. В истории развития ИТ принятие неверных решений объяснялось чаще всего непониманием проблемы в контексте бизнеса.
4. Не переусердствуйте с управлением
Крупные организации тратят массу времени и других ресурсов на формирование различных комитетов и прочих управленческих структур. Но небольшим организациям такие структуры ни к чему.
Управление имеет важное значение, но иногда (если, например, в компании работают 200 человек) вполне достаточно того, чтобы генеральный директор и ИТ-руководитель пришли к согласию. Управление должно гарантировать проведение высшим руководством общей линии, а стратегия – демонстрировать, каким образом компания собирается извлекать из ИТ максимум выгоды. При организации управления не надо доводить все до абсурда.
5. Доверие – всему голова
Демонстрируя готовность выслушать, понимая проблемы, зная, как их решить, и воплощая выработанную стратегию в жизнь, вы формируете новый уровень доверия. Выстраивая карьеру ИТ-директора, старайтесь добиться доверия и сохранить его во всех аспектах своей деятельности.
ИТ-руководителям имеет смысл спросить себя: кто из окружающих меня сослуживцев мог бы сказать, что доверяет мне? Если вы не можете назвать ни одного имени, возникает вопрос, правильно ли вы себя ведете. Если же вам доверяют лишь несколько человек, нужно работать над расширением этого круга и побуждать доверяющих вам коллег выступать в роли ваших защитников.
6. Пусть ваше видение станет достоянием всей команды
Чтобы достичь результатов, ИТ-директору нужны четкое видение, стратегия и план действий. Этого вполне достаточно для создания успешного продукта, но маловато для самостоятельности и автономности внутри команды. Предложите всем членам команды вносить свои дополнения, поскольку в процессе обсуждения у всей команды формируется четкое видение перспектив, а в процессе разработки и реализации воспитывается чувство командной гордости.
7. Разберитесь в себе
Хорошенько подумайте, действительно ли вы хотите выбрать эту профессию. Часто бывало так, что люди получали ИТ-дипломы, думая, что хотят стать ИТ-директором. На самом же деле они просто увлекались технологиями.
С приходом облаков ИТ стали в большей по сравнению с традиционной разработкой программного обеспечения степени ориентироваться на формирование взаимоотношений, выстраивание команд и выработку стратегии. Нельзя стать программистом, ограничиваясь только приемкой исходных спецификаций и отправкой назад полученных результатов. Профессионалы в ИТ-сфере должны понимать взаимосвязь технологий, людей и процессов. Сегодня быть ИТ-директором – это уже совершенно другая работа.
- Martha Heller. 7 tips for future CIOs. CIO. Aug 17, 2016 — Martha Heller. 7 tips for future CIOs. CIO. Aug 17, 2016
www.cio.ru
