Организационная структура управления айти компании

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

Почему я об этом пишу?

Часто я сталкиваюсь с описанием вакансий и запросами вроде «нам нужен CPO в стартап». После вопроса сколько в стартапе людей и продуктов, выясняется что продуктов один или два, сотрудников — не более 30, а под CPO подразумевается просто опытный менеджер продукта, который должен работать руками (в то время как роль CPO — это роль стратега, управленца и ментора).

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

Такое несоответствие реальной потребности и воображаемой я встречаю повсеместно.

Кто все эти люди?

Корпоративные иерархии и HR-отделы оперируют набором красивых слов, и вот некоторые из них:

Значения этих слов варьируются от компании к компании, где-то случайно, где-то намеренно: «Мы называем нашу кнопку унитаза велосипедом потому что это подходит нашей компании», «Мы к этому пришли исходя из своего опыта».

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

О ролях и функциональности я и хочу поговорить ниже.

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

Начнем с технической иерархии.

CTO

Отвечает за развитие технологической части компании.

Размытое определение? Уточним: — В стартапе на 10 человек CTO обычно выполняет функции тимлида, но получает красивое название по двум причинам: чтобы потешить собственное эго и в расчете на то, что в будущем он займет эту роль. Объясняется это тем, что человек отвечает не за конкретную команду, а за развитие всей технологической части сейчас и в будущем.

— В компании на 100 человек основная задача CTO — отвечать за выполнение технической части продуктовых планов компании, развивать компетенции технического отдела, синхронизировать подходы разных команд к разработке, способствовать устойчивости технической части бизнеса.

— В компании на 1000+ человек частью задач предыдущего блока (синхронизация подходов разных команд к разработке, поддержание единого стэка и архитектуры) занимается Chief Architect. Фокус CTO уходит на найм и развитие руководителей, управление техническими лидерами направлений, и ответственность за выполнение технических планов.

— В компании на 10 000+ CTO отвечает за долгосрочное техническое видение компании и выполнение стратегических планов.

Chief Architect

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

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

CIO

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

Tech Lead

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

Team Lead

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

Как это выглядит вживую:

Задача тимлида — выполнить планы команды, на это завязана его мотивация. Когда в компании одна команда, тимлид — то фактически CTO, у него много свободы и ответственности.

С ростом количества людей и делением их на команды, каждая команда начинает (и должна) переживать только о своих планах. Чтобы синхронизировать их работу появляется CTO, человек который отвечает за все команды.

Со временем выделяются отдельные направления, и в помощь CTO приходят техлиды и Архитектор. Роль CTO фокусируется на людях и стратегии, Архитектор занимается синхронизацией подходов к разработке, а техлиды отвечают за выполнение конкретных планов.

Цели спускаются от CTO к техлидам и затем в команды. Цели архитектора отделены от «выполнения планов» и сводятся к обеспечению единого подхода к выработке решений архитектурных задач. Власть архитектора в праве вето на технические решения, а основная задача — своевременная разработка решений вместе с командами, которые будут при этом устраивать другие команды и не мешать продуктовым/проектным планам.

Чтобы было понятнее: CTO нанимает руководителей, участвует в постановке проектных целей, отвечает за согласование и выполнение планов и за стратегическое развитие технической части. Архитектор создает стратегическое архитектурное видение и делает так, чтобы команды в погоне за своими планами его не сломали.

Перейдем к продуктовой иерархии.

CPO

Зеркало роли CTO в продуктовой части. Если компания маленькая, то CPO по сути будет единственным менеджером продукта, а роль — это просто красивое слово.

Конечно под словосочетание Chief Product Officer можно подвести что угодно — и роль единственного продакта в том числе, он же главный по продукту, главнее нет. Но реально эта роль существует в больших компаниях с разными продуктами и командами, когда появляется необходимость синхронизировать продуктовое видение разных менеджеров продукта так, чтобы в погоне за своими целями они не разорвали продукт на части.

Вдобавок к этому его задача — обеспечивать отбор специалистов и поддерживать уровень экспертизы среди менеджеров продукта.

Senior Product Manager

Здесь тоже существуют разные интерпретации, но мы обратимся к слову Senior. Когда видишь такую приставку хочется спросить senior to whom. Очевидно, что в погоне за блестящими значками и бантиками просто опытных менеджеров продукта стали называть Senior, но если следовать логике, то старший менеджер продукта появляется, когда есть младшие.

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

Senior Product Owner

Такой роли не бывает. У продукта есть владелец. Постарше он или помладше — это никак не влияет на продукт и его развитие. Продакт оунеры не подчиняются друг другу, владелец продукта — это роль, а не должность.

Здесь мы подходим к классическому квартету Product Owner / Product Manager / Product Manager / Business Owner и разделению ролей.

Product Manager

Менеджер продукта отвечает за стратегическое видение продукта, роадмап, анализ рынка/продукта и генерацию гипотез в соответствии с приоритетами бизнеса.

Product Owner

Владелец продукта отвечает за приоритизацию бэклога и полученный результат перед бизнесом. В организационной диаграмме вы не найдете «владельца продукта». Владельцем продукта обычно выступает представитель со стороны бизнеса или заказчика, который отвечает непосредственно своей шкурой за продукт. Например: владелец продукта «автоматизация бухгалтерия» может быть CFO, так как именно он согласует с менеджером продукта «автоматизация бухгалтерии» роадмап.

Ответственность разделяется соответственно: если из-за некачественных вводных владельцем продукта были приняты неверные решения — это ответственность менеджера продукта. Если были выбраны или согласованы неверные приоритеты — это ответственность владельца продукта. Если продукт оказался не востребован рынком — ответственность зависит от того, предупреждал ли менеджер продукта об этом владельца. Если владелец был предупрежден — то это его ответственность.

Project Manager

Менеджер проекта отвечает за реализацию бэклога в оговоренный срок и бюджет.

Business Owner

Отвечает за результаты капиталовложений в разработанный продукт перед советом директоров/акционерами.

Владелец продукта и бизнес-оунер — это роли, а менеджер продукта и менеджер проекта это еще и профессии.

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

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

Например, есть владелец продукта «кассовый терминал», который коммуницирует с бизнесом по всему миру. Есть менеджер продукта «кассовый терминал, который развивает этот продукт. А есть бизнес-оунер из Мексики, который отвечает за развитие бизнеса в этом регионе. Он не влияет напрямую на бэклог, но отвечает за бизнес-показатели в регионе и общается с владельцем продукта.

