Как пасти котов. Наставление для программистов, руководящих другими программистами

«Один из моих знакомых руководителей проектами однажды сравнил процесс управления программистами с выпасом котов. Он хотел сказать, что песики, преданно заглядывающие в глаза, нам совершенно не нужны. Хорошего программиста нужно ценить вместе со всеми его странностями. С другой стороны, всех этих хороших программистов нужно каким-то образом заставлять двигаться в одном направлении»[4 - Ellen Ullman, Close to the Machine (San Francisco: City Lights Books, 1997), p. 20.].

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

Какие бывают породы программистов

На что похож типичный программист? Можно ли построить шаблон программиста, хотя бы для того, чтобы понять мотивы его поведения? Может быть. В психологической науке существуют так называемые тесты оценки личности. Здесь тот же принцип – достаточно разобрать отличительные черты программистов в отдельности, и вы поймете, что многие из этих характеристик (даже если они на первый взгляд кажутся взаимоисключающими) могут существовать в одном лице. Я разделяю породы на три категории: распространенные, редкие и дворовые. Распространенные породы встречаются чаще всего. Редкие породы встречаются не так часто, но иногда с ними все-таки приходится сталкиваться. Дворовые породы, как и следует из их названия, приносят не слишком много пользы, но знать о них нужно, хотя бы в силу того, что они существуют. Если регулярно помогать дворнягам повышать уровень знаний и, соответственно, преодолевать слабости, которые они по определению привносят в процесс кодирования, они могут стать очень достойными исполнителями.

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

Распространенные породы

Ниже я перечисляю распространенные породы и их характеристики.

Архитектор[5 - Термином «архитектор» я в данном случае обозначаю один из личностных типов программистов и совершенно не имею в виду полноценного программного архитектора. О том, какую роль играет архитектура в общей схеме разработки, говорится в главе 6.].Большинство руководителей обожают этот тип программистов – и, действительно, любой такой деятель окажется ценным приобретением для вашей команды. В основном архитекторы концентрируются на общей структуре кода. Они мыслят объектами, а их лучший друг – лист белой бумаги. Посвящая себя без остатка решению бизнес-задач, они строят абстракции, проводят анализ систем, после чего переходят к кодированию конкретных решений. Слов нет – все это очень важные элементы программирования, но для комплексного выполнения задач их еще не достаточно. Зачастую в высшей степени разумные замыслы архитектора воплощаются в настолько общем и непонятном коде, что людей, могущих разобраться в нем и продолжить начинание, просто не находится. Особи, способные генерировать удачную идею в голове (а лучше в Visio), а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Недостаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорически отказывается[6 - А ведь это очень важно – согласно авторитетным оценкам, по меньшей мере 70 % стоимости программного обеспечения приходится на сопровождение. См. William H. Brown et al, AntiPatterns: Refactotoring Software, Architectures, and Projects in Crisis (New York: John Wiley & Sons, 1998), p. 121.]. Некоторые архитекторы очень любят набросать структуру кода, с тем чтобы впоследствии передать его на растерзание программистам более «низкой» квалификации. Иногда в коде, написанном архитекторами, встречаются весьма странные конструкции – например, окна с сообщениями о системных прерываниях из-за ошибок, появляющиеся по той лишь причине, что код предполагалось исполнять в виде библиотеки DLL на сервере.

Конструктивист. Конструктивисты получают удовольствие от процесса написания кода и его результата. Стратегическим планированием они себя утруждают не всегда, но факт в том, что с написанием кода они справляются быстро, причем в большинстве случаев ошибок в нем не обнаруживается даже на этапе альфа-тестирования. Код конструктивисты пишут по наитию, а потому их логика не всегда понятна. У некоторых конструктивистов все в порядке и с интуицией, и со стратегическим планированием, поэтому код выступает естественным продолжением хода их мыслей. Но стоит попросить конструктивиста составить документацию, он обязательно ответит, что код самодокументируемый. Впрочем, если на него немного надавить и дать понять, что без документации никуда не деться, он, вероятно, согласится ее составить – и сделает это качественно. Кто спорит – код должен быть самодокументируемым, но следует иметь в виду, что основное внимание программисты этого типа уделяют процессу создания кода, поэтому остальное для них не так уж важно. Количеству сборок, которое конструктивист выдает за день, позавидует даже Microsoft. Соответственно, их код обычно отличается надежностью. Однако же по мере разбухания (а этот процесс неизбежен) надежность улетучивается, а конструктивист начинает судорожно искать новые, «заплаточные» решения – ведь для него очень важно видеть результат и пребывать в уверенности в том, что он справился с поставленной задачей. Конструктивист в сочетании с архитектором имеют все шансы стать прекрасной командой. Если же вы умудритесь отыскать конструктивиста и архитектора в одном лице, считайте, что львиная доля кадровых проблем решена.

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

