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

Зачем нужен IT-лидер?

Как минимум, это человек, который (просто так, от скуки) сядет и во вторник вечером обновит ОС у себя на десктопе до новой Debian Testing. Кому это вообще надо? Всему отделу. А откуда еще набрать новый стек новых проблем нового релиза ОС в виде опыта? Не на сервера же ее ставить. Как хороший пример, приличная часть бед systemd, которыми страдал Debian первое время после выхода стабильной восьмой версии, были видны еще за полгода до выхода релиза. Просто сразу после обновления ОС и перезагрузки. Эти проблемы полезно узнать, необходимо ими поделится и научиться их побеждать. По другому никак нельзя взять в эксплуатацию ОС, с которой никто не работал ни дня.

Вообще новый релиз ОС - это огромный набор "фич" и багов, только в отличие, например, от релиза php - баги и "фичи" считаются тысячами, а баги и "фичи" нового php входят в этот набор. Хоть это бывает не часто, зато обычно весело - с матом и улюлюканьем по офису в сторону "ааа, криворукие, зависимость на пакет прописали которого в репе нет". Ну да, в Testing это бывает. Выкидывают из него пакеты новых версий так же быстро, как и возвращают. В общем-то, это одна из причин, почему на Testing жить на серверах нельзя совсем.

Вот сижу в 5 часов 07 минут по Москве и пишу этот пост. Почему? Потому что нет сейчас дежурного, недоступен, а задачи есть и нужно их решать кем-то. Естественно, этот кто-то - человек, имеющийся всегда в резерве. А если и резерв недоступен, то сиди, друг мой, сам, а пока на единственном оставшемся в живых сервере с FreeBSD собирается всякое, можно и в блог об этом написать.

Кто-то расценит это как минусы профессии, кто-то как плюсы. Лично мне эти плюсы нравятся, а минусы дают своеобразие.

Нельзя без менеджмента

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

Вообще, о менеджменте в IT можно писать массу всего, о всяких системах управления, вроде scrum или канбан, о подходе к дежурствам, критическом пути и прочем. Да это вообще не имеет никакого значения. Просто у вас есть баланс - 4 задачи остаток с прошлой недели, 51 новая, значит, закрыть нужно минимум 51, чтобы к концу недели не рос технический долг. Технический долг растет с ростом отдела и прохождением времени? Значит, это повод для дежурного в праздники, пока всё тихо, и нет потока заявок что-нибудь из этого долга закрыть.

IT менеджмент не заканчивается только на людях, задачах и ресурсах. Он на этом только начинается. Обычно оптимизировать трудозатраты, автоматизировать работу и тем самым вертикально наращивать имеющийся ресурс, нормальный менеджер не может. Это по плечам только тому, кто и менеджер, и лидер, и самому не влом что-то написать, и кто с этим потом сам же и будет жить. Что-то автоматизировал плохо - вот теперь мучайся сам с этим. Опыт таких ошибок научит раза с третьего понимать, что именно в твоем отделе нужно, а что нет. У меня, например, нет автоматических тестов на внутренние сервисы. Просто потому, что эти сервисы пишут один раз и более "фич" туда не вносят. Несколько недель фикса багов и сервис имеет достаточно функционала и достаточно прямо работающего, чтобы его не трогать. А зачем тогда мне автоматические тесты, если никто старый код не трогает? А вот теперь я почти уверен, что не приходят тестовые смс от мониторинга раз в 2 часа, чтобы просто проверить, что "смс-сервис реально жив".

Это здорово!

Вообще, человеку, работающему в своем деле, нравится всё. Есть свой юмор в конторских чатах, а потом и на bash.im, есть работа и зарплата, есть достижения и успехи, есть много чего своего-личного.

- Здравствуйте, это канал об аниме?

- Да.

- Как мне пропатчить KDE2 под FreeBSD?