1 Решения, решения

1

Решения, решения

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

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

Опасность посредственности

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

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

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

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

Слегка управляя

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

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

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.