Инженер. Инженеры вам понравятся. Эти ребята имеют обыкновение скупать все возможные средства сторонних производителей, писать десятки COM-объектов и сводить их воедино, так что они прекрасно работают в версии 1. Присущая им тяга к усложнению проявляется лишь тогда, когда речь заходит о версии 1.1. Программирование часто приравнивают к инженерии программных средств – и, действительно, многие стороны нашей профессии подчиняются этой методологии. Но давать инженерам карт-бланш нельзя. В программных продуктах, выстроенных инженерными методами, нет ничего предосудительного – в конце концов, согласно классическому определению, инженерия есть научные принципы, задействованные при решении программных задач. Нам нужны программисты, которые не боятся сложностей, но те из них, которые любят усложнять все и вся, представляют серьезную опасность. Поймите меня правильно: я совершенно не собираюсь бросать камень в огород инженеров. В конце концов, я сам многие годы трудился над аппаратным обеспечением компьютеров. Но аппаратная направленность иногда входит в противоречие с теми аспектами программного обеспечения, благодаря которым оно становится программируемым (то есть гибким и многократно используемым). Любое аппаратное устройство обычно служит одной, четко определенной цели, а для программного обеспечения такой подход неприемлем.

Ученый. Ученые – это мальчики и девочки, которые считают себя последователями Бэббиджа и Тьюринга. Никогда в жизни они не вставят в код инструкцию GoTo. Отодвигая художественную составляющую программирования на второй план, они делают все в соответствии с фундаментальными принципами компьютерных наук. И как раз в этом обычно и заключается проблема. В то время как они одержимы безупречностью своих трудов, ваша главная забота как руководителя состоит в том, чтобы разработать доброкачественный продукт и сдать его к установленному сроку. Программисты такого типа на самом деле очень полезны, и когда речь заходит об особо трудных задачах кодирования, их идеям нет цены. Вы просто должны следить за тем, чтобы их педантичность не перевесила практические соображения. У инженеров и ученых есть одна общая черта – те и другие очень любят все усложнять. Иногда даже кажется, что они все поклоняются богу сложности (и даже приносят ему жертвы!). Отдавая должную оценку глубочайшим познаниям ученых и по мере необходимости обращаясь к ним, руководитель не должен допускать их полновластия в вопросах написания кода – иначе они сделают его слишком сложным.

Лихач. Лихачи – это те товарищи, которые делают все быстро. Забывая о комментариях, отступах и соглашениях об именовании переменных, они, тем не менее, умудряются достигать результата очень оперативно – и, что самое замечательное, вплоть до первой неперехваченной ошибки их продукты вполне успешно работают. Иногда такое поведение характерно для молодых программистов, горящих желанием впечатлить вас, – они опрометчиво считают, что оперативность в достижении результата в полной мере соответствует вашим ожиданиям. Признайтесь: мы часто сами выстраиваем у них столь ложное представление, а значит, веди мы себя по-другому, никаких лихачей не было бы. Наши собственные начальники устраивают совещания, на которых устанавливают контрольные сроки, а потом сообщают их нам. Как мы добьемся выполнения поставленных временных задач – это уже наша проблема. Вспомните, как часто идут разговоры о бессмысленности установления крайних сроков кодирования до окончательного выяснения всех требований! Так вот, вам придется к этому привыкнуть. К сожалению, такова реальность – пользователи и рыночные соображения часто принуждают нас сперва давать обещания, а потом уже приступать к планированию. Именно по этой причине вы читаете мою книгу – вам нужны советы по поводу того, как выжить в динамичном, жестоком и суровом мире разработки программных средств.

