Книга: Как пасти котов. Наставление для программистов, руководящих другими программистами

Проектные совещания

Проектные совещания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Делайте заметки. Если можете себе это позволить, заведите электронное табло. Зафиксируйте совещание на видеопленке, оцифруйте ее, а после создания первого черновика проектной спецификации покажите отснятый материал членам группы.

• Подключите ноутбук к большому монитору и демонстрируйте сотрудникам группы примеры готового кода, указывая на те его аспекты, которые считаете удачными или, напротив, неудачными.

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

• Работайте в удобном и изолированном от шума помещении. Делайте перерывы, чтобы усталость организмов присутствующих не мешала деятельной работе их мозгов.

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

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

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

Совещание без реализации принятых решений на практике есть не более чем потеря времени.

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

Оглавление книги