Страница:
Для того чтобы программисты достигали в своей деятельности серьезных успехов, у них должна быть возможность, с одной стороны, некоторое время поработать в коллективе, с другой – пораскинуть мозгами в полном одиночестве.
Поскольку в ваши обязанности входят регулярные встречи с сотрудниками в формате «один на один», пространство вашего кабинета следует немного увеличить по сравнению со средним показателем. Не обольщайтесь – роль руководителя сама по себе не дает вам права на большую площадь; она нужна лишь для того, чтобы вы более эффективно выполняли свои функции. Кроме того, для проведения полноценных собраний с участием всех сотрудников отдела вам нужен конференц-зал, оснащенный электронным табло. Все мы наслушались историй о том, как легенды нашей высокотехнологичной отрасли регулярно режутся друг с другом в видеоигры. Вот и вам, если, конечно, позволят ресурсы, желательно организовать отдельное пространство для отдыха сотрудников. Если же средства не позволяют завести такое помещение исключительно для программистов вашего отдела, постарайтесь решить эту проблему совместно с другими подразделениями.
Удаленная работа, о которой мы также упоминали в предыдущей главе, – это хороший способ свести к минимуму влияние внешних раздражителей и решить проблему уединения; в то же время с точки зрения сотрудничества такая практика дает не слишком хорошие результаты. В процессе разработки программных средств почтовые сообщения и телефонные звонки на самом деле не компенсируют недостаток личного общения. Поэтому вы должны сочетать возможность удаленной работы с потребностью в работе совместной. Когда ответственные лица находятся в одном месте в одно время, на принятие решений у них уходят считанные минуты. Если же они находятся в разных местах, на решение аналогичных проблем могут уходить часы, а то и целые дни.
Предоставляйте лучший инструментарий
В распоряжении любого программиста должен быть быстродействующий компьютер с максимально возможным объемом памяти. Кроме того, программисту нужна тестовая машина, воспроизводящая стандартные характеристики пользовательских компьютеров. Вполне вероятно, что в вашей компании наличествует сетевая инфраструктура, призванная обеспечивать поддержку разрабатываемых продуктов (веб-серверы, метафреймы Citrix Metaframe и т. д.). Соответственно, для тестирования результатов разработки эти продукты следует дублировать зеркалами. Иногда они могут использоваться совместно с группой тестирования, однако имейте в виду, что отделение сред разработки и тестирования от непосредственного производства себя оправдывает. Мне приходилось встречаться с компаниями, которые бездумно разрешали программистам напрямую редактировать веб-сайты путем удаленной загрузки файлов. Это самый неудачный метод, какой только можно себе представить. Он, конечно, удобен, но чрезвычайно опасен.Если вашим сотрудникам приходится переходить с места на место (или сверхурочно работать дома), лучше всего приобрести для них ноутбуки. Сегодня они практически не уступают по своим возможностям настольным компьютерам, поэтому экономить не стоит. Не забывайте к тому же, что программисты предъявляют к своим машинам значительно более высокие требования, чем средние пользователи. Возможно, вам придется скорректировать принятую в компании политику технического обеспечения с учетом потребностей ваших подчиненных. Программистам нужно предоставить полномочия администратора в отношении прав доступа и конфигурирования их собственных машин. Если кто-то из них запутается в конфигурации, покажите, как решить проблему, которую он сам себе создал. Прибегать к услугам специалистов следует лишь в крайнем случае. Программисты, которые не знают, как сконфигурировать операционную систему или установить ее с чистого листа, просто недостаточно научены. Их уровень владения понятиями TCP/IP не должен уступать уровню системных инженеров.
В конце рабочего дня
Скорее всего, вы уже предвкушаете разговоры насчет наведения порядка на рабочем столе и перекладывания вещей с места на место. Это все хорошо, но мне хочется сказать кое-что более важное. Каких бы высот по части организованности вы ни достигли, чувства усталости и переутомления не избежать. Таков уж характер деятельности менеджера. Производство программных средств, руководство людьми и лидерские функции в их среде, равно как и все другие действия, осуществляемые руководителем, иногда приводят его в состояние прострации. Как бы то ни было, обобщая все вышесказанное, надеюсь, что вы запомните несколько принципов, способствующих достижению успеха.
• Допускают ли ваши собственные рабочие условия оперативность при превращении информации в действия? Если нет, постарайтесь систематизировать делопроизводство в соответствии с рекомендуемыми методиками в этой области – так, чтобы, помимо просто руководства, вы могли взять на себя лидерские функции.
• Работайте над теми сферами своей деятельности, которые поддаются контролю, и смиритесь с тем, что некоторые из сфер неконтролируемы.
• Наладив активное взаимодействие с другими отделами, всеми силами способствуйте повышению организационного уровня компании в целом. Держите дела в своем отделе под контролем и будьте в этом отношении примером для других руководителей.
Большие задания следует дробить на более мелкие и лучше управляемые. Вооружившись этим подходом, можно с готовностью приниматься за решение глобальных задач. Иначе говоря, выводите вторичные задачи, которые предусматривают возможность решения в течение одного непрерывного промежутка времени. Так вы сможете организовать свои временные ресурсы и решать по одной задаче за раз. Ничто так не поднимает уровень самооценки, как наличие структурированного плана и его последовательное выполнение. Уверенность в своих силах, в свою очередь, приводит к достижению успеха, снижению стрессовых нагрузок и к удовлетворению собственной деятельностью, подпитываемой помощью в достижении результата окружающим вас людям.
• Допускают ли ваши собственные рабочие условия оперативность при превращении информации в действия? Если нет, постарайтесь систематизировать делопроизводство в соответствии с рекомендуемыми методиками в этой области – так, чтобы, помимо просто руководства, вы могли взять на себя лидерские функции.
• Работайте над теми сферами своей деятельности, которые поддаются контролю, и смиритесь с тем, что некоторые из сфер неконтролируемы.
• Наладив активное взаимодействие с другими отделами, всеми силами способствуйте повышению организационного уровня компании в целом. Держите дела в своем отделе под контролем и будьте в этом отношении примером для других руководителей.
Большие задания следует дробить на более мелкие и лучше управляемые. Вооружившись этим подходом, можно с готовностью приниматься за решение глобальных задач. Иначе говоря, выводите вторичные задачи, которые предусматривают возможность решения в течение одного непрерывного промежутка времени. Так вы сможете организовать свои временные ресурсы и решать по одной задаче за раз. Ничто так не поднимает уровень самооценки, как наличие структурированного плана и его последовательное выполнение. Уверенность в своих силах, в свою очередь, приводит к достижению успеха, снижению стрессовых нагрузок и к удовлетворению собственной деятельностью, подпитываемой помощью в достижении результата окружающим вас людям.
Что дальше
В следующей главе мы поговорим о том, какую роль вы должны исполнять на совещаниях. Организационные навыки, проявляемые на совещаниях, вносят существенный вклад в достижении поставленных целей. В идеале совещания с другими группами (и, в особенности, с собственными сотрудниками) должны проводиться исходя из четко сформулированных целей и не менее определенных представлений о предполагаемых результатах. По мере ознакомления с материалом моей книги вы постепенно придете к мысли, что решить все проблемы сразу не получится. Вряд ли, к тому же, вам удастся извлечь из этой книги точные схемы действий в тех или иных ситуациях. Темы, которые я поднимаю, придется переосмыслить – так, чтобы выстроить материал согласно специфике исполняемых вами функций. Итак, вперед – читайте сердцем! Делайте с моим материалом все, что сочтете нужным, – я не обижусь.
Глава 5
Как вести совещания
Почему совещания нужно вести? Дело в том, что когда программисты, намереваясь обсудить ту или иную проблему, собираются вместе, их личностные качества имеют обыкновение вступать в конфликт, который, естественно, достижению поставленных целей совещания не способствует. Привыкнув заниматься кодированием, вы, скорее всего, перед проведением первого (или пятидесятого) совещания будете испытывать неприятные опасения
[52]. Не беспокойтесь, эта глава, посвященная проведению совещаний, призвана повысить вашу подготовленность в этой области. Именно от вашей разумности зависит успех в деле ведения совещаний.
Технари вроде нас с вами часто страдают аллергией на совещания. Нам кажется, что, кроме потери времени, от них нет никакого толку, и значительно эффективнее лишний час повисеть над клавиатурой и попытаться написать приемлемый код. Как руководитель вы действительно ожидаете, что сотрудники будут проводить драгоценные рабочие часы за компьютером, но в то же время вы должны контролировать их деятельность. Совещания помогают координировать результаты ваших собственных усилий. Рассматривать совещания как неизбежное зло не следует, ибо они таковым не являются. Собираясь вместе со своими сотрудниками, можно обсуждать идеи друг друга и тем самым совершенствовать представления рабочей группы о выбранных стратегии и тактике.
Технари вроде нас с вами часто страдают аллергией на совещания. Нам кажется, что, кроме потери времени, от них нет никакого толку, и значительно эффективнее лишний час повисеть над клавиатурой и попытаться написать приемлемый код. Как руководитель вы действительно ожидаете, что сотрудники будут проводить драгоценные рабочие часы за компьютером, но в то же время вы должны контролировать их деятельность. Совещания помогают координировать результаты ваших собственных усилий. Рассматривать совещания как неизбежное зло не следует, ибо они таковым не являются. Собираясь вместе со своими сотрудниками, можно обсуждать идеи друг друга и тем самым совершенствовать представления рабочей группы о выбранных стратегии и тактике.
Еженедельные совещания
Я рекомендую проводить совещания с сотрудниками каждую неделю в одно и то же время. Не стоит отлынивать от этих встреч, даже если вы плохо себе представляете, что на них можно обсудить. На самом деле предмет для обсуждения найдется – нужно только каждую неделю придерживаться на совещании четкой повестки дня.
• Что вы делали на прошлой неделе?
• Что вы собираетесь делать на этой неделе?
• Что мешает вам выполнить ваши задания в назначенное время?
Заставьте своих сотрудников приносить на совещания списки поставленных перед ними задач и просите их каждый раз отвечать на эти три простых вопроса. При формулировании заданий вы устанавливаете для них сроки завершения, не так ли? Задания программистам нужно давать в письменном виде, даже если текст задания ограничивается высокоуровневым описанием очередной характеристики программного продукта. Зачастую выполнение основного задания предполагает предварительное решение ряда вспомогательных задач. На все эти задачи – основные и второстепенные – нужно обращать внимание; вы должны постоянно напоминать сотрудникам о том, что от них требуется. В зависимости от уровня руководства проектом, который вам доступен и которому вы симпатизируете, список задач может выглядеть совершенно по-разному – в диапазоне от простого описания задачи с указанием срока ее решения до комплексной временной схемы проекта с детальной росписью подзадач для каждого значимого объекта поставки. О назначении заданий я говорил в предыдущей главе. Попробуйте придумать собственный метод составления списков заданий. Адаптируйте его к индивидуальным характеристикам компании и к собственному стилю руководства. Наличие списков заданий должно стать обязательным условием проведения еженедельного собрания персонала.
Во время совещания делайте акцент на понятии «объектов поставки». Этим понятием обозначаются характеристики или продукты, поставляемые вашими подчиненными программистами для публичного потребления. Избегайте призрачных намеков на результат. Не надо говорить программистам о том, что они должны «исправить ошибки» или «внести некоторые доработки».
Во время совещания делайте акцент на понятии «объектов поставки». Этим понятием обозначаются характеристики или продукты, поставляемые вашими подчиненными программистами для публичного потребления. Избегайте призрачных намеков на результат. Не надо говорить программистам о том, что они должны «исправить ошибки» или «внести некоторые доработки».
Если в вашей компании есть мощная группа с сильными маркетинговыми ресурсами, в задачу которой входит исчерпывающее описание продукта, ваши функции заметно упрощаются. Повторюсь: на совещаниях, вместо того чтобы спорить с программистами о хитросплетениях кода, вы должны проверять сотрудников и обеспечивать их готовность в срок решить задачи, поставленные в связи с производством программного продукта. С другой стороны, иногда легкомысленное отношение к коду способствует его более успешной разработке; поэтому старайтесь не предстать в глазах сотрудников тираном.
Достоинство предложенной мной программы совещания состоит в том, что она проста, предполагает диалог с сотрудниками и обеспечивает возможность выявления трудностей, с которыми они сталкиваются. Заставляя программистов формулировать достигнутые цели и ставить перед собой цели на неделю, вы укрепляете в их сознании мысль о том, что они работают ради создания конкретного продукта. С другой стороны, вам нужно, чтобы программисты, копаясь в деталях реализации, держали в голове все вспомогательные задачи, направленные на решение более общей (высокоуровневой) задачи. Сначала полезно определить в контексте проекта высокоуровневую задачу – например, «реализовать модуль, выражающий функцию X», а затем, исходя из имеющихся ресурсов, сформулировать вспомогательные, зависимые задачи. В процессе администрирования за этим также придется следить. Если бы мы, руководители, могли держать в голове все детали, связанные с реализацией любой конкретной характеристики программного продукта, было бы, конечно, замечательно; впрочем, в таком случае мы утратили бы потенциал делегирования и фактически отказались бы от обращения к интеллектуальным ресурсам и техническим навыкам своих сотрудников. Скажем по-другому: пытайтесь держать в голове как можно больше деталей, и если ваша команда состоит из профессионалов с достаточной мотивацией, они помогут вам справиться с задачей.
В конце концов, над результатом работает вся группа, а ваша цель заключается в том, чтобы ставить планки и проверять результаты.
Время от времени к своей повестке дня я прибавлял разбор литературы. Выберите добротную книгу о методиках программирования, принципах проектирования или по какой-либо другой теме, связанной с будущим развитием нашей отрасли, и попытайтесь совместно с подчиненными разобраться в ее материале. Попросите каждого выступить на следующем совещании с устным докладом по ее содержанию. Создайте атмосферу университетского семинара, только не пытайтесь казаться слишком серьезным. Эта методика здорово стимулирует потребность в дальнейшем обучении.
Не сомневаюсь, что при необходимости вы учтете этот мой опыт; однако остерегайтесь растягивать совещания и обсуждать предметы слишком детально. Дело в том, что при продолжительности более 45 минут результат совещания может оказаться отрицательным. Совещание сотрудников способствует углублению интеграции в команде и предоставляет возможность специалистам, столкнувшимся с особо трудными задачами, обращаться к коллективному интеллекту. К тем, кто не справляется со своей работой в срок, следует относиться довольно жестко. Заставьте их объяснить остальным членам группы, по какой причине они опаздывают с решением поставленной задачи. Впрочем, не переусердствуйте в своих манипуляциях с групповым поведением. Публичное унижение сложно признать эффективным средством повышения производительности – поэтому, критикуя сотрудников, будьте сдержанны; в том же, что касается похвал (по крайней мере, на публике), не скупитесь.
Особое значение совещания персонала приобретают при приближении срока завершения работы над кодом. В такие моменты внимание группы следует обратить на особо нудные задачи и внесение в текст программы последних корректив – эти вопросы всегда необходимо решать с особой тщательностью. Проводя еженедельные совещания сотрудников, вы сможете поддержать их внимание, когда на подходе будут наиболее критичные этапы процесса разработки.
Каждую неделю при проведении совещаний будьте готовы к тому, что сотрудники станут оценивать ваши лидерские качества. Не стоит забывать, что, проводя еженедельные совещания, вы нарабатываете соответствующий навык. Полжизни мы работаем на публику – а если серьезно, то, что бы там ни говорил Эмерсон (Emerson) [53], мне сложно представить себе ситуацию, в которой последовательный человек выглядел бы глупо. Еженедельно выискивая пути углубления кооперации между сотрудниками, вы формируете полноценную команду. Не стоит препятствовать проявлению соревновательного принципа – впрочем, в этом контексте вы должны играть уравновешивающую роль. Время от времени сотрудников следует ненавязчиво сдерживать или, напротив, побуждать к активным действиям. Если вы хорошо разбираетесь в своих подчиненных, то те действия корректирующего характера, которые вам предстоит предпринять, подскажет ваша интуиция. Эта роль напоминает позицию родителей по отношению к своим подросткам-отпрыскам (слава Богу, на эту тему мне писать не придется).
• Что вы делали на прошлой неделе?
• Что вы собираетесь делать на этой неделе?
• Что мешает вам выполнить ваши задания в назначенное время?
Заставьте своих сотрудников приносить на совещания списки поставленных перед ними задач и просите их каждый раз отвечать на эти три простых вопроса. При формулировании заданий вы устанавливаете для них сроки завершения, не так ли? Задания программистам нужно давать в письменном виде, даже если текст задания ограничивается высокоуровневым описанием очередной характеристики программного продукта. Зачастую выполнение основного задания предполагает предварительное решение ряда вспомогательных задач. На все эти задачи – основные и второстепенные – нужно обращать внимание; вы должны постоянно напоминать сотрудникам о том, что от них требуется. В зависимости от уровня руководства проектом, который вам доступен и которому вы симпатизируете, список задач может выглядеть совершенно по-разному – в диапазоне от простого описания задачи с указанием срока ее решения до комплексной временной схемы проекта с детальной росписью подзадач для каждого значимого объекта поставки. О назначении заданий я говорил в предыдущей главе. Попробуйте придумать собственный метод составления списков заданий. Адаптируйте его к индивидуальным характеристикам компании и к собственному стилю руководства. Наличие списков заданий должно стать обязательным условием проведения еженедельного собрания персонала.
Во время совещания делайте акцент на понятии «объектов поставки». Этим понятием обозначаются характеристики или продукты, поставляемые вашими подчиненными программистами для публичного потребления. Избегайте призрачных намеков на результат. Не надо говорить программистам о том, что они должны «исправить ошибки» или «внести некоторые доработки».
Во время совещания делайте акцент на понятии «объектов поставки». Этим понятием обозначаются характеристики или продукты, поставляемые вашими подчиненными программистами для публичного потребления. Избегайте призрачных намеков на результат. Не надо говорить программистам о том, что они должны «исправить ошибки» или «внести некоторые доработки».
Если в вашей компании есть мощная группа с сильными маркетинговыми ресурсами, в задачу которой входит исчерпывающее описание продукта, ваши функции заметно упрощаются. Повторюсь: на совещаниях, вместо того чтобы спорить с программистами о хитросплетениях кода, вы должны проверять сотрудников и обеспечивать их готовность в срок решить задачи, поставленные в связи с производством программного продукта. С другой стороны, иногда легкомысленное отношение к коду способствует его более успешной разработке; поэтому старайтесь не предстать в глазах сотрудников тираном.
Достоинство предложенной мной программы совещания состоит в том, что она проста, предполагает диалог с сотрудниками и обеспечивает возможность выявления трудностей, с которыми они сталкиваются. Заставляя программистов формулировать достигнутые цели и ставить перед собой цели на неделю, вы укрепляете в их сознании мысль о том, что они работают ради создания конкретного продукта. С другой стороны, вам нужно, чтобы программисты, копаясь в деталях реализации, держали в голове все вспомогательные задачи, направленные на решение более общей (высокоуровневой) задачи. Сначала полезно определить в контексте проекта высокоуровневую задачу – например, «реализовать модуль, выражающий функцию X», а затем, исходя из имеющихся ресурсов, сформулировать вспомогательные, зависимые задачи. В процессе администрирования за этим также придется следить. Если бы мы, руководители, могли держать в голове все детали, связанные с реализацией любой конкретной характеристики программного продукта, было бы, конечно, замечательно; впрочем, в таком случае мы утратили бы потенциал делегирования и фактически отказались бы от обращения к интеллектуальным ресурсам и техническим навыкам своих сотрудников. Скажем по-другому: пытайтесь держать в голове как можно больше деталей, и если ваша команда состоит из профессионалов с достаточной мотивацией, они помогут вам справиться с задачей.
В конце концов, над результатом работает вся группа, а ваша цель заключается в том, чтобы ставить планки и проверять результаты.
Время от времени к своей повестке дня я прибавлял разбор литературы. Выберите добротную книгу о методиках программирования, принципах проектирования или по какой-либо другой теме, связанной с будущим развитием нашей отрасли, и попытайтесь совместно с подчиненными разобраться в ее материале. Попросите каждого выступить на следующем совещании с устным докладом по ее содержанию. Создайте атмосферу университетского семинара, только не пытайтесь казаться слишком серьезным. Эта методика здорово стимулирует потребность в дальнейшем обучении.
Не сомневаюсь, что при необходимости вы учтете этот мой опыт; однако остерегайтесь растягивать совещания и обсуждать предметы слишком детально. Дело в том, что при продолжительности более 45 минут результат совещания может оказаться отрицательным. Совещание сотрудников способствует углублению интеграции в команде и предоставляет возможность специалистам, столкнувшимся с особо трудными задачами, обращаться к коллективному интеллекту. К тем, кто не справляется со своей работой в срок, следует относиться довольно жестко. Заставьте их объяснить остальным членам группы, по какой причине они опаздывают с решением поставленной задачи. Впрочем, не переусердствуйте в своих манипуляциях с групповым поведением. Публичное унижение сложно признать эффективным средством повышения производительности – поэтому, критикуя сотрудников, будьте сдержанны; в том же, что касается похвал (по крайней мере, на публике), не скупитесь.
Особое значение совещания персонала приобретают при приближении срока завершения работы над кодом. В такие моменты внимание группы следует обратить на особо нудные задачи и внесение в текст программы последних корректив – эти вопросы всегда необходимо решать с особой тщательностью. Проводя еженедельные совещания сотрудников, вы сможете поддержать их внимание, когда на подходе будут наиболее критичные этапы процесса разработки.
Каждую неделю при проведении совещаний будьте готовы к тому, что сотрудники станут оценивать ваши лидерские качества. Не стоит забывать, что, проводя еженедельные совещания, вы нарабатываете соответствующий навык. Полжизни мы работаем на публику – а если серьезно, то, что бы там ни говорил Эмерсон (Emerson) [53], мне сложно представить себе ситуацию, в которой последовательный человек выглядел бы глупо. Еженедельно выискивая пути углубления кооперации между сотрудниками, вы формируете полноценную команду. Не стоит препятствовать проявлению соревновательного принципа – впрочем, в этом контексте вы должны играть уравновешивающую роль. Время от времени сотрудников следует ненавязчиво сдерживать или, напротив, побуждать к активным действиям. Если вы хорошо разбираетесь в своих подчиненных, то те действия корректирующего характера, которые вам предстоит предпринять, подскажет ваша интуиция. Эта роль напоминает позицию родителей по отношению к своим подросткам-отпрыскам (слава Богу, на эту тему мне писать не придется).
Проектные совещания
Будь вы хоть во сто крат талантливее лучшего программиста своей группы, скорее всего, всех ваших навыков, не говоря уже о времени, не хватит, чтобы самостоятельно реализовать все характеристики разрабатываемых программных продуктов. Даже если бы у вас нашлось время, разрабатывать все самому не имеет особого смысла – ведь тогда коллеги-программисты не смогут ощущать себя соучастниками творческого процесса. Иногда на проектных совещаниях нам приходится иметь дело с социально пассивной группой
[54], которую неплохо бы превратить в команду активных, мотивированных и рвущихся к действию специалистов, готовых проектировать и реализовывать очередные характеристики вовремя и практически безошибочно. Такого рода индивидуальные особенности сотрудников зачастую довольно причудливо проявляются в контексте поведения группы в целом. Как настроить людей, с которыми приходится работать, на позитивный лад? Кто знает – может быть, вам и удастся достичь цели колдовскими чарами и материальным поощрением, но на самом деле эти способы неэффективны. Что вам действительно нужно, так это разум опытного психолога и душа дипломата-карьериста. Добро пожаловать в чрезвычайно запутанный, но в не меньшей степени притягательный мир группового поведения!
Проектировать программные продукты самому неразумно – ведь тогда коллеги-программисты не смогут ощутить себя соучастниками творческого процесса.
Так как же стать блистательным лидером проектной группы, если в данный момент вы таковым не являетесь? Без мыслительной деятельности и постоянной практики ничего не выйдет. Рассмотрим, однако же, некоторые проблемы и явления, наблюдаемые на стандартном проектном совещании.
• Ваша задача – сделать так, чтобы все функции были корректно спроектированы и впоследствии качественно разработаны.
• У каждого участника группы могут быть собственные представления относительно проектного решения одной и той же функции.
• Программисты склонны проектировать лишь те функции, которые они могут или хотят разрабатывать.
• У некоторых программистов могут быть планы, отличные от ваших; трудно выявляемые, такие бунтари способны привести к саботажу совещаний.
• Единодушная поддержка сотрудниками высказанных вами идей (если только они не объективно гениальны) наводит на грустные размышления.
• В процессе проектирования вы обязаны пытаться достичь консенсуса – это трудная задача, но усилия, поверьте мне, окупаются. Достичь компромисса несколько легче, но если кто-то выступит со своей вымученной идеей и не получит поддержки, вы рискуете создать себе врага.
Совещания либо осложняют существующую в группе разработчиков ситуацию, либо разрешают кризис. В каком направлении пойдете вы, всецело зависит от вашей воли. Силами наличествующего персонала и с учетом предъявленных требований вы должны создать работоспособные спецификации, на основе которых впоследствии можно будет писать качественный код.
В большинстве компаний достичь этой цели довольно сложно. Слава Богу, моя книга – не более чем скромное руководство, и я совсем не претендую на то, чтобы осветить все мыслимые вопросы. (Молодец, Хэнк! Избавился от ответственности.)
Шучу. Если серьезно, обратите внимание на следующие рекомендации:
• Вы должны знать сильные и слабые качества участников своей команды. Не менее важно осознавать собственные достоинства и недостатки. Именно об этом я говорил в первых трех главах книги.
• Документацию с требованиями имеет смысл разбить на разделы по схожей функциональности, допускающие решение средствами объектно-ориентированного проектирования.
• Делайте заметки. Если можете себе это позволить, заведите электронное табло. Зафиксируйте совещание на видеопленке, оцифруйте ее, а после создания первого черновика проектной спецификации покажите отснятый материал членам группы.
• Подключите ноутбук к большому монитору и демонстрируйте сотрудникам группы примеры готового кода, указывая на те его аспекты, которые считаете удачными или, напротив, неудачными.
• Уберите из помещения, в котором проводите совещания, телефонный аппарат. Этого можно не делать лишь в том случае, если во время совещания вы собираетесь обратиться к какому-нибудь удаленному абоненту за свежими идеями.
• Работайте в удобном и изолированном от шума помещении. Делайте перерывы, чтобы усталость организмов присутствующих не мешала деятельной работе их мозгов.
• Составьте план действий на каждый день; при необходимости вносите в него коррективы и отталкивайтесь от него в деле реализации проектных заданий. Отведите последний день на критический обзор и обобщение результатов совещания.
Как я только что сказал, вести заметки совершенно необходимо. Если вы регулярно выходите к электронному табло с предложением новых идей по проекту, что-то писать на бумажке становится довольно проблематично. В таком случае имеет смысл попросить одного из сотрудников выполнять эту функцию за вас. Представляете, как будет обидно, если, проведя плодотворное совещание на прошлой неделе, вы забудете о принятых на нем решениях уже через несколько дней! Для человека, которому вы намерены поручить протоколирование совещания, можно составить специальный шаблон. Пример такового показан на рис. 5.1.
Несколько замечаний по поводу шаблона. Большая часть информации, которая в нем фиксируется, очевидна. Самая пространная область шаблона – «Замечания» – предусматривает запись информации в свободной форме. В ней можно, скажем, начертить блок-схему (если электронное табло неисправно) или просто зафиксировать какие-то идеи, которые во время совещаний часто появляются спонтанно. Раздел «Влияние на проектное решение» тоже довольно важен. Почти всегда артефакты проектирования оказывают влияние на существующее программное обеспечение, равно как и на другие аспекты деятельности компании. Вот эти-то варианты воздействия вам и предстоит зафиксировать. Область «Необходимые действия» ориентирует в последующих действиях, направленных на реализацию проектного решения. Ведь действительно совещание без реализации принятых решений на практике есть не более чем потеря времени. Кроме того, имеет смысл составить краткое письменное резюме проблем, обсуждавшихся на совещании, и присовокупить его к базе знаний группы разработчиков. Эта информация может понадобиться тем сотрудникам, которые по той или иной причине не смогли присутствовать на совещании, а также специалистам, только что присоединившимся к вашей группе и считающим необходимым ознакомиться с историей проекта.
Совещание без реализации принятых решений на практике есть не более чем потеря времени.
В целях соблюдения четкости формулировок постарайтесь, чтобы размер шаблона не превысил одной страницы. Если относительно какого-то конкретного проектного решения увеличить размер шаблона все-таки потребуется, возьмите дополнительный лист и соответствующим образом пронумеруйте его. Полагаю, вы поняли, что я имею в виду. Не сомневаюсь также, что вы сможете придумать более удобный метод. Главное – сделать так, чтобы при переходе на следующий этап проектирования (а именно к спецификации проектного решения) вы не опирались лишь на свою память. Ну ладно, я закругляюсь с этой темой – все-таки мою книгу сложно причислить к комплексным исследованиям по управлению проектами и, тем более, к монографиям по объектно-ориентированному проектированию.
Не углубляясь в дебри программного проектирования, отмечу один момент, касающийся персонала. Вы должны осознать, что несмотря на ваши функции руководителя, совершенно не факт, что из всех сотрудников группы у вас самые яркие архитектурные способности. Как вы знаете, программисты все разные, и зачастую в одном человеке мирно уживаются характеристики разных типов. (Вспомните мою классификацию пород, приведенную в главе 1.) Если вы отдаете себе отчет в том, что ваши возможности по части глобального архитектурного мышления весьма ограниченны, выделите среди своих сотрудников тех людей, которые способны достигнуть в этом отношении более серьезных результатов, и позвольте им принимать в процессе как можно более деятельное участие. Следует быть готовым к непреодолимому желанию тоже поучаствовать в процессе генерации идей, однако имейте в виду, что ваша основная задача – справляться с отбором предлагаемых идей, а не генерировать свои. Быть пропагандистом хороших идей, уверяю вас, обычно не менее почетно, чем быть их генератором. В этой области вам придется пустить в ход свои дипломатические способности.
Проектировать программные продукты самому неразумно – ведь тогда коллеги-программисты не смогут ощутить себя соучастниками творческого процесса.
Так как же стать блистательным лидером проектной группы, если в данный момент вы таковым не являетесь? Без мыслительной деятельности и постоянной практики ничего не выйдет. Рассмотрим, однако же, некоторые проблемы и явления, наблюдаемые на стандартном проектном совещании.
• Ваша задача – сделать так, чтобы все функции были корректно спроектированы и впоследствии качественно разработаны.
• У каждого участника группы могут быть собственные представления относительно проектного решения одной и той же функции.
• Программисты склонны проектировать лишь те функции, которые они могут или хотят разрабатывать.
• У некоторых программистов могут быть планы, отличные от ваших; трудно выявляемые, такие бунтари способны привести к саботажу совещаний.
• Единодушная поддержка сотрудниками высказанных вами идей (если только они не объективно гениальны) наводит на грустные размышления.
• В процессе проектирования вы обязаны пытаться достичь консенсуса – это трудная задача, но усилия, поверьте мне, окупаются. Достичь компромисса несколько легче, но если кто-то выступит со своей вымученной идеей и не получит поддержки, вы рискуете создать себе врага.
Совещания либо осложняют существующую в группе разработчиков ситуацию, либо разрешают кризис. В каком направлении пойдете вы, всецело зависит от вашей воли. Силами наличествующего персонала и с учетом предъявленных требований вы должны создать работоспособные спецификации, на основе которых впоследствии можно будет писать качественный код.
В большинстве компаний достичь этой цели довольно сложно. Слава Богу, моя книга – не более чем скромное руководство, и я совсем не претендую на то, чтобы осветить все мыслимые вопросы. (Молодец, Хэнк! Избавился от ответственности.)
Шучу. Если серьезно, обратите внимание на следующие рекомендации:
• Вы должны знать сильные и слабые качества участников своей команды. Не менее важно осознавать собственные достоинства и недостатки. Именно об этом я говорил в первых трех главах книги.
• Документацию с требованиями имеет смысл разбить на разделы по схожей функциональности, допускающие решение средствами объектно-ориентированного проектирования.
• Делайте заметки. Если можете себе это позволить, заведите электронное табло. Зафиксируйте совещание на видеопленке, оцифруйте ее, а после создания первого черновика проектной спецификации покажите отснятый материал членам группы.
• Подключите ноутбук к большому монитору и демонстрируйте сотрудникам группы примеры готового кода, указывая на те его аспекты, которые считаете удачными или, напротив, неудачными.
• Уберите из помещения, в котором проводите совещания, телефонный аппарат. Этого можно не делать лишь в том случае, если во время совещания вы собираетесь обратиться к какому-нибудь удаленному абоненту за свежими идеями.
• Работайте в удобном и изолированном от шума помещении. Делайте перерывы, чтобы усталость организмов присутствующих не мешала деятельной работе их мозгов.
• Составьте план действий на каждый день; при необходимости вносите в него коррективы и отталкивайтесь от него в деле реализации проектных заданий. Отведите последний день на критический обзор и обобщение результатов совещания.
Как я только что сказал, вести заметки совершенно необходимо. Если вы регулярно выходите к электронному табло с предложением новых идей по проекту, что-то писать на бумажке становится довольно проблематично. В таком случае имеет смысл попросить одного из сотрудников выполнять эту функцию за вас. Представляете, как будет обидно, если, проведя плодотворное совещание на прошлой неделе, вы забудете о принятых на нем решениях уже через несколько дней! Для человека, которому вы намерены поручить протоколирование совещания, можно составить специальный шаблон. Пример такового показан на рис. 5.1.
Несколько замечаний по поводу шаблона. Большая часть информации, которая в нем фиксируется, очевидна. Самая пространная область шаблона – «Замечания» – предусматривает запись информации в свободной форме. В ней можно, скажем, начертить блок-схему (если электронное табло неисправно) или просто зафиксировать какие-то идеи, которые во время совещаний часто появляются спонтанно. Раздел «Влияние на проектное решение» тоже довольно важен. Почти всегда артефакты проектирования оказывают влияние на существующее программное обеспечение, равно как и на другие аспекты деятельности компании. Вот эти-то варианты воздействия вам и предстоит зафиксировать. Область «Необходимые действия» ориентирует в последующих действиях, направленных на реализацию проектного решения. Ведь действительно совещание без реализации принятых решений на практике есть не более чем потеря времени. Кроме того, имеет смысл составить краткое письменное резюме проблем, обсуждавшихся на совещании, и присовокупить его к базе знаний группы разработчиков. Эта информация может понадобиться тем сотрудникам, которые по той или иной причине не смогли присутствовать на совещании, а также специалистам, только что присоединившимся к вашей группе и считающим необходимым ознакомиться с историей проекта.
Совещание без реализации принятых решений на практике есть не более чем потеря времени.
В целях соблюдения четкости формулировок постарайтесь, чтобы размер шаблона не превысил одной страницы. Если относительно какого-то конкретного проектного решения увеличить размер шаблона все-таки потребуется, возьмите дополнительный лист и соответствующим образом пронумеруйте его. Полагаю, вы поняли, что я имею в виду. Не сомневаюсь также, что вы сможете придумать более удобный метод. Главное – сделать так, чтобы при переходе на следующий этап проектирования (а именно к спецификации проектного решения) вы не опирались лишь на свою память. Ну ладно, я закругляюсь с этой темой – все-таки мою книгу сложно причислить к комплексным исследованиям по управлению проектами и, тем более, к монографиям по объектно-ориентированному проектированию.
Рис. 5.1. Вариант шаблона для записей на совещаниях