Редкие породы

Далее я привожу список редких пород и их отличительных черт.

Волшебник[7 - Некоторые предпочитают называть программиста этого типа «гуру» или «спецом». А мне больше нравится «волшебник».]. Каким-то загадочным образом те, кого я называю волшебниками, регулярно решают самые трудные задачи программирования, причем идут такими путями, которые раньше никому и в голову не приходили. Более того – волшебники делают все это вовремя, и иногда у них получаются вполне доступные для понимания программы, которые даже можно сопровождать. Немного волшебства в нашем деле не помешает. Но стоит распустить подобным деятелям руки, и вскоре вы превратитесь из здравомыслящего руководителя работоспособной группы программистов в обычного подмастерье. Кроме того, если вы будете слишком полагаться на волшебника, в один прекрасный день он вас разочарует – в конце концов, постоянно творить чудеса никому еще не удавалось.

Минималист. Несмотря на удивительно скромный объем кода, производимого минималистами, код обычно оказывается очень функциональным. Каждая процедура умещается в редакторе кода на одном экране. Объекты стройны, выстроены четко и недвусмысленно сообщают о своем назначении. Звучит неплохо, не правда ли? В общем, да, только стоило бы учитывать мотивы такого поведения. Ведь иногда они кроются в том, что человеку хочется побыстрее разобраться с текущим проектом и перейти к следующему, который его больше захватывает. Иногда (кстати говоря, эта характеристика распространяется и на архитекторов) минималисты, решив поставленную задачу, быстро теряют к ней всякий интерес, и уж, конечно, при обнаружении в ходе альфа-тестирования каких-либо проблем выказывают устойчивое нежелание их исправлять. Иногда минималисты капризны и очень придирчиво выбирают область приложения своих сил. С сопровождением кода дела у них обстоят хуже всех.

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

Трюкач. Трюкачи слишком увлекаются разными технологическими трюками. Они постоянно осваивают разные новинки, но результат от этого не улучшается. По правде говоря, всех нас в той или иной степени привлекают забавные технологические приемы. Я вот, например, помню мой первый компьютер. Он был аналоговым, и, поворачивая диски, я переключал ветви в предустановленном аппаратном алгоритме. Эта штука была похожа на гипертрофированную логарифмическую линейку. В общем, я до сих пор люблю забавляться со всякими высокотехнологичными штуковинами. Если вам приходится работать с трюкачами, попытайтесь направить их увлечение игрушками на решение их первоочередной задачи, а именно на производство бизнес-решений. Если им удалось втиснуть на экран, который, как предполагается, будет отображаться с разрешением 800 ? 600, 30 разных элементов пользовательского интерфейса, это еще совершенно не означает, что они решили свою задачу в соответствии с реальными потребностями пользователей[8 - Вы тоже ненавидите пользователей?! Представляете, как было бы здорово писать программы только для программистов?]. Трюкачи, при всех их познаниях в технологии, часто не могут усвоить конечное назначение программы. Полагая, что их функции ограничиваются забавами с разными инструментальными средствами, они отказываются учитывать те аспекты программирования, благодаря которым мы не затрачиваем на сопровождение титанических усилий.

Дворняги

Остановимся теперь на дворовых породах и их отличительных чертах.

Разгильдяй. Что сказать о разгильдяях? Некоторые люди небрежны, и это проявляется в коде, который они создают. Они не обращают внимания на такие мелочи, как правильное написание имен переменных и правила венгерской нотации. Зачастую качественно выполнять свои обязанности им мешают проблемы личного плана. Тому, как пишется эффективный код, их нужно учить. Они любят начать с одного стиля, а через процедуру-другую перейти к новому. Читать их код очень утомительно – иногда поздними ночами его приходится переписывать, поскольку иначе есть риск не успеть к сроку сдачи проекта. Если вы не справились с задачей по их вине, прошу вас: отнеситесь к ним снисходительно. В конце концов, они просто отъявленные разгильдяи, которых лучше всего пересадить в отдел бета-тестирования. Хотя нет – так вы просто заморозите проблему, в итоге она все равно может проявиться. Если разгильдяй действительно любит писать код, при условии, что вы уделяете ему достаточно внимания, он имеет шансы реабилитироваться. Всех, кому это не удается, нужно просто пнуть под зад или познакомить с консультантом по трудоустройству.

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

