ИТ-Стайер

Высшей квалификационной ступенькой для программиста в моей классификации является “разраб”. Это уникальные люди, которые в той области, которую они автоматизировали знают все лучше всех. Они работают с вопросом “зачем?”. Ни один “представитель бизнеса” с ними сравниться не может. И не мудрено. Когда ты переводишь бизнес в цифру, и делаешь это вдумчиво, ты проникаешь в тайны мастерства недоступные никому. Разраб знает “как работает склад” лучше любого руководителя склада. Ему вообще можно не ставить задачи. Ему достаточно подкинуть идею, а зачастую он сам приходит с идеей, и уже реализованной. Их не нужно мотивировать (про мотивацию мы еще поговорим), они знают и любят свое дело. Это золотой фонд любой компании. Если у вас есть разрабы – вам просто повезло.

Есть такой нюанс, что программисты не только программируют на нечеловеческом языке, но и часто разговаривают не по человечески.

Очень полезно, когда в компании есть специалисты, которые переводят с человеческого языка на язык программистов и обратно. Не у всех эта функция выделена и отнесена к ИТ, но мой опыт говорит, что как только компания может себе позволить содержать такого отдельно выделенного человека – это стоит делать. Системный аналитик, бизнес аналитик – называть можно по разному, но тот кто может причесать техническое задание – это те без кого разработка будет хромой (помним, что разрабы редкость).

В ИТ есть еще ряд специализаций. Но в корпоративной среде они встречаются не всегда. Тестировщики, технические писатели, архитекторы систем – их функциональность может фоном накладываться на деятельность других специалистов.

Я все это к чему? ИТ – это очень неоднородная среда. В ней могут работать люди с самыми различными психотипами и наклонностями. Многие ИТ-шники вообще не умеют программировать, а некоторые совершенно не разбираются в типах компьютерной памяти и даже не смогут настроить домашний WiFi роутер.

В ИТ место найти можно всем.

Глава 4

Как становятся ИТ-шниками?

В ИТ люди приходят самыми разными путями. Здесь можно встретить людей как с несколькими высшими образованиями, так и тех, кто закончил 9 классов и на этом решил с учебой завязать.

Реальный случай, когда человек с 9 классами за плечами претендовал на то, чтобы вести за собой все направление бизнес-аналитики. Прикол в том, что на “местном фоне” он еще и смотрелся не совсем плохо. Правда, когда начали общаться плотнее, как раз и начало вылезать, я бы сказал, отсутствие академизма, лоскутность и поверхностность. Все-таки образование вещь нужная и за плечами его не носить. Сложные вещи парню приходилось объяснять долго, а его излишняя самоуверенность и не подкрепленная знаниями амбициозность скоро привели к тому, что наши дороги разошлись. Потом до меня доходили слухи, что в другой компании он продолжил работать в том же направлении и даже чего-то достиг, но там был несколько другой уровень бизнеса и соответственно совсем другие требования.

С другой стороны наличие хоть какого количества образований совсем не гарантирует, что вы получите хорошего специалиста.

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

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

Вообще, в моей практике “золотой фонд” – это аспиранты, которые бросили по ряду причин аспирантуру и пошли работать.

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

Привести и заставить работать – у нас это не вариант. Все случаи, которые у меня были заканчивались печально. Приводят парня, даже, казалось бы с профильным образованием, который говорит, что он просто мечтает стать программистом, а ты через какое-то время понимаешь, что все усилия бесполезны. Смотрит в монитор, и даже если на нем что-то по теме программирования, а не соцсети или ютубовские ролики непонятного содержания, то 10 строчек кривого кода в день дают сигнал: не твое это, парень, не твое. Нам жалко тратить свое время на тебя и жалко тратить твое время. Тебе нравятся велосипеды – не слушай маму – занимайся велосипедами.

С другой стороны откуда к нам только люди не приходили: из МЧС, из МВД, после армии. В практике был парень кочегар. Показательный случай, когда на одном из складов заметили определенную подозрительную активность в сети. Покопавшись вышли на оператора. Забрали к себе. Впоследствии он стал одним из наиболее ценных сотрудников.

Как создать команду ИТ-шников, где их ловить и как удерживать, мы поговорим отдельно. Сейчас еще хочу сказать, что в ИТ много приходит людей из “бизнеса”. Приходят вместе с проектами и остаются в роли постановщиков задач, руководителей проектов, внедренцев. Приходят те, кому перестает хватать творчества в своих подразделениях, кому надоедает рутина, кому хочется развития. Рано или поздно, если правильно строить ИТ-структуру, в ней оседают лучшие люди, которые являются мотором компании, двигают ее вперед.

