Скопировать ссылку
IT-партнеры и центры компетенций
Управление высокотехнологичной компанией — задача не тривиальная. В IT-подразделениях существует множество вариантов выстраивания связей в командах. Какой из вариантов оптимальный зависит от множества факторов, например, рынка, на котором работает компания, типа продукта, стадии его развития, наличия вендеров и так далее. Разработка, тестирование и внедрение ПО — долгий и сложный путь, который может занимать многие месяцы и требует от команд слаженности, наличия серьезного, но не избыточного, пула компетенций, а от управленцев — кроме глубокого погружения в технологии и знания проекта, еще и умения ротировать кадры. Чтобы проект не замирал в ожидании специалистов с требуемыми компетенциями, но при этом его экономика сходилась, необходимо заранее выстраивать структуру команд.
IT-подразделение любой крупной организации, бизнес которой зависит от цифровых решений, должно быть с одной стороны организовано так, чтобы команды были структурированы вокруг определенного набора постоянных задач и тем, с другой — обладать достаточной гибкостью, так как задачи и темы постоянно возникают новые. Структура должна быть достаточно иерархична, чтобы действовать в рамках единого замысла и стратегии, а с другой не слишком раздроблена на отдельные подразделения и забюрократизирована. А еще она не должна представлять собой обнесенную бетонной стеной, рвом с водой и минными полями крепость, которая ощетинилась дулами орудий по отношению к остальной организации. Должна быть обеспечена прозрачность и понятность IT для бизнеса.
В одной из финансовых структур, где я работал, для выполнения этой задачи (обеспечения взаимодействия с бизнесом) мы ввели в штат должность — IT-партнер под бизнес-направления. Сколько направлений у бизнеса — столько и IT-партнеров.
Этих сотрудников можно сравнить с медиаторами, они обеспечивают коммуникацию между финансистами, продуктологами, маркетологами, продажниками с одной стороны и айтишниками с другой. Благодаря IT-партнерам в компании «бизнес»-сотрудники, то есть те, кто обеспечивает клиентский опыт, экономическую эффективность, планирование, продажи, и IT — специалисты, ответственные за разработку продукта, находят общий язык и работают над одними задачами.
IT-партнеры занимаются поддержкой отношений с внутренними клиентами, решением проблем на стыках зон ответственности, планированием IT-работ в рамках отдельного бизнес-направления. При взаимодействии с сотрудниками из бизнес-направлений IT-партнеры предлагают оптимизацию с точки зрения систем. Например, подробно и аргументированно объясняют, как замена одной IT-системы может оказать влияние на бизнес-функционал и принести пользу, зачастую даже не конкретному заказчику, то есть какому-то подразделению, а компании в целом.
Во-вторых, мы выделили команды (трайбы — англ. племя) под ключевые продуктовые направления. Наши кросс-функциональные команды стали работать над продуктовыми или сервисными направлениями. Каждая команда вбирала в себя специалистов всех необходимых профилей для создания продукта под ключ. Тогда как деление сотрудников в департаменты практически всегда происходит по функциональному признаку, так создаются отделы или подразделения маркетинга, финансов, разработки и так далее. Создание трайбов позволяет объединить в одном «племени» сотрудников разных областей из разных департаментов. Специалисты очень разных профилей (бизнес-заказчики, маркетинг, IT, аналитики) получают одну бизнес-цель и работают в одной команде, буквально сидя за одним большим столом. Так повышается эффективность реализации стоящих перед направлениями бизнеса задач.
В-третьих, мы организовали центры компетенций. В целом идея их создания не нова, центры компетенций аккумулируют соответствующие знания и в них происходит поиск способов решения задач. В той или иной степени идею центров компетенций реализовали в советские годы на предприятиях научно-технические, информационные отделы, архивы, группы качества или стандартизации. В случае с поиском IT-решений выделение центров компетенций позволяет обеспечить технологическое развитие и сохранить контроль над кодом систем, что особенно важно для монолитных приложений. Также центры компетенций обеспечивают маневр людьми и решение особо сложных технологических проблем, с которыми не могут самостоятельно справиться команды трайбов.
Помимо появления трайбов, IT-партнеров, центров компетенций, мы выделили devops-службу, что позволило организовать ее работу как сервис для всех команд разработки. Наличие такой службы со своими собственными ресурсами помогает решать задачи формирования и развития devops-платформы, а также планово улучшать тайминги по сборке / развертыванию ПО на всем контуре (и в целом повышать зрелость devops процессов по всем системам организации).
Еще одним, пятым, управленческим решением стало создание отдельной команды под инновации. Это очень важно, поскольку даже небольшая выделенная команда под инновации позволяет привносить в организацию интересные технологические новинки, некоторые из которых в дальнейшем создают большую пользу и генерируют добавленную стоимость продукту. Задачи инновационной команды не решит отдельно взятый трайб или IT-партнер, поскольку они погружены в «текучку» и увидеть ситуацию с высоты птичьего полета не могут из-за нехватки времени и сил.
«Охота на ведьм»
Перестраивая структуру, я столкнулся с рядом стереотипов, на которых хочется остановиться. Одно из распространенных заблуждении — в IT нужны «руки», а не «головы». Поясню мысль.
Некоторые руководители культивируют в компаниях убеждение, что чем меньше менеджеров (то есть выделенных управленцев) и больше специалистов, работающих руками, заняты на проекте — тем лучше. Порой такие идеи приобретают характер «охоты на ведьм» и приводят к тому, что IT-структура, да и не только IT, становится совершенно неуправляемой как раз из-за нехватки сотрудников, обладающих организаторскими способностями. Как ни удивительно, в обычной рыночной ситуации вы не можете собрать «команду высокомотивированных профессионалов», которые еще и самоорганизуются и будут работать без лидера (вы же не гугл и у вас обычно есть серьезные ограничения по ФОТ). Поэтому нехватки управленцев нужно избегать.
Для подразделений разработки мы опытным путем получили показатель 1 к 8, то есть один управленец на восемь IT-специалистов. Эта формула, с одной стороны, достаточно амбициозная и требует от этих самых менеджеров реального таланта и работоспособности, а с другой — позволяет контролировать и изменять процессы при необходимости. Но нужно понимать, что при проведении в компании большого числа реформ, требуется создать наоборот некоторую «избыточность» управленцев, так как этими самыми реформами кто-то должен заниматься не только в свободное от основной работы время.
Во время трансформации IT-структуры у меня как руководителя, а также у акционера возникло резонное желание — протестировать промежуточные результаты, чтобы понять, а в правильном ли направлении мы вообще движемся.
Каждый CEO, только выстраивая новые «нейронные связи» организации, задается вопросом — а насколько они будут эффективны. Один мой коллега как-то сказал: «если CEO начинает задаваться вопросом, а эффективно ли работает его IT, значит доверия уже нет и никакими методами его не восстановишь». Я с этим не совсем согласен. Эффективно ли мы работаем? Как это померять? Вопрос абсолютно справедливый и требующий ответа.
Апологеты agile скажут, что если бизнес вкупе с IT-подразделением приносят прибыль и хорошо окупаются, то значит они эффективны. Но на самом деле это просто подмена понятий. Наличие прибыли совершенно не говорит об эффективности, может просто сейчас так сложилась рыночная конъюнктура.
Чтобы что-то измерять, нужно сначала договориться о единицах измерения. В agile практиках для этого служат story points (грубо говоря, оценка стоимости каждой доработки в абстрактных единицах). Но они не имеют строгого однозначного определения и, соответственно, являются единицами, которыми можно пользоваться только внутри одной команды.
Когда IT-компания или финансовая организация задумываются о том, чтобы все-таки измерить эффективность, «сторипоинты» начинают «объективизировать», то есть пытаются создать универсальную единицу измерения и договориться о правилах их формирования.
Но совсем не обязательно изобретать велосипед, решили мы. И взяли в качестве такой объективной единицы измерения давно придуманные IBM (и применяемые Gartner — американской консалтинговой компанией в области IT) функциональные точки (Fast Functional Points). Эти единицы, с одной стороны, имеют достаточно четкое и однозначное определение, с другой — понятны и вызывают доверие как у бизнеса, так и у IT-специалистов. Они характеризуют объем полезной функциональности, производимой IT-сотрудниками. Научившись считать полезную работу, которую делает IT-развитие в функциональных точках, мы дальше можем замерять как эффективность всего развития в целом и отслеживать уровень улучшения или ухудшения этого показателя, так и отслеживать его по отдельным подразделениям разработки. Аналогично, становится гораздо проще контролировать качество ПО (так как количество дефектов и инцидентов всегда можно померить на базе объективных единиц полезной функциональности). Естественно, на эти показатели уже можно навешивать соответствующие KPI, чтобы сфокусировать сотрудников на достижении конкретных, важных в данный момент времени показателях.
Кстати говоря, установка KPI на повышение эффективности при проведении определенной дополнительной работы с командами (в части выделения им времени и помощи в организации соответствующих мероприятий, а также построения понятных метрик и контролей) позволяет в итоге запустить в рамках блока циклы непрерывного повышения эффективности, когда команды сами начинают вырабатывать оптимизационные мероприятия по улучшению.
Карго-культ
Любое развитие невозможно без финансирования и цифровая трансформация не исключение. Мы приняли решение придерживаться той же логики, что и по общему IT-бюджету, то есть делить его на run / grow / transform, где run — это поддержка текущего бизнеса и операционной деятельности (даже здесь нужны подразделения IT-развития, разработчики / аналитики / тестировщики и прочие), grow — рост возможностей текущего бизнеса, transform — коренные изменения текущего бизнеса или создание нового. Такое распределение позволяет наглядно продемонстрировать CEO, какая часть IT-расходов по сути является инвестициями в развитие компании, а какая тратится на поддержку текущей деятельности. Кстати, у того же Гартнер есть соответствующие метрики, на которые можно ориентироваться, сравнивая расходы своей компании с расходами других игроков в соответствующих секторах.
В целом же наш бюджет складывался из затрат на поддержку текущего ПО, непосредственно на разработку нового функционала и на его внедрение.
В кредитной организации перед CEO всегда возникает вопрос — какая пропорция штатного персонала и аутсорсеров оптимальна. Не миновал он и нас. Однозначной формулы нет — все зависит от конкретных условий в организации. В целом, аутсорсинг обходится дороже, чем штат, но позволяет гораздо быстрее закрывать потребности (100 человек за месяц — легко), гибко реагировать на изменения (сегодня нам нужны эти 20 разработчиков iOS, а завтра уже нет). Мы посчитали разумным соотношение 70 на 30 в пользу штата, где 70% — штатный персонал. Это позволило не слишком переплачивать за аутсорс там, где нужны постоянные команды, но и иметь возможность гибкого перестроения команд и объемов работ по различным направлениям бизнеса в течение года.
Обсуждая изменения в ИТ-структуре в финансовой организации, нельзя не остановиться на любимом многими agile. Дело в том, что многие айтишники предпочитают эту систему, но на мой взгляд, она в банках далеко не всегда оправдана.
Этот подход давно стал эдаким карго-культом (давайте везде его внедрим и наступит счастье всего человечества или одной отдельно взятой компании). Реально же, это один из инструментов, который следует применять там, где он принесет максимальную пользу. По сути, используя agile, вы платите за скорость и гибкость в принятии решений более высокими затратами и более низкой эффективностью (в понимании единицы производимого функционала на один full-time equivalent IT-специалиста). Так где же целесообразно применять agile? На мой взгляд, при разработке новых продуктов и клиентских приложений (где вы можете получить быструю обратную связь от клиента и скорректировать продукт с учетом полученной новой информации) или при высоком уровне неопределенности задачи (непонято, что реально надо сделать). Именно в этих случаях нужна та самая гибкость, которую привносит agile. А если у вас задача внедрить к определенной дате новый формат взаимодействия с ЦБ, ФНС, реализовать требования СБП — то agile скорее избыточен.
***
Рассказав о некоторых особенностях трансформации IT-структуры в финансовой сфере, мы ни в коем случае не претендуем на полноту и комплексность. Это один из опытов, который принес неплохие результаты. И тут стоит понимать, что сами по себе структурные преобразования не сделают организацию ни высокопроизводительной, ни эффективной, ни инновационной, ни прозрачной и гибкой в части ИТ и взаимодействия ИТ и бизнеса. Структурные преобразования — это небольшой первый этап изменений, которые нужно совершить на пути к цели. Но еще нужны правильные люди, которые будут реализовывать преобразования и правильно выстроенные процессы, по которым эти люди будут работать.