Недавно Scrum Inc стала продвигать альтернативное видение роли Product Owner как человека ответственного за тактическую реализацию стратегического видения менеджера продукта. Я буду придерживаться оригинальных идей Agile, а для еретиков приведу цитату преподавателя Гарвардской школы бизнеса: “I’ve trained dozens of teams who are using SAFe and I have never seen this work well.”

Head of Product, Product Lead

Красивое название для менеджера продукта. Иногда применяется в ситуации когда в продукте есть несколько менеджеров продукта и кто-то из них чуть главнее других.

Head of PMO

В проектных компаниях это человек ответственный за реализацию всех проектов компании, альтернатива CPO в продуктовых компаниях с одним отличием: если в продуктовых компаниях фокус на продуктовых командах и их планах, а CPO просто «разнимает дерущихся» и синхронизирует планы, то в проектных компаниях руководитель проектного офиса отвечает за результаты работы всего проектного офиса. Если у CPO в портфеле не взлетает один из продуктов — это ответственность менеджера этого продукта. Если не работает delivery в одном из проектов — это ответственность руководителя проектного офиса.

Project Lead, Head of Project

Подписывайтесь на мой телеграмм канал @dailykuznetsov где я публикую короткие заметки о финансах, обществе и управлении продуктами

Об авторах

4.1. Структура ИТ подразделения и органы управления ИТ предприятия

Когда руководству уже известен уровень зрелости ИТ-процессов, определена Стратегия развития информационных технологий на среднесрочный период, а также однозначна и понятна цель ИТ – подразделения, то на первый план выходит вопрос: какая же должна быть оптимальная структура ИТ подразделения?

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

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

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

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

– Реализация концепции разработки, обеспечение исполнения планов и графиков работ по разработке, внедрению и сопровождению ИТ-сервисов Заказчиков.

– Сопровождение, администрирование, ввод в эксплуатацию и техническая поддержка ИТ-сервисов Заказчиков.

– Обеспечение бесперебойной работы технических средств Заказчиков.

– Диспетчеризация систем автоматизированного управления производством, информационных технологий, телефонии.

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

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

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

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

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

– Осуществление приемки от сторонних производителей технологического оборудования полного пакета сопровождающего его технологического программного обеспечения.

– Подготовка договоров на разработку программного обеспечения сторонними организациями, контроль за ходом их выполнения, участие в приемке готовых разработок в рамках задач Заказчиков.

– Выявление резервов по повышению эффективности ИТ-сервисов.

– Выполнение и контроль выполнения проектов в области.

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

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

– Сопровождение ИТ-сервисов;

– Разработка и внедрение ИТ-сервисов;

– Поддержка и развитие инфраструктуры предприятия;

– Обеспечение бесперебойной работы АТС и линий связи;

Рисунок 3. Структура ИТ-подразделения по направлениям деятельности

– Материально техническое обеспечение;

– Разработка, внедрение и сопровождение систем управления технологическими процессами.

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

Но эта структура не является типовой, т. к. мы в самом начале вводили некоторые ограничения. Так, например, на основе ограничения в численности сотрудников предприятия более 1001 человек, с применением метрики для определения численности ИТ-специалистов (3,5 %, см. раздел) получаем, что численность ИТ-подразделения должна быть в районе 35 человек. Конечно же, определенная нами численность является ориентиром и для более точного расчета руководство ИТ подразделения должно владеть дополнительными параметрами, например: численность парка персональных компьютеров; количественный и качественный состав периферийной техники; количество абонентов АТС; количество объектов Автоматизированной Системы Управления Технологическим Процессом (далее по тексту – АСУТП); объем и качество (доморощенные системы или готовое комплексное программное обеспечение) программных ИТ-сервисов; сколько и каких моделей картриджей тратится предприятием за период и т. п.

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

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

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

Минусом такой организационной структуры является увеличение руководящего состава в ИТ-структуре, усложнение администрирования распределенных информационных систем, так как получается, что за различные части этой системы отвечают сотрудники разных «дивизионов». Чтобы частично разрешить второй недостаток, используются также смешанные структуры, где основные ИТ-подразделения организуются на дивизиональной основе, но существуют отдельные подразделения ИТ, сохраняющие функциональную организацию, например, служба поддержки, организованная в центральном офисе, является единой для всех филиалов. Другие типы дивизиональных структур – по клиенту или по услуге – в ИТ применяются значительно реже. Примером дивизиональной структуры по продукту может служить выделение отделов в ИТ-подразделении по отдельным крупным информационным системам (отдел сопровождения ERP-системы, например).

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

– если это задачи уровня сложности «Поддержка», то вариантами подчинения ИТ-подразделения могут быть: технический директор, финансовый директор, директор по развитию;

– на уровне «Улучшение» список вариантов подчинения зависит от основных направлений оптимизации и улучшения бизнес процессов, выбранных руководством предприятия, но в большинстве случаев: финансовый директор, директор по развитию;

– на уровне сложности задач «Расширение», с учетом значимости задач для бизнеса и влияния их результатов на бизнес цели: директор по развитию, директор по операционной деятельности, генеральный директор/ директор предприятия;

– при решении ИТ-подразделением задач самой повышенной сложности «Создание» единственный ответ о подчиненности – генеральный директор/ директор предприятия.

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

Далее, для удобства изложения материала, остановимся на названии такого органа управления как – Комитет по ИТ.

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

Основными задачами Комитета по ИТ могут являться:

– Координация работ по проектам разработки и внедрения информационных технологий предприятия для успешного выполнения поставленных задач автоматизации в установленные сроки

– Разработка концепции и планов внедрения информационных технологий, не противоречащих Стратегии ИТ и их утверждение на Комитете.

– Внесение изменений под влиянием внешних или внутренних факторов на бизнес в целом в Стратегию по ИТ.

– Формирование и утверждение перспективных и текущих планов работ по разработке и внедрению информационных технологий.

– Осуществление контроля выполнения текущего плана работ по разработке и внедрению информационных технологий предприятия.

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

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

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

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

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

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

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

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

Переходя к следующему разделу необходимо помнить и понимать, что «плох тот план, который нельзя изменить».

Данный текст является ознакомительным фрагментом.

Начнем с функциональной структуры компании

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

Плюсы:

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

Минусы являются продолжением плюсов:

