CC BY
183
УДК 338.364.2
ПРОБЛЕМЫ ВНЕДРЕНИЯ ИЗМЕНЕНИЙ В ПРОЕКТЕ РАЗРАБОТКИ И ВНЕДРЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Д.С. Пащенко
Внедрение изменений в производственные процессы в проектах разработки программного обеспечения (ПО) имеет различные причины, но всегда сопряжено с многочисленными трудностями, сопротивлением коллектива и необходимостью управления различными сопутствующими рисками. В статье приведен общий алгоритм внедрения изменений на уровне производственного проекта, приведены типичные сложности и пути их преодоления. В статье частично приведены результаты авторского исследования 2013 года в регионе СНГ, в рамках которого специалисты отрасли определяли типичные проблемы стандартизации производства и процессов внедрения изменений в производство ПО.
Ключевые слова: Внедрение изменений, проект разработки ПО, стандартизация производства ПО, организационное сопротивление, роль руководителя проекта.
Вступление
Общий уровень процессного развития российских 1Т-компаний остается на весьма низком уровне, поэтому внедрение значительных изменений в производственные процессы на уровне отдельных производственных проектов остается актуальной проблемой. Довольно часто компании не обладают стандартизированными производственными практиками или не идут дальше декларации их наличия. В таких условиях в каждом проекте складывается своя культура производственных процессов, в которой сочетаются традиции самой 1Т-компании, привычки менеджера проекта и ведущих специалистов, ожидания и стандарты конкретного заказчика и еще целый набор смутных и иногда нелогичных факторов влияния. В таких условиях внедрение изменений на уровне проекта становится единственной возможностью построить эффективное производство продукта проекта и даже иногда повысить мотивацию команды. Более того, многие крупные изменения в общих корпоративных процессных моделях и стандартизация всего производства программного обеспечения (ПО) в софтверных компаниях начинаются с отдельных производственных проектов, «вырастая» потом в общекорпоративные практики. Вопреки авторитетному мнению [1] многие менеджеры проектов внедрения программного обеспечения (ПО) отчетливо видят взаимосвязь между детерминированностью производственных процессов и успешным завершением проекта, а значит - внедрение и закрепление изменений, как и стандартизация разработки программного обеспечения, могут существенно повлиять на общий успех проекта.
С другой стороны, внедрение стандартов в производстве на уровне всей софтверной компании подразумевает в дальнейшем их адаптацию и закрепление в практике каждого проекта. Это значит это централизован-
ные изменения раньше или позже приводят к изменениям «на местах» - в конкретных проектах, что делает изучение процесса внедрения изменений на уровне проекта еще более актуальным.
Основной исследовательской задачей в данной статье является определение общих проблем и успешных практик внедрения изменений в организационных и производственных процессах разработки и внедрения программного обеспечения в проектной команде в 1Т-компании. В статье рассмотрены типичные причины и мотивы внедрения изменений, а также общий ход планирования и внедрения изменений в виде цикла внедрения изменений. При этом рассматривается как круг обязанностей менеджера проекта, так и его коммуникации с другими заинтересованными лицами - представителями заказчика, линейными руководителями 1Т-компании, кураторами проекта.
Особенное место в данном процессе занимает сопряжение преобразования организационных и производственных процессов с текущей деятельностью и обязательствами проектной команды перед заказчиком по срокам, уровню качества и функционалу разрабатываемого продукта проекта. Текущий прогресс производства и риски, связанные с основными целями проекта, оказывают огромное влияние на успешность и непрерывность процесса внедрения изменений, поэтому руководитель проекта вынужден всегда управлять данной взаимосвязью, учитывая нюансы обоих процессах.
Причины изменений
Рассмотрим основные группы причин, побуждающие к внедрению изменений в производстве на уровне отдельно взятого проекта:
- Внешние для проекта причины:
- Следование общекорпоративным стандартам;
- Следование требованиям аудиторов, заказчика или рынка.
- Внутренние для проекта причины:
- Объективная необходимость изменений;
- Субъективное навязывание изменений руководством.
Следование общекорпоративным стандартам в проекте может быть
обусловлено переходом всей компании к новой модели производственных процессов. В таком случае руководители проектов имеют возможность принять участие во внедрении изменений еще на стадии их общекорпоративного планирования и детализации. С другой стороны довольно часто в проектах происходит десинхронизация следования уже принятым стандартам, и тогда существенные отклонения, требующие корректировки выявляет внутренний аудит.
Однако, внешний аудит, заказчик и даже изменения на рынке также могут инициировать существенные изменения в производственных процессах. Так внешний аудит может выявить неисполнение проектной командой взятых на себя контрактных обязательств. Заказчик (как внешний, так и внутренний) может побуждать проектную команду к повышению
эффективности текущей работы. Да и сам рынок программного обеспечения довольно стремительно меняется: меняются не только подходы к разработке, но и базовые технологии, что также может стать причиной существенных изменений в производственных процессах.
Авторское исследование, проведенное в СНГ в конце 2013 г и посвященное изучению проблем стандартизации производственных процессов создания ПО [2], показало, что наиболее частой причиной внедрения изменений на уровне проекта является объективная необходимость. Это означает, что требования к изменениям формируются по результатам анализа текущих результатов работы и соотносятся с будущими задачами. При этом в исследовании были выделены наиболее распространенные и типичные роли руководителя проекта при внедрении изменений в производственные процессы:
- Определяет взаимные приоритеты текущей работы и процесса внедрения изменений;
- Инициатор / Прямой руководитель всех процессов внедрения изменений;
- Участвует в подведении итогов и анализе результатов.
При этом исследование также установило, что цели внедрения изменений в производстве ПО на уровне проекта лишь в очень редких случаях могут быть приоритетнее, чем цели текущей проектной деятельности (например, создания продукта проекта). Очевидно, что проектная команда и ее руководитель всегда будут отдавать значимый приоритет основным целям проекта.
Также среди внутренних сценариев, побуждающих к изменениям на проектном уровне, следует выделить следующие:
- Внедрение антикризисного управления в проекте;
- Смена руководителя проекта.
При этом с исследовательской точки зрения интересным является случай внедрения в проекте антикризисного управления, сопровождающийся, как модификацией текущих практик в производстве, так и внедрением абсолютных новых подходов, направленных на повышение эффективности работы проектной команды. В следующем разделе данной статьи будет приведен пример из личного опыта автора, иллюстрирующий антикризисное управление на уровне отдельного проекта.
Этапы цикла внедрения изменений
Рассмотрим основные этапы внедрения изменений на уровне проекта, а также связанные с ним риски и типичные проблемы, иллюстрируя это примерами внедрения изменений в производственных проектах в различных российских 1Т-компаниях. Ключевая особенность внедрения на уровне проекта заключается в том, что график внедрения изменений должен быть определенным образом сопряжен с графиком создания продукта проекта. При этом упомянутое выше исследование показало, что для ре-
спондентов является действительно важным отражение активностей по внедрению изменений в общем проектном плане создания продукта проекта. Мнения участников исследования приведено на следующей диаграмме (здесь приведены проценты мнений от общего количество экспертов, участвовавших в исследовании):
Рис. 1. Важно ли планирование и учет внедряемых изменений в производственных процессах в общем плане производства продукта проекта? 1 - Очень важно; 2 - Иногда важно; 3 - Не важно; 4 - Не следует это документировать в проектном плане.
Кроме этого, организация проектных команд (тип матричной структуры софтверной компании) определяет общий уровень влияния, как руководителя проекта, так и отдельных линейных руководителей. Это означает, что организационная структура также является существенным фактором во внедрении изменений в производственные процессы на уровне проекта. Так, например, в компаниях с «сильной» матрицей успешность внедрения изменений в процессы на уровне проекта напрямую зависит от уровня авторитета руководителя проекта.
При этом остается очень важным поддержание постоянных коммуникаций между руководителем проекта и линейными руководителями на всех этапах планирования и внедрения изменений. Особенно эти коммуникации важны при обнаружении и преодолении организационного сопротивления: обычно линейные руководители гораздо лучше знают личные качества подчиненных, что позволяет быстрее налаживать контакт и обсуждать противоречия, возникающие при внедрении изменений.
Типичная схема внедрения на уровне проекта похожа на схему внедрения на уровне всей компании [3] с некоторыми упрощениями: Пла-
нирование изменений - Подготовка среды к изменениям - Детализация изменений - Внедрение изменений.
ЦЕЛИ ПРОЕКТА УБ. ЦЕЛИ ИЗМЕНЕНИЙ
ОЦЕНОЧНЫЙ ПЛАН ИЗМЕНЕНИЙ
Корректировка целей, планов, карты рисков
Выявление групп сопротивления
ОЦЕНКА УРОВНЯ СОПРОТИВЛЕНИЯ
Подготовка среды к изменению
Формальное информирование
Определение значимых параметров: цели, сроки, бюджет и т.д.
Риски: оценка, планы, контроль
Планирование изменения
Детализация изменения
Рис. 2. Жизненный цикл внедрения изменений на уровне проекта
в софтверной компании.
Безусловно, каждый этап занимает существенно меньше времени, чем при внедрении на уровне компании, а приоритет целей создания продукта проекта обуславливает итеративный подход к внедрению изменений. Более того, в каждый момент времени внедрение изменений подразумевает соответствие внедряемых практик текущему этапу проекта (особенно для итеративных практик типа КиРУМБЕ).
Начнем с этапа планирования изменений, в котором определяющую роль играет тип мотивации к внедрению изменений. Именно этот мотив определяет состав участников, планирующих будущие изменения. Мы уже указали, что мотивация может быть внутренней и внешней по отношению к проектной команде, а в ее основе может быть, как объективная необходимость, так и субъективные факторы.
В любом случае при внедрении изменений на уровне проекта руководитель «сопрягает» план внедрения изменений и план производства продукта проекта. С практической точки зрения это означает внесение в
проектный план дополнительных активностей и появление в карте рисков проекта дополнительного набора рисков, связанных с внедрением изменений. К создаваемым активностям и поправкам в плане проекта относятся: дополнительные аудиты, изменения сроков работ, выделение дополнительного времени для обучения членов проектной команды новшествам. Также изменения в производственных процессах подразумевают внесение правок в конфигурационный план проекта, в т.ч. связанных с автоматизацией производственных процессов.
В самом распространенном случае планирование следующего релиза (этапа проекта) включает дополнительные трудозатраты на внедрение изменений. Из личного профессионального опыта приведем анонсированный ранее пример планирования проекта, в котором было введено антикризисное управление, повлекшее значительные изменения в процессах внедрения программного обеспечения.
На момент введения антикризисного управления проект опаздывал на 10 месяцев, при этом проектная команда даже не начинала структурированную разработку программного обеспечения, продолжая работать над требованиями и второстепенными документами по ГОСТ, практическая ценность которых также стремилась к нулю из-за накапливающихся противоречий и общей потери актуальности задач проекта и ожиданий заказчика. При этом создаваемые прототипы информационной системы автоматизировали лишь часть основных требований, и в большей степени демонстрировали принципиальную готовность команды проекта к разработке системы, чем какой-либо программный продукт.
Антикризисное управление было направлено на завершения затянувшегося этапа Анализа и Проектирования, согласование аналитических документов и начало полномасштабной разработки самой системы. Таким образом, построение процессов разработки (планирование, мониторинг, анализ успешности, коррекция) совпало с перепланированием всего проекта и установлением реалистичных сроков разработки, отладкой процесса тестирования. При этом в сроки разработки, риски и конфигурационный план были внесены поправки, связанные с организационными сложностями. А именно: с необходимостью переформирования проектной команды, создания практик стабильного выпуска релизов, тестирования промежуточных версий, управления требованиями. В итоге план проекта в части этапа Разработка (завершается выпуском релиза-кандидата, закрывающего 90-95% требований проекта) был продлен на дополнительные два с половиной месяца, согласованные с Заказчиком. Проектная команда перешла на регулярный выпуск релизов, не смотря на многочисленные технические проблемы с интегрируемыми технологиями, и впервые за всю историю проекта сдала релиз-кандидат в назначенный срок.
Приведенный пример иллюстрирует следующие моменты:
- Антикризисное управление и внедрение изменений в процессы и
артефакты проекта является одним из базовых условий мобилизации проектной команды и перехода к регулярному исполнению работ проекта;
- Основные усилия в планировании изменений в процессах внедрения ПО прилагает руководитель проекта, жёсткие условия проекта только увеличивают уровень директивности управления;
- Даже явные сложности с такими параметрами проекта, как сроки и бюджет, позволяют учитывать в планировании проекта усилия по реорганизации производственных процессов разработки.
На этапе планирования внедрения изменений важную роль играет взаимодействие руководителя проекта с другими потенциально заинтересованными лицами:
- В матричной структуре это линейные руководители соответствующих отделов, объединяющих аналитиков, разработчиков и тестировщиков;
- В проектных компаниях директора направлений (портфелей, практик) могут быть заинтересованы в планировании производственной деятельности на процессном уровне;
- В высокоразвитых компаниях, имеющих офисы процессного развития и ББРО, внедрение изменений на проектном уровне встречается очень редко. Вовлечение специалистов офиса процессного развития в таких случаях обязательно.
При этом планирование изменений интересует вышеуказанных лиц прежде всего на уровне конечных целей изменений, а контроль основных параметров (сроки и затраты) обычно остаются на уровне самого проекта. При этом своевременное информирование и координация интересов с линейными руководителями подразделений может существенно помочь как в осуществлении изменений, так и минимизации сопутствующих негативных последствий.
Перейдем к рассмотрению этапа «Подготовка проектной команды к изменениям», который является обязательным, но не занимает так много времени, как при внедрении изменений на уровне всего предприятия. Наиболее популярным и действенным шагом в подготовке команды проекта к изменениям в производственных процессах является набор встреч руководителя проекта к командой, посвященных информированию и планированию изменений. При этом очень важна обратная связь, позволяющая определить на раннем этапе уровень сопротивления изменениям и перечень проблем, которые необходимо учесть. Естественным результатом данного этапа является детальный рабочий план внедрения изменений, вносящий изменения в основной план производства продукта проекта. Также карта рисков проекта дополняется специфическими рисками, которые связаны с внесением изменений в организационные и производственные процессы.
На этапе «Детализации изменений» руководитель проекта должен начать работу с выявленными группами сопротивления и скорректировать планы по внедрению изменений благодаря полученной обратной связи. Конечно, данный этап на уровне проектной команды не занимает много време-
ни, но уже сейчас становится очевидна одна из ключевых проблем в будущем процессе внедрения - возникновение организационного сопротивления, противодействующего внедрению и закреплению изменений [5]. В упомянутом выше исследовании более чем половина экспертов отметила четкую необходимость преодоления организационного сопротивления при внедрении изменений в производство ПО на уровне проекта. Эксперты выделили следующий список эффективных методов преодоления организационного сопротивления (в порядке убывания эффективности и популярности):
- Вовлечение сопротивляющихся сотрудников в процесс внедрения изменений (более 90% экспертов использовали в своей практике);
- Положительная мотивация к работе по новым правилам;
- Компромисс по срокам и объемам внедрения изменений;
- Разъяснение с элементами директивного подавления.
Данный результат подчеркивает, что «жесткие» методы на уровне проекта отнюдь не являются популярными, а руководители проекта, как правило, даже в тяжелых моментах поддерживают позитивный микроклимат в проектных командах.
На этапе «Детализации изменений» вовлечение сопротивляющихся сотрудников может заключаться в следующих приемах:
1. Сбор мнений сотрудников и предложений по улучше-нию\адаптации запланированных и анонсированных изменений. Интересным представляется привлечение отдельных лиц с наметившейся тенденции неприятия и сопротивления к профильной экспертной оценке тех или иных нововведений. При этом, чем более профильным будет запрос на такую экспертную оценку, тем больше пользы это принесет производственным процессам и тем сильнее будет возникающее чувство сопричастности к нововведениям.
2. Закрепление за группами сопротивления или отдельными лицами отдельных участков работ во внедрении будущих изменений, тесно связанных с другими задачами. Данный прием ставит членов команды во взаимозависимость не только с точки зрения достижения основной цели проекта, но и с точки зрения результатов внедрения изменений в производственных процессах. Производство ПО в любых современных методологиях подразумевает, что для каждой технологической операции будут как параллельные процессы, так и соседние звенья - последующая и предыдущая технологические операции [6]. Внедрение изменений в любую операцию неизбежно оказывает влияние на соседние звенья, что обеспечивает вовлечение во взаимодействие большее количество специалистов и некоторую солидарную ответственность за результат внедрения изменений.
На следующем этапе цикла - «Внедрение изменений» - происходит реализация плана внедрения и закрепление результатов в рабочей практике коллектива. На данный этап приходится основная часть усилий, и он занимает самую весомую часть времени во всем цикле.
Список ключевых практик, необходимых для успешного внедрения изменений в производственные процессы на уровне проекта на последнем этапе цикла, можно сформулировать следующих образом:
1. Реализация плана внедрения изменений;
2. Управление сопутствующими рисками;
3. Преодоление организационного сопротивления.
Реализация плана внедрения изменений подразумевает его постоянную корректировку, т.к. процесс закрепления изменений часто носит долгий и нестабильный характер, а предсказать все возникающие и противодействующие факторы просто невозможно. В этом смысле популярной стала практика «компромиссов по срокам и объемам внедрения изменений», когда изменения внедряются не целиком, а постепенно и только после стабильного закрепление предыдущей части нововведений. Не смотря на логичность такого подхода, практика показывает: растянутый процесс внедрения изменений на уровне проектной команды имеет существенные недостатки. Во-первых, члены проектной команды не могут жить в череде постоянных изменений, и это негативно сказывается на микроклимате и производительности труда. Во-вторых, существенные изменения в параметрах основного проекта и\или ожиданиях от продукта проекта могут раньше или позже оставить изменения незавершенными. По мнению автора, разбитие внедрения изменений на какие-то компромиссные части возможно только, как крайняя мера, когда мотивация к изменениям проектной команды падает, а проект испытывает серьезные сложности в части своих основных параметров - сроков, качества продукта проекта и объема выполненных работ, бюджета и т.п.
Управление рисками внедрения изменений в целом характеризует опыт инициатора изменений и существенность всех подготовительных работ, проведенных на более ранних этапах цикла внедрения изменений. Типичные риски, ставшие очевидными на данном этапе, чаще всего укладываются в следующий список:
1. Риски, связанные с затратами ресурсов на внедрение изменений;
2. Риски, связанные с микроклиматом команды и ее общим уровнем производительности;
3. Риски, связанные с влиянием изменений на проектные параметры и продукт проекта.
Преодоление организационного сопротивления на этапе «Внедрение изменения» должно быть сформировавшимся, регулярным и осознанным. В течение подготовки коллектива проекта к изменениям и детализации изменений все «островки недовольства» и группы сопротивления должны быть выявлены, а на текущем этапе к каждой группе должен быть применен комплекс мер и приемов. Из практики следует, что неумелое внедрение изменений может добавить количество недовольных, но в основу оценки успешности преодоления организационного сопротивления в
команде проекта можно положить следующее эмпирическое правило:
- Если к середине запланированного срока последнего этапа в цикле внедрения изменений (вне зависимости от прогресса, но с учетом временных корректировок) в команде не остается ни одного центра активного сопротивления изменениям, значит комплекс мер по преодолению сопротивления эффективен.
При этом, конечно, кто-то может быть по-прежнему недоволен, кто-то покинул команду, а кто-то пассивно сопротивляется изменениям. Однако, если центры сопротивления остаются, руководитель проекта и\или инициатор изменений к середине временного срока этапа «Внедрения изменений» должен применить аварийный план для преодоления организационного сопротивления.
Вовлечение групп сопротивления на этапе «Внедрение изменения» - это распространенный и действенный прием, повышающий шансы на успешное внедрение изменений. Даже на завершающем этапе цикла изменений члены команды обладают возможностью повлиять на развитие производственных процессов в своем проекте, а это значит и ощущение сопричастности, и большая согласованность изменений, и даже повышение качественного уровня новшеств. Иллюстрацией такого вовлечения на последнем этапе цикла является пример из авторского опыта [4]: при внедрении производственной процессной модели члены команды на завершающем этапе получили задания - подготовить инструкции, описывающие создание отдельных проектных артефактов или, например, целые процессы. Члены команды в соавторстве подготовили восемь инструкций, среди которых были, например:
- Принятые практики создания ЦМЪ диаграмм;
- Управление запросами на изменение;
- Правила проведения интервью по сбору требований.
Что характерно, создание некоторых инструкций было инициировано членами команды, и они описывали создание специализированных артефактов, уникальных в данном проекте.
Важной составляющей процесса внедрения изменений является закрепление новых практик в команде: будь то какое-то средство автоматизации или принципы формирования релизов -необходимо, чтобы внедренные изменения начинали работать на практике. Безусловно, для этого мало издать распоряжение или написать сообщение проектной команде в месен-джере. Как правило, это требует серьезных усилий со стороны инициатора изменений. В упомянутом исследовании среди эффективных шагов по закреплению изменений в практической деятельности команды, создающей ПО, эксперты выделили (в порядке убывания рейтинга ответа):
- Аудит и внимание со стороны руководителя проекта;
- Поощрение использования новой практики;
- Появление контроля со стороны соседних звеньев производства;
- Закрепление в документах проекта.
Хотя документирование изменений в проектной документации по мнению экспертов не стало распространенным методом закрепления новшеств, тем не менее - это один из важных шагов и ведет в том числе к «инициированию положительных изменений в других проектах или на уровне компании».
Заключение и выводы
В данной статье описаны основные проблемы, возникающие при внедрении изменений в производственные и организационные процессы на уровне проекта. Внедрение происходит по определённому логическому циклу, в течение которого планируются цели изменений и уточняются планы по их внедрению, а на завершающем этапе изменения внедряются и закрепляются в производственной практике проекта.
На каждом этапе цикла внедрения изменений необходимо соотносить цели внедряемых изменений с целями проекта, дополняя основной план проекта дополнительными активностями, направленными на повышение успешности внедрения и закрепления новшеств в производственных процессах.
На этапах «Планирование изменений» и «Подготовка среды к изменениям» необходимо активно информировать проектную команду и собирать возможные дополнения к планируемым изменениям. На этапе «Детализация изменений» сущность изменений должна быть очевидна для всех заинтересованных лиц, а основной план проекта дополнен активностями по внедрению изменений. В плане рисков проекта также должен появиться дополнительный раздел, описывающий риски внедрения изменений. Прежде всего, это риски, связанные с расхождением целей изменений и основных производственных целей проекта, а также риски, указывающие на организационное сопротивление. Этап «Внедрение изменения» является самым длительным и трудоемким. На данном этапе основные усилия инициаторов перемен направлены на реализацию плана внедрения и минимизацию негативного влияния всех рисков.
Роль руководителя проекта при внедрении проекта трудно переоценить, однако, поддержание коммуникаций с другими лицами, заинтересованными в успехе внедряемых изменений, позволяет снизить организационное сопротивление и сгладить другие негативные последствия.
В статье приведен разбор риска Организационное сопротивление и работа с данным риском в течение всего цикла внедрения изменений. Очевидно, что чем раньше начинается идентификация и преодоление данного риска, тем меньше его негативное влияние, как на успех внедрения изменения, так и на успех всего проекта.
Руководитель проекта, как правило, оказывается ключевой фигурой в закреплении нововведений в реальной производственной практике, даже если они также поддержаны средствами автоматизации. Закрепление изменений, как правило, требует аудитов и положительной мотивации к работе по принятым нововведениям.
В любом случае внедрение изменений на уровне проекта требует комплексного подхода с учетом всех рисков, являясь своеобразным мини-проектом внутри основного проекта. Успешное проведение такого мини -проекта часто оказывает положительное влияние на производительность труда и мотивацию команды, а значит - успешность производства основного софтверного продукта.
Список литературы
1. Коуберн А. Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения // Humans and Technology Technical Report, Oct.1999 (русский перевод К.Максимов, А.Максимова, Электронный ресурс [Сайт] URL: http: //www.maxkir.com/sd/people_as_nonlinearRUS.htm)
2. Pashchenko D., Blinov A. (2014) Standardization of Software Development in Project Practices in CIS-region: Research Results & Resume» Systems, Software and Services Process Improvement // 21th European Conference EuroSPI Edited: Fergal McCaffery, Rory V. O'Connor, Richard Messnarz
3. Пащенко Д.С. Проектирование организационных изменений в IT-компаниях с учетом факторов противодействия, Менеджмент и бизнес-администрирование 2012 - №4
4. Пащенко Д.С. Особенности реализации проектов организационных изменений в российской софтверной компании, Управление проектами и программами 2014 - №1
5. Занковский А.Н Организационная психология // М. Флинта, 2002
6. Фокс Дж. Программное обеспечение и его разработка, Пер. с англ. // М.: Мир, 1985
Пащенко Денис Святославович, denpas@rambler.ru кандидат технических наук, MBA, независимый консультант в области разработки программного обеспечения.
ISSUES OF CHANGES IMPLEMENTATION IN PROJECT OF SOFTWARE
DEVELOPMENT
D.S. Pashchenko
Changes implementation in software production process model on the level of project have different causes, but it always have to overcome a lot of problems like organizational resistance and other following risks. In this article there is a common algorithm of changes implementation on project level, defines major problems and approaches of its overcoming. Also there are a part of author's Delphi panel research from 2013, dedicated general issues in software production standardization and changes implementation in production process models.
Keywords: Changes implementation, software delivery project, standardization of software production, organizational resistance, role of project manager.
Pashchenko Denis Svyatoslavovich, candidate of technical science, denpas@rambler.ru, an independent consultant in software development, Russia, Moscow.
