Бесплатный фрагмент - Управление производственными изменениями в высокотехнологичной компании

Пащенко Денис Святославович.

Управление производственными изменениями в высокотехнологичной компании: монография / Д. С. Пащенко

Рецензенты:

Мосин Александр Валентинович, кандидат технических наук

Миневич Леонид Маркович, кандидат технических наук

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

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

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

© Д. С. Пащенко, 2019

Введение

Управление изменениями стало в XX веке самостоятельной научной дисциплиной, имеющей свои безусловные правила, и отдельным видом консалтинговых услуг, направленным на повышение операционной эффективности, с объемом мирового рынка более 50 млрд. долларов США [1]. Обострение конкурентной борьбы, глобализация рынков и географическое распределение производств, построение слаженных экосистем в бизнесе в XXI веке вынуждают придать данной дисциплине отраслевую специализацию. Более того, компании «новой экономики» [2] действуют в своем собственном своде бизнес-законов, где интеллектуальный потенциал сотрудников и «ноу-хау» являются более значимым активом компании, чем традиционные основные средства и другие материальные активы. Высокотехнологичные компании не слишком зависят от географии их расположения, их бизнес-процессы во многом виртуализированы, производимые ими товары и услуги довольно часто не имеют осязаемой формы, а клиенты и заказчики могут находиться по всему миру. Одним из самых ярких примеров отраслей «новой экономики» являются информационные технологии и, в частности, производство программного обеспечения (ПО). В 2019 году 7 из 10 самых дорогих компаний в мире ведут свою основную деятельность в отрасли информационных технологий [3]; они же являются крупнейшими в мире разработчиками прикладного ПО и Интернет-сервисов.

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

Описывая развитие IT-отрасли, следует указать, что создание и изменение моделей производственных процессов создания ПО, долгосрочные оценки и прогнозирование результатов проектов, научный анализ лучших отраслевых практик имеют более чем 40-летнюю историю. За это время изменились не только фундаментальные рыночные условия отрасли (объем рынка, конкуренция, сферы применения), но и базовые технологии и организационные модели. Однако в рамках введения в данную монографию будут обозначены в нескольких штрихах лишь ключевые производственные модели последних 40 лет.

К середине 70-х годов прошлого века сообщество разработчиков ведущих компаний США не обладало достаточной внутренней самоорганизацией для создания промышленных стандартов собственной деятельности. Традиционно описываемая «модель водопада» на практике оставалась общепринятым подходом. Вместе с этим некоторые лидеры рынка разработки крупных информационных систем вроде IBM создали практические инструкции по управлению проектами и по использованию собственных средств разработки ПО. Однако такие «первые пробы» не выдерживали испытаний при практическом применении и постоянно корректировались.

В 80-е годы XX века потребители программных продуктов были вынуждены сами стандартизировать если не ключевые процессы разработки, то хотя бы качественные параметры продуктов, процессы их проектирования и поставки потребителям. Здесь следует выделить работы Б. Боэма [5, 6] и стандарты описания жизненного цикла программных систем (ISO/IEC, ANSI/IЕЕЕ, DOD/NIST). Данные стандарты регулировали скорее коммерческие взаимоотношения между потребителями и производителями и ожидания по продукции. Несмотря на все усилия организаций, поддерживавших развитие и внедрение данных стандартов, их широкое распространение было достигнуто лишь в долгосрочных программах проектов в области государственных заказов (например, оборонная и космическая отрасли в США).

К началу 90-х годов прошлого века сразу несколько лидирующих компаний пытались вырваться из тисков привычной «модели водопада» в поисках увеличения эффективности процессов производства ПО. Следует выделить несколько причин данной тенденции:

— лавинообразный рост рынка — значительное количество компаний из разных отраслей экономики автоматизируют все больше собственных бизнес-процессов, используя прикладное ПО;

— рост ожиданий потребителей — текущие и потенциальные потребители требуют высокой скорости развития программных продуктов.

Одним из наиболее ярких явлений данной эпохи стало использование итеративных моделей разработки. Стандартизированные и специфицированные итеративные модели разработки были предложены лидерами индустрии прикладного ПО в виде собственных методологий (Rational Software — RUP; Microsoft — MSF; Borland — ALM), что стало основой итеративных процессных моделей.

