Несколько лет аутсорсинговых проектов, в основном в заказной разработке, дают интересный опыт, которым делится руководитель отдела управления проектами Технологического управления Ситибанка Владимир Стасевич.
Intelligent Enterprise: Какова стратегия банка в разделении работ между внутренним ИТ-отделом и внешними поставщиками?
Владимир Стасевич: Мы работаем в крупной международной организации, и большая часть бизнес-процессов поддерживается едиными ИТ-решениями. В России, как и в других странах, где работает Citi, мы внедряем новые технологии, адаптируя их к местным потребностям бизнеса. Это могут быть особенности рынка, особенности регуляции — что угодно, но такие «зазоры» мы должны сгладить и заполнить некими дополнительными ИТ-инструментами. Наша стратегия состоит в том, что мы практически все аутсорсим, своих программистов у нас очень мало. При этом мы придерживаемся жесткой политики качества при выборе поставщиков. Если один поставщик услуг нас перестает устраивать, мы отдаем работу другому, а не пытаемся выполнять ее сами.
Хотя мы стараемся по максимуму покупать готовое ПО, поскольку так дешевле, получается это очень редко. Сложно найти подходящие для наших целей продукты, и доля заказной разработки очень велика, к сожалению. Например, системы Ситибанка не умеют работать с российскими платежами в ЖКХ. Можно купить готовый продукт по обработке таких платежей, но для нас он совершенно избыточен, громоздок, нам из такого продукта нужно‑то всего один или два модуля, все остальное у нас есть и так. Поэтому приходится заказывать софт. Но аутсорсинг мы применяем и в поддержке, и во внедрении тиражных продуктов.
Наши аутсорсинговые проекты мы начали в 2004 г. С тех пор эту модель мы используем все больше и больше, поскольку растет наш бизнес в России, его потребности диктуют и больший масштаб, и более широкую функциональность.
Каковы ваши требования к поставщикам услуг? Каким вы видите идеального поставщика?
Здесь можно выделить два блока: требования к компании в целом и требования к ее сотрудникам.
Что касается фирмы, то, безусловно, это должна быть компания с историей. У нее в портфолио должно быть несколько проектов для разных заказчиков, с каждым из которых работает хотя бы человек десять. Таким образом, всего у подрядчика должна быть как минимум сотня программистов «под ружьем». Мы сами аутсорсим десятки разработчиков по различным проектам.
Фирма для нас — это, прежде всего, ее топ-менеджмент и сотрудники. Руководители могут, например, осознанно инвестировать в новые знания своего персонала, нам это интересно и важно. Нам интересен поставщик, который готов вкладываться в изучение технологий, вообще пока малоизвестных в России, и изучать их именно «под нас». Компания может также инвестировать в необходимую нам инфраструктуру. У нас есть, и довольно жесткие, требования к инфраструктуре: к тестовым средам, к закрытому контуру, в который попадают наши данные, к организации рабочих мест. Их может обеспечить только достаточно устойчивая и состоятельная организация. Способность и готовность поставщика делать такие вещи важна для нас. Те, кто не готов инвестировать в наши отношения, в долгосрочное сотрудничество, нам неинтересны.
Но основное, за чем мы следим постоянно и что выбираем, — это конкретные люди, исполнители. Участникам тендеров мы всегда сначала даем пилотные проверочные задания. Прежде всего проверяем качество аналитиков. Даем пример и просим подготовить документацию по нему, чтобы посмотреть, как в компании вообще поставлено дело. Они применяют к этому примеру свой обычный, типовой рабочий процесс, его качество мы и хотим оценить. Были случаи, когда на простую задачу нам присылали многостраничные документы, громоздкие, избыточные по детализации. Это не годится, такие поставщики сразу отсеиваются. Профессионализм и заключается в том, чтобы сделать ровно столько, сколько надо, — не больше и не меньше. Сертификаты или следования каким‑то формальным стандартам для нас не критичны, важны подход и адекватность сотрудников поставщика, прежде всего аналитиков.
Следующий этап — выполнение пилотного проекта, это работа примерно на полгода. Здесь тоже самое важное — знакомство с исполнителями, особенно менеджерами проекта. И вот так, очень постепенно, если все устраивает, мы наращиваем объем взаимодействия.
У нас есть фиксированные требования к тому, как должны быть организованы работы, как должно идти взаимодействие, и наш стандарт управления проектами распространяется в том числе и на подрядчиков. Это стандарт не жесткий, он действует на уровне здравого смысла: если есть разумные доводы, почему в данном случае не надо делать какие‑то операции и этапы, принятые у нас, — хорошо, не будем их делать. Все идет от задач, мы придерживаемся принципов разумной гибкости, а не жесткой формализации. Возможны любые изменения принятых процессов, надо только понимать, ради чего они требуются. Если подрядчик аргументированно защищает свою позицию — мы меняем порядок действий. Если же довод только такой, что «не хочется», — в этом случае мы отказываемся от сотрудничества.
С точки зрения документации, главное — аналитическая документация, где сказано, что делает данный софт, как именно, для чего, какую бизнес-задачу решает, как участвует в бизнес-процессе, какие есть кнопки и меню, какие действия они инициируют. Есть требования по сути, а не по форме. Код документировать не надо, самая лучшая документация — это сам хорошо написанный код. Сами разработчики составляют детальные технические описания, на уровне отдельных переменных, которые использует определенная подпрограмма. Мы это не используем. Если мы передаем систему другому исполнителю, то эти описания попадут к нему, хотя, скорее всего, и он не станет ими пользоваться. При необходимости другие программисты могут разобраться в том, что написали их предшественники. Самое главное — понимать, зачем все это сделано.
Организуя заказную разработку, вы полагаетесь на внешнюю команду целиком или же практикуете аутстаффинг?
Бывает и то, и другое. Либо мы ищем компанию, подбирающую людей под конкретного заказчика, и говорим: вы умеете набирать людей, сделайте это для нас, но управлять программистами будем мы сами. Либо мы ищем зрелую команду, которая может сделать разработку целиком, «под ключ»: с правильным контролируемым бюджетом, с контролируемым качеством реализовать то, что описано в техзадании. Конечно, в идеале хотелось бы только говорить: «Хочу вот это!» — и получать достойный результат за адекватную цену. Однако на практике постоянно требуется наше вмешательство, контроль, коррективы. Иначе наши ожидания не совпадут с представлениями программистов о «правильном софте».
Компаний первого типа — очень много, и конкуренция между ними велика, а вот исполнителей «под ключ» — единицы. Это настоящие жемчужины, поскольку очень мало кто знает, как вести разработку в целом. Таких фирм не становится больше с годами, и это не только в России, но и в остальных странах. Нашими основными поставщиками услуг в течение нескольких лет являются Epam и «Рексофт».
В связи с этим мы не пытаемся использовать только зрелые команды, мы работаем и с молодыми компаниями, но все же определенный уровень нужен. Они должны быть хороши как инженеры, как «технари», отлично разбираться в ИТ. Необходимо, и достаточно, чтобы на той стороне был нормальный менеджер. К сертификатам PMI это никакого отношения не имеет. По ту сторону стола должен сидеть человек, обладающий достаточными полномочиями для принятия решений, умный, слышащий то, что мы говорим, и применяющий это к своей команде. Если так получается — половина успеха гарантирована.
Нельзя сказать, что это уж совсем редкость, но такие менеджеры проектов подбираются по крупицам. Как и при подборе собственного персонала, пересмотреть надо множество кандидатов, чтобы найти подходящего. Так же и поставщики услуг — выбирать приходится долго. Если же такого человека у команды нет, а мы это сразу увидим в пилоте, то даже нет смысла начинать с ними работать. Процесс не сойдется точно. Если же такой менеджер есть, то он наберет себе и правильных «старших», либо с рынка, либо изнутри. А дальше мне уже неинтересно: я знаю, что правильные старшие построят и правильные команды программистов. За этими двумя уровнями управления на их стороне я пристально слежу: руководитель проекта, account manager и его непосредственные помощники. Они и определяют, как будет развиваться проект. Ни формальные процессы, ни сертификаты — ничто этого не заменит. Все определяют люди.
Как вы организуете внедрения тиражного ПО?
С внедрениями схема совершенно другая. Мы берем аналитиков «он‑сайт», в подчинение к нашим сотрудникам. Смешанных команд практически нет, все «внедренцы» работают под нашим руководством. Если же конкретный человек доказал, что он действительно понимает наши потребности и способен их реализовывать, — отлично, но это уже касается выбора отдельных людей, а не фирм.
Каким образом вы аутсорсите поддержку приложений?
В основном мы стремимся к тому, чтобы поддержку оказывали сами разработчики. Тогда им становится выгодно, чтобы с самого начала система разрабатывалась и писалась хорошо. Причем тут важны не столько деньги, сколько взаимодействие людей: если я писал код, а мой сосед по офису потом его чинит, возможно, ночами, а работаем мы все время вместе, то качество точно постепенно улучшится.
Если речь идет о поддержке «чужих» решений, то поставщик оказывает нам услуги обучения аналитиков, они могут работать у нас или на своей площадке. То есть разработчики, даже тиражного ПО, находят людей, обучают их и готовят для работы с нами, а дальше они уже работают в тесном контакте с нами. У нас есть и своя служба поддержки.
Мы ни одну услугу не аутсорсим полностью. Всегда ряд функций остается за нашими сотрудниками, причем это функции уровня управления. Вторая линия поддержки у нас двухсоставная. Часть выполняется нашими силами, часть — силами разработчиков. Это линия «два с половиной». Наши менеджеры, отвечающие за определенные приложения, покупают себе услугу поддержки: они могли бы делать то же самое с помощью внутренних ресурсов, но дешевле отдать внешним поставщикам.
Дешевле? В российской практике соображения гибкости и скорости исполнения, потребность в уникальной экспертизе обычно выходят на первый план при заказе аутсорсинговых работ, но никак не цена.
Для нас, как для международного банка, каждое рабочее место и каждый сотрудник обходятся дороже, чем для фирм, у которых нет таких систем защиты, безопасности и прочих системных требований. Поэтому нам дешевле привлекать стороннюю рабочую силу. Мы используем дешевые размещения, другие города. Для нас работа с Рязанью, например, и вообще работа в «распределенной» среде привычна, поскольку мы так же работаем с Лондоном, с Индией.
В схемах оплаты мы полностью перешли на «время — материалы», очень редко используем фиксированные тарифы. Это пришло в процессе нашего развития. Сначала почти везде использовали фиксированную ставку, но схема «время — материалы» оказалась дешевле. Ставки меньше, административные расходы тоже, ведь подрядчик подписывается под фиксированную стоимость, только если рамки проекта определены. Как только требуются изменения, исполнители требует новых денег. Эти постоянные переговоры отнимают массу времени и ресурсов.
Поэтому при долгосрочном сотрудничестве с людьми, которым ты доверяешь, такая схема оказывается выгоднее. Фиксированные тарифы нужны, чтобы работу за твой счет делали качественно. Незнакомый разработчик может годами на тебя работать, ты будешь все время платить, а проект не будет завершен. Если же подрядчики известны, то риски снижаются. Когда мы контролируем каждый час, который они тратят, это, конечно, дешевле, проще и удобнее.