• снижение гибкости и скорости принятия решений из-за формализованного подхода в работе. То есть, если новеньких сотрудник заметил проблему, то он скажет про нее своему начальнику, тот своему, то своему… ну вы поняли.
• трудности с координацией подразделений между собой. Поскольку каждое подразделение выполняет только свою часть работы и зачастую они (подразделения) не подконтрольны друг другу возникают проблемы во взаимодействии с подразделениями. Например, отделу маркетинга нужно отправить платежки подрядчику в 11 утра, а в бухгалтерии, по традиции, проводят оплаты в 14.00. И хоть ты тресни!

Функциональная структура подходит для небольших компаний, которые работают над одним проектом (продуктом, услугой). Если компания работает с несколькими проектами, то рекомендуются применять матричную структура для построения компании. Есть еще функционально-матричные гибриды компаний и компании, которые работают как бог на душу положит.
Тем не менее функциональная структура не такое уж и редкое явление в IT-компании. Сейчас мы рассмотрим, какие подразделения и роли внутри них могут быть в IT-компании. Помним, что в основе разделения – функция:

Стратегия ↓

CEO (Chief Executive Officer) – стратегическое управление компанией. Принятие ключевых решений по продукту и выбору партнеров, по финансам и модели развития.

CTO (Chief Technology Officer) ответственный за стек технологий для разработки и определяет критерии найма разрабов, собеседует их. Курирует обучение молодых, процессы своевременных релизов, планирует примерный объём ресурсов для функционирования разработки, определяет архитектуру продукта.

СIO (Chief Information Officer) обеспечивает работу внутренней инфраструктуры компании, директор по информационным технологиям. Какие сервера, где и что храним.

Маркетинг ↓

Marketing Manager – лидогенерация в Интернете, курирование SEO оптимизации и SMM продукта, интернет продакшна (ролики, лендосы и т.п.). Закупка трафика и рекламная монетизация.

Business Development Manager – лидогенерация “в полях”, выступления на конференциях, поиск нужных связей и клиентов. Курирование производства выездной промо-продукции, организация стендов.

Продажи ↓

Sales Manager – обработка лидов и заявок, выявление потребностей и формирование кастомизированного предложения, “дожатие” клиента, заключение сделок.

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

Разработка ↓

Product Manager  – курирует продукт, владеет бэклогом продукта, уточнет требования, приоритезирует задачи для разработчиков в зависимости от стратегический целей. Наблюдает за метриками продукта, предлагает идеи по его улучшению продукта.

Business Analyst – помогает сформировать понятное техзадание, отвечает за сбор требований для проекта.

Project Manager – управляет проектом, коммуницирует с клиентом и/или Product Manager, отвечает за планирование, расписание, ресурсы сроки и мотивацию команды.

Architect – занимается высокоуровневым построением продукта, отвечает за интеграцию проектов.

Tech Lead разработки – самый опытный разработчик в команде. Отвечает за то чтобы молодые делали все по-технологии и качество кода было хорошим. Обучает молодых девелоперов.

Team Lead – отвечает за слаженную работу команды. Совмещает менеджерские обязанности и обязанности ведущего разработчика.

Разработчик  – разрабатывает.

Дизайнер – делает дизайн.

DevOps – налаживает процесс непрерывной поставки релизов (CI), отвечает за работу серверов.

Data Science – анализирует всевозможные данные и генерирует гипотезы как сделать продукт или процесс лучше.

Тестирование ↓

Тестировщик – тестирует, пишет автоматические тесты или тестирует вручную по чек-листам.

Team Lead тестирования – старший тестировщик в команде тестирования. Отвечает за внутренний контроль качества, обучение молодых тестировщиков и за приёмку продуктов от вендоров (если таковые имеются), за построение процессов тестирования (если тестировщиков много).

Ресурсы ↓

Resource Manager – функция прямого начальника рядовых сотрудников. Определяет его зарплату, решает его вопросы с отпусками, развитием и т.п. Можно совмещать с кем угодно, в небольшой конторе это чаще всего СЕО или СТО лично, в средней – Project Manager или начальник отдела. В компании с функциональной структурой встречается крайне редко.

Recruiter – написание вакансий, поиск сотрудников, первичный отбор кандидатов, организация и проведение собеседований, закрытие вакансий.

HR Manager – онбординг, выслушивание предложений сотрудников, организация корпоративных ивентов, формирование HR-бренда компании.

Vendor Manager – поиск и выстраивание отношений с подрядчиками, которым можно отдавать лишние проекты или брать в аренду срочно нужные ресурсы, оформление с ними договоров

Операционные функции ↓

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

Сисадмин – устанавливает софт на компы и чинит их по необходимости, администрирует внутреннюю сеть.

Юрист – решает юридические вопросы.

Бухгалтер – ведет бухучет, начисляет зарплату.

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

Если компания небольшая, то один сотрудник может совмещать несколько ролей (тимлид и техлид, рекрутер и кадровик), отделы также могут объединяться (маркетинг и продажи, разработка и тестирование). Чем больше компания, тем специфичнее становятся и роли в ней.

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

В статье рассмотрим структуру (рис. 1) данной системы и приведем большое количество примеров многих ее компонентов. Эта структура показывает, какой полный набор моделей и документов в идеале должен иметь современный ИТ-департамент средней и крупной организации (многих отраслей, особенно самых высокотехнологичных).

При разработке данной схемы автор учитывал следующие факторы.

• Возможности систем бизнес-моделирования (
  Microsoft Visio, Business Studio и др.) по разработке соответствующих моделей и документов. Это ключевой фактор, т.к. не имеет смысла говорить о каких-то моделях и включать их в рекомендуемую структуру, если их разработку не поддерживают современные системы.

• Готовые типовые решения –
  «Большая библиотека системного аналитика и ИТ-архитектора» 

• Успешные практики и проектный опыт

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

• Требования национальных и международных стандартов и методологий в области ИТ (включая ITIL — Information Technology Infrastructure Library, TOGAF — The Open Group Architecture Framework, Archimate, ISO/IEC/IEEE 42010 и др.)

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

Рассмотрим более подробно, что входит в каждый из компонентов схемы (рис. 1) с примерами.

1. Нормативные документы (ИТ)

Данная группа включает непроцессные верхнеуровневые нормативные документы: политики, положения, порядки. Процессные регламенты относятся в группе «4. Процессы и процедуры (ИТ)».

Наиболее важные документы данной группы, которые должны быть разработаны и постоянно актуализироваться.

• Политика информационных систем

• Политика в области обеспечения качества ИТ (IT quality assurance)

• Политика информационной безопасности

• Положение об ИТ-архитектуре

• Положение об архитектуре, функционировании и развитии компьютерной сети

• Положение об организации ведения и архитектуре электронных баз данных

• Порядок проведения регламентных работ в ИТ-инфраструктуре

• Порядок установки, модификации и обслуживания объектов ИТ-инфраструктуры

• Порядок доработки, тестирования и внесения изменений в ИТ-системы

• Положение о разработке программных продуктов

• Порядок подготовки, организации и выполнения ИТ-проектов

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

2. Организационные регламенты (ИТ-персонал)

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

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

3. Формы документов (ИТ)

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

4. Процессы и процедуры

Данная группа включает: дерево (реестр) ИТ-процессов (рис. 3), модели ИТ-процессов и процедур, показатели KPI ИТ-процессов (рис. 4), матрицы распределения ответственности и ролей в процессах, практики ITIL. Виды ролей, которые желательно утвердить по каждому ИТ-процессу: владелец (ответственный), бизнес-аналитик (системный аналитик), риск-офицер (риск-менеджер), исполнитель (участник). Примеры построения бизнес-архитектур, описания и оптимизации процессов, цифровой трансформации приведены в
книге.

5. Архитектура приложений, технологий и баз данных

Данная группа включает: архитектура приложений (модели ИТ-систем и связей) – рис. 5 и 6, архитектура технологий, системных компонентов и платформ, архитектура баз данных, модели потоков данных, задачи и требования к ИТ-системам, матрицы прав доступа к ИТ-системам, полномочий.

6. Другие модели и материалы

Данная группа включает: стратегические карты ИТ и цели, реестр рисков ИТ-систем, модели технической архитектуры (оборудование), модели сетевой архитектуры (ЛВС, Active Directory и др.) – рис. 7, модели (графики) ИТ-проектов, другие аналитические и технические модели.

Расчет уровня зрелости системы регламентации и моделей ИТ-департамента

На основе рис. 1 можно разработать чек-лист, с помощью которого оценить уровень развития (проработки) каждого компонента и затем получить агрегированную оценку для системы в целом.

Предлагаемая шкала: 2 – полностью проработано и используется, 1 – проработано и используется частично, 0 – отсутствует. Формула: сумма оценок разделить на максимально возможный суммарный балл по всем компонентам. Автору известны организации, у которых данный чек-лист показывает 100%, т.е. максимальный уровень зрелости. А значит и другие организации тоже могут приблизиться к совершенству, выполнив соответствующие работы.

Ещё раз обратим внимание, что важно не просто разработать все необходимые регламенты и модели, а постоянно поддерживать их в актуальном состоянии, исполнять на практике и развивать. Только в таком случае всё это имеет ценность и даёт долгосрочные конкурентные преимущества.

Электронную версию чек-листа в формате Excel можно получить у автора по контактам, указанным в данной статье.

Уровни ИТ-архитектуры

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

Заключение

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

• Снижение трудозатрат на разработку документов, выполнение проектов, обучение сотрудников.

• Возможность выполнить большой объём задач собственными силами без привлечения внешних консультантов, т. е. дополнительных расходов.

• Минимизация рисков ИТ-систем и ИТ-процессов (ошибки, дефекты, сбои).

• Улучшение показателей KPI ИТ-процессов, качества и эффективности работы организации.

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

• Исполнение национальных и международных стандартов и требований в области информационных технологий, информационной безопасности.

Структура верхнего уровня

Одна из «белых книг» (white paper) компании Hewlett-Packard, посвященная вопросам эталонной модели управления ИТ-сервисами, на первой странице содержит следующей лозунг «Люди + Процессы + Технологии» («People + Process + Technology»). Хочется верить, что people попали на первое место не случайно. Почему-то когда речь заходит об информационных технологиях (ИТ), мы сразу уходим в технические аспекты, начиная мыслить терабайтами, гигагерцами, мегапфлопами и т. д., а вопрос человеческого фактора как бы должен разрешиться сам по себе. В то же время, на Западе уже давно осознали, что если Вы не уделите достаточного внимания вопросу «человеческих ресурсов», то любая попытка внедрения нового или изменение существующего ИТ-процесса обречена на провал. Итак, если пользователи ПК в вашей компании уже превратились в ваших клиентов и информационные системы больше не рассматриваются как замена калькулятора для работников бухгалтерии, то данная статья — для Вас. Правда, не стоит ждать от нее готовых ответов и рецептов, возможно, предложенная модель не подойдет Вашей организации без соответствующей адаптации, но я надеюсь, что она заставит Вас задуматься, есть ли у Вас «правильные люди в правильных местах» и чем они там кстати занимаются. Хочется подчеркнуть, что в этой статье я попытаюсь описать все функции, которыми занимается ИТ-подразделение, однако я все равно не могу гарантировать, что этот список будет исчерпывающим, потому что он составляется без учета специфики отрасли и формы собственности предприятия.

Еще хотелось бы договориться о терминологии. Под словом «структура», для простоты, мы будем понимать функциональную, а не организационную структуру. Описанные же функции в каждом конкретном случае могут выполняться как одним человеком, так и целым отделом.

Во главе ИТ-структуры в крупных компаниях, как правило, находится Директор по Информатизации (в западных компаниях он обычно называется CIO = Chief Information Officer) — это аксиома, с которой никто, как я надеюсь, не будет спорить. Но вот дальше начинается творческий хаос, так как каждый директор волен создавать ту структуру, какую он считает оптимальной. Я считаю, что настало время задуматься о стратегии развития и дружно зашагать к «идеальному» ИТ-департаменту, где все будет прекрасно.

Небольшое лирическое отступление: существует множество вариантов и подходов к представлению структур, есть даже специальное программное обеспечение, хотя в большинстве случаев Excel или Visio будет более чем достаточно. В данной статье я буду использовать «объемный взгляд». Подобную трехмерную структуру легче всего изобразить в виде куба. Лично мне крайне импонирует именно трехмерный подход, т. к. кубическая визуализация позволяет объединить в единую картину то, что обычно приходится изображать в нескольких различных срезах. Однако к вопросам кубизма мы вернемся чуть позже.

На втором уровне ИТ-департамент распадается на 3 ветви. Две главные ветви, «Решения» (IT Solutions) и «Поддержка» (IT Services) мы рассмотрим подробнее позднее, на третьем уровне детализации. А сейчас посмотрим на содержимое среднего прямоугольника. Эти функции крайне редко реализуются в рамках ИТ-подразделений компаний в России.