Такие компании (Telelogic, Rational Software), вдохновленные усиливающимся влиянием ПО на традиционную экономику и ростом рынка заказной разработки ПО, в середине 90-х начали консолидацию программных продуктов, автоматизирующих процессы планирования, разработки и поддержки ПО.

Таким образом, стандартизация и внедрение производственных изменений в IT-секторе мировой экономики носило весьма динамичный, но не централизованный и непоследовательный характер. Даже серьезные академические попытки создания отраслевых стандартов довольно часто оказывались неудачными и требовали постоянных и значительных усилий в продвижении и популяризации на рынке. Так, с середины 80-х годов прошлого века и до сего дня существует, как минимум, два общепринятых мировых стандарта, построенных на итеративных моделях разработки ПО — это стандарты CMM (позже — CMMI) и стандарты ISO (например, ISO/IEC 12207). В данных стандартах подробно описаны все процессные области и процессы, связанные с разработкой программного обеспечения по итеративным моделям.

В течение 90-х годов рынок услуг в области разработки ПО становится глобальным, а IT-аутсорсинг — интернациональным. К середине первого десятилетия текущего века десятки (если не сотни) компаний, сертифицированных по 4-му и 5-му (самым высоким) уровням зрелости CMM, участвовали в глобальном рынке.

Однако рынок ПО продолжал свой лавинообразный рост в начале XXI века. В мире развивались новые классы устройств, работа которых принципиально требовала иных видов системного и прикладного ПО. Такое разнообразие задач автоматизации (и количество конечных заказчиков и потребителей) вызвало значительные изменения в структуре рынка. Традиционные треугольники соотношения цены, качества и сроков проекта получили противоречивые ожидания со стороны различных групп заказчиков.

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

— смена поколений разработчиков, а значит, сдвиг стереотипов и профессиональных ориентиров;

— значительное расширение горизонтов автоматизации бизнес-процессов и разнообразие различных устройств, для которых создается ПО;

— возрастание требований бизнеса и ожиданий потребителей по срокам реализации программных продуктов в ущерб конечному качеству в долгосрочной перспективе.

По своей сути «гибкие» технологии разработки относятся к итеративным моделям. Однако конкретные методики применения Agile сделали последние 15 лет современной истории полем для экспериментов и споров — от полного противопоставления RUP-образных моделей (сейчас также известны как UP — Unified Process) и Agile до слияния обеих парадигм разработки ПО в «гибридных» формах организации производства.

Основные попытки применения и стандартизации «гибких» подходов — это осмысление отдельных практик в рамках «улучшения» определенной области более старых итеративных и инкрементных моделей на базе RUP и MSF. Данный процесс далек от завершения, но основные закономерности можно выделить уже сейчас:

— почти каждая Agile-практика создавалась на основе реального проектного опыта, «отягощенного» специальными рисками и ограничениями по ключевым параметрам проекта;

— почти каждая практика описана в книге ее автора или манифесте последователей;

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

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

Большое количество исследований [7, 8], включая авторские [9, 10], показывают, что на пространстве Восточной Европы и СНГ «гибкие» и «гибридные» модели оказались доминирующими уже к 2015 году. На фоне продолжающегося стремительного роста рынка разработки ПО данная тенденция означает строгую необходимость учета их особенностей при изучении управления производственными изменениями в компаниях, разрабатывающих ПО.

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

В первой главе монографии приведен тематический анализ литературы за последние 20 лет и описана эволюция производственных парадигм и процессных моделей создания ПО.

Во второй главе монографии представлены основные проблемы внедрения производственных изменений в компаниях «новой» экономики, приведены типичные причины и классификация изменений, описан объект изменений — модель производственных процессов, приведен классический процесс внедрения изменений и объяснены его специфические особенности. Также во второй главе описаны результаты авторских исследований, проведенных в 2013–2017 годах и посвященных изучению проблем внедрения изменений в IT-компаниях, организационному сопротивлению и востребованности современных технологий и подходов к разработке ПО в России. Результаты данных исследований приведены для проверки рабочих гипотез:

— о зависимостях развития производственных процессов разработки ПО от отраслевых рыночных тенденций;

— о сложности и ресурсоемкости самого процесса внедрения производственных изменений в IT-компании.

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

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

Глава 1. Эволюция управления производственными изменениями в разработке ПО

1.1. Анализ литературы и опыта лидеров рынка

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

Американская и западноевропейская научно-популярная литература о программной инженерии и анализе эффективности производства ПО условно делится на следующие категории:

— Регулярные исследования и отчетные конференции отраслевых научных организаций (стандарты ISO, модели CMMI, своды правил Agile-сообществ).

— Отдельные книги и статьи самостоятельных исследователей, как например, Ф. Брукс или Т. Демарко, обобщающие практические результаты собственной работы автора в одной или нескольких IT-компаниях.

— Регулярно обновляемые справочники по средам разработки ПО, моделям производственных процессов и средствам их автоматизации от ведущих лидеров рынка — Microsoft, IBM, Oracle, Google.

В данной монографии не будет производиться обобщение всех теоретических и практических исследований в области технологий программной инженерии и свойств программных продуктов за последние 50 лет: эти обобщения уже сделаны в различных диссертационных работах [11] и пособиях [12]. Отметим весомый вклад таких исследователей, как Ф. Брукс, Б. Боэм и А. Коберн. Также стоит упомянуть, что отрасль стремительно изменяли многолетние усилия института Карнеги — Меллон (CMU SEI), а в настоящее время десятки тысяч компаний в мире повторяют последовательно улучшаемые производственные модели лидеров рынка — Google, IBM, Microsoft, SAP, Oracle. В течение последних 15 лет популяризация исследований о практиках разработки ПО в компаниях из Кремниевой Долины позволяют новейшим тенденциям стремительно проникать на самые обширные мировые рынки экспорта услуг по разработке ПО — в Китай и Индию [13, 14].

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

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

— Программную инженерию как область деятельности и знания.

— Производственные процессы создания ПО (процессную модель).

— Стандартизацию и формализацию производственных процессов создания ПО.

Рассмотрим данные ключевые понятия и их взаимосвязь в теоретическом представлении ученых в 2000–2019 годах. Глубокое понимание процессов разработки ПО и эволюции основных производственных парадигм позволяет точно понимать сам объект изменений, а значит, повышает шансы на успешный подбор и реализацию методов внедрения изменений.

Приведем интегрированное определение программной инженерии [6] — установление и использование обоснованных инженерных принципов и методов информатики для достижения эффективности в получении, использовании и поддержке ПО, которое создается вовремя, не превышает выделенных бюджетных средств и удовлетворяет выдвигаемым требованиям. Развитие программной инженерии как научно-практической дисциплины неразрывно связано с кризисами отрасли разработки ПО и преодолением возникающих противоречий и проблем (технологических, экономических, методологических).

Важно для темы данной работы проанализировать отдельные ключевые понятия и их эволюцию в научных монографиях и исследовательских работах. Это позволяет представить общее изменение рынка, как в части ожиданий потребителей, так и в части исследований реальных изменений в производстве ПО. Анализ литературы и опыта компаний построен по восходящей линии прогресса — от более консервативных производственных парадигм, присущих оборонным предприятиям и российским «IT-заводам», выполняющим разработку ПО для отстающего госсектора экономики, к современным подходам и процессным моделям, применяемым российскими компаниями, обладающими мировым уровнем конкурентоспособности. Отметим, что в России и Восточной Европе очевиден глубокий разрыв между академическими изданиями о программной инженерии и практикой работы лидирующих компаний данной отрасли — Яндекса, Люксофта, ЭПАМ, Лаборатории Касперского.

Среди российских ученых следует, прежде всего, выделить Владимира Васильевича Липаева, который в течение нескольких десятилетий описывал развитие отечественного опыта крупных проектов разработки ПО, сравнивал практику проектов авиационно-оборонного комплекса с лучшими мировыми стандартами (ISO-SPICE) и моделями (CMMI v. 1.1 и 1.2), применял в своих проектах в конце прошлого века господствовавшие в то время водопадные производственные модели и систему всеобщего управления качеством (TQM) при разработке ПО.

Программную инженерию В. В. Липаев [15] рассматривает как часть системотехники, наделяя разработку ПО соответствующими чертами данной дисциплины:

— важностью компромисса между заявленными и возможными результатами проекта;

— необходимостью эффективного обеспечения жизненного цикла продукта;

— применением комплекса мер для поддержания высокого качества выпускаемых продуктов.

