Требования к стандартизации IT-компаний, которые часто имеют проектную структуру, диктуются необходимостью внедрения изменений в организациях на различных уровнях проектов. «Для получения более эффективных результатов требуется вести учет особенностей каждого отдельного проекта или программы, для поиска несоответствий между ожиданиями и возможностями компании» [1].
Управление изменениями в IT-компаниях постоянно сопряжено с высокой долей неопределенности результата, и данный аспект является одним из самых сложных. В статье описываются результаты исследования, которое посвящено стандартным практикам планирования и их внедрения на уровне производственного проекта разработки программного обеспечения, даются практические выводы и рекомендации, которые позволяют подойти к процессу внедрения изменений системно и учитывать часто встречающиеся риски. «Особое внимание уделено мерам по сохранению позитивного микроклимата в команде проекта, а также способам преодоления организационного сопротивления и реакции членов команды на изменения» [2]. «Быстро осуществляемые изменения без подготовки производственных процессов, даже в случае объективных причин, могут негативно отразиться на отношениях в команде и снизить авторитет проектного менеджера» [3].
Проводилось исследование по «методу Дельфи», проходило в 3 раунда с 1 октября 2015 г. по 28 декабря 2015 г. В состав экспертов входил 21 специалист, участники занимали руководящие должности, в основном это проектные менеджеры с командами от пятнадцати сотрудников и более, производственные директора, директора по качеству и высшее руководство IT-компаний.
В 1-м раунде эксперты высказывали свое мнение по вопросам из предложенного списка. Формулировались вопросы в рамках двух тем: лучшая практика и опыт внедрения изменений на уровне проекта, перспективы инструментов автоматизации и развития процессных моделей на постсоветском пространстве в течение следующих 10 лет.
Вопросы подразделялись на три типа: открытые, возможно высказать любое, в том числе своё мнение; закрытые, возможно выбрать только один из предложенных вариантов ответа; закрытые, возможно выбрать один и более ответов из предложенных вариантов.
Во втором раунде, проводилось сравнение ответов всех экспертов по каждому вопросу с доминирующим мнением. Эксперты, чьи ответы расходились с общей позицией, имели возможность скорректировать свою точку зрения и либо присоединиться к мнению большинства, либо должны были прокомментировать свой ответ.
В последнем, третьем раунде подводился итог исследования, уточнялась полученная информация и в случае необходимости запрашивалась дополнительная.
Подробно рассмотрим процесс обработки ответов экспертов и оформление результатов.
Анализ ответов на открытые вопросы, которые были получены в первом раунде, выделяли общие тенденции, они будут приведены в данной статье. Для всех вопросов закрытого типа определялся преобладающий ответ – общее мнение панели.
Результаты, которые получились в ходе следующего раунда, были использованы для подведения итогов исследования. Вопросы, в которых возможны были несколько вариантов ответа, составляли ранжированный список, в первом пункте которого был преобладающий ответ, а для вопросов с одним возможным вариантом ответа строились столбчатые диаграммы.
Показатели активности участников по раундам представлены в таблице.
Активность экспертов по раундам
|
Раунды |
||
1 |
2 |
3 |
|
Количество экспертов, чел. |
21 |
16 |
21 |
Доля ответивших экспертов, % |
100 |
76 |
100 |
Во втором раунде произошло снижение активности экспертов, что является характерным для данных исследований.
Виды компаний, которые получили приведенный в исследовании опыт, представлены на рис. 1. Данный опыт подтверждает соответствие между желаемой и действительно получаемой информацией для IT-компаний схожего типа.
Рис. 1. Распределение экспертов по типам софтверных компаний
Следует отметить, что распределение участников по странам и городам распределилось следующим образом. Представители стран постсоветского пространства заняли 10 %, представители Украины – 14 %, города Москва и Санкт-Петербург – 57 % и остальные города России – 19 %.
Наиболее многочисленной была средняя возрастная группа, возраст экспертов от 30 до 40 лет – 62 %, от 40 до 50 лет – 33 % и от 20 до 30 – 5 %.
В сфере IT данный возраст ассоциируется с расцветом творческого потенциала сотрудника. Эксперты старше пятидесяти лет в исследовании не участвовали.
Для современных организаций, в том числе и проектных компаний, вопросы стандартизации и внедрения изменений на уровне всей организации неизбежно приводят к изменениям на уровне каждого проекта и программы. И невозможно обойти вопрос о роли руководителей проектов, их значимость возрастает, а к рискам, которые свойственны всем процессам внедрения, добавляются специфические риски для каждого проекта. «Существенное изменение подразумевает такое изменение, при котором члены проектной команды, не поддерживающие их, не смогут выполнить часть своей работы корректно, что приведет к существенному снижению качества продукта» [4].
Наиболее важным видом деятельности руководителя оказалось определение приоритетов между текущей работой проектной команды и внедрением изменений, с этим согласилось почти 80 % экспертов.
Опыт около 60 % экспертов показывает, что руководитель проекта должен:
– руководить им напрямую, либо является инициатором внедрения изменений;
– участвовать в подведении итогов и анализе результатов.
Резюмируя вышесказанное, ключевым фактором успешности данного процесса становится вовлечение руководителя проекта в управление изменениями на уровне проекта и сохранения баланса между затратами ресурсов на осуществление изменений и достижение текущих целей проекта.
Эксперты отметили важность планирования при внедрении, первая группа – очень важно, вторая группа – иногда важно, третья группа – несущественно и четвертая – вредно для целей проекта, изменений на уровне проекта в целом рис. 2.
Рис. 2. Ответы экспертов на вопрос «Насколько важно планирование внедрения изменений в производство ПО» на уровне проекта?
Рис. 3. Ответы экспертов на вопрос «Насколько важен учет внедряемых изменений производственных процессов в плане производства продукта проекта?»
Участники исследования отметили, что запланированные изменения производственных процессов поддерживаются основной массой рядовых сотрудников и предоставляют возможность собрать различные мнения на более ранних этапах внедрения, чтобы вовремя скорректировать будущие изменения и получить максимальное количество данных о возможном организационном сопротивлении, а не непосредственно при внедрении изменений.
Вывод экспертов о важности учета процесса внедрения изменений в основном производственном плане проекта, первая группа – очень важен, вторая группа – иногда важен, третья группа – неважен и четвертая – не следует это документировать в проектном плане изменений на уровне проекта в целом на рис. 3.
При анализе учета процесса внедрения выделились следующие недостатки. Для него становятся очевидны дополнительные риски реализации проекта, и тем самым заказчик получает возможность проследить влияние производственных изменений на главные цели проекта. Восприятие проектного плана усложняется. Несмотря на выделенные недостатки, планирование и ведение документации происходящих изменений производственных процессов на уровне проекта повышает его шансы на более успешное внедрение нововведений.
Эксперты выделили две классические причины внедрения изменений в производственные процессы: потребность в изменениях, которые продиктованы текущими экономическими условиями проекта, с этим согласны более 90 % экспертов и потребность следовать требованиям внешних аудиторов, заказчика, регуляторов рынка, с этим согласны около 40 % экспертов. Также участники отметили, что возможными причинами внедрения могут быть следующие:
– необъективность и произвол руководителя проекта;
– требования следовать стандартам компании;
– обязательное повышение процессной зрелости отдельно взятого проекта, вызванное особыми требованиями заказчика.
Участники отметили, что цели внедрения изменений согласуются с целями проекта, благодаря этому приоритетная реализация приводит к увеличению скорости работ по внедрению. Руководитель проекта и его команда, руководящая внедрением изменений, обязана учитывать этот факт на всех этапах, а также согласовывать сроки и цели внедрения изменений с проектными целями на этапе планирования. Это позволит избежать организационного сопротивления и саботажа со стороны сотрудников, повысить их мотивацию и уровень поддержки проектных менеджеров.
Эксперты выявили типичные проблемы при внедрении изменений:
– конфликты между целями проекта и целями внедрения изменений, встречались в практике около 73 % экспертов;
– организованное сопротивление проектной команды, с ним сталкивались более 50 % экспертов.
Участники определили основные причины приведенных проблем, среди них:
– неполное вовлечение членов проектной команды, включая и руководителя, в управление изменениями;
– плохое разъяснение будущей деятельности в необходимом объеме;
– нечеткое понимание целей изменений проектной командой.
Веская причина, которая указывает, что группа участников не вникает в суть внедрения, подтверждается цитатой из исследования: «Команда проекта не понимает, что проведение изменений в конечном итоге имеет те же цели, что и проектная деятельность, то есть удовлетворение потребностей заказчика и получение прибыли или успешное производство продукта проекта» [5].
Одним из самых эффективных способов преодоления организационного сопротивления около 90 % участников назвали «вовлечение сопротивляющихся сотрудников в процесс внедрения изменений», несмотря на то, что этот процесс требует больше временных затрат и приложения значительных усилий.
Более 60 % экспертов отметили положительную мотивацию к работе по новым правилам у большинства членов команды.
В порядке убывания рейтинга составлены следующие ответы экспертов и выделены следующие средства закрепления изменений в практической деятельности команды, создающей ПО:
– внимание и аудит со стороны руководителя проекта;
– поощрение при применении новой практики;
– контроль со стороны смежных отделов, цехов производства;
– запись или протокол внедрения изменений.
Эксперты пришли к мнению, что закрепление изменений в проектной документации пока не часто используется в практике. Но, это важнейший шаг, который ведет к инициированию положительных изменений на уровне других проектов или организации в целом.
Участники исследования не смогли прий-
ти к единому мнению относительно целесообразности привлечения внешних консультантов к процессам внедрения, это указывает на различия в опыте экспертов и нестабильности качества услуг консультантов.
Совершенно четко прослеживается влияние на внедрение существенных изменений в проектные практики на всех этапах лиц, заинтересованных в результате внедрения: заказчики, спонсоры, представители офиса управления проектами. Проектный менеджер и команда, управляющая внедрением изменений, должны постоянно учитывать это влияние.
Результаты исследования привели к следующим выводам.
1. Планирование и документирование изменений в рабочих планах проекта способствует повышению их прозрачности и позволяет на ранних этапах изменений составить мнения проектной команды.
2. Руководитель проекта играет важную роль во внедрении изменений на уровне проекта, даже в случае, когда не он выступает в качестве инициатора. Весомыми факторами успеха проведения изменений являются поддержка и лояльность проектного управляющего и его вовлечение в управление процессом.
3. Перед внедрением процессных изменений на этапе их планирования следует сопоставить время на осуществление изменений со временем разработки собственно самого проекта.
4. Принципиально важно по-разному подходить к планированию процессных изменений в IT-компаниях различающихся по численности работников с учётом современных форм организации производства софта (ПО). Следует понимать, что сами разработчики ПО, по крайней мере, в состоянии разобраться в сути предлагаемых процессных изменений. Поэтому в малых коллективах с более простой схемой процессных изменений, доступной для охвата пониманием всеми работниками целиком, обязательно надо получить их мнения и предложения по изменениям. Это позволит избежать части сопротивления проектной команды и повысить действенность изменений для успешности проекта. В крупных проектных командах при сложной схеме производственных процессов, особенно в условиях оффшорного программирования, эта проблема не стоит так остро из-за разобщенности работников и естественной «зашоренности» их представлений обо всём проекте.
5. Основные проблемы, возникающие при внедрении изменений в производственную практику проекта: различия и в некоторых случаях даже конфликтность между целями изменений и целями самого проекта и сопротивление изменениям, которое оказывают в организации проектной команде.