Respondeat superior
Я написал довольно много постов о тактических ошибках в управлении проектами. Давайте поговорим об ошибках стратегических, которые совершаются на уровне выше. Или даже на паре уровней выше.
Ошибка № 1: зависимость от поставщика
👾 👾
Без поставщиков вести бизнес невозможно. Требуются железки и софт. Недостатка в поставщиках обычно нет, они сами стучатся в личку, вовлекают низкими ценами, программами лояльности и проч. Проблемы начинаются, когда выясняется, что поставщик стал незаменим. У него появляются рычаги для ценового влияния на вас, вам проще оплачивать возросшие счета, чем от него отказаться.
В принципе, для небольшой организации это ок. Когда вас обеспечивает единый поставщик, проще обеспечить интеграцию между компонентами и обеспечить безопасность.
Однако бизнес либо развивается, либо стагнирует. Решите идти дальше, брать новые высоты — поставщик не поможет. А скорее всего, будет ещё и сопротивляться попыткам поменять его решение на более масштабируемое. Например, может отказаться предоставлять документацию по миграции.
Надо диверсифицировать железки и софт везде, где это возможно, как диверсифицируете ценные бумаги в портфеле.
Ошибка № 2: относиться к облаку так, будто оно является продолжением вашего центра обработки данных
👾 👾
Удобство облачных сервисов привело к том, что всё больше айти-директоров переносят туда вообще, все свои сервисы. Но нужно очень чётко понимать, что облако — не продолжение вашего ЦОДа.
Инфраструктура облачного провайдера может лечь. Может лечь канал до неё и вы останетесь без сервисов, ваша компания не сможет работать.
И здесь приходит на помощь диверсификация. Лучше иметь несколько облачных провайдеров и дублировать сервисы для надёжности.
Ошибка № 3: чрезмерная разработка бизнес-кейса
👾
Помните мою статью про бизнес-кейс? Тема очень важная, многим айти-директорам так долго внушали, что экономическое обоснование необходимо, что они стали тратить недели на изучение вариантов, расчётов и вылизывание презентаций.
Расходы на инфраструктуру или соблюдение требований закона — исключения, на них деньги будут всегда. В остальном, стратегические айти-инициативы требуют очень серьёзного сторонника со стороны руководства бизнеса.
Получить такого сторонника можно только постоянным соблюдением данных обязательств. На этом и стоит сосредоточиться.
Ошибка № 4: нанимать сотрудников с несоответствующим уровнем квалификации
👾 👾
У вас может быть прекрасная команда, которую будет портить и дизморалить один токсичный сотрудник. Да, он может быть грамотным инженером, хорошо знать вашу линейку продуктов и при этом оскорблять коллег и третировать смежников. Я натурально работал с таким сотрудником, айти-директор запрещал мне его уволить. Сотрудник генерировал великое количество проблем и чтобы от него избавиться, пришлось приложить очень много усилий.
Айти-директор должен без колебаний увольнять неподходящих людей.
Ошибка № 5: продвижение неправильного внутреннего кандидата
👾 👾
Продвигать на руководящие должности внутренних кандидатов хорошо и правильно, экономится время на онбординг, да и повышение зарплаты, как правило, сильно меньше, чем если брать человека снаружи.
Основная ошибка обычно в эффекте ореола. Вы считаете, что раз он хорошо пишет код и строит коллег на предмет стандартов, станет хорошим тимлидом. Нет, не станет, для управления нужны другие навыки. А хорошего разраба вы в итоге потеряете. Выращивание руководителей — отдельная дисциплина.
Ошибка № 6: применение agile-методологии к основным системам
👾 👾 👾
Аджайл — штука хорошая. Особенно асинхронный аджайл. Но не везде. Для базовых, фундаментальных вещей лучше применять фиксированный подход, иначе вы рискуете выпустить их из-под контроля.
Гибкие механизмы позволяют создавать докеровские контейнеры и микросервисы в облаках. Но подход будет иметь катастрофические последствия для основных айти-системы, таких как электронная почта, телефония, базовый ERP, кадровый и бухгалтерский софт.
Понимаете, если генеральный директор вдруг однажды с утра не сможет отправить электронное письмо партнёрам, у него возникнут к вашей компетентности большие вопросы и он не будет слушать ваши отговорки про инкременты и короткие циклы обратной связи.
Нужна приоритизация сервисов и разный подход к их поддержке и развитию.
Ошибка № 7: слишком часто говорить «да»
👾 👾
На самом деле, здесь две крайности. Постоянно отмахиваться от инноваций, топя компанию в ретроградстве, но соглашаться со всеми ещё хуже, это грозит потерей контроля над безопасностью своих систем.
Допустим, вам звонит кто-то из руководства компании, просит доступ к критичной штуковине, вы соглашаетесь, он её обрушивает. Виноваты, конечно, вы.
Или какое-то из дочерних подразделений внедряет супермодный облачный инстурмент без проверки безопасности и вы получаете утечку.
В общем, надо периодически пользоваться правом отказа.
Ошибка № 8: сокрытие проблем
👾 👾 👾
— Там взорвался бак с гелием. В целом, всё нормально, но в помещениях реактора 3,6 рентген. Ничего хорошего, но и не ужасно.
«Чернобыль», HBO.
Наверное, худшее, что может сделать айти-директор — скрыть проблему.
Да, когда на крупном проекте начинаются проблемы, а они будут обязательно, многие айти-менеджеры пытаются о проблеме не сообщать, надеясь её пофиксить до того, как до высшего руководства дойдёт инфа.
Проблемы нарастают как снежный ком, пока не доходят до того, что нужно идти к руководству с новостью, что наша система не работает уже двое суток и для её восстановления нужно несколько десятков миллионов. После такого доклада вам, скорее всего, доверять перестанут.
Поддерживайте хорошие отношения с руководством и сообщайте о проблемах сразу, не вдаваясь в технические детали.
Заключение
Я отметил жучками критичность каждой ошибки. Но крайне желательно избегать их все.
Добавить комментарий