Чем же это отличается от того, что писали в "Peopleware" Демарко и Листер (Lister)? Они высказали мнение, что люди представляют собой важный фактор, и указали на некоторую специфику вопроса. Меня же интересует то, как групповые и индивидуальные особенности человека влияют на проектирование способов разработки ПО (иными словами, на методологии), в применении к различным группам, работающим над разными видами задач.
Мои идеи весьма сходны с теми, которые излагал Вайнберг в главе "Teaming" ("Работа в команде") своей книги "The Psychology of Computer Programming" ("Психология программирования"). Особенно все то, что касается противопоставления двух стилей руководства - управления задачами (task management) и управления поддержкой (maintenance management). Это весьма близко к тому, что пытаюсь получить я - некие характеристики и рекомендации, которые из них следуют. Вайнберг основывается на тех проектах, которые он исследовал в 60-е годы. Однако его выводы остаются справедливыми и полезными и сейчас, 30 лет спустя, что еще раз подтверждает стабильность и важность человеческого фактора в разработке ПО. Мне кажется, уже наступило время тщательно изучить подобные факторы, и начать относиться к следующим из них рекомендациям как к основам разработки ПО, а не открывать их для себя каждые 30 лет.
В этой статье я расскажу о той работе, которую проделал, чтобы понять, что именно люди являются главным залогом успеха проекта. В настоящее время для прогнозирования я использую именно человеческий фактор. Я пишу эту статью от первого лица, потому что формальный, академический стиль не очень подходит для описания поисков чего-то совершенно очевидного и при этом не совсем понятного. Лучше всего подать это в виде рассказа от первого лица.
Году эдак в 1987, когда я занимался формальной разработкой программного обеспечения, существовало следующее убеждение: "В разработке ПО проблема заключается в том, что при постановке задачи и проектировании допускается слишком много неточностей. Все будет хорошо , если мы сможем заставить людей работать с математическим формализмом". Однако, поработав немного в этом направлении, я обнаружил, что перед нами стоят:
Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.
Проблема 2. Они вполне могут обойтись и без методологов, и при этом успешно создавать программное обеспечение. Я ушел от формальных разработок, в то время как мои коллеги выдвинули новую идею: "Вся проблема - в обучении. Все будет хорошо , если мы дадим разработчикам необходимые математические знания гораздо раньше, еще в средней школе". Однако мое знание людей подсказывало, что такое желание неосуществимо. Не то, чтобы я ставил под сомнения очевидные преимущества формальной разработки ПО, просто я сомневался в нашей способности убедить 10 миллионов человек заняться математикой. Правильно было бы поставить вопрос следующим образом: "При каких обстоятельствах и для чего нужно включать в проект специалиста по формальной разработке?"