Подразделение «Финансы и Контроль» (англ. F&C = Finance and Control) отвечает за формирование и соблюдение бюджета по ИТ. Кроме того, это подразделение отвечает за «управление затратами ИТ» (IT cost management) в масштабах всей организации. Т. к. в рамках организации ИТ-подразделение относится в большинстве случаев к «центру затрат» (cost center), то правильное распределение затрат поможет точнее оценить слабые и сильные места нашей ИТ-структуры, что в дальнейшем позволит принять взвешенное решение об аутсорсинге части сервисов. Хорошей практикой также будет расчет «возврата инвестиций» (англ. ROI = Return Of Investment) от различных проектов. Во многих западных компаниях такие расчеты могут стать ключевым фактором принятия решения о внедрении того или иного проекта в жизнь. Расчет ROI — это тема отдельной статьи, а в рамках данного материала хотелось бы отметить, что подобный расчет — задача более чем нетривиальная и требует специального (предпочтительно экономического) образования. Наконец, не стоит забывать о таком понятии как «полная стоимость владения» оборудования и других ресурсов, которое включает не только стоимость собственно приобретения, но и затраты на последующее обслуживание (англ. TCO = Total Cost of Ownership).

«Отдел кадров» (англ. HR = Human Resources). Лозунг Кадры решают все благополучно ушел в небытие вместе с социализмом. И все же люди, работающие в сфере ИТ — это особый сорт людей, требующий своего подхода. Я ни в коем случае не предлагаю создавать отдельную кадровую службу для департамента ИТ, просто кадровые работники должны на себя взять планирование развития специалистов по ИТ в профессиональном плане, а также их карьерного роста. Если ИТ-департамент невелик, можно передать эти функции в существующую кадровую службу компании, главное, чтобы работник, который курировал это направление, был в курсе специфики ИТ и представлял себе способы работы с людьми, занятыми в этой сфере. Разумеется, эта работа также должна относиться в затраты ИТ-департамента и оплачиваться, мы же помним, что за все рано или поздно надо платить :-).

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

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

И замыкает наш список «правых рук» функция правового сопровождения или другими словами юрист(ы). Нет ничего удивительного, что в наш век информационным технологиям посвящены целые разделы юриспруденции, а вопросы лицензирования программного обеспечения, информационной безопасности и пр. могут оказаться не по зубам Вашей «стандартной» юридической службе. Особенно актуальным юридический аспект может быть в том случае, если Вы активно занимаетесь разработкой программного обеспечения (ПО). Если у Вас нет желания потом решать в суде вопрос собственности на ПО, которое разрабатывал Ваш программист в рабочее время, оплачиваемое Вами же (работодателем), то имеет смысл крайне внимательно отнестись к составлению трудового договора, а также различных «соглашений о неразглашении». Думаю, Вы легко придумаете еще множество вопросов, в которых Вам может понадобиться помощь квалифицированного юриста в этой достаточно новой сфере юриспруденции.

Техническая поддержка в сфере ИТ (IT Services)

После того, как мы посмотрели на вспомогательные (но от этого не менее важные) функции нашего «идеального» ИТ-департамента, самое время уделить внимание его основной функции — собственно поддержке (IT services). Основную задачу этого направления деятельности я бы сформулировал так: «Обеспечение единого, высокого уровня технической поддержки в сфере ИТ по всей организации в режиме 24/7 с гарантированным временем ответа на любой запрос по ИТ и «прозрачностью» пути его решения». Иными словами, любой пользователь должен иметь следующие возможности:

1. знать «права и обязанности пользователя в сфере ИТ»
2. обратиться к службе поддержки любым удобным для него способом
3. получить информацию о гарантированном времени получения ответа
4. проверить статус запроса и узнать, кто занимается решением его вопроса
5. пожаловаться на несоблюдение «прав пользователя»

Вот и появился обещанный куб. Не пугайтесь, сейчас я подробно изложу содержимое каждого измерения, а ниже будет приведена «модель оказания поддержки».

Сначала рассмотрим первое измерение куба. Пожалуй, именно оно определяет рамки и содержание предоставляемой поддержки.

Управление поддержкой в сфере ИТ (ITSM = IT Service Management). Ключевым элементом этой категории является менеджер по работе с клиентами (Help/Service Desk), который играет роль единой точки входа для любых (!) запросов от конечных пользователей, попадающих в сферу деятельности отдела. Еще совсем недавно такой менеджер был первым и единственным уровнем взаимодействия с заказчиком, но сейчас уже имеет смысл говорить о наличии еще одного канала взаимодействия или «нулевого уровня», так называемом e-Support. Такого рода «самообслуживание» стало возможным в результате активного развития новых средств коммуникации, таких как: корпоративные порталы, IVR (Interactive Voice Response), SMS, WAP, электронная почта и пр. Описание работы этого менеджера выходит за рамки данной статьи, однако я уверен, что вам не составит особого труда найти специалистов и материалы по построению подобных сервисов. В то же время хотелось бы отметить, что, что менеджер по работе с клиентами — лицо Вашего ИТ-департамента, и Ваш имидж во многом зависит именно от его работы.

Разработка ИТ-платформ. Данное подразделение отвечает за выбор и разработку стандартных продуктов, их конфигураций и методик использования. К таким продуктам чаще всего относят: образы (images) для персональных компьютеров и серверов, создание автоматизированных сценариев инсталляции ПО (packaging), выбор моделей и конфигураций аппаратного обеспечения, топология и требования к ЛВС, написание инструкций для персонала. Все вместе это можно объединить такими понятиями как стандартизация и унификация.

И вот сейчас самое время для лирического отступления №2. Очень часто в борьбе за свои права пользователи забывают о своих обязанностях. Однако чтобы обеспечить гарантированное качество обслуживания, необходимо максимально сократить количество моделей и конфигураций аппаратного и программного обеспечения. Таким образом, права пользователя на покупку и установку нестандартного «софта и железа» должны быть ограничены, а наличие у пользователя нестандартного ПО может стать причиной отказа в осуществлении поддержки вообще или существенном увеличении времени обслуживания. В идеале в любой фирме должна быть официальная, публично доступная «конституция» (англ. policy) пользователя.

