Здравствуйте. Начинаем курс «Человеческий фактор в разработке корпоративных систем». Предыдущие курсы в основном были связаны с технологическими аспектами. Тем не менее, мы помним, что при разработке корпоративных систем весьма значительную роль играют аспекты менеджериально-управленческие, и те кризисы, о которых мы говорили, во многом обусловлены человеческим фактором. О чем пойдет речь в курсе? Прежде всего, это модели, которые описывают взаимодействие разработчика и заказчика — двух основных сторон в разработке корпоративных систем. Мы рассмотрим модель передачи информации Клода Шеннона. Рассмотрим, каким образом происходит искажение и потеря информации при передаче от разработчика к заказчику и обратно, каким образом происходят потери при сообщении ключевых требований к разработке программных продуктов, каким образом вообще происходит взаимодействие разработчика и заказчика, каждый из этих двух сторон, напомним, является достаточно сложной многоаспектной системой. Мы рассмотрим ряд других аспектов, ряд других моделей, которые описывают, каким образом происходит человеко-ориентированное взаимодействие. В системе разработчик-заказчик мы рассмотрим принципы передачи информации, которые, на самом деле, достаточно близки и к системе студент-преподаватель. Основные принципы такие, как мотивация, организация знаний, предыдущие знания и другие, которые могут мешать, а могут способствовать правильной передаче информации и организации этой информации при передаче от разработчика к заказчику. Таким образом, мы попробуем рассмотреть основные аспекты, которые в совокупности позволяют избежать или сгладить последствия кризисов при разработке программных систем. Вводная часть курса посвящена основным понятиям и определениям, а также краткому рассмотрению структуры курса. О чем пойдет речь? Мы будем говорить во многом о кризисе, но немного с других позиций, прежде всего с позиции человеческого фактора, с позиций того, каким образом команда разработчиков и команда заказчиков взаимодействуют и что может мешать их взаимодействию, что может приводить к возникновению кризисных ситуаций в разработке программных систем. Прежде всего, мы напомним о том, как возник кризис и, как возникла программная инженерия как ответ кризису. Посмотрим, как работают команды разработчика и заказчика как самоадаптирующиеся системы, системы, которые являются во многом самоуправляемыми, особенно при реализации тех гибких методологий, в частности, такой методологии, как Microsoft Solutions Framework, Java методологии, о которых мы говорили, и каким образом удается при правильном построении команды, при правильном подборе команды, формировать адаптивное управление разработкой программных систем и противостоять кризису. Напомним о кризисе, который возник в разработке программных систем на рубеже 60–70 гг. По сути дела кризис является следствием дисбаланса в тройке ресурсов: это время, это те функции, которые мы должны разработать в нашей программной системе, и это иные ресурсы, прежде всего, людские ресурсы. В этом курсе мы сфокусируемся на людских ресурсах, дисбаланс в которых, конечно же, приводит или может привести к кризису и, в случае с тем самым изначальным кризисом в разработке программных систем, во многом так оно и произошло. Таким образом, попробуем сосредоточиться на том, какие именно атрибуты продукта, характер и масштаб продукта, какие именно свойства времени, финансовых ресурсов и других ресурсов в совокупности с взаимодействием команд разработчика и заказчика могут приводить к кризисным явлениям и как такого рода кризисных явлений избежать. Мы помним схему в форме треугольника, на которой изображено то, каким образом может возникать кризис, внутренняя зона является зоной комфорта, по сути дела, существенного дисбаланса между ресурсами не наблюдается, и можно продолжать разработку, но, если несколько меняются приоритеты или возникают ограничения, связанные, скажем, с финансовым характером проекта, а может быть и с взаимоотношениями в команде разработчика и заказчика, какие проблемы могут возникать. Мы выходим за рамки этой зоны комфорта и начинаем попадать в зону, которую можно условно назвать зоной компромисса. Там еще можно достичь компромисса, можно сбалансировать те показатели, которые у нас присутствуют в треугольнике и избежать кризиса. Если же мы попадаем в следующую зону, в кризисную зону, в ряде случаев кризиса избежать уже не удается. Ответом на кризис явилось создание той самой дисциплины, которая получила название программной инженерии и которая, напомним, существует для того, чтобы строить большие сложные тиражируемые программные продукты, которые строятся командой или даже несколькими командами разработчиков для, вообще говоря, команды заказчика. Какие важные уроки можно извлечь из этого названия, какие выводы можно сделать? Ну, прежде всего, нам нужно получить практически достижимые результаты в том смысле, что с ограниченным бюджетом, с ограниченным временем и с ограниченными ресурсами того коллектива, который работает как со стороны разработчика, так и со стороны заказчика, нам нужно обеспечить приемлемое качество продукта. При этом, естественно, нужно ввести предсказуемое планирование и управление, которому во многом мешает отсутствие или недостаточно эффективное использование того, что называется мягкими навыками — «Soft skills». Это, прежде всего, коммуникация, переговоры, навыки взаимодействия в команде и тому подобные аспекты. Нужно отметить, что в программной инженерии не так важно, скажем, кодирование, которое, как мы помним, собственно, составляет порядка 5 % затрат от общих затрат на разработку программного продукта, но существенная часть работы как раз кроется в человеческом факторе. Предельно важно взаимодействие разработчика и заказчика. Предельно важно не потерять той изначальной идеи, которую заказчик вкладывает в то, каким образом он хочет видеть свой продукт. И вот для этого, для продуктивного взаимодействия между командой разработчика заказчика как раз и нужны эти мягкие навыки, о которых пойдет речь в дальнейшем. Вернемся к кризису 60–70 гг. В чем были основные проблемы, если посмотреть на это в ретроспективе? Прежде всего, это высокая сложность тех систем, которые создаются, и, конечно же, высокая мощность тех компьютеров, которые возникли. Появилась проблема, как вообще человека связать с этой сложной комплексной схемой, в которой работают целые команды, в которой работают достаточно большое количество крупных и мощных ЭВМ, и каким образом вести процесс разработки программного обеспечения с тем, чтобы он был не просто надежным и предсказуемым, но и приносил качественный результат. Естественно, для этого нужно настроить человеческий фактор, который и является причиной тех самых кризисных сбоев, которые возникали при разработке программных систем.
