Разработка требований: уроки офшорного аутсорсинга

Разработка требований — наиболее важная стадия программного проекта [2, 3], от ее результатов во многом зависит успех проекта в целом.

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

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

Специфика разработки требований в условиях офшорного аутсорсинга

Схема на рис. 1 представляет типичных участников программного проекта при аутсорсинге. Мы используем ее для описания четыре характерные особенности такого проекта в условиях офшорного аутсорсинга и их влияния на разработку требований.

Типичные участники программного проекта в условиях аутсорсинга (пунктирная линия символизирует косвенную связь через ИТ-отдел заказчика)

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

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

Третья особенность — различия в организационной культуре или местные различия в стиле работы между группами заказчика и подрядчика. В имеющейся литературе широко освещается вопрос о том, как культурные различия в таких областях, как трудовая этика, рабочие часы, служебная иерархия, способы общения и отношение к качеству могут повлиять на разработку требований [8,9].

Четвертая особенность — комплектование рабочих групп заказчика и подрядчика специально для данного проекта, что ведет к многочисленным переходам сотрудников из одного подразделения в другое [10].

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

Конкретные примеры

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

Пример 1. Противоречие целей заказчика и подрядчика

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

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

Пример 2. Недостаточная вовлеченность заказчика

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

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

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

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

Пример 3. Противоречивые подходы к разработке требований

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

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

Пример 4. Плохая увязка обязательств заказчика с целями проекта

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

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

Пример 5. Разногласия при выборе инструментальных средств

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

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

Пример 6. Проблемы коммуникации

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

Пример 7. Отказ от ответственности

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

Пример 8. Проблемы визирования

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

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

Пример 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].

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

Классификация передовых методов

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

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

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

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

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

ЛИТЕРАТУРА

1. P. Iyengar, Application Development Is More Global than Ever, publication G00124025, Gartner, 2004; www.gartner.com/resources/124000/124025/application_dev.pdf.
2. I. Sommerville, G. Kotonya, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998.
3. L. Maciaszek, Requirements Analysis and Systems Design: Developing Information Systems with UML, Addison-Wesley, 2001.
4. 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.
5. 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.
6. 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.
7. 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.
8. G. Hofstede, Cultures and Organization: Software of the Mind, McGraw-Hill, 1991.
9. E. Carmel, Global Software Teams, Prentice Hall, 1999.
10. 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.
11. P. Darke, G. Shanks, Stakeholder Viewpoints in Requirements Definition: A Framework for Understanding Viewpoint Development Approaches, Requirements Eng., vol 1, 1996.
12. 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.
13. D. Damian et al., "Requirements Meets Awareness: Awareness Needs in GSD," Proc. 2nd Int'l Workshop Global Software Development, IEEE CS Press, 2003.
14. L. Dube and G. Pare, "Global Virtual Teams," Comm. ACM, vol. 44, no. 12, 2001.
15. J.A. Hrones, Jr., B.C. Jedrey, Jr., D. Zaaf, Defining Global Requirements with Distributed QFD, ACM Trans., vol. 5, no. 4, 1993.
16. 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.