Сопровождение инфраструктуры ИТ. В данном контексте под инфраструктурой обычно подразумевают все программно-аппаратные комплексы, за исключением оборудования конечных пользователей и ЛВС. Вычислительные, дата, сетевые и операционные центры должны быть максимально централизованны, обеспечены высококвалифицированным персоналом и средствами отказо- и катастрофоустойчивости. Идея централизации восходит еще ко временам мейнфреймов (mainframe) и в очередной раз история повторяется. В эру дефицита профессионалов и относительной доступности каналов связи с высокой пропускной способностью значительно проще сконцентрировать вычислительные мощности, тем самым максимально облегчив возможность развертывания филиалов и отделений, обеспечив Вашей компании максимальную гибкость и свободу действий. И хотя окончательное решение вопроса вопрос «централизация против децентрализации» еще впереди, уже сейчас заметна тенденция к централизации инфраструктуры.

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

Подразделение поддержки внедрения проектов отвечает за переход от стадии разработки какого-либо проекта к этапу его ввода в эксплуатацию (пуско-наладка, англ. release to production). Его основная роль — это гарантировать, что все сервисные службы готовы к эксплуатации и поддержке данного проекта в полном объеме, т. е. проект становится стандартным в «портфеле» продуктов и поддержки. Обычно подразделения поддержки внедрения формируются из проектных команд, занимавшихся разработкой концепции и технической реализацией проекта или программы.

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

Для обеспечения эффективной работы сервисного подразделения необходима соответствующая технологическая архитектура, а затем ее постоянное совершенствование и внедрение новых средств и систем автоматизации работы. Например, к таким системам можно отнести следующие системы автоматизации: Remedy, HP OpenView, IBM Tivoli и другие. Иными словами, технологическая архитектура — это инструментарий эффективной работы поддержки.

Вам придется решать, где и какие функциональные блоки будут расположены физически, что может быть совсем не таким очевидным, как кажется на первый взгляд. И хотя еще ни одна российская компания не созрела для того, чтобы расположить свой IP Call Center в Бангалоре (Индия), как это делают многие транснациональные корпорации, в масштабах России вопрос географической гетерогенности тоже вскоре будет более чем актуален.

ИТ-решения (IT Solutions)

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

Грань Application Units во многом схожа с предыдущей, с той лишь разницей, что в ней собрано ПО собственной разработки. Некоторые программные продукты, производимые этой структурой, могут быть предназначены для внешних клиентов и продаваться в составе продуктов Вашей компании. Однако если по количеству сотрудников отдел «ИТ-решений» в крупной корпорации порой соответствует небольшой специализированной компании, занимающейся разработкой и производством ПО (software house), то по качеству разработок практически всегда ей уступает. Обычно это связано с несоблюдением технологии производства ПО и отсутствием таких функций как: «контроль качества» (Quality Assurance), методология, документирование и некоторые другие.

А для того, чтобы разработка велась структурированно и согласованно, необходима координационная служба (Program and Portfolio Support), которая будет следить за соблюдением стандартов, методологии и приоритетов, а также отвечать за сопровождение процесса создания ПО.

От автосервиса к дому моды

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

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

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

[ Примите участие в обсуждении статьи ]

Об оргструктуре и бюрократии

Здравствуй, хабрасообщество.

Не так давно [около года — именно столько времени пролежала статья «в столе»] сидели мы с товарищем и думали за вопросы организации ИТ-компании. В реально большой ИТ-шной компании мы не работали, вся жизнь прошла в ИТ-подразделениях организаций, для которых ИТ — не основной вид бизнеса. Так что, хотя об организационной структуре мы представление имеем, с деталями её применения к приличных размеров конторе, чья жизнь — реализация и сопровождение софта, мы не знакомы.

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

Введение

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

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

Для начала распишем, что должна делать организация.

1. Написание техзадания по списку техтребований и согласование их с заказчиком;
2. создание полноценной технической документации (так как мы ориентируемся на последующее сопровождение проектов);
3. проработка методологического и математического обеспечения;
4. разработка архитектуры решения;
5. создание софта;
6. тестирование;
7. внедрение;
8. сопровождение.

Описание структуры

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

Такому объединению есть несколько причин:

1. Для отдела тестирования и технического документирования:
   • интеграционное тестирование фактически проверяет программу на соответствие спецификации, т.е. техническому проекту;
   • правильно определённая методика выпускного тестирования выявит не только фактические, но и логические ошибки — то есть когда программа не падает, но результат отличается от спроектированного;
   • написанный софт выглядит как чёрный ящик, что позволяет абстрагироваться от его внутренностей;
2. Для отдела внедрения и сопровождения:
   • налаживаются контакты представителей техподдержки и представителей заказчика, так как внедрение и сопровождение «в одном флаконе»;
   • «нулевое внедрение» производится на площадке тестировщиков, что позволит обкатать различные сценарии установки и получить боевой опыт дома.

Для такой схемы есть ещё одна причина, которая будет рассмотрена ниже.

С разработкой всё проще, есть отдел разработки системного и прикладного ПО, отдел веб-технологий, и выделен (так как большой объём работы с БД) отдел работы с БД.

Что касается разработки техзадания и заключения договоров — это типичные такие менеджеры, которые работают по проектному принципу с задачей «договориться с заказчиком, выдать задачи исполнителям, и следить чтобы всё было по графику». Директор наверняка будет с нетерпением ждать этих орлов в кабинете каждый отчётный период и ни за что не делегирует возможность дать им разгон своему заму.

Есть ещё пара пунктов, с которыми не совсем понятно. Это проработка математического обеспечения и разработка архитектуры софта.

Задача отдела матобеспечения — сформулировать методики, написать формулы, проработать методологию бизнес-процессов у заказчика. Этакий пул экспертов, досконально разбирающийся в теме, готовый дать решение по любому концептуальному вопросу.

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

Обе задачи не относятся ни к производственной, ни к операционной деятельности. Скорее, это некие отделы НИР, которые смотрят вперёд, собирают оптимальные решения, применяют их на практике и руководят разработкой.

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

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

Тут требуется сделать небольшое лирическое отступление.

Давайте быстренько автоматизируем это!

В 2007м году поступило совершенно неформализованное задание «сделать им хорошо». После выяснения, кому именно и как именно надо «сделать хорошо», родился здоровый документ, в котором было всё это написано. Путь согласования документа, прямо скажем, был тернист и извилист, и учитывал интересы всех. Сейчас я понимаю, что, если это всё написать, получилась бы если не 1С, то что-то похожее; тогда мне это было совершенно неочевидно. «Ладно, — подумал я, — фигня, где наша не пропадала!..» — и сел за работу. Месяца через четыре был готов какой-то прототип, и я поехал его сдавать.

