Основное внимание при рассмотрении вопросов управления проектами, как правило, уделяется поведению менеджера, при этом подчинение, как неотъемлемая часть процесса управления, часто ускользает из поля зрения специалистов. Предлагается рассмотреть два принципиально разных типа подчинения: подчинение типа ‘Солдат’ (безоговорочное подчинение, при котором от подчинённого не требуется понимания назначения и смысла его действий) и подчинение типа ‘Рейнджер’ (обсуждение задач и путей их реализации с последующим добровольным принятием на себя обязанностей по их выполнению). Констатируется важность и востребованность обоих типов подчинения в различных софтверных проектах, а также недостаточное внимание к подготовке технических специалистов с целью овладевания обоими типами подчинения.

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

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

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

Подчинение типа ‘Солдат’- классический тип безоговорочного подчинения, при котором от подчинённого не требуется понимания (а иногда даже требуется непонимание) назначения и смысла его действий, видение общей картины и т.п. Подчинение сводится к чёткому и своевременному выполнению детальных предписаний, которые тем не менее могут предтавлять собой достаточно интеллектуальные и сложные проблемы. Особенность этого типа подчинения не в простоте или сложности выполняемых указаний, а именно в непонимании высшего назначения и смысла этих задач. Подчинение этого типа подразумевает стиль менеджмента (назовём его ‘Командование солдатами’), который характеризуется сокрытием общего видения от конечных исполнителей ввиду их неспособности увидеть или понять общую картину, или тем, что общее видение может помешать выполнению ими своих задач. В современных управленческих подходах этот стиль считается устаревшим, неэффективным и даже помещается в анти-паттрены управления (‘Управление грибами’). Тем не менее, этот стиль всё ещё остаётся весьма распространённым и, надо признать, довольно эффективным в некоторых проектах и командах, например:

• Там, где уровень сложности проекта существенно превосходит уровень подготовки команды. В такой ситуации руководитель высокого уровня или единственный технический специалист, способный обозреть и грамотно запланировать всю работу над проектом, вынужден использовать такой подход. Мартин Фаулер даже выделил архитекторов, исполняющих в софтверных проектах такую роль, в отдельный тип ‘Architectus Reloadus’ [1]. Наиболее наглядный пример оправданного и весьма эффективного применения этого стиля подчинения/управления, который приходит мне в голову, это массовые выступления во время спортивных или иных мероприятий. В этом случае каждый отдельный участник шоу не способен ни увидеть, ни толком представить зрелищность происходящего, его работа заключается в чётком и ритмичном выполнении сравнительно простых действий (например поднятие карточек определённого цвета), тогда как совместные действия всех участников вревращаются в итоге в феерическое шоу, задуманное руководителем.
• В нездоровых командах, где есть предвзятость, зависть, завышенная самооценка или другие сложности личностного плана, с целью выиграть время для более адекватного решения этих проблем и уменьшить риски провала проекта.
• В случае, когда руководитель обладает информацией, не подлежащей разглашению внутри команды, но тем не менее важной для реализации проекта.
• При наличии сложностей в обмене информацией между заказчиком/исполнителями или внутри критичных к коммуникациям подразделений проекта.
• и т.п.

Подчинение типа ‘Рейнджер’ — обсуждение задач и путей их реализации в команде с последующим добровольным принятием на себя обязанностей по выполнению этих задач каждым членом команды. Этот тип подчинения предполагает высокую грамотность, осведомлённость и лояльность каждого члена команды. Команда скорее похожа на группу равных по рангу профессионалов, где каждый занят своим делом, чем на иерархическую структуру ‘руководители-подчинённые’. Стиль менеджмента в таких командах принципиально иной, не основанный на подчинении как таковом, функция руководителя сводится к донесению до членов команды потребностей проекта и обеспечении команды всем необходимым для работы. Дальше команда через обсуждение (в том числе и с руководителем как с признанным авторитетом) предлагает и принимает пути решения и ответственных исполнителей. Такой стиль подчинения/управления стал невероятно популярным в последнее время и признан значительно более эффективным в большинстве софтверных проектов и команд по ряду причин:

• Растущая сложность и динамичность софтрверной индустрии требует лучше подготовленных специалистов, работающих быстро, точно и креативно. Команда, состоящая из профессионалов первой величины, невероятно эффективна при условии, что интересы, возможности и креатив каждого участника не только не подавляются, а наоборот стимулируются и используются.
• Интерпретация софтверной разработки как акта умственного труда, более тяготеющего к социальной, чем к инженерной сфере [2], а значит очень чувствительного к факторам социального поведения [3].
• Меняющиеся стереотипы демократического общества, в котором слепое повиновение постепенно перестаёт быть обязанностью наёмного сотрудника.
• и т.п.

Становится очевидным, что в приведенных здесь отношениях подчинение играет не меньшую роль, чем управление. И если умению управлять уделяется достаточно много внимания (литература, тренинги), причём достаточно полно охватывается и классический (‘Командование солдатами’), и гибкий (назовём его ‘Направление рейнджеров’) стили менеджмента. Умение же подчиняться предполагается, как правило, как нечто данное а-приори и не требующее особой подготовки. Речь заходит о литературе и тренингах только в случае подготовки ‘рейнджеров’, от которых ожидается самостоятельность, профессионализм и инициативность. Тем не менее, в ситуациях, когда проект требует подчинения в стиле солдата, то это почти никогда на рассматривается как нечто, требующее особого внимания. Именно по этой причине некоторым софтверным компаниям (как правило, крупным) с проектами, предполагающими подчинение в стиле ‘солдат’ бывает так тяжело (практически невозможно) подобрать хороших профессионалов, а нанятые в такие проекты рейнджеры уходят через 2-3 месяца, оставив неприятный осадок и у себя, и в компании. Хорошие профессионалы, однажды побыв рейнджерами (или тем более руководителями), больше не могут (да и не хотят) быть солдатами, а отсутствие подходов по подготовке их к этому только усугубляет ситуацию. В итоге получается, что наличие рейнджера в строю солдат так же (а иногда и более) пагубно для проекта (да и для самого профессионала), чем наличие солдата в группе рейнджеров.

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

1. Martin Fowler, Who Needs an Architect? (IEEE Software — July/August 2003 — p.2-4).

2. Alistair Cockburn, The end of software engineering and the start of economic-cooperative gaming (Computer Science and Information System — Feb 2004 — Vol.1, iss.1)

3. Alistair Cockburn, Characterizing people as non-linear, first-order components in software development (Humans and Technology — Oct 1999)