«Открытые системы» , № 07, 2006 189 прочтений
Разработка требований: уроки офшорного аутсорсинга
По оценкам аналитической компании Gartner, за последние годы программные проекты претерпели ряд изменений под влиянием расширяющейся глобализации разработки ПО [1].
По оценкам аналитической компании Gartner, за последние годы программные проекты претерпели ряд изменений под влиянием расширяющейся глобализации разработки ПО [1]. С развитием аутсорсинга отношения между заказчиком и подрядчиком развиваются в направлении сотрудничества между многочисленными организациями, расположенными вдали друг от друга. Работая в компании, обладающей огромным опытом оказания ИТ-услуг в глобальном масштабе, мы неоднократно сталкивались с особенностями разработки требований в условиях глобализации процессов разработки ПО. Разработка требований — наиболее важная стадия программного проекта [2, 3], от ее результатов во многом зависит успех проекта в целом.
Проблемы разработки требований, связанные с географической распределенностью процессов разработки, освещаются в целом ряде исследований [4-7]. В данной статье основное внимание мы уделяем проблемам, обусловленным отношениями офшорного аутсорсинга между заказчиком и подрядчиком. На основе собственного опыта участия в реальных проектах, а также рекомендаций, почерпнутых из литературы, мы выделяем факторы успеха и предлагаем прогрессивные методы решения проблем, возникающих при разработке требований.
Подробно рассмотренные нами конкретные примеры призваны помочь как заказчикам, желающим отдать на внешний подряд разработку требований к своему ПО, так и подрядчикам, вовлеченным в аутсорсинг.
Специфика разработки требований в условиях офшорного аутсорсинга
Схема на рис. 1 представляет типичных участников программного проекта при аутсорсинге. Мы используем ее для описания четыре характерные особенности такого проекта в условиях офшорного аутсорсинга и их влияния на разработку требований.
|
| Типичные участники программного проекта в условиях аутсорсинга (пунктирная линия символизирует косвенную связь через ИТ-отдел заказчика) |
Первая особенность заключается в том, что подрядчик обычно имеет дело с двумя группами участников в организации заказчика: ИТ-отдел и бизнес-сообщество (менеджеры и пользователи). Аналогичным образом заказчик вынужден иметь дело с двумя группами в организации подрядчика — местной группой координации и офшорной группой разработчиков. Такое положение дел, как правило, ведет к разобщенности между группами, принимающими решения и выполняющими проект (обычно офшорными), и группой, знающей потребности заказчика (обычно местной). Взаимодействиями между источником требований (бизнес-сообщество) и поставщиком решений (подрядчик) управляют несколько групп. Это обстоятельство влияет на разработку требований по трем направлениям. Необходим более строгий процесс управления изменениями требований (что увеличивает непроизводительные затраты), поскольку растет число промежуточных звеньев при передаче информации и усиливается разобщенность между лицами, принимающими решения. Малейшее отступление от этого процесса может разрушить единое понимание изменений в требованиях. Замедляется также обсуждение требований между заказчиком и подрядчиком вследствие постоянного перемещения информации из одного офиса в другой. Наконец, возникает множество ступеней формального разделения между участниками, находящимися на одном и том же уровне организационной ответственности. Это может привести к смещенным и неполным представлениям, которые уменьшают прозрачность при сборе, обсуждении и утверждении требований.
Вторая особенность — наличие нескольких инструментов и процессов разработки требований в организациях и подразделениях заказчика и подрядчика. Использование нескольких инструментов, шаблонов и методологий, которые слабо связаны или плохо совместимы друг с другом, может привести к расточительным переделкам при разработке требований или потерям данных в ходе их передачи от одного инструмента к другому, в результате чего может увеличиться дефектность требований. Это также вынуждает заказчика и подрядчика вводить разные стандарты документирования требований вследствие различий в уровнях зрелости процесса разработки требований в рабочих группах.
Третья особенность — различия в организационной культуре или местные различия в стиле работы между группами заказчика и подрядчика. В имеющейся литературе широко освещается вопрос о том, как культурные различия в таких областях, как трудовая этика, рабочие часы, служебная иерархия, способы общения и отношение к качеству могут повлиять на разработку требований [8,9].
Четвертая особенность — комплектование рабочих групп заказчика и подрядчика специально для данного проекта, что ведет к многочисленным переходам сотрудников из одного подразделения в другое [10].
Эти особенности создают множество проблем в разработке требований, которые участники распределенных программных проектов в последние годы испытали на себе. Число и сложность проблем многократно возрастают, если в офшорный аутсорсинг вовлечены несколько организаций.
Конкретные примеры
Разберем несколько ситуаций из произвольно выбранных проектов, чтобы подробнее проиллюстрировать затронутые проблемы.
Пример 1. Противоречие целей заказчика и подрядчика
В одном из проектов группа подрядчика должна была перенести негибкую унаследованную систему с высокой совокупной стоимостью владения на современную платформу, основанную на новейших технологиях. В техническом задании было обозначено, что планируется разработка бизнес-требований в масштабе предприятия, за которыми должен последовать сбор детальных требований к приложениям.
Члены проектной группы подрядчика согласно техническому заданию хотели закончить разработку общих требований прежде, чем заняться деталями, и оценивали свои успехи в соответствии с тем, насколько эффективно это делалось (высокая скорость, высокое качество, низкая стоимость). Однако, чтобы ускорить выход на рынок, ИТ-директор заказчика хотел действовать на основе приоритетов, а именно: сначала закончить детализацию требований для одного определенного направления бизнеса. На встрече между ответственными сотрудниками заказчика и подрядчика не удалось прийти к соглашению, поскольку специалисты по разработке требований находились в офшоре и не смогли принять в ней участие. Возник конфликт, так как группа подрядчика концентрировала усилия на разработке требований, касающихся предприятия в целом, а ИТ-директор продолжал основное внимание уделять приоритетному направлению бизнеса. Поскольку участники при личной встрече не обсуждали бизнес-цели и их логическое обоснование, ни одна из сторон не оценила полученные результаты как положительные.
Пример 2. Недостаточная вовлеченность заказчика
Проектная группа подрядчика, работающая частью в Индии, частью в Европе, была обеспокоена недостаточной вовлеченностью сотрудников заказчика в разработку требований. В частности, ее веру в свои способности завершить работу вовремя и в рамках бюджета подрывали две проблемы.
Пример 9. Инструменты, не оправдавшие ожиданий
Офшорная группа экспертов по разработке требований была не в состоянии помочь своей местной группе из-за неправильного выбора инструмента. Местная группа разработки требований хотела воспользоваться преимуществами круглосуточного рабочего цикла (follow the sun model of working) и запросила у офшорных экспертов макеты экранов, основанные на документации по требованиям на базе сценариев использования. В надежде на быструю оборачиваемость они собирались ежедневно обмениваться сценариями использования и соответствующими макетами экранов. Однако, к их удивлению, в первом цикле затраты времени у офшорной группы оказались почти в три раза больше ожидаемых. Проведя анализ, мы поняли, что офшорная группа использовала специализированный инструмент, который давал качественные результаты и требовал больших усилий, тогда как местная группа хотела получить лишь грубый эскиз для обсуждения и согласования требований с бизнес-пользователями заказчика.
Стратегические факторы успеха
Приведенные примеры порождают ключевой вопрос: как справиться с этими проблемами? В недавних публикациях предлагаются решения проблем, вызванных скорее географически распределенной разработкой требований, в то время как мы рассматриваем проблемы, возникающие именно в сценарии офшорного аутсорсинга. Мы надеемся, что наш анализ поможет сформулировать рекомендации по методам разработки требований как на стратегическом (что), так и на тактическом уровне (как), которые могут быть использованы в реальных проектах.
Простой анализ первопричин (root-cause analysis) в этих девяти примерах позволяет выявить ключевые стратегические факторы успешной разработки требований при аутсорсинге.
Общие цели. Анализ первопричин в примерах 1 и 9 показывает, что продуктивность разработки требований падает, если участники не стремятся к общей цели. Как отмечается в работе [10], истинное сотрудничество, предполагающее взаимную ответственность и согласованность усилий, требует общего видения. В предложении авторов [11] по управлению конфликтами и согласованию точек зрения их участников также подчеркивается важность общей цели.
Общая культура. Культура играет важную роль в успехе любой коллективной деятельности. Анализ примера 2 демонстрирует недостаток культурной общности между участниками проекта. В основополагающей работе [8] идентифицируются ключевые факторы, обусловливающие культурные различия между индивидуумами. Последние исследования [4,5,12] затрагивают культурные нормы, ценности, язык и неявное знание, которые также влияют на поведение участников.
Общий процесс. Процесс определяет методологию для формирования артефактов любой деятельности по разработке требований, а также для используемых при этом инструментов, методов и шаблонов. Примеры 3 и 6 иллюстрируют проблемы, порожденные отсутствием единого процесса. В работе [6] также показана важность согласования процесса между группами.
Общая ответственность. Разработка требований — наиболее запутанная часть процесса разработки ПО, каждый из этапов которой, будь то планирование, сбор исходных данных, документирование, анализ, обсуждение, согласование или проверка, зависит от множества радикально несхожих заинтересованных лиц. При разработке требований в каждом акте взаимодействия между заказчиком и подрядчиком распределение ответственности происходит по-своему. Примеры 4 и 7 показывают недостаток общей ответственности как первопричину всех проблем. Этот вывод находится в согласии с другими исследованиями [5, 13].
Доверие. Это основообразующее связующее звено, которое усиливает каждый из предыдущих факторов. Недостаток доверия может лишить проект одного или нескольких факторов успеха, в то время как достаточное доверие способствует их развитию.
Классификация передовых методов
Следующий шаг в нашем анализе — найти методы, помогающие достичь стратегических факторов успеха при разработке требований. Эти методы должны обеспечить фундаментальный подход к достижению стратегических целей. Здесь мы предлагаем целостную классификацию таких методов.
Типичная задача, встающая перед практиками, заключается в том, чтобы выбрать правильный метод для применения в контексте реальной жизни. Эта задача становится еще труднее, когда есть несколько методов, но они не являются ни взаимоисключающими, ни исчерпывающими в своей совокупности.
Первый шаг в решении этой задачи состоит в том, чтобы построить классификацию, позволяющую быстро оценить имеющиеся методы и выявить направления дальнейших исследований.
Наш опыт показывает, что большинство методов разработки требований, рекомендуемых для распределенных софтверных групп, пригодны также и для распределенной разработки ПО в условиях аутсорсинга. Составленная на основе литературных источников и нашего практического опыта таблице представляет собой частично заполненную классификационную таблицу передовых методов разработки требований для каждого стратегического фактора успеха.
Группы разработки требований, работающие в условиях аутсорсинга, сталкиваются с проблемами, которые непосредственно не затрагиваются традиционными методами программной инженерии. Опыт практиков и исследователей, почерпнутый из реальной жизни, концентрируется в ряде новых методов, позволяющих справиться со многими из этих проблем. Мы надеемся продолжить изучение вновь появляющихся методов разработки требований и оценку их действенности в рамках предложенной классификации.
ЛИТЕРАТУРА
- P. Iyengar, Application Development Is More Global than Ever, publication G00124025, Gartner, 2004; www.gartner.com/resources/124000/124025/application_dev.pdf.
- I. Sommerville, G. Kotonya, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998.
- L. Maciaszek, Requirements Analysis and Systems Design: Developing Information Systems with UML, Addison-Wesley, 2001.
- D.E. Damian, D. Zowghi, The Impact of Stakeholders' Geographical Distribution on Managing Requirements in a Multi-site Organization, Proc. 10th Anniversary IEEE Joint Int'l Conf. Requirements Eng. (RE 02), IEEE CS Press, 2002.
- J. Hanisch, B.J. Corbitt, Requirements Engineering during Global Software Development: Some Impediments to the Requirements Engineering Process: A Case Study, Proc. 12th European Conf. Information Systems (ECIS 04), 2004.
- L. Lopes et al., Requirements Specification in Distributed Software Development - A Process Proposal, Proc. 38th Hawaii Int'l Conf. System Sciences (HICSS 05), IEEE CS Press, 2005f.
- H. Edwards, V. Sindhar, Analysis of Software Requirements Engineering Exercises in a Global Virtual Team Setup," J. Global Information Management, vol. 13, no. 2, 2005.
- G. Hofstede, Cultures and Organization: Software of the Mind, McGraw-Hill, 1991.
- E. Carmel, Global Software Teams, Prentice Hall, 1999.
- G. Pare, L. Dube, Virtual Teams: An Exploratory Study of Key Challenges and Strategies, Proc. 20th Int'l Conf. Information Systems (ICIS 99), ACM Press, 1999.
- P. Darke, G. Shanks, Stakeholder Viewpoints in Requirements Definition: A Framework for Understanding Viewpoint Development Approaches, Requirements Eng., vol 1, 1996.
- R. Prikladnicki et al., Requirements Management in Global Software Development: Preliminary Findings from a Case Study in a SWCMM Context, Proc. 2nd Int'l Workshop Global Software Development, IEEE CS Press, 2003.
- D. Damian et al., "Requirements Meets Awareness: Awareness Needs in GSD," Proc. 2nd Int'l Workshop Global Software Development, IEEE CS Press, 2003.
- L. Dube and G. Pare, "Global Virtual Teams," Comm. ACM, vol. 44, no. 12, 2001.
- J.A. Hrones, Jr., B.C. Jedrey, Jr., D. Zaaf, Defining Global Requirements with Distributed QFD, ACM Trans., vol. 5, no. 4, 1993.
- D. Damian and Eberlein, "The Effects of Communication Media on Group Performance in RE," Proc. 4th Int'l Conf. Requirements Eng. (ICRE 00), IEEE CS Press, 2000.
Джиоти Бхат (jyotimb@infosys.com) — специалист по управлению бизнес-процессами в лаборатории Infosys Software Engineering and Technology Labs. Мэйанк Гупта (mayank_gupta@infosys.com) — главный архитектор компании Infosys Technologies, специалист по инженерным вопросам и управлению бизнесом. Сантос Мэрфи (santhosh_murthy@infosys.com) — консультант группы InFlux Business Process Consulting в лаборатории Infosys Software Engineering and Technology Labs.
J.M. Bhat, M. Gupta, S.N. Murthy, Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing, IEEE Software, Sept/Oct 2006. IEEE Computer Society, 2006, All rights reserved. Reprinted with permission.
