Каждую неделю при проведении совещаний будьте готовы к тому, что сотрудники станут оценивать ваши лидерские качества. Не стоит забывать, что, проводя еженедельные совещания, вы нарабатываете соответствующий навык. Полжизни мы работаем на публику – а если серьезно, то, что бы там ни говорил Эмерсон (Emerson)[53], мне сложно представить себе ситуацию, в которой последовательный человек выглядел бы глупо. Еженедельно выискивая пути углубления кооперации между сотрудниками, вы формируете полноценную команду. Не стоит препятствовать проявлению соревновательного принципа – впрочем, в этом контексте вы должны играть уравновешивающую роль. Время от времени сотрудников следует ненавязчиво сдерживать или, напротив, побуждать к активным действиям. Если вы хорошо разбираетесь в своих подчиненных, то те действия корректирующего характера, которые вам предстоит предпринять, подскажет ваша интуиция. Эта роль напоминает позицию родителей по отношению к своим подросткам-отпрыскам (слава Богу, на эту тему мне писать не придется).
Будь вы хоть во сто крат талантливее лучшего программиста своей группы, скорее всего, всех ваших навыков, не говоря уже о времени, не хватит, чтобы самостоятельно реализовать все характеристики разрабатываемых программных продуктов. Даже если бы у вас нашлось время, разрабатывать все самому не имеет особого смысла – ведь тогда коллеги-программисты не смогут ощущать себя соучастниками творческого процесса. Иногда на проектных совещаниях нам приходится иметь дело с социально пассивной группой[54], которую неплохо бы превратить в команду активных, мотивированных и рвущихся к действию специалистов, готовых проектировать и реализовывать очередные характеристики вовремя и практически безошибочно. Такого рода индивидуальные особенности сотрудников зачастую довольно причудливо проявляются в контексте поведения группы в целом. Как настроить людей, с которыми приходится работать, на позитивный лад? Кто знает – может быть, вам и удастся достичь цели колдовскими чарами и материальным поощрением, но на самом деле эти способы неэффективны. Что вам действительно нужно, так это разум опытного психолога и душа дипломата-карьериста. Добро пожаловать в чрезвычайно запутанный, но в не меньшей степени притягательный мир группового поведения!
Так как же стать блистательным лидером проектной группы, если в данный момент вы таковым не являетесь? Без мыслительной деятельности и постоянной практики ничего не выйдет. Рассмотрим, однако же, некоторые проблемы и явления, наблюдаемые на стандартном проектном совещании.
• Ваша задача – сделать так, чтобы все функции были корректно спроектированы и впоследствии качественно разработаны.
• У каждого участника группы могут быть собственные представления относительно проектного решения одной и той же функции.
• Программисты склонны проектировать лишь те функции, которые они могут или хотят разрабатывать.
• У некоторых программистов могут быть планы, отличные от ваших; трудно выявляемые, такие бунтари способны привести к саботажу совещаний.
• Единодушная поддержка сотрудниками высказанных вами идей (если только они не объективно гениальны) наводит на грустные размышления.
• В процессе проектирования вы обязаны пытаться достичь консенсуса – это трудная задача, но усилия, поверьте мне, окупаются. Достичь компромисса несколько легче, но если кто-то выступит со своей вымученной идеей и не получит поддержки, вы рискуете создать себе врага.
Совещания либо осложняют существующую в группе разработчиков ситуацию, либо разрешают кризис. В каком направлении пойдете вы, всецело зависит от вашей воли. Силами наличествующего персонала и с учетом предъявленных требований вы должны создать работоспособные спецификации, на основе которых впоследствии можно будет писать качественный код.
В большинстве компаний достичь этой цели довольно сложно. Слава Богу, моя книга – не более чем скромное руководство, и я совсем не претендую на то, чтобы осветить все мыслимые вопросы. (Молодец, Хэнк! Избавился от ответственности.)
Шучу. Если серьезно, обратите внимание на следующие рекомендации:
• Вы должны знать сильные и слабые качества участников своей команды. Не менее важно осознавать собственные достоинства и недостатки. Именно об этом я говорил в первых трех главах книги.
• Документацию с требованиями имеет смысл разбить на разделы по схожей функциональности, допускающие решение средствами объектно-ориентированного проектирования.
• Делайте заметки. Если можете себе это позволить, заведите электронное табло. Зафиксируйте совещание на видеопленке, оцифруйте ее, а после создания первого черновика проектной спецификации покажите отснятый материал членам группы.
