Конечно, никто не идеален. Все совершают ошибки. Большинство из них безобидны, некоторые неудобны, но простительны, а некоторые могут погубить вашу карьеру — или вашу компанию — вместе с ними.
В этой статье мы продолжим рассматривать поистине неисчерпаемую тему ошибок, которые могут совершить те или иные специалисты. Вот только сегодня мы будем говорить о тех важных, стратегических ошибках, которые могут совершить руководители ИТ.
Когда вы отвечаете за корпоративные технологии, риски гораздо выше, а последствия ошибок могут быть гораздо серьезнее. Поэтому мы не просто приведем примеры и скажем, что так делать не надо, а проранжируем эти ошибки по степени серьезности.
Уровень 1 (неловкая история, которую вы бы рассказали за кружкой пива, но, возможно, не сразу);
Уровень 2 (от которой вы можете оправиться, но не ждите быстрого продвижения по службе);
Уровень 3 (вас расстреливают увольняют).
А теперь давайте рассмотрим самые большие ошибки, которые вы можете совершить, и как их избежать или быстро исправить.
Ошибка № 1: зависимость от поставщика
Уровень серьезности: 2
Как это обычно бывает: поставщики заманивают вас низкими ценами и бесконечными обещаниями. Но как только вы попадаете в их руки, они уже не отпускают вас. Сначала все вроде идет хорошо, сотрудничество устраивает обе стороны, но вскоре оказывается, что поставщик не заменим и имеет значительный контроль над ИТ‑активами и огромные ценовые рычаги. Проще говоря, он может диктовать свои цены на поставляемые товары и услуги, и вам крайне сложно от него уйти.
Да, порой в этом есть свои преимущества. Помимо скидок за объем, приобретение нескольких продуктов от одного и того же поставщика должно обеспечить более тесную интеграцию между ними, а также более надежную безопасность. А это значит, что вам придется иметь дело с меньшим количеством поставщиков. Это может быть идеальным вариантом для небольших организаций.
Но когда вы решите, что пришло время двигаться дальше, не ждите, что поставщик поможет вам. Если вы поймете, что решения, предлагаемые поставщиком, вас не устраивают, не рассчитывайте, что он будет охотно предлагать вам что‑то другое. Скорее всего, он начнет всячески сопротивляться замене его решения на другое.
Так, он может отказаться предоставить вам необходимую документацию для миграции данных на другое решение или не предоставить другую необходимую информацию.
Кроме того, если мы вложили значительные средства в одно решение, то потом нам будет крайне сложно обосновать выделение средств для перехода на другое.
Везде, где это возможно, необходимо диверсифицировать технологии.
Например, при использовании облачных решений, для того, чтобы не оказаться в подобной ситуации многие ИТ‑директора, сотрудничают с несколькими поставщиками облачных услуг и разрабатывая эффективные методы управления технологиями. Также, ИТ‑руководителям необходимо более тесно сотрудничать с отделом закупок, чтобы избежать чрезмерной зависимости от какого‑либо одного поставщика.
Ошибка № 2: относиться к облаку так, будто оно является продолжением вашего центра обработки данных
Степень серьезности: 2
Популярность и удобство использования облачных услуг привели к тому, что очень многие организации перенесли все свои сервисы в облака. Но здесь также не стоит забывать о том, что облако это не продолжение вашего ЦОДа.
При всех SLA и прочих обещаниях облачного провайдера и провайдера каналов связи не стоит забывать, что у них своя инфраструктура и она тоже может лечь. Может упасть оборудование в облаке, могут упасть каналы, ведущие к облаку. Так или иначе мы рискуем лишиться доступа к нашей инфраструктуре. И здесь не особо важно, что послужило причиной этого сбоя, важно то, что наша компания не может работать без доступа к своим сервисам.
Для того, чтобы не попасться в эту ловушку, опять‑таки нужно взаимодействовать с несколькими поставщиками облачных услуг, дублировать свои системы в разных облаках и использовать резервные каналы связи.
Ошибка № 3: чрезмерная разработка бизнес-кейса
Степень тяжести: 1
ИТ‑директорам так долго вдалбливали в голову, что это стало частью коры головного мозга: чтобы получить одобрение на крупные расходы на ИТ, необходимо составить убедительное экономическое обоснование. Поэтому менеджеры могут тратить недели на изучение вариантов, подсчеты и подготовку презентации в PowerPoint.
Но если у вас нет бизнес‑лидера, готового реализовать ваше предложение, все это часто оказывается напрасным.
Необходимые расходы на инфраструктуру или соблюдение нормативных требований — редкие исключения. Но любая стратегическая ИТ‑инициатива требует горячего сторонника со стороны бизнеса. Завоевать доверие руководителей означает не только бесперебойно выполнять свою работу в сфере ИТ, но и сотрудничать с другими командами в организации, перенимая их существующие процессы и улучшая их. Если вы сделаете это, то руководители компаний с гораздо большей вероятностью прислушаются к вашим идеям, когда возникнет стратегическая возможность.
Ошибка № 4: нанимать сотрудников с несоответствующим уровнем квалификации
Степень тяжести: 2
Чтобы построить успешное предприятие, нужна команда, но достаточно одного некомпетентного сотрудника с плохим отношением, чтобы развалить все и вся. Иногда, таким сотрудником является сам руководитель.
Здесь приведем небольшой пример: несколько лет назад кадровое агентство подобрало идеального инженера по сетевым технологиям и программному обеспечению для одного из своих клиентов, SaaS‑стартапа. Он был красноречив, харизматичен, имел докторскую степень по информатике и владел несколькими патентами. Он нравился всем — кроме технического директора стартапа.
По свидетельству кадровиков телефонное интервью прошло хорошо, но очное собеседование было абсолютной катастрофой. Технический директор стартапа, который был одновременно соучредителем и менеджером по найму (типичный руководитель‑оркестр), провел все собеседование, оскорбляя кандидата и пытаясь превзойти его. Остальные руководители компании хотели сделать предложение, но технический директор отказался. В итоге кандидат перешел на работу к конкуренту, который впоследствии развалил этот SaaS стартап. Типичный пример из серии — я начальник, ты дурак.
Здесь проблема в тех тараканах, которые зачастую живут в головах у руководителей и мешают развиваться всей компании.
Ошибка № 5: продвижение неправильного внутреннего кандидата
Степень тяжести: 2
Если неспособность нанять правильного внешнего сотрудника является ошибкой, то и продвижение неправильного внутреннего кандидата это тоже ошибка.
Вообще говоря, продвижение изнутри — это отличная политика, это поощрение человека за лояльность, обеспечение карьерного роста или возможность почувствовать себя хорошим руководителем. Но это также может обернуться против вас, особенно если сотрудник на самом деле не подходит для новой работы.
Типичная история, когда хороший разработчик становится не самым лучшим руководителем и в итоге его увольняют или он сам уходит. В результате компания теряет и хорошего разработчика, (так как уходить обратно из руководителей в разработчики вряд ли кто‑то захочет) и руководителя.
Ошибка № 6: применение agile-методологии к основным системам
Степень тяжести: 3
Все любят Agile. Ну по крайней мере все пытаются использовать данную методологию, не всегда к месту. В условиях бурного развития облачных сервисов и растущих требований к скорости бизнеса ИТ‑директора понимают, что многое в ИТ их организации выходит из‑под их контроля.
Но те же самые гибкие механизмы доставки, которые позволяют компаниям создавать контейнеры Docker и микросервисы в облаке, могут иметь катастрофические последствия для основных ИТ‑систем, за которые отвечает ИТ‑директор, таких как электронная почта, телефонные службы, ERP и бэк‑офисные приложения.
Многие ИТ‑директора лишились работы из‑за того, что они не могли поддерживать электронную почту. Гибкие методологии часто идут вразрез с жестким и строгим контролем изменений, который необходим для основных систем. Если они выходят из строя, компании могут быстро потерять деньги.
Чтобы смягчить эту проблему, ИТ‑директорам необходимо провести четкие границы, позволяющие оперативно вносить изменения в бизнес‑системы и обеспечивающие более строгий контроль изменений в основных системах. Нельзя использовать одну методологию для всего.
Нельзя допустить, чтобы те вещи, которые затрагиваются механизмами гибкой доставки, подвергали риску ваши основные сервисы. Основная проблема в том, что провести и обеспечить соблюдение этих границ не всегда просто. Бизнес требует скорости, но благоразумие требует медленных, методичных изменений. Эти две вещи противоречат друг другу, и часто ИТ‑менеджер оказывается посередине.
Ошибка № 7: слишком часто говорить «да»
Степень тяжести: 2
Топ‑менеджеров ИТ часто обвиняют в том, что они говорят «нет» инновациям. Но еще большая проблема — когда они не знают, как отказать людям, и рискуют потерять контроль над безопасностью своих систем.
Сколько раз ИТ‑специалисты или сотрудники службы безопасности получали звонок от человека, занимающего высокий пост и требующего доступа к чему‑то рискованному?
Как часто бизнес‑подразделения внутри организации уходят в отрыв и внедряют новые блестящие облачные инструменты или сервисы без надлежащей проверки или одобрения со стороны ИТ‑отдела или службы безопасности?
Да, такие инструменты, как облачные хранилища и SaaS‑решения, могут дать командам огромные преимущества. Но когда ИТ‑менеджеры одобряют каждый запрос на исключение, они создают новые дыры и слепые зоны в своей организации — и, возможно, новые уязвимости.
Слишком частое согласие делает невозможным поддержание всех исправлений и соответствия требованиям, особенно если вы не в курсе, когда кто‑то из отдела маркетинга запускает новый экземпляр AWS.
Ошибка № 8: сокрытие проблем
Серьезность: 3
И в завершении нашего рейтинга стратегических косяков рассмотрим, пожалуй, наиболее распространенный — сокрытие проблем.
Когда крупный проект начинает идти наперекосяк, многие ИТ‑менеджеры пытаются замять проблему, надеясь исправить ее до того, как начальство заметит. Как правило, дальше все идет по накатанной. К тому времени, когда они наконец признаются, что новый релиз кода вывел из строя всю систему на 48 часов или что им нужно еще 4 миллиона долларов для завершения проекта, они уже потеряли доверие.
Важно понимать, что чем раньше вы сообщите плохие новости, тем лучше, потому что плохие новости никогда не становятся лучше сами по себе. И чем раньше люди начнут с этим разбираться, тем больше вероятность того, что вы сможете восстановить проект и вернуться на прежний уровень.
Сообщать плохие новости всегда непросто, но это пройдет гораздо легче, если вы установили и поддерживаете хорошие рабочие отношения с руководством компании.
Заключение
Мы рассмотрели восемь основных ошибок, которые могут допустить ИТ директора. Некоторые из этих ошибок не столь критичны, хотя другие вполне могут привести к серьезным последствиям как для самого руководителя, так и для всей компании в целом.
Большинство из этих ошибок можно избежать или хотя бы минимизировать их последствия, поэтому важно своевременно принимать необходимые меры для решения описанных проблем.
Если вы работаете в сфере управления IT‑компанией или технологическими проектами, предлагаем рассмотреть курс «Стратегическое управление IT‑компанией». В рамках курса разбираются практические аспекты принятия управленческих решений, включая анализ типичных ошибок и методы их минимизации.
Чтобы узнать больше обо всех доступных курсах, включая программу, формат обучения и направления, заходите в каталог курсов.
Если вам интересно принять участие в открытых онлайн-уроках, актуальные даты и темы предстоящих открытых уроков доступны в календаре мероприятий.