Выяснилось, что всё не так: то неудобно, это неверно, тут вообще бизнес-процесс поменялся… ну, в общем, я думаю, все могут представить эту ситуацию. Крякнув, я снова сел за работу.

Через несколько итераций (и после отвлечения на написания регламентов и изменение концепции) программа была принята, а ещё через несколько месяцев внедрена и встала на боевое дежурство. К тому времени вследствие изменения внутренней структуры организации, изменения приоритетов и т.п., 75% написанного изначально ТЗ потеряла актуальность. Но это, на самом деле, не проблема. Проблема в том, что в погоне за скоростью написания софта все эти изменения не документировались. Соответственно, в настоящее время (да-да, оно до сих пор работает, что удивительно) софт может сопровождать ровно один человек, то есть я. А так как договора на сопровождение нет, то писать мне какие-то документы резона никакого нет (да и сам софт на дельфях). В результате раз в год они мне звонят, я правлю какие-нибудь мелочи сроком не более чем на неделю, и забываю об этом софте ещё на год.

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

Возвращаясь к оргструктуре

Итак, в нашей идеальной структуре потенциальные ошибки, подобные описанным в предыдущем пункте, должны будут фильтроваться дважды — при передаче документа от техписателей и при передаче софта внедренцам. Каждый срыв срока — предмет для разбирательства глав департаментов и менеджера проекта. Это совершенно чёткие вехи, от которых зависит проект. Более того, процессы с каждой стороны вех контролируются разными департаментами, что позволяет избегать размытия ответственности и передачу «на честном слове».

Производственная часть есть. Осталось добавить финдиректора, отдел АХО, юристов и эйчарню, и оргструктура нашей ИТ-компании готова.

О составе проектной команды

Состав формируется как «представители отдела разработки под предводительством крутого специалиста из отдела проектирования ПО при поддержке методолога из группы матобеспечения под чутким контролем менеджера старательно удовлетворяют заказчика». Так что такой подход позволяет использовать не только «классический» водопад, но и гибкие технологии, где менеджер выступает как product owner. Единственно, это требует небольшого оверхеда на обратную связь с отделом технической документации, что не должно очень уж сильно тормозить процесс.

Единство и борьба противоположностей

Исходя из пути проекта в нарисованной организации, а также разделения обязанностей на развитие, разработку и поддержку, получаем интересные следствия о личностных качествах руководителей этих отделов:

1. Зам. директора по развитию — увлекающийся, с широким кругозором, всегда стремится к новым знаниям, новым технологиям. Его департамент почти всегда работает в чистый минус, но идеи, рождающиеся в нём, дают пищу остальным отделам, двигая компанию вперёд. Убеждённый оптимист.
2. Зам. директора по операционной деятельности — осторожный, опытный работник, видящий всё на три шага вперёд, и потому скорее пессимист, хотя чаще всего обзываем ретроградом. Его департамент приносит стабильный, но небольшой доход, и он не хочет, чтобы из-за новых веяний инноватора всё пошло прахом.
3. Зам. директора по производству — самый уравновешенный из всех, первый заместитель. Служит балансиром между инноватором и традиционалистом, придерживается эволюционной теории. Он приносит большую часть прибыли, обеспечивая всех бонусами, а директора — новой машиной, а потому спокоен.
4. Финансовый директор — считает доходы и расходы и время от времени мягко напоминает инноватору, что если так пойдёт дальше, то директор не получит свой ежегодный порш кайен, а все остальные — свой бонус.

Заключение

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

Выбрать метод управления ИТ-проектами — Kanban, Scrum или Agile — важная задача для любого руководителя. Но важны и детали: как правильно выстроить коммуникацию между сотрудниками, особенно в условиях наступившей тотальной удаленки, какие программы помогут организовывать совещания, обмениваться кодом или следить за ходом выполнения проекта, а также как сохранять мотивацию у сидящих дома разработчиков. «Хайтек» выяснил у руководителей российских ИТ-компаний, как они управляют своими командами, как осуществляется коммуникация между сотрудниками и какие сервисы делают распределение задач проще.

Как устроены матричные структуры ИТ-компаний

Андрей Жикин, директор по информационным технологиям Yota

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

Мы стараемся удерживать максимально плоскую структуру, поэтому 24 отдела ИТ-департамента поделены поровну: одна часть находится под руководством директора по информационным технологиям, а другая — в подчинении директора по развитию и эксплуатации ИТ-систем.

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

Организовать коммуникацию нам помогают несколько инструментов:

• На верхнем уровне помогает канбан портфеля проектов — доска, на которой в онлайн-формате регулярно синхронизируются задачи по ИТ, бизнесу, проработке проблем и прочим кейсам. Этот инструмент значительно повышает прозрачность, позволяет вовремя находить слабые места, а также выравнивать ожидания всех участников.
• На уровне проектного управления — Big Picture в Jira. Это инструмент для структуризации задач и объединения их в проекты, визуализированные диаграммами Ганта.
• На техническом уровне — описания в виде контрактов по API. Каждый проект перед стартом реализации получает описание, которое команды должны учитывать в рамках производства. Это упрощает коммуникацию на стадии разработки, так как ожидаемый результат описан достаточно четко и понятно.
• На уровне общих коммуникаций мы используем MS Teams как средство видеосвязи и «ТамТам» как мессенджер для кросс-функционального общения. Также взаимодействие сотрудников происходит в корпоративной группе во «ВКонтакте», через почтовые рассылки и реже через физические письма.

---

Kanban — система разработки, наглядно показывающая, что необходимо производить, когда и сколько. Реализует принцип «точно в срок», способствующий равномерному распределению нагрузки между работниками. При данном подходе весь процесс разработки прозрачен для всех членов команды, а задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу.

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

---

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

● MS Office 365 — отличное облачное решение для основных корпоративных потребностей;

● Jira — для структуризации задач;

● Confluence — база знаний;

● Trello/Miro — доска для Канбана.

Для управления проектами мы используем микс водопада и Agile. Например, Kanban используется как для внутренней работы команды, так и для управления портфелем проектов. Этот инструмент применяется также на уровне топ-менеджмента для внедрения глобальных изменений в компании. При этом для сохранения прогнозируемости и управляемости производства используются классические инструменты с диаграммами Ганта.

Микросервисная архитектура: каждому продукту своя команда

Игорь Калинин, основатель компании TWIN

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

