Форум OlegON > Разговоры на отвлеченные темы > Беседка

Рекомендации для ИТ-директора : Беседка

21.11.2024 22:11


11.01.2024 19:32
Не лелею себя надеждой, что все топы прямо побегут выполнять эти рекомендации, однако, кому-то и из сотрудников это может пригодиться в споре с руководством в качестве третьей стороны. Если кто-то не знает, я в шкуре директора уже побыл и повторять не стремлюсь, но опыт в ИТ уже достаточно многолетний, чтобы я мог им поделиться и предостеречь от ошибок, результат которых я уже успел увидеть на своем веку. К сожалению, крайне мало сейчас коллективов, где начальник понимает, для чего он в принципе нужен и большинство руководителей относится к подчиненным с аксиомой, что "чтобы корова меньше ела и давала больше молока, то ее нужно меньше кормить и больше доить", с соответствующим результатом на выходе при нулевой мотивации сотрудников.

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

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

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

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

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

5. Если программист написал кривой софт, то инцидент решается переписыванием софта, а не выдергиванием администратора каждый раз, когда софт падает.

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

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

8. Дежурство с оговоренным временем доступа к компу - это рабочее время (переработки), которое оплачивается полностью, а не только реальным временем нажимания на кнопки. Любое дополнительное ограничение сотрудника или его труд должны оплачиваться. Если в выходной день сотрудник должен отвечать на звонки - оплачивается все время, когда он что-то должен, а не количество времени, потраченное на звонок.

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

10. Обязательно существует полная, подробная карта сервисов с указанием их взаимосвязей, актуальными версиями софта, железа и адресами.

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

12. Инициатива внедрения новых сервисов или продуктов должна подтверждаться обязательным закреплением поддержки этого сервиса за конкретной должностью, а не сотрудником. Иными словами, если есть Вася, который занимается 1С и вдруг согласился внедрить вам Oracle BI или Kafka для совершенно стороннего сервиса, то первый вопрос, который вы задаете самому себе - какая должность из имеющихся в штате соответствует поддержке Kafka с учетом того, что на этой должности должно быть несколько сотрудников на случай их болезни или увольнения. Второй вопрос - кто будет поддерживать этот софт со стороны производителя и на каких условиях. Наличие самого Васи в данном случае не играет никакой роли. Я видел много случаев, когда внедряли сервис, а потом судорожно искали на кого бы его спихнуть, поскольку Вася собрал что-то, имея недостаточно квалификации, а то и поставил лимитированный по возможностям вариант, возможности кончились, Вася давно уволился, никто не понимает, как это работает, а на "временном" костыле уже завязана куча ключевых сервисов. Хотя на момент внедрения казалось, что идея шикарная.

13. Старайтесь не плодить зоопарк, расширяя его только в случае самой крайней и лютой необходимости. Если железо - одного вендора и с одинаковыми прошивками, если Windows - одинаковых версий и патчей, если Linux - один дистрибутив одной версии и т.п. В противном случае вы рискуете в один прекрасный момент получить сразу несколько разнообразных проблем при ограниченном штате сотрудников, вместо, например, одной.

14. Первое, с чего можно начать с момента вступления в должность, если вы пришли снаружи - внушить самому себе и сотрудникам, что ближайшие полгода никаких кардинальных изменений не будет, необходимо понять фронт работ и взаимоотношения между сотрудниками/отделами. Второе - оценить состояние парка, перечень переданных материальных ценностей и ответственных за них. Третье - регламент резервных копий и список ответственных за них. Вишенкой - схема, указанная в п. 10 и перечень текущих проблем, которые решаются давно или не решались до сих пор, но являются болезненными темами других отделов.
29.01.2024 13:36
15. Когда вводится в эксплуатацию новая система или новый сервис - обязательно согласовывайте квоту на дисковое пространство сразу. В противном случае первоначальные "хотелки" в скромных требованиях плавно перерастают в стремительный рост обеспечиваемых бюджетом затрат на обслуживание существующих систем, которые пополняются дисками просто на основании того, что место кончается, а систему не списали, даже если она тестовая. При большом количестве систем это ведет просто к лавинообразному росту затрат, которые невозможно конкретизировать.
Часовой пояс GMT +3, время: 22:11.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.