CC BY
25
У. Стефенсона (1935 г.) заключается в анализе перевернутой матрицы данных — когда ищутся взаимосвязи между опытами (наблюдениями), а не измеряемыми в этих опытах параметрами. Основной целью контент—анализа является выявление наиболее общих тенденций без учета специфики какого-либо рынка или товарной категории.
4. Статистические методы исследования колебаний объемов продаж, экономико-математическое моделирование.
5. Наиболее современные модели измерения эффективности рекламы — теория игр и биполярные модели.
Выводы
В статье представлен краткий анализ существующих моделей оценки эффекта и эффективности маркетинговых коммуникаций. Рассмотрены различные точки зрения на проблему, предложена классификация моделей. Проблема оценки эффекта и эффективности маркетинговых коммуникаций постоянно обсуждается, окончательных и бесспорных решений в этой области нет, особенно при оценке коммуникационного эффекта и эффективности маркетинговых коммуникаций.
СПИСОК ЛИТЕРАТУРЫ
1. Докторов Б., Broadcasting, 2001, № 2. C. 52-55. http://www.pseudology.org/GaUup/Audiometriya.htm
2. Климин А. И. Стимулирование продаж. М.: Вершина, 2007. 272 с.
3. Кутлалиев А., Попов А. Эффективность рекламы: 2-е издание. М.: Изд-во Эксмо, 2006. 416 с.
4. Ламбен Ж.Ж. Стратегический маркетинг. Европейская перспектива СПб.: Наука, 1996. 589 с.
5. Мещеряков Б., Зинченко В. Большой психологический словарь. М.: Олма-пресс, 2004. 672 с.
6. Огилви Д. Огилви о рекламе (Ogilvy on Advertising). М: Эксмо, 2003. 232 с.
7. Хопкинс К. Научная реклама. М.: Изд-во Эксмо, 2007. 128 с.
УДК 659.1
Мякио Ю., Бетз С., Миролюбов А. А.
Управление проектами международного аутсорсинга программного обеспечения
Введение
Международный аутсорсинг является частью общего явления глобализации , который развивается благодаря соверменным информационным и коммуникационным технологиям. В настоящее время аутсорсинг превратился в сложившуюся практику управления разработкой программного обеспечения. Фирмы используют аутсорсинг для достижения следующих целей:
— сокращения или улучшения контроля над затратами;
— управления потребностями компаний в ресурсах при переменной производительности;
— высвобождения ключевых ресурсов компании для более необходимых целей;
— получения доступ к мировым компетенциям разработки программного обеспечения;
- передачи партнерам управления особо сложными и трудными функциями.
Международные исследования показывают, что в последние годы именно фактор существенного снижения затрат стал основной причиной быстрого распространения международного аутсорсинга. Однако, вследствие развития процессов глобализации, происходит постепенное сокращение разрыва в оплате труда программистов и системных аналитиков разных стран мира. В этих условиях при отборе участников проекта международного аутсорсинга на передний план выдвигаются неценовые факторы, а именно — более качественное управление пот-
ребностями заказчика в мощностях и освобождение собственных ресурсов для других целей. У этой тенденции имеются две причины. Во-первых, значительные управленческие усилия при осуществлении проектов снижают возможность дальнейшего уменьшения издержек. Во-вторых, все большее значение приобретает гибкость управления, так как аутсорсинг способствует более рациональной оценке потребностей компании в ресурсах.
Как известно, термин "аутсорсинг" используется для обозначения взаимоотношений между покупателем (клиентом), который передает производство продукции или услуг на субконтрактной основе третьей стороне (продавцу или провайдеру). При аутсорсинге программного обеспечения производство осуществляется в основном в контексте проектов. Это приводит к появлению трех составляющих аутсорсинго-вых взаимодействий: покупатель, продавец и проект. Отношения между ними в дальнейшем уточняются контрактом. Если схема взаимоотношений усложняется добавлением одного или более участников, то можно говорить о мулти-сорсинге (multisourcing). Оффшоринг (offshoring) или оффшорный аутсорсинг означает контракт, по которому потребитель аутсорсинговой деятельности находится на другом континенте. Ближний аутсорсинг (пеа^оп^) означает, что потребитель находится в другой стране на том же континенте. Далее ради упрощения ситуации будет использован единый общий термин "аутсорсинг".
Аутсорсинг разработки программного обеспечения, благодаря рациональному соотношению низких затрат, а также соблюдению временных и качественных требований, интенсивно развивается в последние годы, однако его преимущества как модели ведения бизнеса не представляются самоочевидными. Многочисленные исследования демонстрируют достаточно высокий процент неудач, который достигает от 50 % до 80 % общего числа всех проектов аутсорсинга.
В данной статье исследуются проблемы реализации проектов международного аутсорсинга программного обеспечения, определяются причины их неудачного завершения. Выявлены недостатки модели аутсорсинга, рассмотрены риски реализации проектов; предложен новый подход к реализации проектов аутсорсинга на основе удовлетворения информационных потребностей всех его участников. Представ-
лена модель управления информацией при осуществлении проекта аутсорсинга программного обеспечения, представлены результаты реализации прототипа такой модели.
1. Условия применения аутсорсинга программного обеспечения
Объективно существующие противоречия целей и интересов заказчика (покупателя) и разработчика (продавца) информационных услуг составляют ключевую проблему использования аутсорсинга программного обеспечения (Perrons and Platts 2004, Roberts 2005). С точки зрения покупателя, возможность достижения установленных целей и правильный учет факторов успеха проекта являются его основными рисками в аутсорсинге. Это означает, что результаты проекта в значительной мере зависят от ясной формулировки цели и от уровня коммуникаций.
Успех проекта разработки программного обеспечения (ПО) измеряется тремя основными индикаторами — время, стоимость и ожидаемый результат. При этом проект может считаться успешно завершеннным только в том случае, если каждый из этих индикаторов получит положительную оценку. Это означает, что для достижения успеха проекта необходимо одновременное соблюдение интересов обоих сторон — покупателя и продавца .
Успех проекта аутсорсинга также зависит от качества, технологического опыта и уровня взаимоотношений всех его участников. При этом чисто технические стороны реализации проекта не являются определяющими факторами его неудачи. Правильно построенные аутсорсинговые отношения должны основываться на совместимости, доверии и взаимном уважении интересов участников (см.Не^1еЬ and Moitra 2001,Grinter et al.1999, Cramel and Agarval 20001). Недоучет одного или более из этих факторов может привести к проблемам в ходе выполнения проекта.
Важнейшей особенностью международных аутсорсинговых схем является географическая удаленность партнеров, усложняющая коммуникацию, координацию и кооперацию между участниками проекта (см. рис. 1). Подробное обсуждение этих вопросов представлено в ряде исследований (см. Casey and Richardson, 2006). Поэтому основная проблема для обеспечения успешного сотрудничества заключается в том, чтобы свести к минимуму негативные эффекты, возникающие от действий этого фактора.
iL
/, /2 Затраты на
рекламу, руб.
Рис. 1. Эффекты дистанционной работы
Следствием географической удаленности участников аутсорсинговых схем становятся коммуникационные разрывы, которые проявляются в различиях рабочего времени (по часам суток) и календаря рабочих и общевыходных дней. В ряде случаев это может привести к утрате взаимодействия между участниками проекта. Для решения этой проблемы наиболее предпочтительным средством коммуникации становится электронная почта.
Культурные характеристики участников проекта также представляют собой достаточно подробно исследованный вопрос международного аутсорсинга программного обеспечения. Это проблемы языковых различий, стилей коммуникации, глубины ориентации на процессный подход, отношения к иерархии власти и ко временным ограничениям проекта. Для уменьшения степени влияния культурных различий на результаты проекта могут быть рекомендованы различные меры кросс-культурного взаимодействия — в частности, изучение социокультурных особенностей партнеров, ротация участников проектных групп в зарубежных филиалах и другие.
2. Управление рисками проектов дистанционной разработки ПО
Первое системное представление риска реализации проектов разработки ПО было представлено в т. н. спиральной модели Боэма (Barry Boehm) в 1988 г. Боэм формулирует 10 наиболее распространенных (по приоритетам) рисков разработки программного обеспечения:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация функциональности ПО, не соответствующей требованиям заказчика.
4. Разработка неправильного пользовательского интерфейса.
5. Излишняя оптимизация и оттачивание деталей.
6. Не прекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки работ, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. "Разрыв" в квалификации специалистов разных областей знаний.
Следует отметить, что модель Боэма является итеративной, и анализ риска в ней выполнен по отношении к процессу разработки ПО. Однако дополнительные факторы риска, возникающие при использовании модели аутсорсинга ПО, в ней не рассматриваются.
По мнению авторов, риски коммерческой разработки программного обеспечения следует рассматривать с позиции экономической и технологической перспективы. В экономической перспективе могут быть выделены макро- и микроэкономические риски. С макроэкономической точки зрения рассматривается совокупное воздействие на аутсорсинг общеэкономических процессов (напр., экономический рост, инфляция безработица и другие) и регулирующих мер, направленных на решение экономических проблем в государственном масштабе. Следует отметить, что аутсорсинг как вид экономической деятельности способен создавать новые рабочие места более высокого уровня функциональности, одновременно сокращая предложение на национальном рынке рабочей силы. Тем самым дистанционная разработка программного обеспечения при определенных условиях может оказывать позитивное влияние на развитие национальной экономики.
С микроэкономической точки зрения риски аутсорсинга анализируют в экономической и в управленческой перспективе (см. АиЬеЛ и др. 1998). Экономическая перспектива рассматривает риск как вероятность получения или потери доходов организации при конкретных альтернативах. Управленческая перспектива определяет риск как угрозу или опасность неудачного завершения проекта, при этом риск определяется вероятностью получения негативных результатов для деятельности организации в целом .
Существующие исследования микроэкономических аспектов аутсорсинга ПО фокусируются главным образом на том, как осуществляется покупка и продажа аутсорсинговых услуг, как принимаются решения об использовании аутсорсинга и как осуществляется поддержка этих решений, какие риски при этом появляются и как ими можно управлять. Однако все эти вопросы необходимо рассматривать одновременно с анализом технических аспектов аутсорсинга ПО, поскольку они влияют на экономические результаты проектов и определяют успехи конкретных фирм-участников.
2.1. Факторы риска аутсорсинговых схем дистанционной разработки ПО
Для того, чтобы определить составляющие риска аутсорсинговых схем и их взаимосвязи, было предложено описание процесса анализа рисков в виде следующей последовательности (см. рис. 2).
Рис. 2. Процесс исследования рисков аутсорсинга ПО
На первом этапе исследования проводилось интервью экспертов. Анализ собранного материала был основан на использовании Конструктивистской Теории (Glaser, 1967). Было сформулировано 15 основных гипотез, основанных на анализе рисков. На следующем этапе исследования, для проверки ранее сделанных предположений было проведено интерактивное анкетирование. На третьем этапе были определены риски и факторы принятия решений по их минимизации. Далее полученные факторы принятия решений ранжировались по степени их важности для целей управления проектами оффшорной разработки ПО и с учетом анализа информационных и экспертных источников (Au-bert 1999, Moczadlo 2005). Категории вопросов для интервьируемых экспертов и соответствующие цели исследования представлены в табл. 1.
Полученные результаты анкетирования были проверены на соответствие данным публикаций в области дистанционной разработки ПО ( Aubert и др. 1999, Moczadlo 2005). Возможные области возникновения риска при реализации проектов дистанционной разработки ПО представлены на рис.3. Такие факторы возникновения рисков, как технические условия, состояние информационной инфраструктуры и географическая удаленность оказались менее значимыми по сравнению с т. н. "мягкими факторами", такими, как коммуникация, способ
Таблица 1
Категории вопросов и цели интервьирования
Категория Цели
Общая информация Информация о компании, и сфере деятельности интервьюируемых специалистов
Стратегические обоснования и решения Обоснование и тип применяемой модели аутсорсинга разработки ПО
Программное обеспечение (технические вопросы) Какие части проекта разработки программного обеспечения были переданы на оффшорный аутсорсинг. Какой подход и какая тактика была применена в процессе разработки программного обеспечения
Определение стоимости работ Как обеспечивалось соответствие планируемых и фактических затрат на аутсорсинг
Подготовка проекта Какая подготовка технического обеспечения, организационной структуры, оценки внешней среды была проведена до начала проекта
Руководство проектом В какой форме осуществлялось руководство проектом
Форма контракта Как распределялась ответственность между клиентом и подрядчиком по условиям контракта
Проблемы реализации проекта Какие культурные, лингвистические и организационные проблемы возникали в ходе проекта
Другие проблемы Иные события, которые не могли быть отнесены ни к одной из выше перечисленных категорий
Технологические условия
Коммуникационные характеристики
Проектный менеджмент
Информационная инфраструктура
Способ Мышления
J Культурные различия
Географическая
удаленность
партнеров
Политические и правовые уел овия ведения бизнеса
Рис. 3. Факторы риска аутсорсинга (Moczadlo 2005)
мышления, культурные различия, а также стиль руководства проектом. Авторы считают, что отрицательные результаты при использовании технологии дистанционной разработки ПО появляются в основном как результат совокупного действия этих четырех факторов.
Однако перечисленные факторы в данном представлении являются достаточно абстрактными. Их необходимо конкретизировать, т. е. разбить на дополнительные элементы (субфакторы) с тем, чтобы более тщательно определить и провести анализ их критических областей. Ниже будет описаны модель зрелости проекта и процессно-ориентируемый подход, используемые для снижения роли факторов риска в реализации проекта дистанционной разработки ПО.
2.2 Управление риском в проектах аутсорсин-говой разработки программного обеспечения
Для того, чтобы выявить и проанализировать риски разработки программного обеспечения на основе аутсорсинга, необходимо идентифицировать индивидуальные риски покупателя и продавца. Для идентификации рисков, их измерения и управления применяется достаточно большое число подходов. Ряд специалистов предлагают использовать экономическую теорию в качестве основы модели управления рисками аутсорсинга ПО. Например, Беймборн (ВетЬот, 2006) предлагает для разработки и анализа сценариев аутсорсинговых моделей использовать аппарат теории игр; Бенарох (ВепагоА 2002), предлага-
ет управлять риском технологических инвестиций на основе справедливых опционов. Другие подходы рассматривают риски аутсорсинга с позиций технологии управления проектами либо с технологической перспективы. Так, например, в работе (Wang и др. 2006) авторы исследуют проблемы отбора участников аут-сорсинговых схем, (Heindl и Biffl 2006) делают акцент на требованиях инжениринга. При этом следует отметить, что достаточно редко в поле зрения исследователей процессов аутсорсинга попадают риски разработчика программного продукта, хотя очевидно, что их последствия самым непосредственным образом сказываются на покупателе. Например, покупатель в целом не защищен от риска некачественного и несвоевременного обслуживания приобретенного ПО.
Минимизация рисков либо их устранение путем использования управленческих методов является важным вопросом при разработке программного обеспечения. Управление риском в процессе дистанционной разработки программного обеспечения должно затрагивать все процессы жизненного цикла разработки и использования ПО. Это означает, что управление рисками должно учитывать как основные, так и вспомогательные части проекта (см. Kerzner 2000). В данной статье рассмотрен подход к управлению рисками аутсорсинга на основе использования моделей зрелости.
Модели зрелости достаточно широко используются в отрасли разработки программного
обеспечения для совершенствования процессов, используемых технологий и трудовых ресурсов, что позволяет достигать оптимальных результатов. Эти модели способны измерять исходный уровень зрелости организации и показывают, каким образом могут быть достигнуты следующие уровни зрелости (см. Хэмфри 1990, Куртис 1995). Важность использования моделей зрелости подтверждается и тем фактом, что качество производимого продукта напрямую зависит от зрелости организационного процесса. К настоящему времени разработано большое число моделей зрелости для поддержки совершенствования процессов разработки ПО и других 1Т- направлений. В зависимости от поставленных целей, применение различных моделей зрелости направлено на различные аспекты разработки ПО. В табл. 2 представлен краткий обзор используемых в отрасли ПО моделей зрелости.
Модели зрелости способствуют построению развитых организационным процессов фирм-раз-рабочиков ПО (Herbsleb и др. 1997). При этом вся деятельность фирмы концентрируется на усовершенствовании существующих процессов.
Помимо совершенствования организации процесса разработки ПО, развитие механизмов коммуникации и координации между партнерами снижает неопределенность получения результатов и в целом улучшает исполнение процесса. Поэтому эти действия играют центральную роль в достижении положительных результатов при осуществлении проектов распределенной разработки ПО (Кейси и Richardson 2006, Kraut и Streeter 1995). По мнению авторов, проблемы коммуникации и координации определяются не только процессами разработки, но также зависят от организационной зрелости покупателя и специфики проекта.
Таблица 2
Обзор моделей зрелости
Модель Зрелости Основное содержание
P-CMM ( Модель Зрелости Персонала) Основное содержание управления в процессе развития концентрируется на сотрудниках фирмы (Куртис , 1995)
DMM (Документарная Модель Зрелости) Оценка качества документации при разработке программного обеспечения для лучшего понимания программы (Pierce 2002 Tilley)
MMAST (Модель Зрелости для Автоматизированного Тестирования ПО) Совершенствование системы проверки разрабатываемого ПО (Хэмфри 1990)
IDEAL (Модель: Инициация- Диагностика — Создание — Действие — Усиление) Обеспечивает выполнение набора действий в процессе совершенствования процесса разработки программного обеспечения (Kautz и др. 2000). Определяется пять последовательных фаз развития процесса для достижения организацией более высокого уровня зрелости
SE-CMM ( Модель Зрелости Системного проектирования) Обеспечивает поддержку в координации и представлении модели для совершенствования процесса системного проектирования
SA-CMM (Модель Зрелости — Способность к приобретению ПО) Способность приобретения ПО организацией (Carnegie 2002). Определяет пять уровней зрелости организации и несколько Ключевых Областей Процесса (KPAs)
CMMI ( Модель Зрелости — Способность к Интеграции) Определяет цели, которые должны быть достигнуты (путем установления набора процессов в организации), для того чтобы увеличить производительность разработки программного обеспечения, в результате которых они становятся конкретными и управляемыми. CMMI включают пять уровней зрелости и 22 области процесса
CMMI-DEV (Модели Зрелости- Способность к Интеграции для Развития) Поддержка процессов разработки и обслуживания ro(Carnegie 2006)
CMMI-ACQ (Модель Зрелости -Способность к Интеграции для Приобретения) Поддержка процессов управления цепочкой поставок, приобретения, аутсорсинга в промышленности и правительственных структурах (Carnegie 2007)
Способность участвующих организаций к взаимодействию на структурном уровне также влияет на результаты использования аутсорсинга разработки ПО. Как правило, модели зрелости проектов распределенной разработки ПО используются для оценки готовности вендоров выполнить установленную задачу. Однако, исследование механизмов, оценивающих способность заказчиков к сотрудничеству в проекте, а также пригодность конкретного проекта к его реализации посредством дистанционной разработки остается недостаточным. Поэтому авторы считают, что предлагаемая ими Модель Зрелости Распределенной Разработки ПО (OMM - Outshoring Maturity Model ) способна до некоторой степени восполнить этот пробел.
3. ОMM — модель зрелости распределенной разработки ПО
OMM предназначена для оценки готовности аутсорсинговой компании к участию в проектах распределенной разработки программного обеспечения. OMM может исполь-
зоваться в равной степени для Оп-шоринга и для оффшоринга. ОММ также представляет собой инструмент для управления риском (Betz и Мдкщ, 2008). ОММ оценивает уровень зрелости фирм-покупателей, используя следующие показатели : стратегия, опыт участия в оффшоринге, операционное структурирование, уровень зрелости в отношении рисков, обеспечение аппаратными средствами (см. рис. 4). Зрелость проекта определяется на основе следующих параметров: число и состав модулей, размер, длительность выполнения, стабильность требований, число интерфейсов, тип проекта, зависимость внутренних знаний компании и архитектуры. Третья составляющая модели (разработчик) определяется параметрами: географическая удаленность от заказчика, культурные различия, опыт участия в международных проектах, текучесть кадров.
Цель ОММ состоит в том, чтобы определить на основе различных критериев, в какой степени данный проект распределенной разработки ПО может быть успешно завершен. Успешное
Качественная поддержка _решений_
Покупатель
Стратегия
Снижение издержек
Гибкость
Время от начального замысла нового продукта до его внедрения на рынок
Опыт в офшоринге
Менеджмент
Проектировочная команда
Поддержка аппаратным обеспечением
Операциональное структурирование
Проект
Модульная концепция
Размер
Длительность
Необходимые условия стабильности
Количество интерфейсов
Технология
Количество пользовательских интерфейсов
Зависимость внутренней структуры знаний компаний
Архитектура
Продавец
Культурная и графические дистанции
Язык
Культура труда
— Чувство времени
Часовой пояс
Опыт в офшоринге
Колебания
Международные стандарты
Внутренние процессы
Рис. 4. Составляющие модели ОММ
завершение проекта означает, что программный продукт выполнен в соответствии с техническим заданием и все работы по нему завершены в установленное время без дополнительных финансовых затрат. Дополнительным фактором, определяющим потребность в разработке специальной модели зрелости для оффшоринга (ОММ) является тот факт, что риски реализации данных схем разработки ПО сильно отличаются от внутреннего аутсорсинга при разработке ПО. Как было отмечено выше, ОММ оценивает зрелость проекта в трех измерениях. Каждое измерение содержит элементы, которые значимы для успешного осуществления проекта. Рассматривается 5 уровней зрелости ОММ, как это показано в табл. 3. Определяемая ценность показывает на способность организации осуществлять распределенную разработку в данном измерении. Выполняя подобный анализ, организация получает более полное представление о ее слабых сторонах с точки зрения участия в проекте. На основе рассчитанных ценностей по отдельным направлениям определяется итоговое значение зрелости ОММ.
Классификация уровней моделей зрелости проводилась посредством анкетирования.
Вопросы анкеты были сведены в группы и соответствовали различным фазам в фазовой модели ОММ. Это облегчает получение сведений из областей знаний, требующих совершенствования, а также определение ответственных лиц и ответственности. Ниже приведены некоторые из вопросов, которые относятся к первой фазе (т.н. Презентационная фаза) модели фазы ОММ. Как правило, вопросы концентрируются на руководстве проектом с отдельным фокусом на управлении персоналом и навыками.
Эффективность деятельности проектной группы определяется:
• Размером отдельных проектных групп.
• Навыками отдельных участников команды.
• доступностью участников команды.
• Имеются ли в наличии необходимые специалисты?
• Кто инструктирует и тематически обучает необходимого вам специалиста ?
На рис. 4 представлен набор составляющих ОММ. Этим составляющим поставлены в соответствие различные факторы риска. Веса факторов были определены на основе экспертных оценок и представлены в табл. 4.
Таблица 3
Уровни зрелости модели ОММ
Уровень Зрелость Покупателя Проектная Зрелость Зрелость Продавца
1 Начальный Практически нет опыта участия в проектах распределенной разработки Очень сложные проекты, имеющие центральное значение для фирмы Значительные культурные различия и географическая удаленность, нет явных способностей к осуществлению проектов
2 Стартовый Некоторое знакомство с проектами разработки программного обеспечения Сложные, значимые проекты Большая культурная и географическая удаленность, неявные знания
3 Осведомленный Приобретаются начальные знания механизмов распределенной разработки программного обеспечения Неключевые проекты Существует культурная и географическая удаленность, сильные знания
4 Управляемый Умение понимать и контролировать механизмы распределенной разработки программного обеспечения Уменьшенная или локальная новая разработка Некоторые культурные и географические различия, область знаний компании (сфера основных компетенций)
5 Зрелый Глобальный Игрок, распределенная разработка является основной компетенцией Простые, независимые, крупные проекты Граничное культурно-географическое положение, ни один колебание, опыт участия в различных проектах
Таблица 4
Значения весов факторов риска оффшорного аутсорсинга разработки ПО
Факторы риска Значения весов по 10-балльной шкале
технические проблемы 2,5
ИТ инфраструктура 2,5
часовые пояса 3
политические и правовые ограничения 4,5
"ход мышления" 5,5
коммуникация 6
культурные различия 6,5
руководство проектом 6,5
Уровни зрелости модели ОММ оценивается по следующему алгоритму:
1. Проверка через ответ на вопросы.
2. Создание базы для оценки видов деятельности при осуществлении аутсорсинга.
3. Оценка внешних воздействий на проект оффшорного аутсорсинга.
4. Обобщенная оценка уровня зрелости.
4. Проект разработки ПО на основе модели аутсорсинга
В данном разделе описывается процессно-ориентированный подход применительно к проекту разработки ПО на основе аутсорсинга. Подход реализован в виде семи последовательных фаз (см. рис. 5). На каждой фазе проекта используется различная необходимая информация в соответствии с поставленными задачами. Представленный пример использования процессного подхода опирается на эмпирические исследования авторов и литературных источниках (например, см. Ва^еЛ Н. 2008).
Первая фаза — подготовка проекта. Она включает поиск подходящего проектного партнера, оценку готовности подразделений заказчика к работе по проекту аутсорсинга, готовности ИТ-инфраструктуры и наличие
специалистов, наличие четкого понимания ожидаемых результатов. Здесь необходима достаточная мотивация компании для использования модели аутсорсинга/оффшоринга, очевидная для всех сотрудников. Устанавливаются метрики для оценки получаемых результатов.
Вторая фаза, "Конкретный бизнес-пример", используется как инструмент самопроверки заказчика. Процессы разработки ПО по модели аутсорсинга проверяются с т. з. способности их осуществления, наличия необходимых навыков у персонала заказчика и подготовленности проекта аутсорсинга в целом. Роли и обязанности сотрудников при выполнении этой фазы также должны быть распределены.
Третья фаза, "Определение проекта и инициализация", предполагает установление временных рамок осуществления проекта аутсорсинга. Определяются требуемые свойства разрабатываемого ПО. Устанавливаются средства коммуникации в рамках проекта и проводятся встречи представителей потенциальных участников для близкого ознакомления. Смысл этих контактов состоит в уменьшении социальных барьеров взаимодействующих сторон.
Следующая фаза — "Разработка и производство " — посвящена целиком процессу разработки программного обеспечения. В этой фазе переопределяется и проверяется функционирование механизмов управления и коммуникации с партнером аутсорсинговой схемы.
На пятой фазе "Оценка результатов" — поэтапно осуществляется оценка результатов предыдущего этапа. При этом проверяется функционирование информационного потока между заказчиком и исполнителем и обратно. Однако недостаток доверия между сторонами может затруднить эту фазу.
В фазе 6 "Переход" — должно быть передано информационное знание о продукте от разработчика заказчику с тем, чтобы избежать зависимости одного от другого. Эта задача также требует наличия отработанного механизма
Рис. 5. Фазы проекта разработки программного обеспечения на основе модели аутсорсинга
коммуникации и достижения необходимого уровня доверия между обоими сторонами.
Во время фазы 7 "Интеграция" — поэтапно осуществляются интеграция разработанного ПО с существующими у заказчика программными системами. Данный этап включает в себя финальное тестирование нового программного продукта, и поэтому требуется тщательное планирование данного этапа.
Разработка программного обеспечения представляет собой деятельность по передаче точных знаний. Одной из ключевых проблем обмена точными знаниями в процессе реализации совместного проекта (не только при разработке программного обеспечения по модели аутсорсинга, но и в других видах деятельности), является управление знаниями. В работе (Khalid, Khalifa 2007) отмечается, что коллективное использование знания в среде распределенной международной разработки ПО становится основной частью процесса управления знаниями" и "для участников проекта важно осознать, что же в действительности они знают". Это означает, что необходимо создание соответствующих механизмов для поддержки совместно создаваемого и используемого знания. В следующем разделе представлена интегрированная модель для управления распределенной разработкой ПО и поддержки информационного обмена в проектах аутсорсинга. Эта модель основана на процессно-ориентируемом подходе и на информационных потребностях участников при передаче точных знаний.
5. Интегрированная модель управления информацией в проектах аутсорсинга программного обеспечения
Аутсорсинг ПО влияет на деятельность фирмы-заказчика на трех уровнях: эксплуатационный уровень, уровень менеджмента и стра-
тегический уровень (как это показано на рис. 6). На каждом уровне должны быть выполнены соответствующие задачи.
Интегрированная модель аутсорсинга основана на том, что различные роли участников проекта в фирме требуют различных данных по ходу его реализации. Первоначальные данные, используемые в модели, имеют либо внутреннее (проектное) или внешнее происхождение. Внутренние данные появляются непосредственно в ходе реализации проекта (например, исходные коды программы, содержание плана проекта, стратегические решения), или являются производными от этого (результаты выполнения проекта, проверка завершения этапа), в то время как внешние данные не являются про-ектно-ориентированными. На эксплуатационном уровне внешние данные могут иметь вид, например, онлайн — документации; на уровне менеджмента — обучающих программ; кроме того, внешнюю информацию использует система управления навыками, основой работы которой является информация о навыках сотрудников.
Исходные данные, созданные на каждом уровне интегрированной модели, затем пополняются дополнительной внешней информацией. Основные вопросы, соответствующие возникающим информационным потребностям могут быть следующие :
— Каковы главные типы систем, используемых при разработке ПО?
— Какую роль они играют в ходе реализации проекта?
— Как информационные системы поддерживают основные функции разработки ПО?
— В чем состоят эти главные функции?
По мнению авторов, эксплуатационный
уровень требует максимальной поддержки и
Функциональность
Внешняя Информации по проекту
Внутренняя информация по проекту
Управление портфелем проектов
Управление проектом
Управление качеством программного
обеспечения
Управление требованиями к программному обеспечению
Информация о неисправностях Информация об ошибках Проектная документация
Рис. 6. Уровни реализации проекта разработки ПО в компании
в то же время вносит максимальный эффект в осуществление проекта разработки ПО в целом. В статье (Ko, A. J., DeLine, R., and Venolia, G. 2007) рассмотрены информационные потребности, источники информации и проблемы, препятствующие фирмам- разработчикам найти необходимую информацию.
6. Применение интегрированной модели
аутсорсинга (Коммуникационный Куб)
Разработка модели аутсорсинга в виде Коммуникационного Куба представляет собой создание прототипа выше описанной интегрированной модели. Эта разработка комбинирует информационные услуги для всех участников проекта разработки ПО. В свою очередь, это поддерживает процесс распределенной разработки программного обеспечения.
Коммуникационный Куб охватывает все многомерное информационное пространство разработки программного обеспечения. Каждая сторона куба представляет одно информационное измерение. Следует отметить, что такой куб является частным случаем пространства информационных решений (представленного как суперкуб или выпуклый многогранник с множеством сторон). Переход от одной грани к другой достигается вращением куба. По мнению авторов, такой способ отображения
информационного представления является расширением обычного двумерного представления данных пространственным компонентом, в результате чего рассматривается вся связанная информация.
Визуализация информации является персонифицированной в соответствии с ролями участников проекта разработки программного обеспечения. Это означает, что например информационная визуализация для менеджера проекта не будет такой же, как для разработчика. Менеджер проекта получает обобщенную информацию, например число уровней доступа к программным кодам, в то время как разработчик получает информацию на том, кто сделал последнее изменение в этом коде и как выглядит коммуникация.
Коммуникационный куб поддерживает все фазы разработки программного обеспечения, представленные на рис. 5. Информация и данные, которые получены на ранних фазах проекта, автоматически интегрируются в последующие фазы. Тем самым поддерживаются важнейшие области аутсорсинга с т. з. уровня риска коммуникации, руководства проектом и "хода мышления" (рис. 3).
Коммуникация поддерживается в модели разнообразными способами. Коммуникационный куб объединяет различные инструменты
Связанная документация
Протоколы коммуникаций
Средства коммуникаций
The main method. Writes „Hello World" on console and waitsfora keystroke to exit.
foe main method. Writes „Hello Worid" on console an d waits for a key stroke to exit.
Средства описания коммуникаций Локализация
Программные коды
Рис. 7. Прототип интегрированной модели управления проектом распределенной разработки ПО (коммуникационный куб)
коммуникации. Это упрощает автоматическое и полуавтоматическое преобразование коммуникационных данных в проектные данные, например, в содержание планов проекта. Таким образом можно предоставлять информацию менеджеру проектов о текущих действиях разработчиков и возможных угрозах в рамках проекта.
Руководство проектом обеспечивается информационной поддержкой через объединение деятельности разработчиков с инструментарием руководства проектом. Например, такие действия как принятие кода (check-ins), отметка ошибки или завершение задачи соединяются с руководством проектом таким образом, что менеджер проектов автоматически получает полную картину состояния проекта.
Учет параметра "ход мышления" обеспечивается в модели через создание коммуникационного следа при разработке программного обеспечения. Таким образом удается удовлетворить информационные потребности разработчиков.
На рис 8. представлен фрагмент информационного основания CommuniCube. Данные проходят через систему контроля версий программ. "Portrait" и "authors.xml" представляют информацию относительно разработчика, который несет ответственность за конкретную часть разрабатываемого кода. Портреты всех
остальных разработчиков будут появляться по мере их появления в проекте. Персонализация информации выполняется информационным фильтром. Информационный фильтр осуществляет персонифицированное ХМЬ-представле-ние проектных данных.
Выводы
В данной статье представлены результаты анализа основных проблем проектов международной распределенной разработки ПО: географическая удаленность участников, разница во времени, культурные различия. Определены основные области исследования — коммуникация, тип мышления, культурные различия, уровень руководства проектом. Все эти факторы влияют на уровень риска распределенной разработки ПО. Авторами предлагается процессно-ориентированный подход к анализу рисков аутсорсинга, рассматривающий 7 основных этапов жизненного цикла проекта распределенной разработки ПО. Отмечена необходимость обеспечения каждого этапа реализации проекта различной информацией. Представлена интегрированная модель управления информацией в проекте распределенной разработки ПО. Модель имеет три уровня обработки информации — эксплуатационный уровень, уровень управления и стратегический уровень. Предложена реализация модели
CommuniCube
XML-представление проектных данных
Рис. 8. Фрагмент информационной базы модели управления проектом распределенной разработки ПО
управления на основе прототипа (коммуникационный куб). Показаны преимущества данного подхода на практических примерах. Отмечена необходимость дополнительных
исследований реализации данного подхода для уровня менеджмента и стратегического уровня модели управления проектами распределенной разработки ПО.
СПИСОК ЛИТЕРАТУРЫ
1. Aubert B.A., Patry M., Rivard S. (1998) "Assessing the Risk of IT Outsourcing" Proceedings of the Thirty-First Hawaii International Conference on System Sciences, Volume VI, Organizational Systems and Technology Track, Hugh Watson editor, Hawaii. P. 685-693.
2. Aubert B.A., Dussault S., Patry M., Rivard S.
(1999) "Managing the risk of IT outsourcing," System Sciences, 1999. HICSS-32 Proceedings of the 32nd Annual Hawaii International Conference on.
3. Balasubramaniam R. and Amrit T. (1999) "Supporting Collaborative Process Knowledge Management in New Product Development Teams" in Decision Support Systems, Volume 27, Issues 1-2. P. 213-235.
4. Balzert H. "Softwaremanagement: Lehrbuch der Softwaretechnik". Spektrum Akademischer Verlag; Auflage: 2. Aufl. (Februar 2008)
5. Beimborn D., Lamberti H. and Weitzel T. (2006) "Game Theoretical Analysis of Cooperative Sourcing Scenarios". In Proceedings of the 39th Annual Hawaii international Conference on System Sciences Volume 08.
6. Benaroch M. (2002) "Managing Information Technology Investment Risk: A Real Options Perspective", Journal of MIS, Vol. 19, No. 2. P. 43-84.
7. Betz S., Mäkiö J. (2008) "Applying the OUT-SHORE approach for risk minimisation in offshore outsourcing of Software Development projects", Multikonferenz Wirtschaftsinformatik (MKWI) 2008, February 2008, München, Germany.
8. Boehm B.W. (1981) Software Engineering Economics. Prentice-Hall Inc., Englewood Cliffs, NJ.
9. Carmel E. (1999) Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall, NJ, USA.
10. Carmel E. and Agarwal R. (2001) "Tactical approaches for alleviating distance in global softwaredevelopment", Software, IEEE Volume 18, Issue 2. P. 22-29.
11. Carnegie Mellon University, Software Engineering Institute. (1995) A Systems Engineering Capability Maturity Model VersionSM 1.1. available on http://www. sei.cmu.edu/pub/documents/95.reports/pdf/mm003.95. pdf. Accessed May 2008.
12. Carnegie Mellon University, Software Engineering Institute. (2002) Software Aquisition Capability Maturity Model Version 1.03. available on http://www. sei.cmu.edu/pub/documents/95.reports/pdf/mm003.95. pdf. Accessed May 2008.
13. Carnegie Mellon University, Software Engineering Institute CMMI for Development available on
http://www.sei.cmu.edu/publications/documents/06. reports/06tr008.html Accessed May 2008.
14. Carnegie Mellon University, Software Engineering Institute. CMMI for Acquisition. available on http://www.sei.cmu.edu/publications/documents/07. reports/07tr017.html. Accessed May 2008.
15. Casey V. and Richardson I. (2006) "Uncovering the Reality Within Virtual Software Teams", Workshop on Global Software Development for the Practitioner, Shanghai, China. P. 66-72.
16. Curtis B., Hefley W.E., Miller S.A. (1995) People Capability Maturity Model [P-CMM]. UK: Addison-Wesley.
17. Curtis B., Kellner M.I. and Over J. ( 1992) Process Modeling. Commun. ACM 35, 9, 75-90.
18. de Souza, C. R. B., Redmiles, D. F., Mark, G., Penix, J. Sierhuis, M. (2003) "Management of Interde-pendencies in Collaborative Software Development: A Field Study. ISESE, Rome, Italy. P. 294-303.
19. Glaser B. and A. Strauss (1967) "The discovery of grounded theory: Strategies of qualitative research", Wiedenfeld and Nocholson, London.
20. Grinter R. E., Herbsleb J. D., and Perry D. E. (1999) "The geography of coordination: dealing with distance in R&D work." In Proceedings of the international ACM SIGGROUP Conference on Supporting Group Work.
21. Heindl M. and Biffl S. (2006) "Risk management with enhanced tracing of requirements rationale in highly distributed projects." In Proceedings of the 2006 international Workshop on Global Software Development For the Practitioner.
22. Herbsleb J. D. and Moitra D. (2001) "Global Software Development", IEEE Software, March/April. P. 16-20.
23. Herbsleb J., Zubrow D., Goldenson D., Hayes W. and Paulk M. (1997) "Software quality and the Capability Maturity Model". Commun. ACM 40, 6 (Jun. 1997). P. 30-40.
24. Hertzum M. (2002) "The Importance of Trust in Software Engineers", Assessment of Choice of Information.
25. Humphrey W.S. (1990) Managing the software process. Reading, Massachusettes: Addison-Wesley Publishing.
26. Kautz K., Hansen H. W. and Thaysen K. (2000) Applying and adjusting a software process improvement model in practice: the use of the IDEAL model in a small software enterprise. In Proceedings of the 22nd international Conference on Software Engineering Limerick, Ireland.
27. Kerzner H. (2000) "Project Management: a systems approach to Planning, Scheduling, and Controlling", John Wiley & Sons Inc., USA.
28. Khalid A., Khalifa H. J. (2007) "Virtual Classrooms And The Flexibility Of E-Learning In The Gulf Universities", Journal of Knowledge Management Practice, Vol. 8, No. 3.
29. Ko A. J., DeLine R. and Venolia G. (2007) Information Needs in Collocated Software Development Teams. In Proceedings of the 29th international Conference on Software Engineering May 20-26.
30. Kraut R.E. and Streeter L.A. (1995), "Coordination in large scale software development", Commun. ACM 38, 7. P. 69-81.
31. Krishna S., Sahay S. and Walsham G. (2004) "Managing cross-cultural issues in global software outsourcing." Commun. ACM47, 4.
32. LaToza T.D., Venolia G. and DeLine R. (2006) "Maintaining Mental Models: A Study of Developer Work Habits", ICSE, Shanghai, China. P. 492-501.
33. Moczadlo R. (2005)"Chancen und Risiken des offshore-Development - Empirische Analyse der Erfahrungen deutscher Unternehmen", Germany.
34. Perrons R.K and Platts K. (2004) "The role of clockspeed in outsourcing decisions for new technologies: insights from the prisoner's dilemma", In Industrial Management & Data Systems, vol. 104, no. 7. P. 624-632(9).
35. Perry D. E., Staudenmayer N. A., Votta L.G. (1994). "People, Organizations and Process Improvement." IEEE Software, July. P. 36-45.
36. Pierce R. and Tilley S. (2002) "Automatically Connecting Documentation to Code with Rose". Proceedings of the 20th Annual International Conference on Systems Documentation (SIGDOC 2002: October 20-23, 2002; Toronto, Canada). P. 157-163. ACM Press: New York, NY.
37. Roberts R. (2005) "Offshoring: Individual Short-Term Gain versus Collective Long-Term Loss?", IT Professional, vol. 7, no. 4. P. 25-30, Jul/Aug.
38. Vashistha A. and Vashistha A. (2006) "The Offshore Nation: strategies for Success in Global Outsourcing and Offshoring", McGraw-Hill.
39. Wang M., Lu Y., Zhang J. (2006) "Software outsourcing risk management: establishing outsourcee evaluation item systems". Journal of Zhejiang University SCIENCE A, Vol. 7 No. 6. P. 1092-1098.
УДК 339.138
Павлов Н.В.
Содержание и этапы маркетингового
УПРАВЛЕНИЯ ПРоДУКТоМ
В понятие "экономический продукт" большинство современных авторов включает материальный продукт, интеллектуальный продукт и услуги.
Одно из наиболее значимых явлений, произошедших в экономике в последние годы — изменение структуры экономического продукта. Новые, зачастую — принципиально новые продукты появляются все чаще. Возрастает роль интеллектуального продукта и услуг.
Деятельность по управлению продуктом является важной частью маркетинговой деятельности в организациях, причем на современном этапе в области управления продуктом также происходят важные изменения, которые должны отвечать изменениям экономического продукта.
Таким образом, теоретические и практические разработки в рассматриваемой области, включая и создание учебных курсов по управлению продуктом, могут получить дополнительный стимул, если будут уточнены рамки деятельности по управлению продуктом, которые в настоящее время оказались несколько размытыми.
Данная статья посвящена определению содержания, стадий и этапов маркетинговой деятельности по управлению продуктом.
Существует ряд мнений относительно содержания деятельности по управлению продуктом. Обычно комплекс маркетинга в организации разбивается на составляющие, среди которых практически всегда выделяется компонент "продукт" [7]. Иногда содержание компонента
