Я видела много IT отделов в компаниях самых разных отраслей на разных этапах развития. Некоторые события в жизни отдела прослеживаются как стадии, через которые проходят все, ну или почти все, кто мне знаком.
Для чего и для кого пригодятся эти знания?
Для руководителей IT - это некоторый путь, который можно использовать как ориентир в развитии отдела. И если вам кажется, что ваш отдел некуда развивать, то это точно не так)
Для бизнес заказчика - не стоит ожидать от IT-шников автоматизации внутренних процессов и прозрачных переходов данных из одной системы в другую, если развитие подразделения IT находится на ранних стадиях.
Для специалистов в сфере IT тоже будет полезно понимать, что в отделах на ранних этапах развития вы будете универсальным специалистом, совмещающим в себе несколько ролей, а на поздних этапах ваша специализация будет узкой и более требовательной к качеству, но влияния на общий результат будет намного ниже.
На развитие IT в компании можно смотреть с разных сторон. Я расскажу какие этапы развития могут быть в направлениях методологии (как делаем) и организационном (кем делаем). Чаще всего развитие в этих направлениях идёт синхронно и это удобно. Но иногда организационная часть запаздывает, так как она развивается в ответ на запрос новых компетенций и подходов. В этой статье я приведу пример, как развивается IT инфраструктура компании и какие она предъявляет требования к орг. структуре в IT отделе. В следующей статье я расскажу, как меняются подходы с развитием внутренних компетенций.
Первый этап - формирование функции IT отдела. Так как без IT инфраструктуры и телефонии сейчас сложно представить какое-то предприятие, на первоначальном этапе чаще всего появляется системный администратор. Он практически сразу отвечает и за все ПО, используемое в компании - будь это ip-телефония для продаж или 1С для бухгалтера. На этом этапе самое важное правильно выбирать подрядчиков, желательно еще и таких, которые могут все и не будут просто зарабатывать на вас, а будут скорее помогать. Подрядчик должен быть не супер крупным, иначе ему будет неинтересно с вами работать и тем более быть гибким к вашим запросам - вы слишком маленькие.
В какой-то момент на этом этапе где-то возникает неудовлетворенность готовым решением. Очень часто это происходит в бухгалтерии или финансах, хотя не обязательно, и зависит от активной позиции руководителей отделов. В ответ на запрос IT-шники ищут подрядчика для решения задачи и остаются на этом этапе, либо ввязываются в бой и решают задачу своими силами. При чем свое решение - не всегда в написании кода, это может быть и умный GoogleSheet, но важно, что решение собственное и ответственность за него только на внутренних IT-шниках. Это и есть следующий этап.
Второй этап - готовые системы и «сводная». Забавно, но название «сводная» я слышала уже в нескольких компаниях. Наверно, потому что «сводная»
- это первоначально таблица, а таблицы самое простое, что можно использовать для расчетов. И вот первая система под названием «сводная», по моему опыту, это либо биллинговая система, либо подобие BI системы с дашбордами и отчетами для топ-менеджмента, где агрегируются данные из разных систем. То есть либо считаем деньги, либо считаем и показываем важные показатели бизнеса, которые влияют на деньги. Цифровизация часто начинается с функций, генерирующих прибыль, или с отчетности для управленческих решений, наверно, потому что эффект в этих точках наиболее заметен. На этом этапе хорошо бы провести ревизию собственных навыков - что и кто умеет из текущих сотрудников IT отдела, это пригодится дальше.
Если эксперимент со своей первой системой будет удачным то очень быстро придет и следующий запрос от бизнеса для новой собственной системы или для улучшения какой-то текущей. И это первый шаг на долгом пути цифровизации компании, что предлагаю выделить как третий этап. Это один из самых долгих и сложных этапов. С него так же можно скатиться на предыдущий этап или выйти на следующий. На этом этапе впервые руководитель отдела сталкивается с серьезной нехваткой компетенций и времени. Если вы узнаете себя, почитайте Когда разработке нужен Руководитель проектов?
Если только руководителя не сменили на данном этапе, то он растет вместе с отделом. И если до этого руководитель во многом полагался на свой опыт и свои компетенции, то сейчас ему не хватает глубины знаний в разработке - как в процессе, так и в технологиях. И это нормально, рост начнется тогда, когда руководитель увидит нехватку компетенций в какой-то области. Чему учиться? Я бы советовала сначала проектному управлению, затем методологиям в разработке, затем аналитике. IT директор не должен быть экспертом во всех областях, но он должен понимать суть и границы области знаний и уметь оценить компетенции сотрудников. Сотрудники же в своих областях должны быть опытнее и умнее руководителя. Это отличное время и для роста сотрудников внутри отдела, но обязательно с оценкой способностей и обучением.
Где взять недостающие скиллы для команды и для себя?
- Консультанты-эксперты. Благо сейчас рынок консалтинга насыщен. Правда надо убедиться, что у консультанта живой опыт внедрения изменений, а не теоретические знания. Для этого лучше всего живые кейсы в живых компаниях, в идеале с обратной связью от знакомых. Или если у него блог в Дзене о реальных кейсах в развитии IT - как у меня. Так что, приходите ко мне :)
- Обмен опытом. Этот вариант супер актуален на всех этапах. Потому что практику ничем не заменишь и живые примеры коллег тоже. Сложность состоит только в том, что надо найти компанию чуть более развитую чем вы сами. Чтобы они ваши проблемы проживали не так давно. Важен нетворкинг - ходите на IT конференции, вступайте в сообщества, или и тут обращайтесь ко мне - возможно, у меня будет вариант.
- Обучение. Учиться надо всегда - книги, курсы, конференции. Профессиональные сертификаты международного уровня тоже приятно, хоть и не обязательно. Особенно это важно, если меняется роль или расширяются обязанности. Например, Руководитель проектов начинает думать, как развивать продукт, тогда ему нужно обучиться ремеслу Продакта.
- Свежая кровь. Новички могут привнести в компанию новые идеи, но что важнее, уже проверенные на прежнем месте работы практические методы. Тут важно уметь слушать и пробовать, а не отмахиваться от новых идей. Чтобы идеи были в жилу, а не все подряд, надо говорить о проблемах и задачах открыто и быть готовым к чьей-то активности. С другой стороны, если не готовы дать человеку полномочий, лучше не стоит давать ему возможность пробовать внедрять новые подходы.
Цифровизация / Построение IT ландшафта. Насколько быстро от первой системы, компания перейдет к следующим разработкам, зависит по большей части от бюджетов. А рост бюджета зависит от эффекта внедренных систем. Если темп увеличивается, руководство готово увеличивать затраты на цифровизацию, то надо как можно скорее задуматься об общей архитектуре систем. К сожалению, мы не думаем об этом вначале, а зря. Это как строить дом. Если вы построите фундамент 6х8, сделаете скважину и септик, а затем решите что нужно больше этажей или расширить площадь, то переделка будет дорогой, иногда она стоит дороже чем полностью новый дом построить. А если не переделывать, то накопленный старый код, которые еще и сделан был без расчета нововведений, будет мешать, как телеге пятое колесо. И чем дольше вы будете тянуть, тем дороже вам обойдется переделка. Если у вас в отделе нет архитектора - берите архитектора в аутстаф, зовите консультанта, берите на проектную работу, но не делайте без опыта, потом все равно переделывать :)
Есть и другая сторона медали - это излишняя сложность. Бывает часто, особенно с новыми технологиями и с продуктовой разработкой, что сделать из глины и палок за 1 день важнее, чем делать месяц, но правильно. Во внутренней разработке тоже так бывает, потому что компания меняется, рынок меняется и элементарно требования уточняются по мере узнавания предметной области. Тут нужно самому понимать, что важнее и почему, по классике выбираем из времени/стоимости/качества.
На этом этапе так же вам понадобятся компетенции аналитика - и бизнес аналитика, и системного аналитика. Рассчитывайте примерно на каждые 3 разработчика 1 аналитик фуллстек и 1 тестировщик, хотя все зависит от уровня сотрудников и уровня задач. Включение в команду аналитиков и тестировщиков - это повышение качества ваших систем + как ни странно, удешевление производства, так как без аналитиков и тестировщиков, их работу чаще всего выполняет разработчики, которые стоят дороже.
Как только пользователей становится близким к 100 стоит взять специалиста по внедрению. Человека, который будет отвечать за то, чтобы пользователи пользовались системой :) Помогать изучать систему, решать мелкие организационные проблемы, например, отсутствие доступов, собирать и доносить обратную связь - все это отнимает время производства или РПшника. Менеджер внедрения сможет уделять больше времени пользователям и повысит их лояльность при нововведениях. Помните, что плохое внедрение может испортить даже самую лучшую систему.
При увеличении численности сотрудников необходимо создавать центры компетенций. Для РП-шников - проектный офис, для менеджеров внедрения и поддержки - службу клиентского сервиса, для аналитиков - аналитический отдел и т.д. Будут центры компетенций внутри IT отдела или будут выделяться в отдельное подразделение зависит от кругозора и масштабности руководителя IT.
Когда IT делают систему для внутреннего пользователя, рано или поздно возникает гениальная идея - продавать свою систему на рынок. Я не выделяю это в отдельный этап, так как продуктовая деятельность выходит за пределы внутреннего IT отдела. Это важно понимать. Это разные деятельности. Вероятней всего ваша внутренняя команда не будет готова работать как продуктовая, ее надо будет переобучать/пересобирать/перефокусировать. Помимо этого совмещать решение задач внутренних и внешних клиентов для продукта вредно. Надо относиться к продукту на рынок как к отдельному бизнесу и к внутреннему клиенту, как к одному из внешних.
После этапа, когда команда максимально старается делать системы своими силами, наступает этап возвратный к системам с рынка. Команда снова смотрит в сторону готовых систем, но уже более осознанно. Менеджеры и руководство IT отдела понимает, что хочет, чего не хватает, взвешивает сложности разработки и поддержки собственной системы с ограничениями готовой. Все чаще прибегает к вендоровским решениям и доработкам чужими руками. В это время активно используются готовые решения, аутсорс разработка и привлекаются аутстаф специалисты высокого порядка для ускорения и недостающей экспертизы. Да, и на этом этапе экспертизы будет не хватать. Но это уже будет более серьезная экспертиза - в инфобезе, в высоконагруженных и безопасных системах, в качественном деплое или в технологиях - аналитика данных, ИИ, мат моделирование и т.п.
Дальше больших изменений не будет, пока компания будет финансово здорова. Будут качели между последними этапами.
Кстати, если внутри компании есть сильная конкуренция и много решений завязано на политике, то естественный процесс развития IT может изменится. Это случается, когда от бизнеса есть запрос, который IT не может выполнить, а заказчик из бизнеса, мимо IT отдела, находит каких-либо подрядчиков, которые обещают сделать "космолет". Если внутренний IT объективно понимает, что ни своими силами, ни с помощью консультантов-экспертов или узкоспециализированных подрядчиков запрос не выполнить, то предложила бы дать бизнесу и подрядчику шанс проявить себя. Сколько я таких историй не видела - все они, к сожалению, заканчиваются плачевно. Чтобы такого не произошло - поддерживайте доверие между Руководителями всех функций в компании и сделайте работу IT отдела прозрачной. Об этом подробней в другой статье.
Буду рада услышать ваше мнение, дополнения и советы, как организационно подготовиться к изменениям. Благодарю, что дочитали :)
