Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
В большинстве компаний достичь этой цели довольно сложно. Слава Богу, моя книга – не более чем скромное руководство, и я совсем не претендую на то, чтобы осветить все мыслимые вопросы. (Молодец, Хэнк! Избавился от ответственности.)
Шучу. Если серьезно, обратите внимание на следующие рекомендации:
• Вы должны знать сильные и слабые качества участников своей команды. Не менее важно осознавать собственные достоинства и недостатки. Именно об этом я говорил в первых трех главах книги.
• Документацию с требованиями имеет смысл разбить на разделы по схожей функциональности, допускающие решение средствами объектно-ориентированного проектирования.
• Делайте заметки. Если можете себе это позволить, заведите электронное табло. Зафиксируйте совещание на видеопленке, оцифруйте ее, а после создания первого черновика проектной спецификации покажите отснятый материал членам группы.
• Подключите ноутбук к большому монитору
• Уберите из помещения, в котором проводите совещания, телефонный аппарат. Этого можно не делать лишь в том случае, если во время совещания вы собираетесь обратиться к какому-нибудь удаленному абоненту за свежими идеями.
• Работайте в удобном и изолированном от шума помещении. Делайте перерывы, чтобы усталость организмов присутствующих не мешала деятельной работе их мозгов.
• Составьте план действий на каждый день; при необходимости вносите в него коррективы и отталкивайтесь от него в деле реализации проектных заданий. Отведите последний день на критический обзор и обобщение результатов совещания.
Как я только что сказал, вести заметки совершенно необходимо. Если вы регулярно выходите к электронному табло с предложением новых идей по проекту, что-то писать на бумажке становится довольно проблематично. В таком случае имеет смысл попросить одного из сотрудников выполнять эту функцию за вас. Представляете, как будет обидно, если, проведя плодотворное совещание на прошлой неделе, вы забудете о принятых на нем решениях уже через несколько дней! Для человека, которому вы намерены поручить протоколирование совещания, можно составить специальный шаблон. Пример такового показан на рис. 5.1.
Несколько замечаний по поводу шаблона. Большая часть информации, которая в нем фиксируется, очевидна. Самая пространная область шаблона – «Замечания» – предусматривает запись информации в свободной форме. В ней можно, скажем, начертить блок-схему (если электронное табло неисправно) или просто зафиксировать какие-то идеи, которые во время совещаний часто появляются спонтанно. Раздел «Влияние на проектное решение» тоже довольно важен. Почти всегда артефакты проектирования оказывают влияние на существующее программное обеспечение, равно как и на другие аспекты деятельности компании. Вот эти-то варианты воздействия вам и предстоит зафиксировать. Область «Необходимые действия» ориентирует в последующих действиях, направленных на реализацию проектного решения. Ведь действительно совещание без реализации принятых решений на практике есть не более чем потеря времени. Кроме того, имеет смысл составить краткое письменное резюме проблем, обсуждавшихся на совещании, и присовокупить его к базе знаний группы разработчиков. Эта информация может понадобиться тем сотрудникам, которые по той или иной причине не смогли присутствовать на совещании, а также специалистам, только что присоединившимся к вашей группе и считающим необходимым ознакомиться с историей проекта.
Совещание без реализации принятых решений на практике есть не более чем потеря времени.
В целях соблюдения четкости формулировок постарайтесь, чтобы размер шаблона не превысил одной страницы. Если относительно какого-то конкретного проектного решения увеличить размер шаблона все-таки потребуется, возьмите дополнительный лист и соответствующим образом пронумеруйте его. Полагаю, вы поняли, что я имею в виду. Не сомневаюсь также, что вы сможете придумать более удобный метод. Главное – сделать так, чтобы при переходе на следующий этап проектирования (а именно к спецификации проектного решения) вы не опирались лишь на свою память. Ну ладно, я закругляюсь с этой темой – все-таки мою книгу сложно причислить к комплексным исследованиям по управлению проектами и, тем более, к монографиям по объектно-ориентированному проектированию.
Не углубляясь в дебри программного проектирования, отмечу один момент, касающийся персонала. Вы должны осознать, что несмотря на ваши функции руководителя, совершенно не факт, что из всех сотрудников группы у вас самые яркие архитектурные способности. Как вы знаете, программисты все разные, и зачастую в одном человеке мирно уживаются характеристики разных типов. (Вспомните мою классификацию пород, приведенную в главе 1.) Если вы отдаете себе отчет в том, что ваши возможности по части глобального архитектурного мышления весьма ограниченны, выделите среди своих сотрудников тех людей, которые способны достигнуть в этом отношении более серьезных результатов,
Вы говорите, что у вас нет дипломатических навыков? Что я могу сказать? Учитесь! Дипломатия – это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус.
Дипломатия – это искусство выслушивать, прежде чем говорить, думать, прежде чем предлагать, и постоянно искать консенсус.
Задача не из простых, кто бы спорил, но ведь деньги, которые вам платят, надо отрабатывать! Рекомендую прочесть несколько книжек по поводу формирования команды (см. библиографию). Но это не главное. Основная предпосылка к достижению желаемого результата – сильное желание. Стремление добиться общего для всех участников группы успеха вы должны ставить выше искушения выиграть случайный спор. Запомните, выиграть спор невозможно! В условиях командной работы все вместе либо выигрывают, либо проигрывают.
Я упомянул, что основной целью проектного совещания является выработка консенсуса. Я совершенно не имею в виду голосование по предложенным идеям. Демократия – система, прекрасно подходящая для наций, – не приживается в техническом проектировании [55] . Отдав предпочтение идеям одного человека и, соответственно, отказавшись от предложений другого, вы не добьетесь продуктивного мышления. Консенсус достигается за счет синтеза идей. Торг по принципу «я соглашусь на твою характеристику, если ты согласишься на мою», здесь неуместен. Что я понимаю под синтезом? Это процесс, в ходе которого путем проработки конкурирующих идей выкристаллизовываются их наилучшие качества. С вашей стороны для достижения этой цели требуется терпение и настойчивость. Ведь вы как руководитель должны стремиться к тому, чтобы вычленить наилучшее из всех возможных проектных решений. Это та цена, которую приходится платить за успех. В своем потрясающем сборнике статей по кадровому обеспечению Ларри Константайн высказывает следующие соображения:
55
Мне очень понравилась фраза, которую в фильме «Crimson Tide» Джин Хэкман сказал Дэнзелу Вашингтону: «Мы должны не заниматься демократией, а оберегать ее». Аналогичным образом, проводя проектное совещание, лучше воздерживаться от реверансов в пользу той или иной обсуждаемой идеи – как бы красноречиво ее ни защищали приверженцы. Ваша цель заключается в том, чтобы поощрять активный и плодотворный мыслительный процесс.
«Синтез приводит к появлению оригинальной концепции, в которую входят сущностные характеристики всех представленных идей и предложений… Консенсус, построенный на основе синтеза, не только включает в себя лучшие из предложенных альтернатив, – он, как правило, вводит новые характеристики и возможности, являющиеся логическим продолжением объединения высказанных идей» [56] .
Работать с Полом было чрезвычайно трудно. Он меня ужасно раздражал. То обстоятельство, что директор переманил его от нашего главного конкурента, назначив ему зарплату больше моей, а затем поручил мне им руководить, ничуть не способствовало смягчению наших отношений. Ну и что, что он доктор физических наук и единолично написал потрясающую программу, которая заставила нашу компанию заметно потесниться на рынке? С ним было невозможно работать. Он был полностью уверен в своей неизменной правоте и воспринимал коллег как молокососов. Естественно, собственные представления о совершенстве были для него единственной точкой зрения на все предполагаемые функции программы. Он не хотел ничего знать ни о компонентной разработке, ни о программировании в команде. Передо мной стояла невыполнимая задача – задействовать Пола в процессе разработки нового поколения программных продуктов, с помощью его идей побудить к действию остальных специалистов и при этом умудриться сделать так, чтобы они тоже почувствовали свою причастность к проектному решению
56
Larry L. Constantine, The Pcoplewarc Papers (Upper Saddle River, NJ: Yourdon Press, 2001), p. 10.