Сообщений 2 
Оценка 10
[+0/-2]
Оценить 
| Сообщений 2 Оценка 10
[+0/-2]
Оценить
|
Центральная и Восточная Европа (включая Россию, Украину и Беларусь) прошли схожий путь эволюции процессов разработки программного обеспечения (ПО), начиная от постсоветских стандартов и заканчивая масштабным влиянием глобальных корпораций. Именно глобальные игроки, как потребители информационных услуг и продуктов, предъявляют наиболее строгие требования к параметрам разрабатываемого программного обеспечения. Вместе с изменением ожиданий и требований потребителей и технологическим прогрессом менялись и производственные процессные модели производителей. Однако вне зависимости от скорости глобализации рынков информационных технологий в СНГ и странах Центральной Европы текущее состояние рынка коммерческого программного обеспечения получилось схожим: в сегменте b2b занимают существенную долю (особенно в области бизнес-приложений) локальные поставщики или поставщики из соседних стран, в сегменте b2c доминируют транснациональные разработчики (в основном, американские). При этом первая волна собственников IT-компаний уже ушла или уходит на пенсию, передавая управление профессиональным менеджерам, а сделки по слиянию и поглощению компаний стали распространенным методом конкурентной борьбы. Очевидно, в течение такой 25-летней истории развития отрасль прошла набор технологических революций, каждая из которых нуждалась в управлении изменениями в производстве в софтверных компаниях.
Управлению изменениями в производстве посвящено много исследовательских работ [1,2,3], а сама история вопроса уходит уже в XIX век. Однако, в силу специфических ментальных и трудовых факторов, управление изменениями в IT-компаниях имеет ряд существенных особенностей. В проводимом исследовании рассмотрен набор этапов внедрения существенных изменений в производственную модель софтверной компании в виде внутреннего проекта. Такой проект состоит из нескольких этапов: от планирования и подготовки команд разработки до закрепления результатов в производственной практике.
В данном исследовании были получены данные и определены мнения о реальном опыте участия во внедрении производственных изменений от 78 IT-инженеров из 14 стран Центральной и Восточной Европы. Выбор данного макрорегиона, как уже было упомянуто, обусловлен схожим сценарием 25-летнего развития процессов производства ПО и в целом бизнеса в области информационных технологий. Условно можно разделить этот эволюционный путь на период стандартов постсоветской эпохи и период движения навстречу западно-европейским и американским стандартам качества и процессного управления в софтверном производстве. Второй этап идет с середины 90-х годов прошлого века и не завершен до сих пор. Безусловно, страны Центральной Европы находятся географически близко к Западной Европе и ее большому рынку информационных услуг, а также уже давно вошли в экономическую интеграцию в составе Европейский Союза. Однако в целом уровень процессного развития софтверных компаний, подтвержденный сертификатами CMMI (при рассмотрении по отношению к численности экономически активного населения в каждой стране) в Центральной и Восточной Европе одинаков [4].
Исследование проводилось по методу Дельфийской панели и было направлено на получение максимально согласованного мнения экспертов панели. В исследовании было выделено несколько секций вопросов, каждая из которых относилась к определённому этапу внедрения производственных изменений проектным методом. Описание и целесообразность такого подхода и основные этапы внутреннего проекта были подробно описаны автором в другом исследовании [5]. Далее приведем набор этапов типичного внутреннего проекта внедрения изменений:
В исследовании основной фокус сделан на специфических рисках и проблемах, сопровождающих внедрение производственных изменений в IT-компаниях на каждом этапе внутреннего проекта. К ним относятся:
Также в статье представлены рекомендации по преодолению типичных рисков и издержек, сопутствующих внутренним проектам улучшения процессов. Рекомендации направлены на поддержание баланса усилий различных структур и ролей в компании и обеспечение наименее затратного по ресурсам и комфортного для коллектива внедрения изменений в производственные процессы создания ПО. Далее мы убедимся, что полученные в исследовании результаты подтверждают общность уровня процессного развития компаний макрорегиона и их развитие навстречу ведущим мировым стандартам. Также отметим, что процессная зрелость, очевидно, связана с качеством программного обеспечения и итоговым коммерческих успехом [6].
Исследование проводилось с апреля по июль 2014 года по методу Дельфийской панели в три раунда и охватило 78 экспертов из Центральной и Восточной Европы, включая Россию, Украину и Беларусь. Все участники исследований являются реальными членами проектных команд разработки ПО (аналитики, разработчики, архитекторы) с большим опытом работы в IT-отрасли. Почти все участники исследований обладают опытом ярких софтверных проектов и представляют ведущие IT-компании своих стран.
В первом раунде экспертам предложен список вопросов, разделенных на секции, двух типов:
с одним вариантом ответа;
с несколькими вариантами ответа;
Во втором раунде мнение каждого эксперта по каждому вопросу сравнивается с доминирующим мнением в панели. У каждого эксперта есть возможность скорректировать свое мнение или прокомментировать доминирующий ответ, указав особенности своей точки зрения.
В третьем раунде подводятся итоги исследования, запрашивается дополнительная и уточняющая информация.
Для вопросов с одним вариантом ответа производится построение столбчатых диаграмм, демонстрирующих распределение мнений после раунда №2. Для вопросов с несколькими вариантами ответа были построены списки, ранжированные по популярности каждого ответа.
В раунде 2 отмечено традиционное снижение активности экспертов, оставшееся, впрочем, в рамках допущений дельфийского метода. В следующей таблице приведена активность экспертов по раундам:
|
Раунд 1 |
Раунд 2 |
Раунд 3 |
|
|
Панель экспертов |
78 |
61 |
78 |
|
Ответившие эксперты |
100% |
78% |
100% |
Табл.1. Активность экспертов панели по раундам исследования.
В следующих рисунках представлены данные по экспертам панели, позволяющие оценить авторитетность собранных мнений, представленный опыт и его географию в регионе исследования.
Приведенный опыт в исследовании чаще всего является релевантным в схожих типах бизнеса в IT компаниях. Типы производств ПО представлены экспертами следующим образом:
Рис.1. Представленный опыт по типам производств ПО.
География представленного опыта и мнений иллюстрируется следующим рисунком:
Рис. 2. Представленный опыт экспертов по странам региона исследования.
Инженеры в основном входят в среднюю по возрасту группу, ассоциирующуюся в отрасли информационных технологий с расцветом творческого потенциала для команд разработки.
Рисунок 3. Возрастные группы экспертов.
При этом подавляющее количество инженеров работают в области разработки ПО достаточно долго, так, в панели весьма мало экспертов, работающих в области информационных технологий менее 5 лет.
Рис.4. Профессиональный опыт экспертов
В данной секции эксперты определяли основную роль стандартизации производственных процессов и ее влияние на основные аспекты бизнеса: успешность разработки ПО, качество программных продуктов или наем специалистов.
Большинство экспертов согласилось, что стандартизация процессов имеет прямое влияние на высокий уровень конечного качества программных продуктов. По мнению некоторых экспертов, стандартизация также может временно снижать уровень качества из-за внесения дополнительных возмущений в текущие бизнес-процессы в течение какого-то ограниченного времени. На диаграмме приведены мнения экспертов (здесь и далее – в процентах от общего количества экспертов в панели):
Рис. 5. Влияет ли общая стандартизация процессов производства ПО на уровне всей компании на конечное качество получаемого софтверного продукта? 1 – Всегда влияет; 2 – Часто влияет; 3 – Иногда влияет; 4 – Почти не влияет.
Также эксперты выделили исключительные случаи, когда продукты высокого качества создаются с помощью условно повторяемых процессов небольшими постоянными по составу командами профессионалов без явной стандартизации и формализации производственных процессов.
Процессы внедрения изменений в производственные процессы в софтверных компаниях растянуты во времени и, раньше или позже, требуют вовлечения инженеров. Эксперты определили необходимость прозрачности данного процесса для разработчиков с самых ранних этапов. С другой стороны, вовлечение большого количества специалистов (особенно с низкой мотивацией и квалификацией), наоборот, затрудняет внедрение изменений и увеличивает сроки и издержки внедрения изменений.
Рис. 6. Должен ли процесс подготовки и внедрения значительных изменений в производство ПО быть прозрачным для команд разработки? 1 – Да, с начала - с этапа планирования; 2 – Да, позже, с этапа непосредственного внедрения; 3 – Нет, это неважно; 4 – Затрудняюсь ответить.
Таким образом, инженеры считают необходимым раннее информирование команд о будущих процессных изменениях, однако уровень детализации такого информирования зависит от особенностей каждого коллектива и масштаба изменений.
Стандартизация процессов и производственная зрелость обладают эмоциональным эффектом, в том числе в области продаж продуктов и услуг в IT-бизнесе, не говоря уже о явных плюсах для повышения качества продуктов и эффективности бизнеса [7]. Интересным представляется оценка инженерами этого эмоционального влияния на привлечение сотрудников и повышение их профессиональной мотивации.
Рис. 7. Эффективно ли декларирование стандартизированных процессов производства ПО и наличие сертификатов при привлечении талантливых инженеров на работу в компанию? 1 – Да, помогает привлечь сотрудников; 2 – Особенного влияния на привлечение специалистов не оказывает; 3 – Скорее отпугивает талантливых инженеров; 4 – Затрудняюсь ответить.
Таким образом, инженеры довольно скептически относятся к влиянию декларируемой зрелости производства на повышение притягательности рабочего места в компании, как для привлекаемых новых сотрудников, так и для текущих. Инженеры отметили, что лишь иногда члены команд разработки испытывают особенную гордость от факта, что работают в компании со зрелыми процессами разработки ПО.
Рис. 8. Является ли работа в компании со стандартизированными процессами предметом особенной гордости для рядовых инженеров и аналитиков? 1 – Почти всегда; 2 – Довольно часто; 3 – Иногда является; 4 – Почти не является.
В данной секции эксперты оценили основные действия, необходимые для подготовки к внедрению производственных изменений, исходя из опыта и практики своих компаний. В этом смысле первый этап планирования, в результате которого появляется некоторый обзор производственного изменения, должен обеспечить вовлечение наиболее заинтересованных сотрудников компании. При этом на следующем этапе подготовки коллектива к изменениям инициативная команда осуществляет формальное и неформальное информирование всех сотрудников о предстоящих нововведениях.
Эксперты не смогли найти зависимостей между регулярностью процесса внедрения новых изменений в производство и усилиями инициаторов на уровне как всей компании, так и отдельных проектов. Обычно часть изменений появляется в информационном горизонте инженеров спонтанно, а усилия по их планированию могут оставаться незамеченными.
Рис. 9. Имеет ли процесс внесения изменений в производство ПО явную регулярность? 1 – Да, на уровне всей компании; 2 – Да, на уровне каждого проекта; 3 – Нет, изменения вносятся спонтанно; 4 – Часть изменений запланирована, часть вносится спонтанно.
Недостаточный авторитет, непрозрачность деятельности, а иногда и невостребованность в софтверных компаниях формальных структур (таких, как Software Process Engineering Group (SEPG), Офис Управления Проектами, Офис процессного развития) размывает восприятие постоянных улучшений процессов в производстве, как одного из ключевых факторов обеспечения качества программных продуктов. В ощущениях и опыте инженеров, показанных в данном исследовании, роль централизованного внесения изменений в производство кажется недооцененной, а на первый план выходят проектные инициативы.
Панель согласилась, что проектный менеджер (ПМ) является ключевой фигурой в инициировании производственных изменений, хотя есть некоторые ограничения: в проектных командах, работающих по гибким методологиям (или классическому MSF), роль ПМ не очень выражена, поэтому любой член проектной команды может являться инициатором изменений в производственных процессах. Кроме того, в компаниях с развитым централизованным процессным управлением в составе Дирекции качества (Офиса управления проектами, SEPG и других структурах) могут быть ПМ, частично вовлечены в деятельность такой структуры.
Рис. 10. Кто обычно инициирует внедрение изменений в производственные процессы разработки ПО? 1 – Проектный менеджер; 2 – Дирекция качества \ процессного развития; 3 – Члены проектных команд; 4 – Первое лицо компании \ дирекции разработки.
Данные результаты еще более подчеркивают, что в большой части софтверных компаний вертикальные коммуникационные линии от директоров к инженерам, относящиеся к развитию производственных процессов, проходят мимо соответствующих формальных корпоративных структур. В восприятии инженеров проектные менеджеры (руководители проектов) являются основными инициаторами изменений. С одной стороны это означает, что бизнес-цели проектов и цели изменений могут быть сопряжены лучше, т.к. управление ими пересекается в одном инициативном лице, с другой стороны – поддержка изменений руководителем проекта становится одним из ключевых факторов успешности.
Эксперты отметили, что, по их опыту, обычно члены проектных команд не имеют много времени для подготовки к значительным изменениям в производственных процессах. При этом, по опыту почти половины экспертов, проектные команды получают информацию о предстоящих изменениях только в начале их реализации. Такая ситуация демонстрирует недостаточность усилий по раннему информированию сотрудников со стороны менеджмента, а также подчеркивает осознанную инженерами необходимость получения информации о предстоящих изменениях заранее.
Рис. 11. Когда обычно о внедрении изменений в производственные процессы разработки ПО становится известно членам проектных команд? 1 – За месяцы до начала внедрения; 2 – За недели до начала внедрения; 3 – В начале внедрения изменений; 4 – Уже после официальной даты запуска внедрения изменений.
Среди эффективных и распространенных методов подготовки сотрудников к производственным изменениям эксперты выделили:
При этом следует учесть разную степень собственной готовности специалистов к такому привлечению. Данная активность требует взвешенного анализа как персонально-профессиональных качеств вовлекаемого в планирование сотрудника, так оценки влияния такого вовлечения на производственные проекты компании. Дополнительная нагрузка, ведущая к переработкам и увеличению рабочего дня вовлекаемых инженеров, наверняка, скажется отрицательно и на планировании изменений.
Экспертная панель также оценила необходимые параметры «буферного срока подготовки команд разработки к внедрению изменений в производственных процессах». Более половины экспертов (55%) из своего опыта оценили, что такой период занимает несколько недель. И только 25% встречали случаи внедрения изменений, когда командам разработки давали менее недели на подготовку.
Целесообразным представляется в течение данного буферного срока осуществлять процедуры по подготовке коллектива к изменениям. Среди таких мер одной из наиболее естественных и простых является информирование сотрудников о предстоящих изменениях.
Экспертная панель определила наиболее популярные типы такого информирования:
Причинно-следственная связь крайне важна в формировании отношения каждого инженера к изменениям [8], исследование показало наиболее распространенные причины внесения изменений в производственные процессы:
Таким образом, именно экономические мотивы являются наиболее распространенными в восприятии инженеров с точки зрения объяснения внедряемых изменений в производстве. Из этого следует, что при обосновании необходимости внедрения изменений среди инженеров инициативной группой должны использоваться экономические факторы и выгоды успешного внедрения и закрепления изменений.
Несмотря на различия в иерархии в командах, работающих по классическим итерационным и гибким методологиям, руководитель проекта, по мнению панели экспертов, несет максимальную личную ответственность за успех внедрения изменений в процессы разработки ПО.
Рис. 12. Кто несет наибольшую персональную ответственность за успех внедрения изменений в процессы производства ПО? 1 – Каждый руководитель проекта производства ПО; 2 – Только руководитель всего производства в компании; 3 – Все члены проектных команд; 4 – Инициатор изменений вне зависимости от его должности.
Это еще раз подчеркивает важную роль руководителей проектов, являющихся ключевыми фигурами, как с точки зрения решения бизнес-задач в производственных проектах, так и с точки зрения управления изменениями. Полученный результат исследования может быть использован в качестве аргумента при вовлечении руководителей проектов в управление производственными изменениями на корпоративном уровне.
В данной секции эксперты выделили основные проблемы, связанные с непосредственным внедрением в практику запланированных изменений, а также типичные риски и необходимый выбор приоритетов в данном процессе.
Непосредственное внедрение и закрепление изменений является наиболее трудоемким и эмоционально напряженным этапом, часто сопровождается возникновением ранее неучтенных рисков. При этом растягивание во времени данного этапа чревато откатами назад в развитии процесса и даже неожиданными сбоями в текущих производственных процессах.
Эксперты выделили наиболее востребованные организационные мероприятия при внедрении изменений в процессы производства ПО:
Таким образом, исполнение устных распоряжений менеджера проекта, вовлеченного в управление изменениями, должно быть поддержано с помощью письменных приказов и изменений в бизнес-процессах на уровне всей компании. Тем более, что такие изменения бизнес-процессов могут быть поддержаны автоматизацией и настройкой соответствующих систем и инструментов.
При этом эмоциональная составляющая в части внедрения изменений является крайне важной, нередко именно она определяет успех закрепления изменений в практике [9]. Поэтому устные распоряжения и личный контроль непосредственных начальников, пользующихся авторитетом у инженеров, не могут быть заменены механически рассылаемыми письмами по электронной почте.
Безусловно, автоматизация технологических операций при разработке ПО – это один из действенных методов внедрения обязательного исполнения измененных процессов. Панель экспертов, исходя из своего текущего опыта, вполне подтвердила данное утверждение.
Рис. 13. Как подкрепляется внедрение изменений в производственные процессы автоматизацией технологических процессов разработки? 1 – Никак не связаны между собой; 2 – Автоматизация процессов позволяет игнорировать изменения; 3 – Автоматизация процессов заставляет следовать изменениям; 4 – Автоматизацию технологических процессов можно умышленно обойти.
Эксперты определили список типичных существенных проблем при управлении изменениями и стандартизации производства IT-компании. Прежде всего, это «Формальное внедрение без результатов и понимания целей» (встретилось в практике 77% экспертов) и «Конфликты между целями проекта и целями внедрения изменений» (встретилось в практике 54% экспертов). Также эксперты отметили существенные риски, сопровождающие внедрение изменений в производство в большинстве IT-компаний:
Рис. 14. Какие риски обычно сопровождают внедрение изменений в процессы производства ПО? 1 – Резкое падение качества ПО и сроков поставки релизов; 2 – Падение мотивации сотрудников проектных команд; 3 – Падение авторитета проектного и\или линейного руководителя; 4 – Общее возрастание конфликтности в проектной команде.
Данные проблемы в восприятии и инженеров, и IT-руководителей являются одинаково актуальными, что подтверждается более ранним авторским исследованием [5]. Безусловно, каждый такой риск требует анализа и мер реагирования.
Панель рассмотрела набор организационных мер, направленных на работу со специфическими рисками управления изменениями в IT-отрасли. Так, эксперты выделили несколько эффективных мер для преодоления организационного сопротивления:
Мотивация команд разработки – это ключевой фактор в управлении изменениями, панель экспертов определила наиболее востребованные методы мотивации для поддержки внедрения изменений в производственные процессы создания ПО:
Денежные штрафы и поощрения оказались куда менее популярными методами мотивации сотрудников. Это означает, что в восприятии инженеров данные методы не приведут к следованию измененным бизнес-процессам и поддержке нововведений.
В теории управления изменениями известен интересный конфликт целей между основным бизнес-процессом и частной целью внедрения изменений в данный бизнес-процесс. Панель экспертов не сочла распространённым случай, когда цели изменений могут быть приоритетнее, чем текущая деятельность по производству продукта проекта.
Однако некоторые эксперты выделили исключительные случаи, когда прямые распоряжения топ-менеджмента делали изменения в процессах более приоритетными, чем основные цели проектов, где внедрялись изменения.
Рис. 15. Насколько часто цели внедрения изменений могут быть приоритетнее, чем текущая деятельность по производству продукта проекта? 1 – Очень часто; 2 – Часто; 3 – Редко; 4 – Никогда.
Также панель экспертов определила наиболее типичные издержки, которые несет проект в течение времени внедрения изменений в производственные процессы:
При этом в подавляющем большинстве проектов отношения с Заказчиком не претерпевали ухудшений при изменении внутренних производственных процессов.
Приведенный список издержек имеет прямое влияние на экономическую составляющую производственных проектов, такие издержки должны быть учтены в плане рисков и рабочем плане, должны быть разработаны соответствующие предупреждающие и корректирующие воздействия. Очевидно, что реализация данных рисков – это длительный процесс, который следует учитывать еще на этапе планирования внедряемых изменений.
Внедрение изменений в производственные процессы требует значительных усилий на всех уровнях компании. В данной секции эксперты поделились своим мнением и опытом в области эффективности применяемых мер закрепления изменений в производственной практике.
Панель выделила типичные организационные меры для закрепления результатов внедренных изменений в производстве на уровне проекта:
Это вновь иллюстрирует важность роли руководителя проекта в управлении изменениями, хотя в производственных проектах он обладает набором более важных обязанностей, направленных на решение основных бизнес-задач.
Новые практики в производстве требуют регулярного контроля исполнения. Эксперты определили востребованность ряда мер контроля исполнения командами разработки новых стандартов производства ПО:
Между тем, для некоторых экспертов идея аудита со стороны руководителя проекта кажется странной, т.к. они определяют его рабочие активности в достижении целей самого проекта без глубокого погружения в процесс закрепления изменений в производственных процессах. Таким образом, регулярный мониторинг производственного прогресса в восприятии инженеров отягощается дополнительным аудитом со стороны проектного менеджера. Более логичным представляется разделение ответственности за контроль исполнимости новых производственных практик между руководителем и тим-лидом команды проекта.
Также эксперты в соответствии со своим опытом и опытом своих компаний в управлении изменениями оценили результаты производственных преобразований. При этом инженеры воспринимают полученные результаты преобразований более оптимистично, чем IT-менеджеры [10].
Рис. 16. Насколько успешно обычно достигаются цели внедрения изменений в производстве ПО? 1 – Почти все цели утрачиваются; 2 – Часть целей утрачивается, детали меняются; 3 – Достигается большая часть целей; 4 – Цели достигаются, а результаты превосходят ожидания.
Также панель высказала свое мнение о зависимости между количеством попыток внедрения изменений и их конечной успешностью. Данное мнение подчеркивает, что в восприятии инженеров:
Рис. 17. Является ли каждая следующая попытка внедрения изменений в производстве ПО потенциально более успешной в рамках одного коллектива? 1 – Каждая следующая попытка имеет меньше шансов, чем предыдущая; 2 – Количество попыток внедрения изменений не имеет значения; 3 – Каждая следующая попытка имеет больше шансов, чем предыдущая; 4 – Затрудняюсь ответить.
Анализ результатов внедрения изменений в производство ПО очень важен, однако, не менее важно организовать его своевременно. Панель экспертов отметила по опыту своих компаний, что в основном анализ результатов внедрения изменений проводится спустя значительное время после их завершения.
Рис. 18. Когда проводится анализ завершенного внедрения изменений в производстве ПО? 1 – Сроки могут быть любыми; 2 – Анализ проводится спустя несколько месяцев после внедрения; 3 –Анализ проводится перед планированием следующих изменений 4 – Никто не проводит никакого анализа.
Внедрение изменений в производственную деятельность должно быть удобным для сотрудников, являющихся основным нематериальным активом IT-компании, при этом негативное влияние изменений на текущие производственные показатели должно быть минимизировано. Эксперты согласовали свое видение возможной регулярности внедрения значительных изменений в производственную модель, указав, что в рамках одного проекта (или итерации проекта) внедрения двух значительных изменений в производственные процессы следует избегать. Из комментариев экспертов следует пояснить, что подразумевались проекты (итерации проектов) длительностью в 4-6 месяцев.
Рис. 19. Какой период времени считается комфортным между двумя идущими подряд внедрениями значительных изменений в процессы разработки ПО? 1 – В рамках одного проекта этого следует избегать; 2 – Несколько месяцев; 3 – Несколько недель; 4 – Затрудняюсь ответить.
Данный результат в совокупности с ожиданиями по успешности идущих подряд попыток преобразований и сроков подведения итогов может стать некоторой основой расписания регулярного внедрения изменений в производство, осуществляемого централизованно. Суммируя все временные промежутки на планирование, внедрение и подведение итогов, можно примерно оценить минимально комфортную для инженеров периодичность внедрения значительных изменений в производство в 7-8 месяцев. Синхронизация таких итераций с производственными итерациями в проектной деятельности является исследовательским вопросом, требующим дополнительного внимания.
Данное исследование рассматривает опыт инженеров и их восприятие изменений в производственных процессах. В исследовании рассмотрены все стадии внедрения изменений, выполненные с помощью внутреннего проекта с соответствующим набором этапов: от планирования до закрепления в производственной практике. Также в исследовании сделан особенный фокус на специфических рисках и методах их преодоления. Неслучайно такие внутренние проекты довольно часто без должного управления рисками оказываются неуспешными, а иногда и вообще не завершаются закреплением изменений в производственной практике. В более раннем авторском исследовании в регионе СНГ [10] обобщенный опыт IT-менеджеров нескольких десятков софтверных компаний показал довольно спорную успешность внутренних проектов и необходимость детального управления рисками в области организационного сопротивления, точного планирования и ресурсного обеспечения.
В целом инженеры в рамках описываемого исследования согласны, что стандартизация производственных процессов оказывает прямое влияние на качество программных продуктов. При этом в восприятии инженеров необходимым и естественным является раннее информирование сотрудников о будущих изменениях в производственных процессах и прозрачность планируемых изменений с самых ранних этапов.
На этапе планирования и подготовки коллектива к изменениям эксперты выделили ряд основополагающих ожиданий и поделились своим опытом. Так, в восприятии инженеров централизованные изменения зачастую не являются таковыми, инициатива изменений размыта среди различных руководящих лиц компании, также эксперты панели оценили значительную часть изменений в производстве как спонтанно возникающие. Это говорит как об искажении информации внутри компании при ее передаче между уровнями иерархий, так и о плохо построенных процессах раннего вовлечения членов проектных команды в планирование изменений. Также эксперты отметили роль менеджера проекта, как одну из основных в инициировании и управлении производственными изменениями, что указывает на сосредоточении в восприятии инженеров в данной роли нескольких коммуникационных линий, в том числе и в области процессного совершенствования.
Наиболее точные рекомендации, относящиеся к данной части исследований, могут быть сформулированы следующим образом: необходимо формализовать процессы централизованного совершенствования производственных процессов. Незаменимая роль в данных процессах отводится соответствующим структурам (дирекции качества, SEPG, офису процессного развития и т.п.). Также необходимо обеспечивать усиленное информирование коллектива компании о такой деятельности, обеспечивать прямой контакт централизованных структур с инженерами компании (по аналогии с другими отраслями экономики). Руководители проектов не могут и не должны быть новаторами в области производственных процессов разработки программного обеспечения, т.к. это отнимает слишком много усилий и времени от их основных управленческих задач. Исключение, пожалуй, составляет гибкое или экстремальное программирование, где изменения (в т.ч. в области производственных процессов) являются частью обязанностей лидера проекта [11, 12]. С другой стороны, менеджеры проектов должны быть вовлечены в изменения, поддерживать их и, согласно ожиданиям инженеров, выявленных в исследовании, нести частичную ответственность за успешность закрепления изменений в производственной практике.
Эксперты панели представили свой опыт на этапе подготовки коллективов к предстоящим изменениям: в значительном количестве случаев командам разработки не предоставляется достаточно времени на подготовку. Выделенные экспертами приемы подготовки коллективов к изменениям являются довольно стандартными: информирование на различных уровнях и вовлечение в планирование изменений. При этом эксперты указали, что существует некоторый «буферный период», в течение которого изменения уже запланированы, но их внедрение не начинаются.
Такой «буферный период» должен быть учтен при планировании внутреннего проекта и может быть использован для максимального вовлечения инженеров и их менеджеров в управление изменениями. Данная рекомендация согласуется с ожиданиями инженеров по обеспечению прозрачности планирования изменений.
Инженеры определили набор наиболее распространенных причин изменений в производственных процессах. При этом в восприятии инженеров экономически обоснованная объективная необходимость является наиболее распространенным случаем, а значит, аргументы экономического характера обязательно должны быть доведены до сведения вовлеченных сотрудников при управлении изменениями в производстве софтверной компании.
Непосредственное внедрение изменений, по мнению панели экспертов, может и должно быть поддержано на различных уровнях:
Эксперты отметили типичные проблемы при внедрении:
Набор рекомендаций, направленных на преодоление данных проблем и рисков, довольно стандартен: раннее информирование сотрудников об изменениях с акцентом на экономические выгоды для проекта, сопряжение целей производственного проекта и целей внедрения изменений и учет возможного падения качества и отставания по срокам производственного проекта в его карте рисков.
Временные производственные проблемы, связанные с внедрением изменений, должны быть учтены и разрешаться с помощью набора корректирующих воздействий, как например, дополнительные временные запасы, расстановка приоритетов требований, дополнительные итерации тестирования.
Эксперты также выделили издержки, сопровождающие процесс внедрения изменений:
В восприятии инженеров организационное сопротивление является существенной проблемой в управлении изменениями, при этом набор организационных мер для его преодоления и мотивации сотрудников к принятию изменений довольно тривиален: разъяснительная работа, положительная мотивация, вовлечение в изменения и т.п. Интересно, что негативная мотивация, связанная с общественным порицанием или денежными штрафами, не воспринимается инженерами как эффективный подход к закреплению изменений. Такое неприятие инженерами негативной мотивации заранее снижает ее потенциальную эффективность, поэтому денежные штрафы не могут быть рекомендованы, как эффективный способ закрепления производственных изменений.
Панель определила набор мероприятий по закреплению изменений, среди которых центральную роль занимают усилия руководителя проекта, что опять косвенно подтверждает слабость специализированных структур (типа SEPG или Офиса процессного развития) и непрозрачность их деятельности для рядовых инженеров. Безусловно, менеджер проекта может быть вовлечен в аудит, но выполнение им аудита на постоянной основе, безусловно, отвлекает его от решения основных управленческих задач.
Несмотря на довольно позитивное восприятие результатов внедрения изменений в производстве, у инженеров все же есть ряд существенных замечаний в части организации централизованных изменений в производстве. Во-первых, спиральный метод с набором итераций представляется наиболее перспективным и оправданным, т.к. последовательность изменений в совокупности делает процесс постоянного улучшения производства ПО более структурированным и предсказуемым. Во-вторых, частота изменений должна быть синхронизирована с производственными (проектными) итерациями таким образом, чтобы не перегружать команды разработки задачами в области управления изменениями. Из результатов исследования можно сделать предположение, что поддерживаемые менеджментом и централизованные итерации по улучшению производственных процессов должны проводиться не чаще каждых 7-8 месяцев. Отдельно отметим, что оптимистичная оценка результатов внутренних проектов по внедрению изменений в производственные процессы может быть частично связана с недостаточной информированностью инженеров и «побочным эффектом» положительной мотивации, призывающей ценить даже самые незначительные победы.
Также следует отметить, что инженеры в недостаточной степени вовлечены в управление производственными изменениями и связывают основные активности (как, впрочем, и ответственность за результат) в данном направлении с руководителями своих проектов. При этом в восприятии инженеров общее централизованное управление изменениями (при его наличии) должно быть более прозрачным для команд разработки.
Приведенные результаты исследования подчеркивают сложность внедрения производственных изменений в IT-секторе и показывают важность налаживания диалога между менеджментом IT-компании и инженерами на самых ранних этапах данного процесса. При этом на каждом этапе внутреннего проекта необходимо обеспечить адресное управление выявленными рисками.
| Сообщений 2 Оценка 10
[+0/-2]
Оценить
|