Правильная ссылка на эту страницу
http://az-design.ru/Projects/AzBook/src/004/02MSAA00.shtml

Приложение. Руководство по работе дискуссионных групп

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

Представление дискуссионной группы по управлению проектами

       Самый простой путь принять участие в дискуссии — присоединиться к работе одной из уже существующих групп. Если вы ищете бесплатный вариант, то позвольте мне рассказать о дискуссионной группе по управлению проектами РМ Clinic. Несколько лет назад я учредил форум для руководителей проектов под названием pmclinic. Нам удалось избежать основных неприятностей, связанных с ведением дискуссии по электронной почте (перебранок, пустых советов, слишком интенсивного или слишком скудного потока сообщений), предоставив довольно простую структуру. Каждый понедельник я рассылаю по электронной почте описание какой-нибудь ситуации — реальной проблемы, обрисованной одним из участников форума, — и мы в течение недели обсуждаем эту ситуацию. Люди предлагают свои советы, дают рекомендации, делятся полезными историями о былых сражениях и стараются как можно больше преуспеть во взаимном обучении. Форум стабильно работает вот уже около пяти лет, обзавелся 1000-ю участников и до сих пор имеет невероятно высокое соотношение полезной и бесполезной информации.
       Чтобы присоединиться к РМ Clinic, просто перейдите по этому адресу: http://www.scottberkun.com/forums/pmclinic
       Любой из вас может предложить ситуацию для дискуссии, равно как и внести свой вклад в ее разрешение. Если вы понаблюдаете за форумом в течение двух недель, то почувствуете атмосферу его работы. Если вы посылаете вполне продуманные сообщения, относитесь к форуму с уважением и обладаете чувством юмора, то сможете легко вписаться в наш формат. (А если не впишитесь, то мы вас выгоним быстрее, чем вы сможете произнести слова “руководство проектами”.)

Как организовать свою собственную дискуссионную группу

       Можно, конечно, принимать участие в работе крупных дискуссионных групп, вроде РМ Clinic, но учиться лучше в составе небольших групп. Лучше всего воспринимаются разговоры за круглым столом, поскольку в них достаточно небольшое число участников, чтобы знать всех лично, и достаточно большое, чтобы имелись разнообразные мнения и поддерживалась оживленная беседа. И самое лучшее заключается в том, что небольшие группы проще организовать.
       С другой стороны, у вас могут быть специфические интересы, скажем веб-разработка или определенный стиль управления, и желание сосредоточить внимание группы в одном направлении. В таком случае вы можете организовать многочисленную дискуссионную группу наподобие РМ Clinic, но сконцентрировать ее работу на определенных взглядах на ведение руководства, даже на том стиле руководства, который укоренился конкретно в вашей компании.
       В любом случае для начала понадобятся три вещи:
       — Час или более в неделю.
       — Книга или ряд тем для обсуждения.
       — Другой заинтересованный человек.
       Поскольку вы держите в руках эту книгу, то вы уже на правильном пути. Все, что осталось — найти время и людей.

