Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

Вот некоторые правила, которых полезно придерживаться при росте организации:

• Взвешивайте затраты на внедрение технологических приёмов и пользу от них

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

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

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

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

Один из самых обескураживающих аспектов разработки ПО — внедрение новых приёмов, в то время как команда не полностью использует все возможности имеющихся. В вашей команде так быть не должно. За правильное использование имеющихся приёмов отвечают менеджеры и ведущие специалисты. Можно потерять доверие участников команды, санкционируя добавление новых технологических приёмов и игнорируя те, что уже есть. Если обнаружится, что ни один из имеющихся документированных приёмов не используется полностью, созовите собрание группы и решите, представляют ли они ценность. Да — оставьте их и используйте «на все сто». Нет — избавьтесь от лишних технологических приёмов. Что толку держать приёмы, развесив их по стенам, как картины? Они только портят интерьер.

Суть в следующем: нужно внедрить минимальный набор технологических приёмов, необходимый для выполнения работы и следить за тем, чтобы группа освоила их в совершенстве. Не следует осваивать новые приёмы, если вы сами не уверены, что они будут задействованы в полной мере. Группа должна знать: уж если вы решили что-то сделать, то сделаете это непременно.

• Взвешивайте потребности отдельного специалиста и всей команды

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

Из собственного опыта

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

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