Само же программное обеспечение в силу личного опыта В. В. Липаев считает частью какой-либо технической системы, во многом лишая ПО его самостоятельного значения и возможности стать ключевым фактором конкурентоспособности в современном бизнесе. В монографиях автора [16, 17] теоретические подходы к рациональной организации производства в компаниях, выпускающих ПО, описаны терминами и стандартами крупных промышленных производств и опираются на проектный опыт этого автора в советской и российской военно-авиационной отрасли. Меж тем современные лидеры рынка, напротив, стараются отдалиться от подходов из традиционной промышленности; они избирательны в применении даже самых очевидных инженерных принципов: автоматизации, разделении труда, управлении качеством продукта, организации цикла производства.

Также В. В. Липаев в своем научном труде [15], ставшим классикой в отечественной бизнес-информатике, рассматривает среди множества моделей процессов жизненного цикла систем и программных средств три фундаментальных подхода из XX века: каскадный, инкрементный и эволюционный. Учитывая необходимость адаптации любой методологии производства ПО для конкретного проекта, он вводит понятие «профиль стандартов» как совокупность возможностей (процессов, артефактов, стандартов), необходимых для стандартизации производственных процессов и преследующих цели снижения трудоемкости программного продукта, повышения его качества, улучшения функциональной и платформенной масштабируемости. Применение профиля стандарта позволяет адаптировать производственную процессную модель к конкретному проекту, использовать только актуальные процессы и артефакты, учитывать все многообразие уникальных технических и экономических параметров. Такие профили стандартов могут включать в себя и процессные модели по ISO 15288 (12207) и стандарты CMMI v. 1.3 и элементы классического системного анализа. Аналогичный подход в западной литературе называется «тейлорингом процессов» и также подробно описан в стандартах группы CMMI. Адекватным местом расположения описания профилей стандартов должен быть устав проекта — ключевой документ, создаваемый во время инициирования проекта и получивший центральное место при описании процессов управления в моделях PMI [18].

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

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

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

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

В своей монографии об экономике в разработке сложных программных систем [16] В. В. Липаев детально описывает подходы к оцениванию и управлению экономической эффективностью производства ПО. Он уделяет большое внимание формализации производственных и управленческих процессов, специализации сотрудников в команде, автоматизации и стандартизации каждого этапа производства: от планирования и прогнозирования характеристик проекта до испытаний готового продукта. Сложность алгоритмов и предметной области и размер программного продукта — это основные факторы, влияющие на оценку всех ключевых параметров соответствующего проекта: сроков завершения, уровня качества, бюджета. Однако в данной работе В. В. Липаева есть ряд существенных особенностей, о которых следует рассказать отдельно. Так, существенным отличием в его практике анализа трудоемкости проекта по созданию ПО является факт вычленения работ по системному и бизнес-анализу из общей оценки. Специфика личного опыта В. В. Липаева и государственных заказчиков, очевидно, требует проведения отдельных научно-исследовательских и «конструкторских» работ до запуска разработки ПО; различные аналитические работы в таком случае оцениваются и анализируются отдельно, не попадая ни в одну из моделей, описываемых автором (например, COMOCO 2 или «Прометей»). В практике современной коммерческой разработки это скорее исключение, чем правило: все результаты консалтинговых или научно-исследовательских работ становятся просто входящей информацией для аналитических работ в проекте, а не заменяют их. Другой (и во многом архаичной!) рекомендацией автора является оценка сроков реализации проекта на основе измерения скорости создания строк кода, что в современных языках и средах объектно-ориентированного программирования имеет мало практического смысла (за исключением низкоуровневого программирования для аппаратного обеспечения, как, например, ПО для панелей управления самолетом или кораблем).

Экономические обоснования проектов разработки ПО в монографии В. В. Липаева излагаются в духе традиционной экономики XX века: маркетинговые исследования востребованности ПО, выделение специалистов для прогноза экономической эффективности производственных процессов, формирование коллективов для экономически эффективного производства. При этом организация такого экономически эффективного производства опирается на формализацию производственных и управленческих процессов, обязательное использование артефактов управления проектом — рабочего плана, плана рисков, интеграционного плана, плана управления качеством продукта.

В качестве организационных мер повышения экономической целесообразности производства ПО данный исследователь предлагает:

— на оперативном уровне — организовывать регулярные встречи проектных команд для анализа экономической эффективности производственных процессов;

— на стратегическом уровне — сохранять и повторно использовать модели успешных процессов и подходов к реализации ПО на определенном этапе ЖЦ.