Поиск людей

       Интернет упрощает эту задачу. Если составить приглашение, внушающее доверие, и послать его в нужное место, то людей будет хоть отбавляй. Безусловно, проще всего найти людей, заинтересованных участием в работе дискуссионной группы, на работе или учебе. Если вы читаете эту книгу, чтобы преуспеть в своей работе или в освоении учебного курса, то оглядитесь вокруг. Проведите опрос своих знакомых и определите круг заинтересованных людей.
       В качестве других мест поиска можно рассматривать:
       — Вашу компанию. Если исключить вашу команду, есть ли в организации какая-нибудь общая рассылка, которую можно использовать для привлечения людей? Если есть учебная организация или знакомый кадровик, они могут быть заинтересованы в распространении объявления о вашей дискуссионной группе.
       — PM-clinic. Довольно большой процент участников дискуссионной группы РМ Clinic прочитали эту книгу или заинтересованы в ее прочтении. Вам, вероятно, придется вместо личного общения создать виртуальную группу, но для пробы своих сил — это место одно из самых доступных.
       — Блоги, посвященные управлению и программному обеспечению. Простой поиск в Интернете поможет вам найти множество людей, уже создавших сообщества, которыми вы можете воспользоваться. Нужно вежливо сообщить им о ваших намерениях и спросить, не могли бы они разместить у себя ваше объявление.
       — Группы по изучению процессов управления и разработки программного обеспечения. В большинстве крупных городов есть сообщества, организующие группы подготовки, нацеленные на изучение менеджмента, управления проектами или разработки программного обеспечения. Институт руководства проектами — PMI (project management institute), имеет местные отделения в большинстве городов и может посодействовать в распространении вашего объявления по электронной рассылке. Сообщество Personal MBA group (http://personalmba.com/) включило книгу “Making Things Happen” в список рекомендуемой литературы и располагает обширной социальной сетью.

Набор группы

       От того как вы начнете свое объявление, будет зависеть и то, кто зарегистрируется для работы в вашей дискуссионной группе, и то, кто останется работать в ней дальше. Как бы тривиально это ни звучало, но ваше объявление сообщает людям, насколько хорошо вы умеете общаться, какой из вас организатор и стоит ли на это объявление откликаться. Нужно составить короткое объявление, разумное, забавное и понятное. Можете свободно воспользоваться следующим вариантом:

       Хотите быстро освоить искусство лидерства и руководства командами?
       Мы набираем небольшую группу заинтересованных в совершенствовании навыков руководства командами и менеджмента. Предполагается, что будут проводиться еженедельные встречи в местном кафе (или виртуальное общение по электронной почте) с обсуждением одной из глав изучаемой книги, обменом опытом “военных действий” на этом поприще и задушевным разговором, что позволит всем нам набраться ума-разума в данной области. Если вы заинтересовались, то откликнитесь кратким сообщением по электронной почте, при этом укажите уровень своего образования и опыт работы, продемонстрируйте легкость характера и присутствие чувства юмора и выскажите свои предложения насчет книги или статьи, достойной для разбора в дискуссионной группе.

       На подобное объявление откликнется немало людей, и вы сможете отфильтровать неподходящие ответы. Составьте рассылку, предложите время и место первой встречи и организуйте ее. Если выбор пал на личное общение, то снимите место в известном и удобном для общения кафе или баре, которое не будет на тот момент слишком заполнено посетителями (в шумных кафе трудно вести беседу), и выберите подходящее для этого время. Если будут затруднения, то многие публичные библиотеки предоставляют для общего пользования свои конференц-залы. Если вы набираете группу на работе, воспользуйтесь рабочим конференц-залом.
       Если вы выбрали виртуальное общение, воспользуйтесь любым из инструментальных средств, позволяющих организовать работу дискуссионной группы, таким как Google Groups (http://groups.google.com/) или Yahoo! Groups (http:// groups.yahoo.com/), которые могут взять на себя все административные заботы о списке участников. Веб-сайты Meetup.com и Ning.com располагают другими полезными свойствами для организации групп.

Последующие действия

       Что из всего этого получилось, покажет первая же встреча или дискуссия. На первой встрече нужно определить повестку дня, предложить основной формат проведения встреч и дать возможность людям высказать свои суждения. Если все согласились с тем, что вы наметили, переходите к дискуссии. Вам, как организатору, нужно всегда появляться на встрече со списком своих собственных вопросов для группы и одной-двумя историями, которыми вы хотели бы поделиться с людьми, если они не спешат добровольно поделиться своими собственными историями. Улыбнитесь, представьте людей по мере их появления и делайте все возможное для формирования той самой дружественной атмосферы, которую вы хотите создать в группе. Когда найдется какой-нибудь желающий помочь в руководстве группой, сделайте этого человека соорганизатором.
       Для успешного проведения первой встречи есть один прием — предварительно устроить с несколькими участниками встречу с глазу на глаз. Закажите для них кофе, познакомьтесь и попросите поддержки при проведении первой общей встречи. Такая предварительная подготовка почвы для взаимопонимания в дискуссионной группе снизит вашу нервозность при проведении первой дискуссии, а заодно создаст предпосылки для создания дружественной атмосферы для всех присутствующих, поскольку на встрече будут присутствовать как минимум двое знакомых друг другу людей. Разумеется, такую же роль может сыграть и какой-нибудь ваш друг, заинтересовавшийся работой дискуссионной группы.
       Но независимо от того, насколько вы сможете произвести впечатление на присутствующих, некоторые покинут дискуссионную группу после первой же встречи. Это нормальное явление. Они проявили любопытство, захотели посмотреть, что это такое, но после первого же посещения их любопытство иссякло. Остаются именно те, кто вам нужен. Даже если у вас остался только один заинтересованный человек, вы можете попросить его помочь в расширении группы или же сохранить этот минимальный состав группы.

Обычные темы для обсуждения

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

Баланс личного времени и времени, уделяемого команде

       Одна из моих обязанностей в качестве руководителя проекта — защита разработчиков моей команды от постоянных отвлечений и выстраивание структуры их работы таким образом, чтобы у них были отрезки времени, позволяющие сконцентрироваться на выполняемой работе. Моя проблема в том, что я тоже нуждаюсь в каком-то соглашении, позволяющем мне выделить время для того, чтобы сосредоточиться на решаемых вопросах. Я понял, что, пытаясь уладить дела своей команды и своих клиентов, я частенько выкраивал “часы для концентрации” только после работы или на выходные. Мне нужен совет других руководителей проектов, как им удается выдержать баланс времени для уединенной работы, чтобы отвечать на запросы и нужды заказчиков и специалистов команды, и в то же время прерываться на организацию работ из их текущего перечня.

Заказчики и их отношения с командой

       Как руководитель я отвечаю также и за владение обстановкой в части взаимоотношений с внешним заказчиком. Проблема в том, что по крайней мере четверо из моей команды взаимодействуют с командой заказчика (работают с четырьмя различными ее представителями) как минимум раз в неделю. Я понимаю, что практически невозможно быть в курсе всех проблем, с которыми сталкивается заказчик, чтобы обеспечить его удовлетворенность нашей работой. Как мне отследить все контакты с заказчиком и обеспечить полную информированность всей команды без негативной реакции всех участников событий? Самыми ценными были бы советы тактической и стратегической направленности.

Стоит ли следовать инновациям?

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

Мой босс — любитель покрасоваться

       Руководитель всего проекта, мой босс — большой любитель покрасоваться. Когда проводятся командные совещания, он тратит все время на пустую болтовню (рассказывает разные истории о своих подвигах, о том, кто и когда наступил ему на любимую мозоль, отпускает какие-то пошлые шутки). Похоже, что он считает себя интересным человеком, но его точку зрения мало кто разделяет. Поэтому наши еженедельные совещания превратились в сплошную муку. Он не придерживается собственной повестки дня и не понимает, что попусту тратит время многих людей. Как с этим бороться?

Соблюдение краткости совещаний

       Когда я пытаюсь проводить краткие совещания со своей собственной подгруппой, мне трудно добиться их посещаемости. Все полагают, что любые проводимые совещания будут во многом похожи на совещания, созываемые моим боссом (то есть будут затянутыми, скучными, раздражающими и проходящими под его доминирующим влиянием). Поэтому я изо всех сил пытаюсь убедить людей в том, что мои совещания будут проходить по-другому, и как только они соберутся, я прилагаю все усилия, чтобы изменить ситуацию, но люди ведут себя так, будто находятся на общекомандном совещании (хранят молчание в надежде, что все вскоре закончится). Что мне делать?

Смерть в результате несчастного случая

       Недавно моя команда, занимающаяся разработкой веб-приложений, упражнялась в планировании преодоления нештатных ситуаций. Мы собрались всей группой за столом, составили краткий перечень всевозможных неурядиц, а затем попытались провести мозговую атаку, чтобы понять, как на них реагировать. (Это было настолько забавно, что всем вам нужно как-нибудь попробовать заняться тем же самым.) Одна из придуманных нами ситуаций вызвала наибольшее количество споров: “За три недели до наступления очередного контрольного срока вашего лучшего программиста сбил автобус, и он впал в кому, По дороге из больницы в офис вы пытаетесь понять, что же делать дальше. Чтобы вы сделали и как бы преподнесли свои решения своей команде?”

Наш поезд идет под откос

       Наша сравнительно небольшая команда разработчиков (около 15-ти человек, включая тестировщиков и других специалистов) работает уже 5 недель над 30-недельным проектом. У некоторых из нас в ходе начального планирования возникла серьезная обеспокоенность, которая так и не была снята (не была достигнута всеобщая удовлетворенность). А теперь мы поняли, что подходим к краю пропасти: было выбрано ошибочное направление развития архитектуры, бизнес-план страдает бессмыслицей, а команда слишком разобщена и не сфокусирована на достижении единой цели (хотя некоторые в отличие от меня так не думают). Но проект уже приобрел существенный импульс, и руководство не видит опасности или не испытывает озабоченности по поводу имеющихся проблем (хотя уже проявляются тревожные симптомы в виде низкого качества, непрекращающихся споров и нечетко выраженных требований). Как я в качестве руководителя проекта, находящегося в середине процесса разработки, должен действовать, чтобы предотвратить те явления, которые ведут наш поезд под откос? Как защитить команду разработчиков и весь проект от того, что, по моему мнению, приведет к существенным и весьма болезненным изменениям (и к тому, что придется выбросить часть работы в корзину) в течение следующих четырех или пяти недель? Как мне уберечь уже реализуемый проект от схода с рельс?

Борьба с излишней функциональностью

       Мы имеем дело с программным продуктом для ведения бухгалтерского учета версии 3.0. Продукт уже обладает многими общепринятыми и важными функциями, и его конструкция приобретает вполне зрелые очертания. Но возникает ситуация, при которой вся команда (специалисты по бизнесу, маркетингу, а заодно с ними и разработчики) поддается общему настроению по продвижению эффектных по виду, но второстепенных по назначению функций, которыми люди, возможно, если и воспользуются, то не более одного-двух раз. Мне уже приходилось наблюдать подобное “раздувание” функций в других проектах, и в данном случае на лицо все те же признаки. Мы превращаемся из организации по разработке программных продуктов в некую “ферму” по разведению новых функций. И всем видится в перспективе история, как в фильме “Ганг Хо”. Как мне добиться того, чтобы в версиях 3.0 и 4.0 вся хорошая работа, сделанная в предыдущих версиях, не были похоронена под грудой функций и прочего хлама, родившегося в силу чьих-то предпочтений или продиктованного какими-то маркетинговыми ходами? Как проектирование может и дальше содействовать основному бизнесу, не превращая кодирование продукта и разработку его потребительских свойств в некую зону бедствия?

Стиль совещания, напоминающий чемпионат по борьбе

       Я — единственный руководитель проекта в команде из пяти программистов, трех тестировщиков и нескольких других специалистов (составителей документации, специалистов по локализации и т.п.). Процесс решения большинства основных задач проходит в нормальной обстановке, в духе продуктивной совместной работы. Но как только дело доходит до проектирования, все выпускают во все стороны огромные колючки. При определении функциональных особенностей продукта и характера его работы сдержанность куда-то исчезает, и все становится похожим на чемпионат мира по борьбе. Мы спорим, ссоримся, мешаем друг другу и боремся за различные конструкторские решения. Иногда споры идут вокруг конструкции пользовательского интерфейса, иногда вокруг выбора, касающегося общих подходов к программированию (объектных моделей, интерфейса прикладного программирования, а не самой реализации), а иногда они возникают даже вокруг самих технических требований. В нашей организации в порядке вещей ввязывание в подобные дебаты руководителей и менеджеров всех мастей (устройство своеобразных королевских турниров).
       Итак, вопрос заключается в следующем: какую роль должен играть руководитель проекта при выборе основных проектных направлений? Что должны делать руководители проектов, отслеживать ход реализации проекта и всячески содействовать этому процессу или возглавить весь процесс? А если они его возглавят, то в какой степени они должны быть причастны к проектированию программного продукта или веб-сайта?

Самодельный или готовый продукт

       Перед моей командой встал выбор, покупать дорогой готовый продукт или создать подобный продукт собственными силами; мы выбрали последнее, так как для нас этот продукт был важным инструментальным средством (анализатором производительности программ), мы владели этой тематикой и собирались перенастраивать это средство в будущем. После 5-ти месяцев разработки (с месячным отставанием от первоначального графика работ) продукт так должным образом и не заработал и был весьма далек от завершения (еще 8 недель по текущим прикидкам). Стоимость собственной разработки уже превысила стоимость продукта, имеющегося в продаже. Когда именно руководитель проекта должен трезво оценить реальное положение вещей и убедить руководство купить продукт? Или должны ли мы, несмотря на неудачу, потратить солидные средства и довести свой собственный продукт до завершения?

Все и сразу

       Мне приснился классический ночной кошмар руководителя проекта: слабые технические требования, скудная спецификация, небольшой срок выполнения заказа, отсутствие дополнительного времени или ресурсов и настоящая западня: проект ориентирован на запросы клиента, и если продукт не будет поставлен в срок и не удовлетворит заказчика, то моя компания понесет весьма существенные потери. Сгустим краски:
       — Клиент настаивает на том, что каждую проблему следует считать первостепенной, и отказывается расположить проблемы по приоритетности.
       — Клиент все еще проявляет активность по добавлению новых функциональных особенностей.
       — Ко всему прочему, клиент сильно раздражен, поскольку не считает, что наша компания в состоянии успешно справиться с этим проектом.
       — Внутренняя обстановка усугубляется тем, что руководитель группы разработчиков на грани снятия с должности, тестировщик — на грани увольнения (а замены ему нет), а я, единственный руководитель проекта, заменяю того, кто не справился с работой, но остался в компании и не горит желанием помочь мне войти в курс дела.
       Меня призвали разобраться во всей этой неразберихе только вчера. Есть отправная точка — 15 апреля. Мне нужна весьма изощренная стратегия, чтобы выстроить свой путь через всю внутреннюю и клиентскую политику, успокоить раздраженного клиента и поставить ему качественный программный продукт через четыре недели!




<<< Пред. Оглавление
Начало раздела
 

Дата последнего изменения:
Thursday, 21-Aug-2014 09:11:10 MSK


Постоянный адрес статьи:
http://az-design.ru/Projects/AzBook/src/004/02MSAA00.shtml