Искусство управления IT-проектами - [190]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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