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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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