Никто не совершенен. Но для тех, кто отвечает за корпоративные технологии, последствия от стратегической оплошности, приема на работу плохих сотрудников или слабой работы основных служб могут быть катастрофическими. Каким образом можно избежать больших ошибок лидеров ИКТ?
Все люди делают ошибки. Большинство из этих ошибок безвредны, некоторые вызывают смущение, но их можно простить, а есть и такие, которые могут стоить вам карьеры или компании. Некоторые из наиболее распространенных проблем в области ИКТ включают в себя попадание в ловушку отношений с поставщиком, от которого нет возможности избавиться, прием на работу или продвижение не тех людей, а также сокрытие проблемы от топ-менеджмента до тех пор, пока не станет слишком поздно что-то исправить.
Когда вы ответственны за корпоративные технологии, то риски гораздо выше, а проблемы от допущенных ошибок намного хуже. Таким образом, можно классифицировать ошибки по уровню их тяжести: уровень 1 (неудобная история, которую вы расскажете за пивом, но, возможно, не сразу); уровень 2 (одну из них можно исправить, но не ожидайте, что вас теперь будут быстро продвигать); уровень 3 (вы уволены).
Ниже приведены самые распространенные ошибки, которые вы, вероятно, допустите, и способы их избежать или быстро исправить.
Ошибка № 1. Ловушка поставщика
Уровень тяжести: 2.
Это форма соблазнения. Продавцы заманивают вас низкими ценами и бесконечными обещаниями. Но как только они достигнут цели, вырваться из их рук уже невозможно. «Почти каждый поставщик продукта пытается внедриться и расшириться внутри вашей среды, – говорит Эндрю Говард, технический директор «Kudelski Security». – Менеджеры изначально имеют благие намерения, но поставщик со временем становится незаменимым и постепенно приобретает значительный контроль над активами компании и огромный ценовой рычаг гораздо раньше, чем менеджеры это осознают. Я видел, как несколько таких менеджеров потеряли работу из-за такого типа неправильного управления».
При этом Э. Говард видит также и преимущества этого типа управления. Помимо скидок по объему, получение нескольких продуктов от одного и того же поставщика должно обеспечить более плавную интеграцию между этими продуктами, а также более надежную защиту (акцент на должно).
Но когда вы решите, что пришло время двигаться дальше, не ожидайте помощи от поставщика. Э. Говард вспоминает то время, когда он работал в консалтинговой фирме. Поставщик управления документооборотом пытался удержать фирму от перехода к другому поставщику, отказавшись передать свой исходный код, что было требованием в первоначальном соглашении о лицензировании программного обеспечения (SLA), однако оно непонятным образом испарилось в последующих переговорах.
Он также добавил, что переход в «облако» не облегчает проблему. «У многих наших партнеров возникают такие же проблемы с поставщиками услуг SAAS, – говорит он. – Как только вы инвестируете в такого поставщика, становится трудным впоследствии перевести эту инфраструктуру на его конкурента». В связи с этим Э. Говард говорит, что знает многих директоров отделов ИКТ, которые страхуют свои риски, сотрудничая с несколькими облачными провайдерами и разрабатывая жесткие методы управления технологиями. Он также добавляет, что менеджерам необходимо более тесно сотрудничать с отделом закупок во избежание сильной зависимости от какого-либо одного поставщика.
«Я верю в диверсификацию технологий, – говорит Эндрю. – И самый дешевый вариант часто играет не в вашу пользу. Иногда кратковременная боль может принести вам пользу в долгосрочной перспективе».
Ошибка № 2. Работа с облаком как-будто это еще один сервер вашего центра обработки данных
Уровень тяжести: 2.
В феврале 2016 года личные кредиты «Best Egg» перенесли из частного облака на основе VMware в общедоступное облако, работающее на «Amazon Web Services». Служба кредитования между физическими лицами потратила месяцы на планирование, настройку и миграцию служб нижнего уровня и осуществила сопоставление 1:1 между его серверами и серверами AWS. Все было готово к работе, однако через два часа после выхода онлайн критический сервер AWS отказал. «Для нас это был первый пробуждающий звонок в первый же день, – говорит Брайан Конниэн, CIO/CTO учредителя «Best Egg» «Marlette Funding». – Оказывается, стабильность одного облачного сервера на самом деле ниже, чем у частного сервера или виртуальной машины. 99,999% времени безотказной работы облака исходит из возможности динамически создавать новые серверы для замены тех, которые потерпели неудачу».
Крушение произошло в выходные дни, и «Best Egg» смог восстановиться без каких-либо простоев для клиента, но Конниэн получил ценный урок: нельзя рассматривать облачный сервер в качестве единственной машины в центре обработки данных. «Вы можете предоставлять сервер всякий раз, когда кому-то захочется, – говорит он. – И это достаточно для того, чтобы вы довольно скоро потратили сумму, в два или три раза превышающую плановую». Конниэн также узнал, что серверы являются одноразовыми: в случае поломки их просто выбрасывают. Таким образом, «Best Egg» построил систему по принципу избыточности, назначив пул серверов для систем, которые не могли позволить себе простоя, и создав сценарии, автоматически запускающие новые серверы во время разрушения старых.
Теперь во время выпуска новой версии программного обеспечения «Best Egg» просто создает новые серверы, «затаскивает» в них код и тормозит старые. «Преимущества открытого облака могут быть реализованы только тогда, когда вы создаете свою инфраструктуру для сильных сторон открытого облака, – говорит он. – Просто переносить свои серверы в облако недостаточно – также необходимо менять свои мышление и подход».
Ошибка № 3. Чрезмерное развитие бизнес-кейса
Уровень тяжести: 1.
Получение разрешения на большие расходы, необходимые для построения прочного бизнес-кейса, долго вбивалось в головы директоров отделов ИКТ, и, похоже, это стало частью коры их головного мозга. Поэтому менеджеры могут проводить недели, исследуя варианты, деля цифры и создавая презентации в PowerPoint. «Но если у вас нет бизнес-лидера, желающего взять на себя риск за ваше предложение, зачастую все напрасно», – говорит Марк Сеттл, CIO «Okta», поставщика IAAS (идентификация как услуга).
«Несколько лет назад я проводил собеседование на должность директора управления ИКТ в компании Fortune 200 и давал мини-лекцию финансовому директору о важности бизнес-кейсов, – говорит он. – Финансовый директор сказал мне, что он не верит ни одной из цифр в бизнес-кейсе и одобряет крупные инициативы в области ИКТ, только когда есть бизнес-лидер, приверженный использованию новых возможностей».
«Необходимые расходы на инфраструктуру или адаптацию – редкие исключения, – добавляет Сеттл. – Но любая стратегическая инициатива в сфере ИКТ требует страстного сторонника со стороны бизнеса. Заработать доверие руководителей означает не только беспрепятственное выполнение вашей работы, но и партнерство с другими группами по всей организации, перенятие и улучшение их существующих процессов. Сделайте это, и тогда бизнес-лидеры станут благосклоннее к выслушиванию ваших идей во время возникновения стратегической возможности, – говорит он. – Если вы приносите много перегруженных бизнес-кейсов без руководителей, которые готовы встать и пожертвовать собой ради вас, вы усложняете ситуацию для самих себя».
Ошибка № 4. Прием на работу людей с уровнем навыков ниже вашего
Уровень тяжести: 2.
Для создания успешного предприятия необходима команда, но наличие хотя бы одного некомпетентного сотрудника с плохим отношением к делу приведет к провалу бизнеса. «Самая большая ошибка менеджеров – это прием на работу людей, которые не умнее и не лучше их самих», – говорит Дерек Джонсон, вице-президент по развитию бизнеса рекрутинговой компании «Stride Search».
К сожалению, эго менеджеров часто не позволяет им выбрать подходящего человека, говорит Джонсон. Пример: три года назад «Stride Search» определил идеального сетевого инженера и разработчика программного обеспечения для одного из своих клиентов – SaaS. Он был красноречивым, харизматичным, имел степень доктора компьютерных наук и владел несколькими патентами. Все любили его – кроме главного технического директора стартапа.
«Телефонное интервью прошло хорошо, но личное интервью стало абсолютной катастрофой, – говорит Джонсон. – Технический директор, являвшийся одним из основателей компании и менеджером по найму, провел все интервью, принижая кандидата и пытаясь возвыситься над ним. Остальная часть управленческой команды хотела расширить предложение по трудовому контракту, но технический директор отказался. Кандидат пошел работать на конкурента, впоследствии подавившего этот стартап. Подобное случается так часто, что это может стать притчей».
«Не прибегая к трансплантации эго, компании могут бороться с этой проблемой, требуя, чтобы один человек не имел права накладывать вето при приеме кандидата на работу, – говорит Джонсон. – При приеме на руководящие должности высшего звена должен быть задействован совет директоров компании и будущие подчиненные кандидата. Известная поговорка «Лучшие работники нанимают лучших работников, средние работники нанимают худших работников» находит свое подтверждение в реальности. Нет ничего более катастрофичного для организации, чем прием на работу неправильного ключевого человека или уход правильного».
Ошибка № 5. Поддержка неправильного внутреннего кандидата
Уровень тяжести: 2.
Если отказ от принятия на работу подходящего внешнего кандидата является ошибкой, такой же ошибкой можно считать продвижение неподходящего внутреннего кандидата. «Вообще, продвижение изнутри – отличная политика, – отмечает Джанкарло Ди Весе, президент «Unosquare» – компании, занимающейся софтом. – Но вам нужно сделать это по объективным причинам. Необъективные причины? Поощрять кого-то, предоставлять карьерный рост в вознаграждение за то, что он или она является верным сотрудником, или чтобы чувствовать себя хорошим менеджером. Это может быть неудачным решением, особенно, если сотрудник действительно не подходит для новой работы».
«Я видел, как менеджеры делают хорошего разработчика технологическим лидером, а затем этот сотрудник расстраивается и уходит с работы, – говорит он. – Вы думаете, что являетесь великим боссом, давая людям возможность подняться, и в конечном счете вы теряете их, потому что вы оторвали их от того, что они действительно любили делать». Ди Весе говорит, что это случилось с ним около года назад. Он нанял классного разработчика для одного из самых больших клиентов «Unosquare» и поставил его на быстрый путь продвижения. Вскоре разработчик управлял командой из пяти человек. Все шло хорошо на протяжении трех месяцев до того дня, когда он вошел в кабинет Ди Веса и попросил об отставке. Несмотря на то, что работа команды была отличной, разработчик почувствовал, что он не справился со своей работой. Убедить его остаться в своей прежней роли было невозможно.
«Я потерял фантастический ресурс программирования, потому что думал, что предоставляю ему динамическое развитие карьеры», – говорит он. С тех пор Ди Весе создал рамки, в которых новообразованные кандидаты могут предоставлять и получать регулярные отзывы, а руководители имеют возможность внимательно следить за тем, как преуспевают кандидаты, с целью помочь им добиться успеха. И хотя Ди Весе все еще чувствует, что продвижение изнутри является хорошей философией, он говорит, что это не всегда верное решение – менеджерам необходимо разумно подходить к подбору новых сотрудников.
Ошибка № 6. Применение гибкой методологии
Уровень тяжести: 3.
Со взлетом облачных сервисов и растущими требованиями к скорости бизнеса директора отделов ИКТ понимают, что большая часть информационных технологий организации находится вне их контроля. «Те же гибкие механизмы доставки, позволяющие компаниям разворачивать контейнеры Docker и микроуслуги в облаке, могут иметь катастрофическое влияние на основные системы, находящиеся в зоне ответственности директора. Например: электронная почта, телефонные службы, ERP и бэк-офисные приложения», – говорит Говард из «Kudelski».
«По причине неумения поддерживать нормальную работу электронной почты было уволено больше директоров отделов ИКТ, чем по каким-либо другим причинам, – говорит он. – Гибкие методы часто противоречат строгому контролю за изменениями, необходимому для основных систем. Если системы рухнут, предприятия могут быстро потерять деньги. Чтобы смягчить эту проблему, директора должны иметь четкие границы, позволяющие проводить гибкие изменения в бизнес-системах и обеспечивающие более строгий контроль за изменениями. Одно решение не подходит для всех систем подряд».
«У вас не должно быть вещей, которые, имея гибкие механизмы доставки, угрожают вашим основным службам, – говорит он. – Проблема заключается в том, что определение правил и обеспечение их соблюдения не всегда легко. Бизнес требует скорости, но безопасность требует постепенных, методических изменений. Эти два аспекта противоречат друг другу, и часто менеджер отдела ИКТ оказывается посередине».
Ошибка № 7. Слишком часто говорить «да»
Уровень тяжести: 2.
«Топ-менеджеров сферы ИКТ часто обвиняют в том, что они говорят «нет» инновациям. Но еще большая проблема заключается в неумении отказывать людям, что в результате может привести к риску потери контроля над безопасностью своих систем, – говорит Ричард Хендерсон, глобальный стратег по безопасности сферы ИКТ в фирме «Absolute». – Сколько раз специалисты отдела ИКТ или службы безопасности получали звонок от какого-либо высокопоставленного лица, требующего доступ к закрытым данным? Как часто бизнес-подразделения внутри организации выходят из-под контроля и развертывают блестящий новый облачный инструмент или услугу без надлежащей проверки или утверждения со стороны специалистов отдела ИКТ или служб безопасности?»
Хендерсон признает, что трудно отказать генеральному директору, когда он делает особый запрос. Но у вас должен быть план, позволяющий справляться с редкими исключениями. Здесь важна прочная схема управления активами, а также программное обеспечение, которое отслеживает конечные устройства и предупреждает вас, когда пользователи входят в общие облачные сервисы. Употребление слова «да» слишком часто делает невозможным сохранение всего в исправности и надлежащем виде, особенно, если вы не осведомлены о том, что кто-то в маркетинге раскручивает новый экземпляр AWS.
«Главное здесь – не помешать людям использовать эти вещи, что, в свою очередь, означает соответствие минимальным требованиям защиты команд, решивших использовать данные службы, – говорит Хендерсон. – Директора управлений ИКТ должны сказать: «Послушайте, если вы захотите это сделать, мы вам поможем, но вы должны учитывать базовый уровень безопасности».
Ошибка № 8. Сокрытие проблем
Уровень тяжести: 3.
«Во время развала большого проекта многие менеджеры пытаются скрыть проблему в надежде исправить ее до момента, когда начальство узнает о ней, – говорит Сетл из «Okta». – Но затем ситуация обычно только ухудшается. В тот момент, когда они все же признают, что новый выпуск кода привел всю систему в негодность на 48 часов или что им нужно еще 4 миллиона долларов для завершения проекта, то они теряют доверие». «Чем раньше вы доложите о плохих новостях – тем лучше, – говорит он. – Потому что плохая новость никогда не улучшается сама по себе. И чем раньше люди начнут с этим работать, тем более вероятно, что вы сможете восстановить проект и вернуться в нужное русло».
Делиться плохими новостями всегда нелегко, но все пройдет намного более гладко, если вы поддерживаете хорошие рабочие отношения с бизнес-лидерами. Менеджеры должны создавать возможности для общения с финансовым директором и другими бизнес-лидерами в то время, когда они еще не находятся в кризисном режиме. Сетл говорит, что это не всегда легко для технарей, но это навыки, которые им нужно развивать.
«Даже если это небольшая безобидная болтовня и беседа с руководителем о возникающих вопросах, с которыми они сталкиваются, все это облегчает проведение более сложного разговора, когда все идет не так, как хотелось бы, и вам необходимо дополнительное финансирование».
