Команда

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

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

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

Третий тип – предложенная Ф.Бруксом бригада главного программиста. Учитывая многократную разницу в производительности программистов, основную работу над проектом поручают выполнять специалисту очень высокого класса, которому ассистирует «второй пилот» – тоже высококлассный программист. Остальные участники играют вспомогательные роли, направленные на получение максимальной производительности главным игроком. Главный программист принимает основные решения и несет полную ответственность за проект. Роль второго программиста – критическое осмысление решений главного, а в случае, когда главный не сможет продолжать работу над проектом – его замена. Достоинство – эффективное использование потенциала программистов высокого класса. Недостатки связаны с высоким риском провала проекта, так как он завязан на одного человека. Кроме того, сложно найти действительно хорошего специалиста.

Реально в чистом виде подобные структуры команд практически не встречаются, чаще команда имеет черты различных структур. Особенности проекта (например, «безнадёжный проект»[4]), или методологии (например, «экстремальное программирование»), или квалификации (студенты) зачастую диктуют свою форму организации команды. Как бы то ни было, руководитель проекта должен думать и над созданием команды, и над сохранением её, по крайней мере, до конца разработки.

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

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

• активный поиск виновных в случае неудачи;

• работник стремится обезопасить себя при помощи инструкций и докладных записок;

• конфликты из-за мелочей;

• работник не осведомлен о критериях оценки труда;

• работа оценивается на уровне эмоций и поверхностных наблюдений.

Причин, приводящих к развалу команды, довольно много, можно привести такие, как непригодность руководителя, нечеткость целей, низкие результаты работы, непродуманная система мотивации, неконструктивный климат. Т.Демарко и Т.Листер рассмотрели препятствия на пути создания, или «выращивания» [1], команд. Оказалось, что их достаточно много: за короткое время им удалось придумать множество способов покончить с командой. Эти способы они назвали «травлей команд». Вот некоторые из них:

• оборонительная позиция руководства, когда руководитель не доверяет компетенции команды;

• бюрократия в организации, приводящая к накоплению и бездумному перекладыванию бумажек;

• физическое разделение работников по разным помещениям;

• дробление рабочего времени для участия сотрудников одновременно в разных работах;

• снижение качества продукта, даже если это связано с необходимостью сдачи проекта в срок;

• идиотские сроки сдачи, которые не сформированы руководителем проекта, а навязаны сверху;

• разделение команд для участия в других проектах.

Обычно утрата командного духа происходит не по злому умыслу, а спонтанно, вследствие низкого осознания его ценности у руководства. Если процесс формирования команды идет успешно, это бывает видно по внешним признакам, например, возникает ощущение общности интересов, гордости за команду и т.п.

Из того, что работа над программным проектом выполняется командой, возникает заблуждение [1], что программирование может и должно быть обезличенным: нужно работать на команду. Этот тезис можно рассматривать как противовес слишком личному отношению некоторых авторов к своим программам: сообщение об ошибках в них они рассматривают как личные выпады, просмотр их кодов – как вмешательство в личные дела, стиль написания программы – это дело автора, а не вопрос сопровождения. Командные интересы требуют относиться к ошибкам как к сигналам об улучшении кода, знакомство с кодом – как повод поделиться своими наработками в интересах команды, стиль должен быть понятным для надёжности разработки. Однако полностью отказываться от своих приёмов и методов работы не только невозможно, но и, скорее всего, вредно: при соблюдении общих соглашений индивидуальный подход к написанию программ позволяет работать более продуктивно и качественно и получать большее удовлетворение от результатов.