Глава 5

Как сделать карьеру в ИТ?

ИТ – отличная тема, чтобы построить карьеру. Хороший ИТ-шник имеет достойный доход, пользуется уважением и всегда имеет перспективу. Вопрос всего лишь в том, чтобы стать “хорошим”.

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

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

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

Какое бы амплуа в сфере ИТ вы не выбрали стоит помнить, что здесь все меняется очень быстро и навряд ли получится, чтобы загрузившись один раз каким-то багажом знаний вы на нем сможете ехать хотя бы 5 лет.

Залог успеха – это постоянное развитие, изучение новинок в своей и смежных областях.

И главное не бояться. Не бояться брать на себя ответственность. Пробовать, делать, ошибаться, переделывать, снова ошибаться и так пока не получится. Я не имею ввиду “кидаться с голой шашкой на танк”. Нужно осознавать ответственность, понимать цену своей возможной ошибки и быть уверенным в своих способностях ее исправить. Это очень важные качества.

Никакое самое длительное и качественное тестирование не может дать 100% гарантии, что внедряемое изменение не приведет к какой-нибудь внештатной ситуации. Не нужно это воспринимать как рекомендацию отказаться от тестирования. Но и затягивать тестирование, превращая его в бесконечное, смысла никакого нет. Нужно всегда быть готовым работать по живому.

Мы еще поговорим о внутрикорпоративной разработке программных продуктов. Она имеет достаточно серьезные особенности. Здесь я хочу сказать о том, что делая свое дело, даже сугубо для себя, нужно смотреть на лучший опыт. Нельзя, без особой необходимости, в угоду срокам, халтурить. Это показатель профессионализма. В моей практике случалось, что мы по 4 раза переделывали пользовательские интерфейсы, хотя самый первый вариант вполне соответствовал техническому заданию и формально к нам претензий быть не могло.

Карьерные пути в ИТ бывают разными. Например, быстрее всего можно добиться минимального успеха в системном администрировании. Как я уже говорил, хороший эникейщик – это клад. За год достигнуть успеха на этом поприще вполне реально. Но тут над вами нарисуется некоторый потолок, который будет пробить достаточно сложно.

У программистов не так. Более или менее нормальный программист – это 3-5 лет. В главе “Кто такие ИТ-шники?” я говорил о своей шкале “кодер”-”программер”-”разраб”. Разраб вообще не имеет потолка.

У системных аналитиков, руководителей проектов – своя стезя. Там тоже потолок достаточно условный, а время созревания не быстрое.

ИТ – это игра в долгую. Тут нужен опыт.

Достаточно важным является нахождение баланса между попрыгунчеством и болотным прозябанием. Это тоже относится скорее к общим рекомендациям. Скоростное метание между компаниями и проектами – это дурной тон. Я всегда с подозрением относился к людям, у которых много мест работы и срок работы на каждом до 1 года. Это нормально в самом начале, когда человек нащупывает сферу своих интересов, понимает, что его привлекает. Но если это продолжается и после 30, то это вызывает серьезный вопрос. Вход в серьезный проект, какой бы ты не был специалист, адаптация к новому месту – это месяцы. Все таки ИТ – это достаточно сложный технологический сектор. Уникумов, которые бы пришли и начали работать по полной через пару недель я практически не встречал.

С другой стороны, если человек сидит на одном месте без развития более 5 лет – это тоже вызывает серьезные вопросы. Тут не идет вопрос о должностном росте. Развитие может быть как вертикальное, так и горизонтальное. Смена прикладной области, погружение в другой проект, замена инструментария – это то, что позволяет не застаиваться.

Болото вокруг нас имеет свойство возникать помимо нашей воли. Часто мы и сами потворствуем этому процессу. Мы стремимся создать себе зону комфорта, обустраивая среду вокруг себя и часто потом не замечаем, что в обустроенном и комфортном для нас гнездышке начинает мягко говоря попахивать гнилью.

Хороший руководитель ИТ-подразделения должен следить за уровнем заболоченности и своевременно кидать камушки в стоячую воду.

Мне приходилось сталкиваться с людьми, которые очень быстро могли обустроить любое гнездо. У них в их зоне ответственности всегда все было хорошо. Не отлично, но хорошо. Они не были перфекционистами, но получив участок деятельности они быстро доводили его до определенной степени комфортности и дальше запускали процесс заболачивания. Я считал своим долгом обеспечить их миграцию с насиженного места, поскольку только таким образом можно было их развивать. Кто-то обижался, кто-то принимал такой расклад, но я считаю, что такой подход был полезен и для них, ибо они прокачивались, и для компании, которая получала больше "обустроенных" мест.