Огромное внимание в работах В. В. Липаева [15, 16, 17] уделяется процессам стандартизации производственных процессов и сертификации систем производства и обеспечения качества в средних и крупных компаниях, производящих сложное ПО. Такие процессы должны быть направлены на преодоление отставания российских программных продуктов и команд по уровню качества и конкурентоспособности на мировом рынке. При этом В. В. Липаев самым тесным образом связывает стандартизацию процессов разработки ПО, уровень качества получаемого продукта и экономику проекта, выделяя следующее: «Радикальное повышение качества производства программных продуктов и обеспечение их конкурентоспособности на мировом рынке возможно только на базе внедрения современных стандартизированных технологий и систем качества, поддерживающих и контролирующих весь их жизненный цикл».

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

Управление изменениями в компаниях, разрабатывающих ПО, В. В. Липаев видел как последовательное повышение зрелости производственных процессов [17], закрепление повторяемости успешных практик, переход к долговременному планированию развития производственных процессов и их широкой автоматизации. К сожалению, специфика личных проектов данного ученого не позволила уделить должное внимание особенностям коммерческого рынка разработки ПО: необходимости преодоления организационного сопротивления и огромной скорости изменений, как в ожиданиях заказчиков, так и в самих технологиях разработки ПО. Данные факторы коммерческого рынка не позволяют применять подходы к управлению изменениями, присущие авиационно-космической промышленности или оборонному сектору: административно-командное давление и внедрение изменений «сверху» и через приказы.

Следующим этапом в исследовании подходов к разработке ПО в отечественной практике стали работы С. А. Орлова [19, 20], в которых при анализе производственных моделей разработки ПО нашли свое отражение современные мировые тенденции. В работах С. А. Орлова вместе с популярными производственными моделями из XX века рассматриваются «гибкие» и «бережливые» подходы в разработке ПО и сложные метрики современной экономики IT-компаний. Кроме того, обсуждаются достоинства и недостатки не самых социально позитивных практик, как, например, увольнение ведущих сотрудников или снижение издержек на заработную плату специалистов в проектной команде.

Программную инженерию, отвлекаясь от лингвистических тонкостей, С. А. Орлов рассматривает как эволюционирующий термин. За 50 лет он прошел дистанцию от «системы инженерных принципов для создания экономичного ПО» до «систематического применения научных и технологических знаний», обеспечивающих управляемость и оптимальность всех процессов на всех этапах ЖЦ ПО [20].

Данный автор разделяет процессы разработки ПО на два типа: управленческие и технические. При этом в управленческие процессы входят все типичные процессы управления проектом: планирование, управление рисками и информацией, контроль и мониторинг, принятие управленческих решений. Во многом описание автора дублирует аналогичные описания модели CMMI [21] и PMI — PMBOK [18]. Однако особенный акцент поставлен на процессах управления персоналом. Автор подчеркивает, что «самым ценным ресурсом программного проекта являются, конечно, люди». Процессы управления проектами разработки ПО данный автор существенно отличает от управления разработкой других сложных технических продуктов по следующим причинам:

— затруднены регулярный мониторинг и оценка результатов работы;

— высокая доля инновационности в каждом программном продукте;

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

К техническим процессам относятся процессы по стадиям ЖЦ итеративных моделей: управление требованиями, проектирование архитектуры, разработка, тестирование, инсталляция, поддержка и т. д. Каждый процесс С. А. Орлов делит на составляющие (в порядке убывания значимости): деятельность, действие, задача.

В XXI веке наблюдается стремительный рост востребованности услуг по разработке ПО и рост конкурентной борьбы; стали очевидны изменение ожиданий заказчиков и одновременно вовлечение в отрасль значительного количества разнообразных команд разработчиков, обладающих различными уровнями инженерной грамотности и профессионального опыта. Это приводит к процессному разнообразию в общемировом масштабе — созданию все новых и новых моделей разработки. В основном это переложения инженерных практик машиностроения или методологий из консалтингового бизнеса. С. А. Орлов условно разделяет их на «тяжеловесные» и «облегченные», или «гибкие», процессы [19], подчеркивая, что обе группы моделей производственных процессов имеют адаптивную природу.

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

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

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

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

