Команда-трансформер

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

Start Up

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

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

Бурное развитие

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

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

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

Вопросы хелпдеска

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

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

Отметим, что к сотрудникам, которые набираются в подразделение сlient helpdesk, предъявляются требования хорошей коммуникации, зачастую со свободным владением иностранным языком. Понятно, что это отсеивает сразу 90-95% кандидатов.

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

Создание полноценной команды инфраструктуры

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

Если в составе ПО компании насчитывается более 10 баз данных, то назревает необходимость создания подразделения администраторов БД. Такие админы примыкают либо к подразделению разработки, вливаясь в него, либо инфраструктуры (в этом случае уже дистанцируясь от объяснений с разработчиками по вопросам индексации таблиц). Обычно это достаточно редкие и дорогие специалисты, которые не всегда нужны как полноценный штат, поэтому берутся аутсорсеры, которые могут ухаживать за сотнями баз данных далеко не в одной компании…

Кроме того, в период построения инфраструктуры и систем, развития и постоянных изменений становится очень востребован еще один член команды – «мониторинг». Однако именно в это время вроде как совсем не до него – нужно быстрее запускаться и работать, а это как-нибудь потом, потом…

Разработка

Трансформация команды разработки в этот период может произойти наиболее глобальная. От одного-двух универсальных сотрудников, которые, поговорив с пользователями и поняв, что нужно, тут же могут сделать изменение в системе, протестировать, показать заказчику, поставить на бой, – до команды, закрывающей полный цикл разработки, включая постановку задачи, бизнес-анализ, BRD, FSD, (нужно оставить, или заменить на «написание кода»), внутреннее тестирование (QA), пользовательское тестирование (UAT), техническую документацию, передачу на сопровождение. При этом команды, которые ведут сокращенный и полный цикл разработки, могут работать параллельно, разделяя или передавая задачи.

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

Стабилизация

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

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

Мониторинг

В компаниях, которые продают онлайновые услуги (вендоры, дата-центры, биржевая торговля - это high frequency trading), мониторинг становится таким же важным сервисом, как и все остальные. На него выделяется отдельное подразделение, настраиваются всевозможные системы мониторингов, сигналов. Ставятся как минимум большие экраны либо собираются иконостасы из мониторов. Важное значение придается визуализации. Показатели latancy выделяются разными цветами, отключения линий и оборудования – разными звуками. А чтобы заинтересовать админов, на экране двигается девушка, озвучивая приятным голосом алерты. Но с таким функционалом хорошо справляются именно сотрудницы, внимательно и скурпулезно отслеживая события.

Проекты

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

Процедуры, политики, инциденты, отчетность

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

Документооборот

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

Деградация или консервация

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

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

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