Если подытожить, то для того, чтобы сделать карьеру в ИТ (как впрочем, наверное, и в любой другой сфере) нужно: держать нос по ветру, следить за изменениями, постоянно задавать себе вопрос: а не пора ли мне чего-то поменять и не стоит ли мне чему-то поучиться? Ну и главное: работать, работать и еще раз работать… Изучай свою матчасть, не бойся брать на себя ответственность и готовься к подвигу.

Уж ИТ – это точно та сфера, где подвигу всегда найдется место. Косяки и аварии в ИТ – это вещь постоянная. Проявить себя в борьбе с ними – это достойно. Единственное, что если косяк или авария будут идентифицированы, как ваши – это может поставить реальный крест на карьере.

Глава 6

Путь ИТ-менеджера

ИТ-отдел, Управление автоматизации, ДИТ или Департамент информационных технологий, Служба технической поддержки информационных систем.. В различных организациях ИТ-подразделения сводятся в различные структуры. Об их составе и наполнени мы поговорим в следующей главе.

Сейчас мы поговорим об ИТ-структуре и управлении ей в целом.

Каких-то особых стандартов я не встречал, но со временем я выработал для себя некоторые подходы, которые сейчас и постараюсь изложить.

Понятно, что все начинается с количества ИТ-шников в Компании. Если группируем 3-4 человека – это группа, если 10 – отдел, до 40 – управление, больше – Департамент. Это достаточно условно, но в целом такой подход вполне себе понятен.

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

В главе 3 мы уже знакомились с тем какие бывают ИТ-шники. В целом ИТ-структура объединяет весь зоопарк: различные администраторы, программисты, специалисты по офисной технике и пр. Что-то они делают сами, какие-то функции вынесены на аутсорсинг.

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

Но, рано или поздно, если компания развивается, то компьютерщика становится два. А там где есть двое, возникают отношения подчиненности. Кто-то становится старшим. Так появляется зародыш ИТ-менеджера.

Старший наделен властью. Он принимает решение и несет ответственность. Он становится фильтром между руководством и своим подчиненным.

Но он только старший. Он сам выполняет часть функциональных работ. Фактически у него есть только помощник, который разгрузил “изначального компьютерщика”.

Дальше появляется еще один помощник, еще один и еще…

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

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

Возникает ситуация, когда развитие компании требует качественного скачка – появления реального ИТ-менеджера.

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

Я практически не встречал случаев, когда допустим ИТ-отдел реорганизуется в ИТ-департамент и Руководитель отдела становится Директором Департамента.

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

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

В качестве примера можно привести реорганизацию, которую мы провели в Магните в 2004 году. Отдел автоматизации был преобразован в Департамент. При этом бывший руководитель отдела был назначен Руководителем Управления развития информационных систем (что по уровню выше руководителя отдела) – заместителем Директора Департамента.

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

Вообще, ситуация перехода в статус менеджера (не только в ИТ) скорее всего для достижения успеха должна сопровождаться сменой места работы. Так процесс происходит менее болезненно. Другой вопрос, перед тем как дергаться возможно стоит здраво оценить свою готовность. Не нужно торопиться. Очень хорошей практикой является сравнение себя и своего руководителя. Задайте себе вопрос: а могу ли я научиться чему-то у своего руководителя. И речь не идет о каких-то сугубо специфических профессиональных знаниях. Скорее стоит смотреть на жизненный опыт.

Иногда полезно оценить себя: насколько я хорош как руководитель? Получить ответ на такой вопрос задача достаточно нетривиальная. Можно провести опрос, можно посмотреть на KPI своего подразделения. можно пройти какой-нибудь профессиональный тест. Но я, со временем, для себя вывел несколько другой критерий. Все очень просто. За чем вам ходят сотрудники? Я считаю, что к хорошему руководителю сотрудники ходят за его мнением. Именно его мнение, основанное на его опыте, знаниях и интуиции является наиболее ценным. Совет – он намного лучше чем приказ. Если к вам ходят за советом, а не за нагоняями и распоряжениями – скорее всего вы хороший руководитель.

Должен ли руководитель быть лучшим в своей специальности? Должен ли он сам выполнять какую-то работу? А должен ли командир мотострелкового полка лучше всех бегать кросс, стрелять и водить БМП?

