Контакты

ИТ: черный ящик или прозрачный процесс?

CNews - 4 октября 2010

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

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

CNews: Почему задача определения эффективности работы ИТ-службы так сложна для российских компаний?

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

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

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

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

CNews: Как компания может реализовать комплекс мероприятий по повышению эффективности ИТ-службы?

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

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

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

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

CNews: Каким образом следует выстраивать взаимодействие между подрядчиком и заказчиком?

Юрий Овчаренко: Характер взаимодействия зависит от задач компании, динамики бизнеса, степени его зависимости от ИТ. Пока в России чаще встречаются две модели. Первая — сотрудничество по принципу fixed cost (стоимость и сроки проекта оцениваются и фиксируются до его начала). Вторая модель — аутстаффинг специалистов подрядчика по принципу time and material (заказчик оплачивает фактическое время, потраченное командой на проект).

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

В случае с моделью time and material (T&M) эти риски исключены, так как стоимость проекта рассчитывается в зависимости от объема выполненных работ и ставок специалистов. Плюсы этой модели — в гибкости, в возможности корректировки содержания и сроков проекта с учетом новых требований со стороны бизнес-заказчиков. T&M-проекты нередко основываются на методологии Agile: разработка разбивается на небольшие по времени итерации (от недели до месяца), в рамках которых создается «кусочек» функционала (при этом предоставляемое заказчику решение является вполне рабочим). Затем происходит переоценка приоритетов разработки — это обеспечивает быстроту реакции на новые запросы бизнеса. Поэтому модель хорошо подходит динамичным компаниям, где каждый новый день может принести потребность в новых функциях систем. Минусы модели — в возможном желании подрядчика затянуть проект и необоснованно «раздуть» оплачиваемые человеко-часы, что приведет к серьезному росту стоимости. Кроме того, некоторые аутсорсеры под T&M маскируют простой аутстафинг — предоставление команды специалистов по принципу «отдал и забыл». В этом случае заказчик вынужден самостоятельно разбираться с переданными ему специалистами, заботиться о качестве их работы и решать возникающие проблемы.

Получается интересная ситуация: при выборе модели fixed cost большая часть рисков ложится на исполнителя, при выборе time and material — на заказчика. В свое время в западных странах удалось найти компромисс: им стала модель выделенных центров разработки. Она предполагает разделение рисков за счет выполнения части проектов для заказчика по фиксированной цене и части — по time and material, а также за счет взаимозависимости аутсорсера и заказчика. Подрядчик с учетом потребностей клиента формирует команду специалистов и создает на своей производственной базе инфраструктуру для ее работы. Центр занимается выполнением проектов только для данного клиента. Тем самым аутсорсер попадает в зависимость от заказчика, поскольку при разрыве отношений у него на балансе остаются специалисты и инфраструктура центра, а их далеко не всегда удается быстро переключить на другой проект. Но и компания зависит от аутсорсера, так как передала ему функции ИТ-службы по разработке систем. В результате — в плюсе оказываются обе стороны: появляется необходимость ценить партнера и строить с ним прозрачные и взаимовыгодные отношения. Заказчик и аутсорсер в равной степени заинтересованы в достижении хороших результатов и должны работать в единой команде, что приводит к снижению рисков

CNews: Насколько существенна разница между выделением команды специалистов (аутстафингом) и выделенным центром разработки?

Юрий Овчаренко: В случае с центром разработки заказчик получает не только квалифицированных специалистов, но и оптимально выстроенные, сертифицированные производственные процессы, которые охватывают весь цикл разработки, тестирования и поддержки систем. Более того, в предлагаемый «пакет» входят отработанные методологии выполнения проектов, инструментарий для управления качеством, системы для формирования, мониторинга и анализа метрик и т.д. Все эти компоненты позволяют повысить эффективность работы в целом на 15%, при планировании и контроле затрат — на 5-20%, в области тестирования и контроля качества — на 10-30%.

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

CNews: Тем не менее, использование проектного аутсорсинга — это повсеместная российская практика, а организация выделенного центра разработки пока не так востребована. Чем это объясняется, по вашему мнению?

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

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

CNews: Какие факторы при создании центра разработки позволят ему оправдать ожидания заказчика в плане эффективности?

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

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

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

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

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

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

CNews: Как происходит первоначальная передача знаний от заказчика в выделенный центр? Какие еще вопросы обсуждаются в процессе создания центра разработки?

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

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

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

CNews: Важным вопросом для заказчика является стоимость создания выделенного центра: иногда услуги подрядчика стоят дороже услуг собственных специалистов. Чем объясняются подобные особенности ценообразования?

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

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

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

CNews: Как оценивается работа центра с точки зрения повышения эффективности процессов разработки?

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

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

Юрий Овчаренко: Если процессы разработки четко выстроены, если действует система метрик и отслеживается динамика показателей по специалистам, процессам и задачам, то управление ИТ становится более прозрачным. Еще недавно идея создания центра разработки — как одного из способов обеспечить прозрачность и эффективность бизнеса — была малопонятна отечественным заказчикам. Но ситуация меняется: если 2-3 года назад такими вещами интересовались преимущественно западные заказчики, то сегодня мы уже реализуем такие проекты и в России. Опыт высокоэффективных западных компаний начинает привлекать «проактивных» ИТ-директоров, тех, кто задумывается о росте продуктивности работы ИТ-службы и ищет новые практические пути решения этой задачи.

CNews: Спасибо.

Оригинал публикации