Почему совещания нужно вести? Дело в том, что когда программисты, намереваясь обсудить ту или иную проблему, собираются вместе, их личностные качества имеют обыкновение вступать в конфликт, который, естественно, достижению поставленных целей совещания не способствует. Привыкнув заниматься кодированием, вы, скорее всего, перед проведением первого (или пятидесятого) совещания будете испытывать неприятные опасения[52]. Не беспокойтесь, эта глава, посвященная проведению совещаний, призвана повысить вашу подготовленность в этой области. Именно от вашей разумности зависит успех в деле ведения совещаний.

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

Я рекомендую проводить совещания с сотрудниками каждую неделю в одно и то же время. Не стоит отлынивать от этих встреч, даже если вы плохо себе представляете, что на них можно обсудить. На самом деле предмет для обсуждения найдется – нужно только каждую неделю придерживаться на совещании четкой повестки дня.

• Что вы делали на прошлой неделе?

• Что вы собираетесь делать на этой неделе?

• Что мешает вам выполнить ваши задания в назначенное время?

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

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

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

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

Достоинство предложенной мной программы совещания состоит в том, что она проста, предполагает диалог с сотрудниками и обеспечивает возможность выявления трудностей, с которыми они сталкиваются. Заставляя программистов формулировать достигнутые цели и ставить перед собой цели на неделю, вы укрепляете в их сознании мысль о том, что они работают ради создания конкретного продукта. С другой стороны, вам нужно, чтобы программисты, копаясь в деталях реализации, держали в голове все вспомогательные задачи, направленные на решение более общей (высокоуровневой) задачи. Сначала полезно определить в контексте проекта высокоуровневую задачу – например, «реализовать модуль, выражающий функцию X», а затем, исходя из имеющихся ресурсов, сформулировать вспомогательные, зависимые задачи. В процессе администрирования за этим также придется следить. Если бы мы, руководители, могли держать в голове все детали, связанные с реализацией любой конкретной характеристики программного продукта, было бы, конечно, замечательно; впрочем, в таком случае мы утратили бы потенциал делегирования и фактически отказались бы от обращения к интеллектуальным ресурсам и техническим навыкам своих сотрудников. Скажем по-другому: пытайтесь держать в голове как можно больше деталей, и если ваша команда состоит из профессионалов с достаточной мотивацией, они помогут вам справиться с задачей.

В конце концов, над результатом работает вся группа, а ваша цель заключается в том, чтобы ставить планки и проверять результаты.

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

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

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

Каждую неделю при проведении совещаний будьте готовы к тому, что сотрудники станут оценивать ваши лидерские качества. Не стоит забывать, что, проводя еженедельные совещания, вы нарабатываете соответствующий навык. Полжизни мы работаем на публику – а если серьезно, то, что бы там ни говорил Эмерсон (Emerson)[53], мне сложно представить себе ситуацию, в которой последовательный человек выглядел бы глупо. Еженедельно выискивая пути углубления кооперации между сотрудниками, вы формируете полноценную команду. Не стоит препятствовать проявлению соревновательного принципа – впрочем, в этом контексте вы должны играть уравновешивающую роль. Время от времени сотрудников следует ненавязчиво сдерживать или, напротив, побуждать к активным действиям. Если вы хорошо разбираетесь в своих подчиненных, то те действия корректирующего характера, которые вам предстоит предпринять, подскажет ваша интуиция. Эта роль напоминает позицию родителей по отношению к своим подросткам-отпрыскам (слава Богу, на эту тему мне писать не придется).

Будь вы хоть во сто крат талантливее лучшего программиста своей группы, скорее всего, всех ваших навыков, не говоря уже о времени, не хватит, чтобы самостоятельно реализовать все характеристики разрабатываемых программных продуктов. Даже если бы у вас нашлось время, разрабатывать все самому не имеет особого смысла – ведь тогда коллеги-программисты не смогут ощущать себя соучастниками творческого процесса. Иногда на проектных совещаниях нам приходится иметь дело с социально пассивной группой[54], которую неплохо бы превратить в команду активных, мотивированных и рвущихся к действию специалистов, готовых проектировать и реализовывать очередные характеристики вовремя и практически безошибочно. Такого рода индивидуальные особенности сотрудников зачастую довольно причудливо проявляются в контексте поведения группы в целом. Как настроить людей, с которыми приходится работать, на позитивный лад? Кто знает – может быть, вам и удастся достичь цели колдовскими чарами и материальным поощрением, но на самом деле эти способы неэффективны. Что вам действительно нужно, так это разум опытного психолога и душа дипломата-карьериста. Добро пожаловать в чрезвычайно запутанный, но в не меньшей степени притягательный мир группового поведения!

Проектировать программные продукты самому неразумно – ведь тогда коллеги-программисты не смогут ощутить себя соучастниками творческого процесса.

Так как же стать блистательным лидером проектной группы, если в данный момент вы таковым не являетесь? Без мыслительной деятельности и постоянной практики ничего не выйдет. Рассмотрим, однако же, некоторые проблемы и явления, наблюдаемые на стандартном проектном совещании.

• Ваша задача – сделать так, чтобы все функции были корректно спроектированы и впоследствии качественно разработаны.

• У каждого участника группы могут быть собственные представления относительно проектного решения одной и той же функции.

• Программисты склонны проектировать лишь те функции, которые они могут или хотят разрабатывать.

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

• Единодушная поддержка сотрудниками высказанных вами идей (если только они не объективно гениальны) наводит на грустные размышления.

• В процессе проектирования вы обязаны пытаться достичь консенсуса – это трудная задача, но усилия, поверьте мне, окупаются. Достичь компромисса несколько легче, но если кто-то выступит со своей вымученной идеей и не получит поддержки, вы рискуете создать себе врага.

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

В большинстве компаний достичь этой цели довольно сложно. Слава Богу, моя книга – не более чем скромное руководство, и я совсем не претендую на то, чтобы осветить все мыслимые вопросы. (Молодец, Хэнк! Избавился от ответственности.)

Шучу. Если серьезно, обратите внимание на следующие рекомендации:

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

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

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

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

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

• Работайте в удобном и изолированном от шума помещении. Делайте перерывы, чтобы усталость организмов присутствующих не мешала деятельной работе их мозгов.

• Составьте план действий на каждый день; при необходимости вносите в него коррективы и отталкивайтесь от него в деле реализации проектных заданий. Отведите последний день на критический обзор и обобщение результатов совещания.

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

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

Совещание без реализации принятых решений на практике есть не более чем потеря времени.

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

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

Вы говорите, что у вас нет дипломатических навыков? Что я могу сказать? Учитесь! Дипломатия – это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус.

Дипломатия – это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус.

Задача не из простых, кто бы спорил, но ведь деньги, которые вам платят, надо отрабатывать! Рекомендую прочесть несколько книжек по поводу формирования команды (см. библиографию). Но это не главное. Основная предпосылка к достижению желаемого результата – сильное желание. Стремление добиться общего для всех участников группы успеха вы должны ставить выше искушения выиграть случайный спор. Запомните, выиграть спор невозможно! В условиях командной работы все вместе либо выигрывают, либо проигрывают.

Я упомянул, что основной целью проектного совещания является выработка консенсуса. Я совершенно не имею в виду голосование по предложенным идеям. Демократия – система, прекрасно подходящая для наций, – не приживается в техническом проектировании[55]. Отдав предпочтение идеям одного человека и, соответственно, отказавшись от предложений другого, вы не добьетесь продуктивного мышления. Консенсус достигается за счет синтеза идей. Торг по принципу «я соглашусь на твою характеристику, если ты согласишься на мою», здесь неуместен. Что я понимаю под синтезом? Это процесс, в ходе которого путем проработки конкурирующих идей выкристаллизовываются их наилучшие качества. С вашей стороны для достижения этой цели требуется терпение и настойчивость. Ведь вы как руководитель должны стремиться к тому, чтобы вычленить наилучшее из всех возможных проектных решений. Это та цена, которую приходится платить за успех. В своем потрясающем сборнике статей по кадровому обеспечению Ларри Константайн высказывает следующие соображения:

«Синтез приводит к появлению оригинальной концепции, в которую входят сущностные характеристики всех представленных идей и предложений… Консенсус, построенный на основе синтеза, не только включает в себя лучшие из предложенных альтернатив, – он, как правило, вводит новые характеристики и возможности, являющиеся логическим продолжением объединения высказанных идей»[56].

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

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

Через месяц я пришел к директору и заявил, что, не имея возможности распоряжаться рабочим режимом Пола (его зарплатой, вопросами его повышения, увольнения и проч.), я не могу им управлять и, соответственно, не беру на себя ответственность за результаты его дальнейшей деятельности. К сожалению для меня, директор согласился с этими доводами; только после этого я осознал, в какой кошмарной ситуации оказался. Получалось, что если результаты деятельности Пола окажутся неудовлетворительными, винить в этом можно будет только меня. Была и другая трудность – я начал нравиться Полу. Он-то думал, что я изолировал его от группы по той причине, что оценил его способности, а совсем не потому, что с учетом его кошмарного характера у меня не было другого выхода. Как впоследствии выяснилось, никаких особых способностей у Пола не было. Ему просто один раз повезло. Как я узнал после многочисленных и продолжительных ужинов с этим деятелем, за долгие годы он сменил уйму должностей и успел позаниматься самыми разными делами, для всех он оказывался чужаком.

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

• Прошлые достижения отдельного сотрудника группы совершенно не гарантирует успешной деятельности группы в целом.

• Формированием группы должен заниматься только ее руководитель. В этом отношении он должен пользоваться полным доверием своего начальника.

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

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

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

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

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

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

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

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

Итак, вы получили новую должность. Теперь вам предстоит существенно расширить границы своего общения. На эту тему есть иллюстрация Скотта Адамса (Scott Adams) – обратите внимание на позицию руководителя (рис. 5.2).

Иллюстрация из Dilbert воспроизводится с разрешения United Feature Syndicate. Inc.

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

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

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

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

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

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

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

Будем надеяться, что поминки проектов вам проводить не придется. Совещания, тип которых обозначен в заголовке, не должны представлять собой арену для выражения недовольства; на самом деле это лишь формальный способ обучения на собственном опыте. Как писал Норман Кит (Norman Keith):

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

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

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

• Насколько четко была сформулирована спецификация продукта? Другой вариант того же вопроса: не случилось ли так, что в силу многократного пересмотра спецификации этап проектирования пришлось отложить на слишком долгий срок?

• Нашлось ли у вас время на макетирование проектного решения или же вы сразу приступили к кодированию?

• Трудно ли было расширять существующую архитектуру новыми функциями?

• Внес ли руководитель проекта весомый вклад в его успешную реализацию? Как можно оценить его организованность, компетентность и готовность к участию в проекте?

• Если бы вам представилась возможность написать тот же код снова, сделали бы вы что-нибудь по-другому?

• Находились ли в вашем распоряжении все программные инструменты, необходимые для решения поставленных задач?

• Как вы думаете, какие составляющие процесса разработки имеет смысл изменить?

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

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

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

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

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

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

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

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

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

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

• Не превращайте совещание в партсобрание. Участие в совещаниях – это тоже работа, и цель состоит в том, чтобы приступить к новой рабочей неделе осмысленно.

• При проведении проектных совещаний обязательно подготавливайте четкий план действий. Руководите разумно и учитывайте фактор группового поведения.

• Проводя беседы с сотрудниками один на один, следуйте принципам, характерным для совещаний в более крупном составе: пытайтесь достичь консенсуса и выстроить план действий.

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

• Проводя ретроспективные совещания по проекту, не поддавайтесь соблазну свалить все грехи на другие отделы. Попытайтесь выяснить, в каких областях вы сами и ваши сотрудники могли бы добиться более высокой продуктивности.

• Старайтесь свести количество телеконференций к минимуму. Путем тщательной подготовки и составления четкого плана старайтесь делать их как можно насыщеннее.

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

Примечания:

5

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

52

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

53

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

(Ральф Уолдо Эмерсон (Self-Reliance, 1841).)

54

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

55

Мне очень понравилась фраза, которую в фильме «Crimson Tide» Джин Хэкман сказал Дэнзелу Вашингтону: «Мы должны не заниматься демократией, а оберегать ее». Аналогичным образом, проводя проектное совещание, лучше воздерживаться от реверансов в пользу той или иной обсуждаемой идеи – как бы красноречиво ее ни защищали приверженцы. Ваша цель заключается в том, чтобы поощрять активный и плодотворный мыслительный процесс.

56

Larry L. Constantine, The Pcoplewarc Papers (Upper Saddle River, NJ: Yourdon Press, 2001), p. 10.

57

Norman L. Kerth, Project Retrospectives (New York: Dorset House Publishing, 2001), p. 7.