Восемь серьезнейших ошибок ИТ-управления

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

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

Для тех, кто отвечает за технологии предприятия, риски выше, и последствия ошибок могут быть печальными. Здесь мы классифицируем просчеты по степени серьезности: уровень 1 – постыдная история, которую можно будет рассказать за пивком, но позже; уровень 2 – поправимая ошибка, после которой, однако, не стоит рассчитывать на скорое продвижение по службе; уровень 3 – катастрофическая ошибка, и вас увольняют.

1. Привязка к поставщику

Это сродни соблазнению: поставщики заманивают вас низкими ценами и бесчисленными посулами, но, поймав вас в свои сети, уже не отпускают.

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

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

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

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

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

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

2. Отношение к облаку как к продолжению вашего центра обработки данных

В начале 2016 года оператор сервиса взаимного кредитования Best Egg Personal Loans перешел из частного облака на основе VMware в публичное облако Amazon Web Services. При этом были потрачены месяцы на планирование, настройку и перенос низкоуровневых сервисов, чтобы полностью воспроизвести локальную инфраструктуру в AWS. Наконец все было готово к работе, но через два часа после запуска один из ключевых серверов AWS дал сбой.

Best Egg, можно сказать, повезло, что сбой произошел в первый же день: выяснилось, что стабильность индивидуальных облачных серверов в реальности ниже, чем у размещаемых локально, – коэффициент работоспособности 99,999% в облаке достигается посредством динамического ввода в эксплуатацию новых серверов взамен отказавших.

Авария случилась в выходной, и Best Egg удалось восстановиться без прерывания клиентского обслуживания, но в компании усвоили важный урок – нельзя относиться к облачным серверам так, как будто это системы в вашем собственном ЦОДе.

После произошедшего в Best Egg вплотную занялись оптимизацией систем для облачной среды. А второй по важности задачей стало пристальное контролирование затрат на обслуживание. «Нельзя выделять новый сервер по первому требованию, – подчеркивают в компании. – Если попустительствовать, то очень скоро вам придется тратить вдвое-втрое больше, чем планировалось».

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

Теперь, когда Best Egg выпускает новую версию ПО, в компании просто вводят в действие новые серверы, рассылают на них код, а старые останавливают.

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

3. Излишне усердное составление финансовых обоснований

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

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

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

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

4. Наем специалистов с меньшим профессиональным уровнем, чем у вас

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

Увы, самомнение начальников нередко мешает им выбирать подходящих кандидатов. Например, в рекрутерской компании Stride Search несколько лет назад нашли идеального инженера по сетям и программному обеспечению для клиента – стартапа в области SaaS. Претендент имел кандидатскую степень в области компьютерной науки и несколько патентов. Он понравился всем, кроме директора по технологиям компании-заказчика.

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

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

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

5. Продвижение по службе неподходящего внутреннего кандидата

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

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

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

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

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

В Unisquare продолжают верить в то, что внутреннее продвижение – хорошая практика, но подходить к отбору кандидатов нужно более тщательно.

6. Применение методологии agile К основным системам

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

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

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

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

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

7. Слишком часто произносимое «да»

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

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

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

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

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

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

8. Сокрытие проблем

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

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

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

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

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

– Dan Tynan. The 8 biggest IT management mistakes. CIO. December 11, 2017