Если командиру полка приходится стрелять самому – значит он плохой командир. Значит он где-то ошибся, он не справился с управлением.

Если руководитель ИТ-подразделения вечно занят работой руками – значит его нужно либо обеспечивать дополнительными ресурсами, либо менять. В одной компании я долго бился с Руководителем отдела системных администраторов, который не успевал писать документы, планы и отчеты, потому что постоянно то ремонтировал компьютеры, то администрировал домен, то решал еще какие-то важные и срочные задачи. На вопрос почему ты это делаешь сам, а не поручишь кому-то из подчиненных (благо их было достаточно и перегруза не было) он отвечал: я должен сам владеть ремеслом и таким образом я поддерживаю свой профессиональный уровень. Как на менеджере мы были вынуждены, к сожалению, на нем поставить крест.

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

Менеджмент – это отдельная наука. Бывают ли универсальные менеджеры? Это очень сложный вопрос. Есть общие принципы управления. Используя их, наверное действительно можно управлять чем угодно. Единственное, встанет вопрос с качеством управления.

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

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

Именно с отраслевой специализаций я бы связал необходимость еще одного скачка в эволюции ИТ-менеджера.

Когда мы говорим об ИТ-отделе – это еще нечто достаточно универсальное. Это уровень потребностей средненькой компании, которая вполне может сидеть на типовых решениях.

Чем больше компания, тем более уникально ее лицо, тем более уникальной становится ее ИТ-система. И управление этой системой тоже требует особых подходов.

Именно уникальность, необходимость формирования и реализации нетиповых стратегических шагов требует появления ИТ-директора.

ИТ-директор – это человек, который работает на другом уровне управления. Он отвечает за то, чтобы ИТ-система отвечала стратегическим вызовам, стоящими перед конкретным бизнесом, конкретной организацией.

Меня всегда умиляет, когда люди осуществляющие подбор на позицию ИТ-директора задают вопросы: а вы умеете программировать на JavaScript? а вы знаете, как администрировать Microsoft Exchange?

Я в таких случаях задаю встречный вопрос: А вы уверены, что вам нужен Директор по ИТ? может вам нужен Руководитель ИТ-отдела? или Руководитель отдела системного администрирования?

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

Можно ли мигрировать между отраслями? Можно. Это тяжело, затратно – но вполне реально. Речь не идет об универсальности ИТ-директоров. Дело в другом. Сама позиция ИТ-директора требует определенного специфического набора компетенций.

И одна из основных компетенций – это системный анализ. Невозможно стать хорошим ИТ-директором не умея анализировать системы. Наличие же этой компетенции при определенном желании, настойчивости и временном ресурсе позволяет разобраться практически в любой области.

Итак.

Старший компьютерщик – Руководитель ИТ-отдела – Директор по ИТ – вот он путь ИТ-менеджера.

Но есть ли что-то дальше?

Есть.

В современном мире ИТ уже не является вспомогательным инструментом в бизнесе. Часто ИТ-это и есть сам бизнес.

Директор по развитию бизнеса, Директор по инновациям, Директор по управлению изменениями – это те позиции, в направлении которых идет путь. ИТ-менеджеры – это разрабы для бизнеса – люди, которые ответят на вопрос “зачем?”.

Мир меняется. Если раньше требование к ИТ-менеджеру было: “Обеспечить, чтобы было сделано как говорит бизнес”, то теперь “сказать бизнесу что и как делать, чтобы достигнуть целей”.

Глава 7

Как организовать ИТ-структуру компании

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

В этой главе мы попробуем рассмотреть подходы к получению адекватных ответов на эти вопросы. Данный материал достаточно скучный, но тем кто думает о карьере ИТ-менеджера надеюсь он будет полезен.

Я не встречал каких-либо универсальных рецептов формирования структуры ИТ-подразделений, да и сомневаюсь, что они могут быть.

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

Какие-то функции могут быть централизованы, какие-то лучше децентрализовать. Что-то можно отдать на аутсорсинг. Где-то сейчас и одного человека много, а где-то нужно иметь 20 человек и там явно нужно строить дополнительные уровни управления.

Разрабатывая структуру нужно ориентироваться не только на стоящие задачи, но и на текущую обстановку, наличие ресурсов, включая возможности размещения и осуществления коммуникаций.

Хорошая структура проста и понятна. Глядя на нее легко увидеть кто за что отвечает. Важным является наименование подразделений и должностей. Они должны отражать основную суть деятельности.