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

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

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

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

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

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

Жизнь продолжается. Даже после того, как вас повысили в должности. Из журнала Computer Language Magazine, том 9, № 3, март 1992 г.

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

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

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