Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

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

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

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

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

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

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

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

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

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

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