Интересным подходом к выбору производственных моделей в разработке ПО является предложенная Е. В. Колтуновой модель принципов разработки ПО, которая в зависимости от ценности того или иного проектного параметра позволяет выбрать методологию исполнения проекта. Например, принцип ориентации на выпуск релиза ПО точно в назначенный срок с большей вероятностью позволяет выбрать фрейворк MSF и препятствует полноценному использованию всеобщего управления качеством (TQM), более ориентированному на качество получаемого продукта. Другой красивый пример — это влияние принципа «Определить проблему до того, как записывать требования». При бизнес-анализе в рамках UP/MSF моделей данный принцип соблюдается значительно лучше, чем при Agile-разработке, где требования определяются и сильно изменяются прямо во время прототипирования и разработки в рамках итераций (спринтов).

Однако предложенный подход не безупречен: к сожалению, не все приведенные принципы и сравнения оказались актуальными для современной IT-отрасли. Так, например:

— Е. В. Колтунова противопоставляет объектно-ориентированное проектирование (ООП) и модульное проектирование, что, в принципе, неверно, так как модульное проектирование включает в себя ООП;

— Е. В. Колтунова полагает, что существуют какие-то модели разработки, в которых разработчики не тестируют собственный программный код. В современной практике коммерческой разработки таких команд существовать не должно;

— Е. В. Колтунова отвергает итеративность водопадной модели: возможно, такие проекты существовали в XX веке в оборонной промышленности, однако в настоящее время даже классический «водопадный» подход подразумевает набор этапов, версий продукта и итеративность разработки.

Е. В. Колтунова в своем диссертационном исследовании указывает, что в российской и общемировой практике недостаточно исследована «теория управления изменениями применительно к практике работы компании, разрабатывающей ПО». Настоящая монография должна исчерпывающе раскрыть данный вопрос хотя бы для российской отрасли разработки ПО. Последнее десятилетие прошло в России под знаком неотвратимого увеличения популярности «гибких» методологий; в стране появились десятки консалтинговых компаний, которые позволили значительному числу IT-компаний перейти к «гибким» методологиям разработки ПО. Авторские исследования показали последовательное увеличение востребованности «гибких» методологий на российском рынке разработки ПО в 2013–2017 годах [10, 22]. Аналогичные явления автор выявил в исследованиях в странах СНГ и Восточной Европы [23, 24].

Agile-подходы («гибкие» методологии) существенно изменили отрасль разработки ПО, достигнув нужной эффективности, как для внешнего, так и для внутреннего заказчика. Следует определить набор «гибких» практик, ставших наиболее популярными в России: прежде всего, это Scrum; значительно менее популярны методики экстремального программирования (XP) и Kanban; еще менее популярны практики «бережливого» производства. Вопреки заносчивому маркетинговому позиционированию российских компаний, на своих веб-сайтах и в рекламных проспектах в 2019 году весьма мало отечественных специалистов используют значимое число артефактов или процессов, относящихся к «гибким», но не являющихся классическими для процессного подхода Scrum. И одновременно с этим значительное число команд и компаний, по наблюдению автора, ошибочно называют свои хаотичные и неформализованные процессы разработки модными терминами из мира «гибких» методологий. Следует полагать, что любые «гибкие» подходы требуют высокого уровня адаптации в каждой компании и команде [25], но это не подменяет базовых принципов процессной организации: повторяемости процессов, анализа взаимосвязи исполнения процессов и получаемых результатов, итерационного улучшения процессной модели.

Рассмотрим с помощью анализа американской и западно-европейской литературы, как продолжалась эволюция термина «программная инженерия» после наступления всеобъемлющей популярности «гибких» методологий. На этих рынках «гибкие» фреймворки уже занимают доминирующее положение и начали собственный эволюционный процесс. При этом практический опыт их использования уже многократно описан. Так, Э. Стелман и Дж. Грин в своей работе [26] рассматривают разработку ПО как большую, сложную и специфическую область знаний, а программную инженерию как эффективный метод производства ПО. Однако, по их мнению, многочисленные «кризисы в отрасли» с 60-х годов XX века нуждались в объективном объяснении и наборе корректирующих воздействий, самым радикальным из которых является смена парадигмы производства. Удивительно, но данные авторы игнорируют 30-летнее развитие итеративных подходов вроде UP или MSF и декларируют прямой переход от «водопадной модели» к гибким подходам в XXI веке. Вместе с этим следует признать, что «гибкие» подходы к разработке ПО серьезно изменили суть программной инженерии в XXI веке, постулируя ее новые основные положения:

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

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

— Сплоченность и эффективность Agile-команд более существенна для успеха, чем четкая иерархическая подчиненность внутри IT-компании и даже внутри одного проекта.