Любитель. Любители очень хотят стать настоящими программистами. Тщательно изучив какой-нибудь инструмент написания макрокоманд, они возводят себя в ранг хакеров. Единственная причина, по которой они бросают уютные места в отделах поддержки пользователей и тестирования, заключается в том, что, по их мнению, быть программистом – это очень круто. Да, мы, действительно, крутые, но, по большому счету, это лишь побочное следствие нашей основной деятельности. Любителям не хватает образования, но по мере их обучения вы должны пристально за ними следить и лишь при условии определенных достижений с их стороны поручать им работу над критически важными приложениями. Узнав на собственном опыте, как трудно заниматься программированием и какое серьезное внимание к деталям требуется от программистов, любители часто разочаровываются в своем выборе. Они отказываются признавать превосходство объектно-ориентированных методов над процедурной парадигмой – и все потому, что нужное прозрение их еще не посетило. В защиту любителей вспомним замечательное высказывание: «любители построили ковчег, профессионалы построили ”Титаник“». На самом деле иногда свежий, незашоренный взгляд начинающего программиста очень помогает нам – старым брюзгливым технарям.

Профан. Программист-профан – это тот, кого называют тупицей. Хуже всего, когда профан не догадывается о своей тупости. Остерегайтесь таких людей. Иногда они могут достаться вам в наследство от предыдущих руководителей, но сами, я вас прошу, никогда их не нанимайте. У меня нет никаких предубеждений относительно умственно ущербных людей, но я твердо уверен, что в профессии, требующей постоянного самосовершенствования и обучения, таким не место. Если человек невежда, но хочет стать лучше, – дайте ему шанс. Отправьте его, например, в отдел тестирования – иногда не отличающиеся выдающимися умственными способностями пользователи находят себя в отлове жучков[9 - Лично я предпочитаю термину «жучок» (bug) словосочетания «программная аномалия» (program anomaly) и «открытие недокументированной характеристики» (Undocumented Feature Offering, UFO).]. Еще одно соображение насчет глупости: на самом деле все мы постоянно страдаем от несовершенства того, что находится между клавиатурой и стулом. Но, в конце концов, если бы для написания кода не требовались мозги, этим занимались бы все без разбору, так ведь? Я советую не путать невежество с глупостью. Невежество исправимо, а с глупостью лучше просто не связываться. Если вы унаследовали кадры, подобранные не программистом, вполне возможно, что среди ваших подчиненных есть такие типажи. Руководители, имеющие весьма отдаленное представление о технологии, иногда покупаются на необоснованные заверения бездарных претендентов на место.

Эклектик. Можно сказать, что эклектики просто стряпают программные продукты. Представитель этой породы сочетает в себе качества инженера, разгильдяя и не слишком талантливого художника, причем упомянутые ингредиенты находятся в чудовищной диспропорции. Результат их деятельности представляет собой винегрет из стилей кодирования и подключаемых модулей при невероятной путанице в коде. Все это выглядит довольно привлекательно, но стоит лишь попробовать кусочек, как наступят необратимые последствия. Отправьте такого программисты на кулинарные курсы и обязательно проверьте, не скрывается ли за внешней оболочкой талантливости банальный разгильдяй. В классическом виде эта дворянская порода встречается довольно редко, а упомянул я ее по той причине, что отдельные ее черты проявляются в стилях кодирования самых разных типов программистов. Если они не считают нужным следовать корпоративным стандартам, вам придется посвящать все рабочее время напряженным попыткам выяснить, что же они все-таки имели в виду и как сопровождать их код. Основным средством реабилитации эклектиков служит критика кода (см. главу 6).

Умение обращаться с представителями разных пород

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

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

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

