Оглавление
Скажи мне, и я забуду. Покажи мне, и я запомню. Позволь мне сделать, и это станет моим навсегда. (Китайская пословица)
Введение
Деградация инженерных активов
Стремительные изменения в обществе XXI века заставляют пересмотреть многие устоявшиеся и устаревшие взгляды. Например, общество XX века постулировало неограниченный экономический рост за счёт неограниченного научно-технического прогресса. Но этот путь наткнулся на препятствия ограниченных природных ресурсов и ограниченных интеллектуальных возможностей. В XXI веке постулирована надежда на то, что экономика это искусство использования доступных интеллектуальных возможностей.
Успех организации — вне зависимости от коммерческой или некоммерческой формы собственности, — зависит от профессиональной квалификации коллектива (интеллектуальных возможностей). Рыночный дарвинизм безжалостно банкротит организации, отстающие в профессиональном развитии. Успешность больше не измеряют в показателях ресурсоёмкости и энергоёмкости продукции. Успешность скрыта в интеллектоёмкости, в умениях команды проекта. И чем выше уровень инновационности продукции, тем выше требования к инженерам, умеющим создавать подобную продукцию.
Для компаний, осуществляющих деятельность в области программной инженерии, происходящие изменения в обществе особенно актуальны. Ведь в них капиталом компании служат не средства производства (офисы, компьютеры и сети), а активные умения коллектива инженеров. Сохранность и расширение этого актива — вопрос выживания организации.
Неприятное свойство инженерных активов в том, что они непрерывно деградируют. Причинами деградации можно назвать именно стремительные изменения в обществе. Деградация снижает способности и умения компании самостоятельно осуществлять инженерные проекты. Деградацию сопровождают снижение доходов, рост расходов, и, как следствие, экономическая несостоятельность.
Как же противодействовать деградации интеллектуальных активов в компаниях программной инженерии? Только через развитие профессиональных умений команды инженерных проектов.
Стратегия развития команды проекта
Стратегия развития команды проекта программной инженерии это стратегия противодействия непрерывной деградации инженерных активов компании.
Источниками непрерывной деградации принимают экономические, социальные, политические, культурные угрозы внутренней среды и внешнего окружения. Соответственно, стратегия структурирована по этим факторам среды.
Экономическая составляющая стратегии основана на попытке максимизации потока совокупного дохода компании при условии сохранения совокупного инженерного капитала, который и генерирует этот доход. Экономическая устойчивость компании подразумевает оптимальное использование ограниченных инженерных активов при минимизации непроизводительной траты времени и усилий инженеров.
Инженерные ресурсы не только в стране, но и в мире, крайне ограничены. Быстро нарастить этот ресурс невозможно. Повышение тиражей дипломов не влияет на количество и качество инженерии на рынке труда.
Качество экономической устойчивости можно оценивать показателями:
качества труда команды проекта — условиями труда;
результативности — количеством завершённых командой успешных проектов;
производительности — количеством успешных проектов в заданный период времени;
экономичности — количеством инженерных активов, задействованных в успешных проектах;
эффективности — отношением экономичности к результативности или для периода времени отношения инженерных активов к производительности этих активов.
Социальная составляющая стратегии направлена на стабилизацию социальных отношений в коллективе. Прежде всего на укрепление преемственности и предотвращение конфликтов между сотрудниками. В основу стратегии заложена самостоятельность команды проекта — идея о том, что команда проекта не объект, а субъект развития. Именно команда проекта, а не кто-то посторонний, самостоятельно и осмысленно развивает себя: планирует и реализует план, контролирует и анализирует результаты деятельности. Самостоятельность и андрагогика стратегии противопоставлена доминирующей в настоящее время несамостоятельности, инфантильности и педагогики.
Политическая составляющая стратегии направлена на умение коллектива учитывать плюрализм мнений при реализации инженерного проекта. Политическую составляющую можно оценивать по наличию и качеству организационной документации: правил, регламентов, инструкций и т.п. Организационная документация отражает правила принятия и практику реализации проектных решений.
Культурная составляющая стратегии направлена на превалировании значимости умений команды над индивидуальными умениями инженера. Инженерная культура ценит сотрудничество, преемственность, интерсубъектвное многообразие.
Общие сведения о профиле компетенций
Для обоснования профиля компетенций команды проекта программной инженерии приведены: назначение, методология, онтология, таксономия и морфология.
Назначение профиля компетенций
Профиль компетенций предназначен для оценки самостоятельности команды проекта.
Самостоятельность команды проекта — умение команды проекта устойчиво, адаптивно и разумно управлять потоком инженерных проектов.
Самостоятельность команды проекта оценивают по данным мониторинга и анализа угроз и рисков:
устойчивости команды проекта, зависящей от адаптивности и разумности;
адаптивности команды проекта, зависящей от устойчивости и разумности;
разумности команды проекта, зависящей от устойчивости и адаптивности.
Устойчивость команды проекта
Устойчивость коллектива — совместное умение участников команды проекта развивать и поддерживать между собой надёжные, прочные, разумные, долговременные отношения.
Риск неустойчивости (ненадёжности) команды проекта оценивают как вероятность ущерба самостоятельности и невозможности в дальнейшем осуществлять инженерные проекты. Обычно к неустойчивости приводят:
отсутствие совместных усилий развития и поддержания умений;
отсутствие преемственности инженерных умений при смене состава команды проекта.
Для противодействия угрозам неустойчивости команда проекта разрабатывает стратегию устойчивого развития. Смысл стратегии устойчивого развития в том, чтобы деятельность нынешнего инженерного состава команды проекта не наносила ущерба деятельности будущей команды проекта. Стратегия сфокусирована на развитии коллективных (совместных) умений, а не на индивидуальном повышении квалификации отдельных инженеров.
Развитие устойчивости коллектива — раскрытие потенциала инженерных способностей участников команды проекта и совершенствование умений программной инженерии, основанных на этих способностях.
Ещё раз следует подчеркнуть, что устойчивость затрагивает не только способности и умения текущего состава команды проекта, но и всех последующих составов в неопределённом будущем.
Адаптивность команды проекта
Адаптивность коллектива — умение команды проекта изменять деятельность под воздействием изменений внутренней среды и внешнего окружения.
Риск косности (неадаптивности) команды проекта оценивают как вероятность возникновения состояния, при котором команда проекта не умеет реагировать на внутренние и внешние изменения. Неумение реагировать замечают по:
отсутствию умения предвидеть (визионировать) угрозы;
отсутствию умения организованно противодействовать угрозам, в т.ч. неумение изменять способы руководства, управления, практики;
отсутствию умения в приемлемый период времени восстановить ущерб от негативных последствий.
Разумность команды проекта
Разумность коллектива — умение команды проекта действовать исключительно после обоснования и обсуждения инженерных решений.
Риск неразумности команды проекта оценивают как вероятность наступления состояния, при котором команда проекта не умеет разумно принимать решения. Неразумность замечают по:
отсутствию умения формулировать содержание (суть, смысл) инженерного суждения;
отсутствию умения грамотно оформлять инженерное суждение;
отсутствию умения обосновывать инженерное суждение;
отсутствию умения представлять инженерное суждение команде проекта, обсуждать различные мнения, принимать обоснованные решения;
отсутствию умения применять принятые решения в разрабатываемом инженерном проекте.
Результаты оценки умений самостоятельности позволяют инженерам:
разрабатывать стратегию развития умений команды проекта;
оценивать командные умения новых и действующих участников команды проекта.
Профиль компетенций команды проекта позволяет различать нюансы инженерной организованности в диапазоне:
от самостоятельной, устойчивой, адаптивной и разумной команды проекта;
до несамостоятельной, неустойчивой, неадаптивной толпы дураков в проекте.
Кроме того, профиль компетенций позволяет команде проекта:
Отбирать и включать в свой состав исключительно инженеров, обладающих необходимыми команде умениями. И при этом не обращать внимание на документы об образовании.
Отсеивать ничего не умеющих владельцев дипломов и сертификатов «всех цветов и оттенков серого».
Методология построения профиля компетенций
Поскольку «Инженерия — не наука», для построения методологии профиля компетенций мы использовали метод Grounded theory, отличный от общепринятого гипотетико-дедуктивного метода научных исследований. Метод Grounded theory выбран как более «заземлённый», приближенный к повседневной инженерной практике. Мы строим профиль, исходя из собственной практики, а не научного подхода с его попытками:
вогнать практику в прокрустово ложе научной гипотезы;
подогнать всех сотрудников под одну модель поведения, не учитывая различий способностей и умений;
использовать слишком узкие и надуманные критерии оценки профессиональных умений.
По нашему мнению именно эти недостатки научного подхода приводят к несправедливости, конфликтам, деградации команды проекта.
В применённом нами конструктивистском варианте Grounded theory, выделена активная роль самой команды проекта как аналитика и архитектора профиля. Самоанализ собственной практики позволяет команде проекта учесть нюансы, которые посторонний аналитик не только не заметит, но и не сможет выявить, поскольку не понимает весь исторический и социальный контекст существования конкретной компании и конкретных участников команды проекта. На «Хабре» и в литературе о менеджменте приведена масса примеров, когда посторонние «оптимизаторы» предлагают уволить по их мнению ненужных сотрудников, которые не удовлетворяют надуманным «научным критериям». А на деле именно эти сотрудники являются самым ценным, опытным и продуктивным активом компании.
Для сбора данных мы использовали метод фокус-группы. Фактически наш киберклуб идеально вписался в этот метод. Мы обсуждаем фантастические и практические ситуации, близкие к программной инженерии. Высказываем свои мнения и взгляды на ситуацию, применяем собственный опыт к поиску инженерных решений для выбранной ситуации.
Умения и компетенции
Используемые в профиле понятия «умение» и «компетенция» — не синонимы.
Умение инженера — усвоенный инженером способ выполнения действия с техникой в различных ситуациях.
Компетенция инженера — оцениваемое умение инженера.
Умение более широкое понятие, чем компетенция. Не все умения инженера возможно и необходимо оценивать. В данный профиль компетенций включены лишь те умения инженера, которые:
возможно описать, формализовать, категоризировать;
необходимы команде проектов программной инженерии.
Охват компетенций
Профиль охватывает состав умений, необходимых самостоятельной команде проекта при осуществлении проектов программной инженерии.
Ранжирование компетенций
Разделы профиля ранжированы по уровню необходимости. В начале списка расположены самые необходимые компетенции, затем достаточные. При проведении оценки компетенций команды проекта следует начинать с первых строк списка и последовательно продолжать по направлению к концу профиля. В случае, если какой-либо пункт профиля вы оцениваете негативно, т.е. данная компетенция отсутствует, то продолжать оценку остальных компетенций не имеет смысла. Например,
Требования к команде проекта программной инженерии имеют следующую логику:
В команду проекта должны входить разумные люди, умеющие брать обязательства, обосновывать свои действия, отвечать за результаты действий перед командой проекта.
Команда проекта должна уметь управлять программируемой техникой. Только разумные люди способны управлять всеми стадиями жизненного цикла программируемой техники позволяет осуществлять инженерные проекты в области программной инженерии.
Команда проекта должна уметь организовать свою деятельность. Управление сложной системой стадий жизненного цикла программируемой техники требует сотрудничества множества специалистов.
Команда проекта должна уметь управлять риторикой программной инженерии. Сотрудничество участников инженерного проекта невозможно без обсуждения рабочих вопросов.
Команда проекта должна уметь управлять грамматикой программной инженерии. Умение использовать инженерный язык (схемы, условные обозначения, графики и т.п.) способствует скорости обсуждения и точности понимания. Сотрудничество инженеров требует грамотного рассуждения и обсуждения.
Команда проекта должна уметь управлять логикой программной инженерии. Риторика и грамматика позволяют рассуждать и обосновать инженерное решение, а затем представить это решение для обсуждения команды проекта.
Команда проекта должна уметь управлять ритмом программной инженерии. Обсуждение рабочих вопросов приводит к принятию решений и задаёт ритм деятельности. Без решения нет действия, а действия нет без обоснованного обсуждения.
Онтология профиля компетенций
В онтологии профиля компетенций команды проекта определены применяемые понятия.
Искусство — разумное умение людей.
Разумное умение предполагает целенаправленную деятельность.
Инженерия — искусство инженера управлять техникой.
Инженерия имеет социальную направленность умений (социальные цели), связывающих инженера и пользователя техники. Инженерия объединяет средства действия (технические устройства), разумные способы действия (технику) и осмысленный результат этого действия (польза).
Программная инженерия — вид (класс) инженерии; умения инженера управлять программируемой техникой.
Программная инженерия явление довольно новое и необычное. С одной стороны, непосредственно программный текст это не материальный предмет, которыми оперирует традиционная инженерия. С другой стороны, сложно найти современную технику, при проектировании, производстве, обслуживании которой инженеры не применяли бы компьютерные программы. Программная инженерия как кот Шрёдингера. Она одновременно нигде и везде.
Первые попытки использовать программную инженерию как отдельную отрасль экономики, отличную от традиционной инженерии, быстро наткнулись на ограничения: нехватку умений, опыта, методологии. Быстро пришло понимание, что управление программными продуктами более примитивное занятие, по сравнению с возведением сложных конструкций традиционной инженерией. Глупо сравнивать приложение для смартфона с атомной электростанцией или космодромом. В результате программная инженерия перестала позиционировать себя отдельно от традиционной инженерии, а начала активно заимствовать богатый инженерный опыт, накопленный инженерами тысячелетиями.
Программную инженерию часто представляют как проектирование программного обеспечения. Но это не так! Проектирование — не самый ресурсоёмкий процесс управления программируемой техникой. Гораздо больше ресурсов пользователи тратят на эксплуатацию, поддержание и обслуживание.
Инженерная организованность — умение инженера организовать программную инженерию.
Инженерная организованность это профессиональное сотрудничество инженеров организации (команды проекта), необходимое для достижения общей цели проекта. Только совместные усилия инженеров позволяют управлять сложной техникой. Организованная команда посредственностей с лёгкостью превосходит толпу уникумов.
Инженерная культура — преемственность значимых для команды проекта умений программной инженерии.
Устойчивость команды проекта полностью зависит от инженерной культуры и сохранения преемственности умений.
Инженерная риторика — умение инженера управлять риторикой программной инженерии.
Риторика программной инженерии включает умения формулировать инженерные суждения, обсуждать инженерный проект, вводить правила управления содержательной составляющей инженерной документации.
Инженерная риторика способствует лаконичности обсуждения, скорости и точности понимания суждений. Прежде чем обсуждать инженерный проект, следует создать онтологию — единое понятийное пространство, интерсубъективно понятное всей команде проекта. В онтологию следует включить лишь те понятия, которые связаны с инженерным объектом. Остальное лишь засоряет контекст и размывает лаконичность общения. Управление онтологиями (словарями, тезаурусами) отдельная тема программной инженерии.
Без понимания терминов обсуждение занимает значительно больше времени, требует от собеседников значительных интеллектуальных усилий. Непонимание в ходе обсуждения приводит к возникновению и нарастанию конфликтов, разрушает согласованность и взаимодействие участников проекта. Как следствие, инженерный проект обречён на провал. Классический пример — строительство Вавилонской башни.
Интерсубъективность команды проекта не предполагает единомыслия. У каждого участника команды проекта свой взгляд на инженерный объект. Своё тонкое понимание одних деталей и непонимание, а порой и заблуждение относительно других деталей проекта.
Инженерная грамматика — умение инженера управлять грамматикой программной инженерии.
Инженерная грамматика включает правила управления формой записей и оформления документации. Инженеры используют для общения специальные знаки (условные обозначения), которыми они описывают инженерные объекты (абстракции). Например, архитектура техники это не изображение конструкции, это текст на профессиональном языке инженеров (схемы, чертежи, документация).
Инженерная логика — умение инженера управлять логикой программной инженерии.
Команда проекта должна уметь рассуждать и понимать собственные рассуждения. Все инженерные проекты уникальные, поскольку все ситуации имеют свои нюансы. Никакой существующий опыт, собственный или чужой, полностью непригоден для очередной ситуации и очередного инженерного проекта. Команда проекта вынуждена анализировать отличия ситуаций, абстрагировать и моделировать эти ситуации, а затем синтезировать индивидуальные решения моделируемой ситуации.
Как бы инженеры не старались в проекте всегда возникают противоречия (требований, условий, критериев, параметров) и конфликты (интересов, участников, вариантов решений). Инженеры должны уметь разрешать противоречия и ликвидировать конфликты как внутри команды проекта, так и с внешними участниками (заинтересованными и незаинтересованными лицами).
Компетенции инженерной логики основаны на правилах поиска и разрешения противоречий и конфликтов как в документации, так и в суждениях.
Инженерный ритм — умение инженера управлять ритмом программной инженерии.
Команда проекта должна уметь синхронизировать ритм внутренней среды с ритмом изменений внешнего окружения. Соответственно, различают умения, связанные с внутренним ритмом программной инженерии, а также умения, связанные с внешним ритмом окружения программной инженерии.
Внутренний ритм программной инженерии — умение инженера организовать деятельность во времени и пространстве для достижения успеха проекта.
Ритм программной инженерии связан с регулярным реструктурированием деятельности. Поскольку программная инженерия основана на разделении труда, любой вовлечённый участник проекта зависит от успешной деятельности других участников. Сбой ритма в одном месте приводит к сбою ритма всего инженерного проекта.
Внешний ритм программной инженерии — умение инженера синхронизировать изменения внешнего окружения с изменениями внутренней среды.
Именно поток внешних изменений генерирует поток инженерных проектов и поток изменений к каждому из осуществляемых инженерных проектов.
Таксономия профиля компетенций
В соответствии с вышеприведённой онтологией при составлении профиля компетенций программной инженерии применена следующая таксономия:
искусство
инженерия
программная инженерия
устойчивость команды проекта
инженерная организованность
культура программной инженерии
разумность команды проекта
инженерная риторика
инженерная грамматика
инженерная логика
адаптивность команды проекта
инженерный ритм
Морфология профиля компетенций
Морфология профиля компетенций полностью соответствует введённой таксономии. Профиль компетенций команды проекта программной инженерии структурирован по следующим категориям:
1 Устойчивость команды проекта.
1.1 Инженерная организованность.
1.2 Инженерная культура.
2 Разумность команды проекта.
2.1 Инженерная риторика.
2.2 Инженерная грамматика.
2.3 Инженерная логика.
3 Адаптивность команды проекта.
3.1 Инженерный ритм.
Профиль компетенций программной инженерии
1 Устойчивость команды проекта
1.1 Инженерная организованность
Компетенции инженерной организованности оценивают умения инженера:
1.1.1 Сотрудничать с участниками команды проекта. Вносить свой вклад в общее дело, независимо от конкретной роли в конкретном проекте. Принимать участие во всех ситуациях, затрагивающих команду проекта. В первую очередь в беспрецедентных и незапланированных ситуациях. Адекватно реагировать на неожиданные ситуации.
1.1.2 Участвовать в разработке и принятии правил поведения. Соблюдать утверждённые правила команды проекта.
1.1.3 Участвовать в разработке разделения труда и утверждении должностных обязанностей (ролей).
1.1.3.1 Добровольно принимать на себя права и должностные обязанности.
1.1.3.2 Нести ответственность за как за собственные действия, так и за действия подчинённых.
1.1.4 Оценивать как позитивные, так и негативные последствия своих действий. Нести ответственность за свои действия. Вести себя в соответствии с принятыми командой проекта правилами и этическими нормами.
1.1.5 Регулярно оценивать свои профессиональные умения на соответствие компетенциям профиля программной инженерии. Выявлять достоинства и недостатки. К достоинствам относят лёгкость (отсутствие трудностей) взаимодействия с командой проекта. К недостаткам относят трудности взаимодействия с командой проекта.
1.1.6 На основе анализа и оценки компетенций:
1.1.6.1 Обсуждать с командой проекта выявленные персональные и организационные трудности.
1.1.6.2 Планировать направление персонального развития профессионализма в области программной инженерии.
1.1.6.3 Планировать направление развития профессионализма в области программной инженерии команды проекта.
1.2 Инженерная культура
Компетенции инженерной культуры оценивают умения инженера:
1.2.1 Признавать значимость самостоятельности команды проекта. Развивать устойчивость, адаптивность и разумность деятельности коллектива. Поддерживать интерсубъективное разнообразие как основу укрепления самостоятельности.
1.2.2 Проявлять моральную готовность самостоятельно расширять и совершенствовать свои умения на протяжении всей профессиональной карьеры.
1.2.3 Поддерживать преемственность инженерных умений при смене состава команды проекта.
1.2.4 Перенимать умения коллектива и выступать наставником.
1.2.5 Управлять внутренним климатом в коллективе. Поддерживать инженерную этику деловых отношений в коллективе. Пресекать токсичность отношений.
1.2.6 Проявлять эмпатию к участникам команды проекта. Уважать профессиональные компетенции других инженеров. Признавать их достоинства и указывать на недостатки с точки зрения потребностей команды проекта.
1.2.7 Действовать спокойно и продуктивно. Управлять своим поведением в любых ситуациях. Достойно переносить неудачи. Преодолевать негативные эмоции неудач и конфликтов.
1.2.7.1 Управлять конфликтами в команде проекта:
1.2.7.2 Не создавать, обходить, уметь разрешать конфликты.
1.2.7.3 Не переводить конфликты идей в эмоциональные конфликты.
2 Разумность команды проекта
2.1 Инженерная риторика
Компетенции инженерной риторики оценивают умения инженера:
2.1.1 Обсуждать детали проекта с участниками команды проекта.
2.1.2 По отношению к собственным суждениям:
2.1.2.1 Формулировать собственные суждения.
2.1.2.2 Спокойно, без эмоций воспринимать критику своих суждений.
2.1.2.3 Доказательно отстаивать своё мнение о достоинствах и недостатках.
2.1.3 По отношению к суждениям других участников команды проекта:
2.1.3.1 Анализировать и оценивать суждения других участников проекта.
2.1.3.2 Выявлять достоинства и недостатки, ошибки и проблемы суждений.
2.1.3.3 Доказательно отстаивать своё мнение о достоинствах и недостатках.
2.1.4 Искать и предоставлять команде новые и дополнительные сведения, полезные для реализации инженерного проекта. Адаптировать и применять полезные сведения в практике команды проекта.
2.1.5 Управлять обсуждением в конфликтных ситуациях. Избегать личностных конфликтов, переводить обсуждение в конструктивное русло в попытке разрешить возникшие противоречия.
2.2 Инженерная грамматика
Компетенции инженерной грамматики оценивают умения инженера:
2.2.1 При обсуждении грамотно излагать суждения в письменной форме.
2.2.2 Грамотно оформлять инженерную документацию.
2.3 Инженерная логика
Компетенции инженерной логики оценивают умения инженера:
2.3.1 Визионировать (предвидеть) и выявлять трудности потребителей.
2.3.2 Абстрагировать и моделировать сложные ситуации деятельности потребителя.
2.3.3 Управлять моделями. Разрабатывать новые и применять существующие модели.
2.3.4 Управлять логическими рассуждениями в т.ч. в составе команды проекта.
2.3.5 Управлять ошибками. Выявлять ошибки и исправлять ошибки инженерного проекта.
2.3.6 Управлять проблемами. Выявлять проблемы, генерировать варианты решений, принимать решения проблем.
2.3.7 Использовать аналогии. Использовать опыт других областей деятельности, выходящих на рамки программной инженерии, при управлении ошибками и проблемами.
2.3.8 Адаптировать к текущему проекту ранее применённые решения.
2.3.9 При решении инженерной проблемы творчески использовать синкретическое пространство умений команды проекта. Оценивать различные подходы. Выбирать наиболее перспективные подходы (способы, методы, умения).
3 Адаптивность команды проекта
3.1 Инженерный ритм
Компетенции инженерного ритма оценивают умения инженера:
3.1.1 Точно по времени и требованиям выполнять на практике принятые на себя обязанности. Следовать принятым командой проекта решениям.
3.1.2 Ставить перед собой цели и достигать цели, определённые командой проекта.
3.1.3 В установленном командой проекта порядке выполнять поручения (задания).
3.1.4 Мотивировать себя и команду проекта.
3.1.5 Решать проблемы самостоятельно без давления со стороны руководителей команды проекта.
3.1.6 Планировать своё время. Составлять личный план работ.
Выводы
Рассуждения о профиле компетенций команды программной инженерии привели к следующим выводам.
1. Стремительные изменения в обществе и технической инфраструктуре служат причиной такой же стремительной деградации умений инженеров. В настоящее время происходит смена инженерных парадигм и умение управлять компетенциями актуально как никогда.
2. Для обоснования профиля компетенций разработаны методология, таксономия, морфология, онтология.
3. В основу методологии профиля компетенций положена обоснованная теория (Grounded theory). Параметры разработаны на основе качественных данных конкретной организации, а не выбраны заранее как это происходит в других теориях. Последующий анализ параметров позволил ввести категоризацию этих параметров.
4. Новизна предлагаемого профиля не только в смене научных теорий на инженерные, но и в смене оценки квалификации от знаний к практическим умениям.
5. Профиль компетенций коллектива программной инженерии можно использовать:
Для выявления угроз внутренней среды и внешнего окружения самостоятельности (устойчивости, адаптивности, разумности) команды проекта и, как следствие, конкурентоспособности компании.
Для выявления недостатков квалификации команды проекта.
Для обоснования стратегии развития команды проекта.
Библиография
Данная статья служит продолжением ранее опубликованных на «Хабре» статей:
Инженерная фантастика II. Попытка обосновать методы инженерных тренингов с помощью научной фантастики.
Инженерная фантастика. Поиск связи научной фантастики с программной инженерией.