Всего в штате компании 34 специалиста: большая их часть занимается разработкой, но в команде также есть тестировщики и Scrum-мастера, которые ставят задачи и контролируют их выполнение. В целом, Scrum — один из главных рабочих инструментов, но не единственный. Так, DevOps-команда и часть телефонистов используют Kanban. Мы стараемся комбинировать разные продукты, чтобы максимально эффективно организовать работу. Для коммуникации в команде используем одновременно и Telegram, и Slack, поскольку там удобно работать с кодом. А переговоры проводим в Google Meet.

В TWIN установлены довольно строгие правила отбора специалистов: отдаем предпочтение разработчикам senior-уровня и редко берем джуниоров. Большая часть команды — 80% — это старшие специалисты. Они же выступают в роли наставников для новичков, благодаря этому новый сотрудник быстрее прокачивает навыки — он одновременно обучается и тут же решает реальные рабочие задачи. Это большой стимул для роста и развития.

Деление на индустрии: точки соприкосновения и неформальное общение

Эдгарс Пузо, генеральный директор Atos в России и СНГ

Мы реализуем переход компании на организационную структуру по индустриям. В процессе перехода было выделено шесть индустрий: финансовые услуги и страхование, здравоохранение, промышленность, государственный сектор, ресурсы и услуги, телекоммуникации и СМИ. Кроме того, в компании развиваются такие технические направления, как Microsoft, SAP, Digital Workplace, Cloud и другие, которые закрепляются в практики. В России формат деления на практики на данный момент находится на фазе становления, но на глобальном уровне он уже успешно работает.

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

Отдельное внимание мы уделяем неформальному взаимодействию сотрудников. С этой целью в компании регулярно проводятся корпоративы и мероприятия по тимбилдингу. Учитывая большое количество сотрудников (свыше 1 500), сложно организовать устойчивую коммуникацию между командами, но мы находимся в постоянном поиске форматов взаимодействия и успешно применяем их на практике.

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

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

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

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

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

Для мотивации сотрудников существует программа Accolade — система признания внутри компании. Несколько раз в год награждаются сотрудники, которые достигли выдающихся результатов сверх стандартной работы. В программе предусмотрены разные уровни наград в зависимости от достижений: bronze, silver, gold. Иерархия должностей позволяет каждому сотруднику увидеть, в каких направлениях можно расти. А корпоративная культура, включающая в себя мероприятия, конкурсы, призы, а также всевозможные активности на платформе для геймификации, позволяет мотивировать сотрудников на более неформальном уровне.

Agile-команды: свобода принятия решений и открытые синки

Евгения Христолюбская, руководитель направления по работе с сотрудниками «Учи.ру»

У нас матричная структура компании: есть вертикали основных специализаций и гибкие продуктовые команды. Таких команд — около 15.

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

Такие команды обладают достаточной свободой принятия решений и (иногда) собственным бюджетом. Каждая развивает собственный «участок» платформы. Основная коммуникация ведется в почте и в Slack. Когда наша компания перешла на удаленку, мы приобрели платную версию, которая позволяет совершать звонки и хранит всю историю переписки. Для видеозвонков мы используем Zoom и Google Meet. Кроме того, на удаленке организовывать встречи стало удобнее: коллеги стали доступнее, лучше соблюдается тайминг и даже большие встречи организовывать теперь легко.

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

Для планирования и отчетности команды используют классические для ИТ-отрасли инструменты Jira, Confluence, Figma и Notion. В компании принято ежеквартальное планирование, и в начале каждого квартала цели и задачи каскадируются от руководителей и вносятся в таск-трекер. Мы не используем трекеры рабочего времени и прочие программы для слежки за сотрудниками.

Особенное внимание в «Учи.ру» мы уделяем мотивации и обучения сотрудников. Для этого используются несколько инструментов:

• Регулярные АМА-сессии для сотрудников на YouTube (AMA, Ask Me Anything, от англ. «спроси меня о чем угодно» — «Хайтек»).
• Обучающие, поддерживающие, развивающие материалы на корпоративном портале.
• Регулярные email-рассылки с рекомендациями и предложениями по досугу и обучению.
• Квизы, фотоконкурсы и онлайн-корпоративы, организация активностей на праздники.
• Митапы в рамках программы #УЧИвУЧИ.
• Еженедельная сводка новостей держит сотрудников в курсе того, что происходит в компании и разных отделах.

Команды с уникальными компетенциями в разных частях страны

Константин Коногорский, заместитель директора по разработке ПО ВИСТ (входит в ГК «Цифра»)

В нашей компании ресурсы сильно разделены по территориальному принципу. У нас есть два крупных отдела в Москве и Кемерове, которые параллельно работают над единым продуктом — АСУ ГТК Карьер. У этих глобальных команд есть руководители территориальных подразделений. Но в каждое из подразделений входит порядка 15 человек, что много для одного руководителя, так что каждая из этих крупных групп разбита еще на три группы по пять человек. Отдельная маленькая группа способна взять на себя набор полноценных бизнес-задач и выполнять их за спринт. Компетенции этих команд в целом одинаковые.

Также есть команды с уникальными компетенциями: например, команда бортового ПО из шести человек, которые специализируются исключительно на программировании прошивок под «железо». В отдельные команды выделены DevOps и тестировщики, которые централизованно покрывают потребности команд, разрабатывающих основной продукт.

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

Из сервисов для коммуникации мы используем Microsoft Teams, Jira и корпоративную почту. Но на самом деле это просто наши корпоративные инструменты для общения. В действительности же люди пользуются любыми инструментами, через которые им удобно вести коммуникацию.

Для распределения задач между командами и внутри команд мы используем современные Agile-методологии. Команды разработки работают по Scrum, а команды тестирования и DevOps — Kanban, в силу их немногочисленности.

Владельцы продукта готовят задачи для разработки на каждый спринт, и команды разбирают их исходя из приоритетов и доступных ресурсов на грядущий спринт. Все это дело мы ведем в Jira и контролируем при помощи кастомной программы, которая выгружает и агрегирует в централизованном пространстве все необходимые данные из Jira. В результате любой сотрудник любого отдела компании (от уборщицы до генерального директора) в любой момент могут посмотреть, успевает ли разработка в сроки или нет, какая динамика у какой команды из спринта в спринт, кто допустил больше багов и многое другое. Мы строим разработку на принципах полной открытости для всей компании.

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

---

Читайте также:

Выяснилось, почему ученые называют пригодными для жизни не те планеты

Создана первая точная карта мира. Что не так со всеми остальными?

На них держится Вселенная: как работают четыре главные силы природы