Есть еще один тип личности, на который следует обращать особое внимание. Я имею в виду программистов-ковбоев. Этот тип плохо согласуется с перечисленными породами, а описывать его лучше в соответствии с тем мнением, которое ковбой о себе формирует. Итак, программист-ковбой обычно в совершенстве владеет своим ремеслом, но при этом управлять им практически невозможно. Ковбои глубоко убеждены, что могут работать только над теми проектами, над которыми хотят, делать это на собственных условиях, согласуясь исключительно с собственными планами и обращаясь только к подходящим по их мнению средствам. Такой программист – своеобразный волк-одиночка (или, если придерживаться терминологии этой книги, – кот, который гуляет сам по себе). В зависимости от того, что вам нужно, и вашей готовности терпеть своеобразие их личности, ковбои могут творить либо чудеса, либо хлам. С ковбоями надо держать ухо востро: они ни при каких обстоятельствах не станут частью вашей команды. Прибегать к их услугам стоит либо в безвыходных ситуациях, либо если разрабатываемый проект должен радикально отличаться от всех других, а сопровождать его будут сторонние специалисты.

Почему в программистах сочетаются все эти чрезвычайно занимательные личностные характеристики? Мне кажется, связано это с тем, что сам характер деятельности разработчика программного обеспечения привлекает людей совершенно определенного рода. В своем классическом труде «The Mythical Man-Mouth» Фредерик Брукс (Frederick Brooks)[10 - Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (New York: Addison-Wesley, 1995), p. 230. Это действительно непреходящая классика. В нашей области очень мало книг, которые переиздаются через 25 лет после появления, и это – одна из самых стоящих.] утверждает, что наше ремесло приносит людям удовольствие пяти видов.

1. Радость созидания.

2. Радость созидания полезных для других людей продуктов.

3. Привлекательность процесса упорядочивания головоломных объектов, состоящих из взаимосвязанных динамичных элементов.

4. Радость от постоянного обретения новых знаний и решения нестандартных задач.

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

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

Кошачьи разборки – соревнование по шипению и царапанию

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

На следующий день в центре внимания опять оказались Джон и Кевин – они собачились за каждое проектное решение, и все остальные сотрудники отдела предпочитали помалкивать. К концу второго дня мы сумели согласовать значительно меньше вопросов, чем планировались, а то, что нам удалось, оказалось результатом ожесточенной бойни между двумя воинственными котами – Джоном и Кевином. Остальная часть группы чувствовала себя совершенно дезориентированной. Люди начали сомневаться, удастся ли вообще закончить работу над системой. Значительно осложняло ситуацию то обстоятельство, что перед группой поставили задачу сделать систему как можно быстрее, ибо та ее версия, которая в тот момент находилась на рынке, негативно сказывалась на репутации компании.

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

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

Слава, почет и деньги

Любой сотрудник жаждет признания своей деятельности, хочет ощущать весомость своего вклада в общее дело. Быть оцененными по достоинству стремятся и некомпетентные сотрудники – даже несмотря на то, что их вклад в деятельность компании исключительно негативный. Все мы любим поразглагольствовать насчет того, что создание кода для нас – это уже своего рода награда. Но хотелось бы мне знать, сколько мы проработаем, если нам не будут за это платить. Но даже если будут платить, и платить хорошо, мы в любом случае будем требовать признания со стороны наших товарищей и надеяться, что начальник между делом похлопает нас по плечу. Настоящие кошки предпочитают спокойно дремать в углу, не заботясь о том, кто и как на них смотрит; кошки-программисты в этом отношении, напротив, проявляют некоторый эксгибиционизм. Ярким подтверждением того, что и программистам нужно признание, служит практика встраивания в код своеобразных «пасхальных яиц» (хотя сегодня она считается несколько вульгарной). Вас, начальника, они воспринимают как зрителя, сидящего в переднем ряду, и, конечно же, ожидают аплодисментов. Причем ожидают все – даже те, над которыми впору начинать читать молитву[11 - Я имею в виду тех, кому пора готовиться к основательной порке.].

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

Расхваливать своих сотрудников – это, конечно, замечательно, но иной раз стоит на секунду остановиться и поразмыслить, отрабатывают ли они те деньги, которые получают.

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

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

Мотивирование деньгами