Управление взаимодействием с субподрядчиками при разработке ПО

Хотя практика разработки программного обеспечения на субподряде сегодня является повсеместной, все еще нет четкого описания используемых стандартов и инструментальных средств, а также точного определения новых рисков, возникающих при переходе на эту новую модель разработки. В данной статье анализируются бизнес-мотиваторы и новые проблемы, с которыми сталкиваются компании при переходе на эту модель, а также объясняется, как программное обеспечение, основанное на технологии IBM® Rational® Jazz™, помогает реализовать интегрированную среду для управления совместной работой с внешними поставщиками услуг.

Бизнес-мотиваторы использования субподряда

За последние 20 лет в ИТ-отрасли проявились две важные тенденции:

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

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

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

Согласно Сэхей (Sahay) и др. (см. раздел Ресурсы), разработка ПО на субподряде имеет особенности, выделяющие ее из других видов субподрядных работ в ИТ-области, поскольку она включает в себя физически неосязаемые артефакты, оцениваемые по субъективным свойствам, таким как эффективность алгоритмов, удобство пользовательского интерфейса, производительность и масштабируемость ("дизайн и разработка ПО никогда не заканчиваются").

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

Как показано на рисунке 1, в зависимости от конкретной ситуации в пределах этого спектра компании могут управлять своими моделями разработки ПО по-разному.

Рисунок 1. Спектр различных ситуаций использования субподряда

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

Наемные разработчики, работающие в компании

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

Внутристрановой (onshore) субподряд

Контракты на субподряд заключаются между компаниями внутри одной страны.
 

Приграничный (nearshore) субподряд

Субподрядные работы ведутся в странах с родственной культурой и близким географическим расположением, как у США и Канады или Великобритании и Ирландии.
 

Оффшорный (offshore) субподряд

Для выполнения некоторых или всех бизнес-функций нанимаются внешние организации, находящиеся в далеких странах.

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

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

Термин "субподрядчик" определяется по-разному. Некоторые авторы ввели понятие "фабрика ПО" ("software factory") для ситуации, когда разработка ПО делегируется независимым и высокопроизводительным компаниям.

Быстрое развитие модели разработки ПО на субподряде отвечает главным образом на следующие технические и бизнес-запросы:

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

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

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

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

Преимущества и недостатки субподряда

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

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

• Неадекватное планирование и изменение процедур управления, что может задержать время выхода на рынок.
• Отсутствие руководства выполнением проекта.
• Отсутствие общепринятых стандартов обмена активами разработки ПО между подрядчиком и субподрядчиком.
• Проблемы удаленного подключения к общему репозиторию активов.
• Конфиденциальность интеллектуальной собственности.
• Плохое взаимодействие, вызванное разницей во времени, географической удаленностью, культурными и политическими различиями.
• Дополнительные расходы на поездки и удаленную конференц-связь.
• Расхождения между ожидаемым и фактическим результатом.

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

Многие авторы рекомендуют следовать классической модели CMM (Capability Maturity Model), более полной модели SA-CMM (Software Acquisition Capability Maturity Model), процессам PMI (Project Management Institute), стандартам ISO 9000 или Six Sigma. Самым употребительным в настоящее время процессом является SA-CMM, но на рынке отсутствует четкий стандарт организации эффективной работы с внешними поставщиками услуг разработки программного обеспечения.

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

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

Преимущества использования платформы Jazz для совместной работы

Наличие ясной инфраструктуры и процесса руководства при субподряде является важным фактором повышения прибыльности. В противном случае субподряд может стать малоэффективным и даже убыточным.

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

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

Платформа поставки ПО при совместной работе IBM® Rational® Jazz™ помогает улучшить работу с субподрядчиками и решить описанные выше проблемы.

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

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

Рисунок 2. Назначение платформы Jazz

Jazz основана на архитектурных принципах, полностью отличающихся от принятых ранее подходов. В отличие от монолитных закрытых продуктов прошлого Jazz использует инновационный подход к интеграции, основанный на открытых гибких сервисах и интернет-архитектуре. Программные продукты, созданные на платформе Jazz, используют богатый набор возможностей для командной разработки и поставке ПО. Более подробная информация о платформе Jazz размещена на Web-сайте jazz.net.

Технология Jazz предоставляет четырехуровневую инфраструктуру для управления и совершенствования разработки ПО при взаимодействии с внешними поставщиками, как показано на рисунке 3 и описано в следующих разделах.

Рисунок 3. Четырехуровневая модель платформы Jazz

Уровень 1. Инфраструктура

IBM Rational Jazz обеспечивает базовые инфраструктурные принципы для взаимодействия с удаленными рабочими местами с использованием протоколов http/https, технологии Web 2.0 и сервисов совместной работы в режиме реального времени.

Как показано на рисунке 4, все взаимодействия между подрядчиком и субподрядчиками осуществляются по стандартным протоколам http/https.

Рисунок 4. Уровень 1, инфраструктура Jazz

Уровень 2. Поставляемые активы

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

Рисунок 5. Уровень 2, поставляемые активы Jazz

Уровень 3. Автоматизация разработки

Продукты IBM или других поставщиков, созданные на платформе Jazz или интегрированные с ней, помогают группам разработчиков автоматизировать процесс создания активов разработки ПО. Например, IBM® Rational® Requirements Composer поможет аналитикам в определении и управлении требованиями, IBM® Rational Team Concert™ поможет разработчикам в создании и развертывании активов исходного кода, IBM® Rational® Quality Manager поможет тестировщикам в создании артефактов тестирования в виде контрольных тестов и тестовых сценариев, а такие инструментальные средства, как BM® Rational® Software Architect и IBM® Rational® Developer for System Z®, помогут разработчикам повысить производительность и качество исходного кода. На рисунке 6 показаны различные компоненты, расширяющие функциональность Jazz и способствующие автоматизации процессов на протяжении всего цикла разработки программного обеспечения.

Рисунок 6. Уровень 3, автоматизация процессов

Уровень 4. Руководство и показатели

Технология Rational Jazz и продукты, созданные на базе этой платформы, автоматически предоставляют высокофункциональные информационные панели с отчетами и показателями, обновляемыми в режиме реального времени. Это помогает и подрядчикам, и субподрядчикам управлять состоянием и продвижением проектов разработки в режиме реального времени, как показано, например, на рисунке 7.

Рисунок 7. Уровень 4, руководство и показатели

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

Таблица 1. Как Jazz снижает риски и затраты перехода на субподряд

Заключение

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

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

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

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

• Настройка шаблона процесса в Rational Team Concert для управления процессом разработки ПО с внешними поставщиками сервисов.
• Применение Rational Quality Manager для управления фабрикой тестирования.
• Применение Rational Requirements Composer для определения и управления требованиями в модели субподряда.
• Использование оперативных и бизнес-показателей для мониторинга и оценки разработки ПО на субподряде.