Человеческий фактор в программировании

ОглавлениеДобавить в закладки К обложке

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

Непосредственные приоритеты

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

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

Спор и диалог

Отсутствие ясности или согласия по поводу критериев — это не единственное, что может затруднить достижение технического консенсуса. Свободное обсуждение — это не только основа командных усилий по достижению согласия. Такое обсуждение интересно и само по себе. Однако будучи интенсивным, оно может перейти в злопыхательский спор. Ни зал суда, ни политическая трибуна не подходят для командной работы, основанной на достижении согласия. Как бы ни зарекомендовал себя состязательный подход в судебной системе, важно, чтобы группы по разработке и проектированию не разбились на противоборствующие сообщества.

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

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

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

Если вы хотите создавать самые лучшие системы, ваши технические решения не должны опираться лишь на мнения тех, кто может переспорить остальных, обладает большей властью или может кричать громче всех. Чтобы избежать этого, возможности логики и аргументации должны быть доступны всей группе, а не только отдельным представителям или группировкам. Необходимо выровнять игровое поле таким образом, чтобы проявились достоинства идей и анализа, а не изощренность аргументации или сила голоса и многоречивость.

Когда людям, отстаивающим свои позиции, не удается найти общий язык, поможет такой метод. Стороны меняются ролями и начинают защищать позиции, предложенные другими. Или же активным спорщикам можно поручить защиту технически интересных, но слабо отстаиваемых идей. «Послушай, Мэвис, твоя идея хороша, но сможешь ли ты убедить нас, что в идее Грега есть преимущества?» Еще один прием — предложить следующее: «Давайте применим те же аргументы в рассмотрении другого предложения».


-= 9 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня