Как «оффшорному разработчику» организовать взаимодействие с заказчиком

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

Опыт привлечения оффшорных разработчиков к реализации проектов в государственном секторе показывает, что им доверяют самые «капризные заказчики»? «Прежде всего, хотелось бы понять – кто  такой «капризный заказчик»? Есть несколько версий трактовки данного термина, - комментирует Любовь Орлова, руководитель дирекции консалтинга и разработки компании «Verysell Проекты». - Во-первых, это может быть действительно требовательный и что называется продвинутый заказчик, который точно знает, что он хочет видеть в результате работы и устанавливает завышенные требования, которые трудно реализовать в конкретной ситуации. Это приводит к рассогласованию позиций и понимания возможностей решения проблемы заказчиком и исполнителем. Во – вторых, заказчик сам плохо понимает вопрос, но подвержен «модным» течениям, поэтому «оффшорное программирование» может в этом случае восприниматься как престижная инновация в процессе создания программного обеспечения».

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

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

Типичный порядок взаимодействия с заказчиком

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

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

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

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

Немаловажную роль играет и то, как вендор строит работу с клиентом при демонстрации ему качества разрабатываемого ПО. Например, министерство обороны США в подобных случаях аттестует подрядчиков по модели технологической зрелости (Capability Maturity Model — CMM). CMM — это стандарт на процесс разработки качественного ПО. К таким стандартам относятся также ISO 9000 и ITIL.

Отдельно стоят методологии по построению качественных процессов. Это - RUP (Rational Unified Process), MSF (Microsoft Solution Framework) и подмножество Agile.

Генеральный директор СUSTIS Владимир Рахтеенко рассказывает: «Мы стараемся максимально осознанно использовать все ценные знания и практики, заложенные в стандарты и методологии разработки. При этом мы стремимся избегать неэффективных бюрократических процедур, которые не приносят пользы конкретному заказчику. В организации проектных команд мы ориентируемся на ценности Agile-методологий, поскольку уверены, что мотивированные группы профессионалов способны творить чудеса. Мы собираем таких людей и даем им возможность самостоятельно искать пути решения поставленной задачи».

Цикл разработки заказного решения

Источник: СUSTIS, 2011г.

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

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

Аутсорсинг и инсорсинг специалистов в команде

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

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

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

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

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