– Служба технической поддержки магазинов
На следующем шаге на уровне холдинга произошла централизация ряда функций (всего что касается телекоммуникаций и обслуживания компьютерной техники общего назначения). В торговой сети отреагировали и появился Департамент управления изменениями технологий и процессов, состоящий из:
– Управления поддержки системных изменений
– Управления развития универсальных программных решений
– Управления развития платформенных решений
– Управления автоматизации торговых объектов
Как видим, структура подвергалась достаточно существенным изменениям. Безусловно, это определенный стресс и затраты, но в нашем понимании подобные изменения соответствовали текущим требованиям и окупались за счет более эффективной организации деятельности.
Я знаю один банк, в котором на одном из этапов его развития изменения среди ИТ-подразделений производились раз в год. Три департамента, четыре департамента, опять три департамента, пять департаментов. Чем там сейчас сердце успокоилось сказать сложно.
Не нужно бояться изменений в структуре, но и не стоит ими злоупотреблять.
Стоит остановиться еще на паре моментов.
При внутренней разработке всегда наблюдается недостаток ресурсов программистов. О причинах и вариантах преодоления такого рода голода мы поговорим в отдельной главе. Сейчас же немного о другом.
Нехватка программистов и очередь на выполнение заявок рано или поздно приводят к росту сепаратистских настроений у руководителей функциональных подразделений в компании. Т.е. каждый руководитель начинает мечтать о своем собственном программисте, с которым он мечтает работать напрямую, а еще лучше о группе программистов.
Мой опыт говорит, что если пойти на поводу у подобных настроений, то ничем хорошим это не закончится.
Сложно объяснить, что, как правило, программист не работает в отрыве. Есть разные специализации. Над продуктом работает коллектив. Есть специалисты по структурам, есть по базам данных, есть по интерфейсам, есть тестировщики, админы и пр. Конечно бывают случаи, когда можно очертить достаточно конкретный круг специалистов, действующих сугубо в интересах одного подразделения (например, если разрабатывается WMS – система управления складом), и тогда, такой коллектив, можно отдать непосредственно в логистику, но это скорее исключение. Как правило, все подразделения завязаны на одну систему или группу систем и управлять развитием в таком варианте можно только централизованно.
Кучкующиеся программисты имеют свойство обогащать друг друга, а вырванные из своей среды они хиреют и деградируют. Если вы, как руководитель функционального подразделения заведете собственного программиста, то не удивляйтесь, что он или испортится, либо как-то незаметно размножится, обрастет соратниками и денег компания будет тратить существенно больше..
И управлять ИТ-шниками не так просто, как кажется. Поверьте, оставьте программистов в ИТ-департаменте, а у себя лучше заведите того, кто будет с ними эффективно коммуницировать: вырастите хорошего ключевого пользователя, постановщика задач, внедренца.
Стоит отметить, что периодически можно встретить и обратную ситуацию. Когда ИТ-подразделения требуют иметь у себя допустим своего рекрутера/специалиста по кадрам или специалиста по учету. На мой взгляд это также неправильно. Вот кого полезно иметь – так это выделенного офис-менеджера, потому как качественная организация быта и решение административных вопросов – это большой плюс, который ИТ-шники ценят.
И в заключении данной главы несколько слов об аутсорсинге. Он может достаточно сильно влиять на структуру.
Я не люблю аутсорсинг. Аутсорсинг – это удел ленивых управленцев, которые готовы переложить работу с людьми на кого-нибудь другого. При этом именно работа с людьми – это одно из основных направлений в деятельности менеджера.
Не бывает дешевого хорошего аутсорсинга. Но бывает выгодный хороший аутсорсинг. Где и когда он оправдан?
Он точно оправдан, когда специалист с какой-то очень специфической компетенцией нужен на ограниченное время. Как правило, такой специалист является реально дорогим, загрузить его постоянной работой на все 100% мы не можем, а факультативно заниматься еще какой-то менее дорогой работой он не хочет, что и правильно.
Близкий по смыслу вариант, когда какую-то работу мы выполняем раз в полгода, год и держать специалиста все остальное время – это просто пустая трата денег.
И еще один хороший вариант привлечения аутсорсинга – как демпфер нагрузки. Аутсорсер хорош тем, что как сегодня легко привлек, так легко и расстался. Правда тут есть и другая сторона. Так же легко такие аутсорсеры косячат и даже хорошие программеры (не путать с программистами) среди них встречаются не часто, а встретить там разраба – это практически нереально.