Вместе с этим авторы подчеркивают, что не каждая компания и команда может с легкостью использовать «гибкие» подходы к разработке ПО. В своем исследовании Э. Стелман и Дж. Грин ссылаются на три основные причины провалов agile-проектов: «отсутствие опыта в использовании гибких методов», «философия компании расходится с agile-ценностями» и «внешнее давление со стороны тех, кто придерживается водопадной модели».

В работе Хенринга Книберга [27] собран набор практических рекомендаций по внедрению методов «гибкой» разработки в компании, разрабатывающей ПО. Автор демонстрирует, как эфемерные манифесты и принципы превращаются в бизнес-процессы и практику разработки ПО на примере собственных проектов. В данной работе программная инженерия представлена в разрезе «гибких» методологий как формализованный набор процессов и артефактов, особенности которых зависят от накопленного опыта команды и продолжают свое улучшение и развитие на основе мнения всей команды инженеров. Выбираемые параметры таких процессов (как и сам состав процессов) считаются успешными только до тех пор, пока получаемые результаты удовлетворяют потребностям бизнеса компании. Автор подробно описывает шаг за шагом все примененные им лично процессы и артефакты Scrum и инженерные практики экстремального программирования (XP), допущенные ошибки и выводы из полученных результатов. Он настаивает, что не может существовать какой-то законченной модели «гибких» процессов: модель сильно зависит от особенностей проекта и постоянно развивается даже для одной и той же команды.

Однако вместе с этим полноценное и неуклонное использование популярных артефактов, подходов и процессов в гибкой разработке — это ключевой фактор успеха. Их стандартизация и мониторинг исполнения — это основная обязанность Scrum-мастера, в то же время работа над их улучшением — это обязанность всей команды. Более того, практика ретроспективы — критического анализа процессов разработки при выпуске каждого релиза ПО — позволяет полученным результатам и критике процессов выйти за рамки команды и стать частью входной информации для совершенствования «гибких» процессов для других команд в рамках IT-компании.

Управление изменениями в процессах разработки ПО рассматривается в [27] как результат экспериментов в сравнительно большой команде разработчиков. Автор изменял размеры команд, пробовал итерации разработки («спринты») различной длины, выбирал разные способы определения критерия готовности релиза и разные стратегии тестирования, пробовал различные способы демонстрации результатов и способы синхронизации Scrum-команд между собой в рамках всей компании. Также в данных экспериментах было опробовано множество практик экстремального программирования: с разными способами непрерывной интеграции, с парным программированием и «разработкой через тестирование».

Отметим, что в описанном опыте Х. Книберга, ключевые этапы — приемочное тестирование, отладка и вывод ПО в промышленную эксплуатацию — не получили развития в «гибких» методологиях. Поэтому логичными рекомендациями с его стороны стали включение тестировщиков в Scrum-команду и постоянное улучшение качества кода внутри итераций разработки ПО.

В продолжение темы научно-практического описания «гибких» процессных фреймворков следует выделить работы актуальных экспертов из США — Тимоти Листера и Тома Демарко, ставших «живыми классиками». С точки зрения данных авторов, программная инженерия — это не только следование определенным повторяющимся практикам, но и анализ, мониторинг и управление рисками на каждом этапе проекта [28].

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

Авторы рассматривают стандартизацию и формализацию производственных процессов как метод управления неопределенностями в проекте. Для них это некоторые корректирующие воздействия, направленные на предсказуемость ключевых параметров проекта, — ценность для компании, сроки сдачи релиза, бюджет, качество получаемого продукта. При этом Т. Демарко с иронией отмечает, что «единственный по-настоящему значимый процесс — это тот, который определяет, какие проекты стоит осуществлять». Более того, в своих более поздних работах [29] Т. Демарко, основываясь на личном проектном опыте, в еще большей степени считает, что строгое следование одинаковым процессам в различных проектах приводит к дополнительным издержкам, а программная инженерия как научная дисциплина излишне догматична и переполнена устаревшими указаниями и выводами.

При этом управление изменениями в IT-компаниях — это непрерывный процесс, во многом опирающийся на инициативу каждого члена проектной команды. Т. Листер и Т. Демарко подчеркивают, что возможности изменения производственных процессов тесно связаны с текущей корпоративной культурой IT-компании. Ограничения корпоративной культуры могут сравнительно легко затормозить любые инициативы по изменениям.