Даже если вы — обладатель самого богатого в мире воображения, у вас не получится оживленной беседы с неодушевленным предметом (если же вы настаиваете, что способны на это, возможно, стоит обратиться за помощью к психиатру). Книги обладают множеством чудесных способностей, но интерактивность не входит в их число. Если хотите чему-то научиться, лучше найти людей, интересующихся этой же темой, и учиться вместе с ними. Чтобы помочь вам отыскать их, я составил полезное руководство.
Самый быстрый способ включиться в дискуссию — присоединиться к той, что уже идет. Если ищете бесплатные методы, позвольте рассказать вам о «Клинике МП». Много лет назад я составил электронную рассылку с адресами менеджеров проекта под названием pmclinic. Нам удалось избежать почти всех раздражающих факторов дискуссий по электронной почте (перебранки, плохие советы, слишком много или мало трафика), выработав простую структуру. Каждый понедельник я рассылаю описание ситуации — реальной проблемы, которую прислал подписчик, — и мы обсуждаем ее в течение недели. Люди дают советы, рекомендации, рассказывают интересные истории «с поля боя» и стараются чему-то научиться друг у друга. Этот список существует почти пять лет, у нас более тысячи подписчиков и до сих пор вполне приличное соотношение пользы и «мусора».
Чтобы присоединиться к «Клинике МП», зайдите на сайт: .
Любой может предложить ситуацию для обсуждения, и любой может в нем поучаствовать. Достаточно продержаться в списке две недели, и вы поймете, что к чему. Если вы размышляете, прежде чем выступить с комментарием, проявляете уважение к людям и обладаете чувством юмора, то прекрасно впишетесь в нашу компанию. (А если нет, мы вышвырнем вас быстрее, чем вы произнесете «менеджер проекта».)
Масштабные групповые дискуссии, такие как «Клиника МП», очень удобны, но самое эффективное обучение происходит в небольших группах. Оптимальный вариант — так называемые обеденные разговоры, когда группа достаточно маленькая, чтобы знать каждого лично, но при этом достаточно большая, чтобы в ней были представлены разные точки зрения и оживленное обсуждение. А главное, небольшую дискуссионную группу легко организовать.
Однако у вас могут быть конкретные интересы, например разработка или определенный стиль управления, и вы захотите направить обсуждение группы в это русло. Тогда лучше организовать большую дискуссионную группу, как «Клиника МП», но сосредоточиться на конкретном подходе к менеджменту, возможно в рамках культуры вашей конкретной компании. В любом случае, чтобы организовать группу, вам понадобятся три вещи:
Раз вы держите в руках эту книгу, вы уже на верном пути. Осталось найти время и людей.
Сеть облегчает задачу. Если вы сформулируете приглашение, которое внушит людям доверие, и разошлете его в нужные места, желающих будет больше, чем нужно. Самое простое место для поиска тех, кто интересуется дискуссионной группой, — на работе или в вузе. Если вы читаете эту книгу и хотите, чтобы она помогла вам на вашей должности или на вашем курсе, оглядитесь. Начните расспрашивать знакомых и посмотрите, кому это интересно.
Другие места для поиска:
Как именно вы объявите о группе? От этого зависит, кто захочет в нее записаться и кто останется в ней. Несмотря на кажущуюся очевидность, мне все же хотелось бы подчеркнуть этот момент: ваше объявление показывает людям, насколько хорошо вы умеете общаться, насколько вы организованны и стоит ли им тратить на вас время. Пишите кратко, но стильно, понятно, с юмором. Вот пример, которым вы можете воспользоваться:
Хотите стать лучшим лидером и менеджером команд? Мы собираем небольшую группу людей, которые стремятся улучшить свои навыки в этом деле. Встречи проходят каждую неделю в местном кафе (или виртуально по электронной почте). Мы будем обсуждать книгу, которую сейчас читаем, обмениваться личным опытом, общаться на интересные темы и становиться мудрее. Если вам любопытно, напишите о себе, продемонстрируйте свои доброжелательность и безупречное чувство юмора и предложите книгу или статью для обсуждения в группе.
Такое объявление по электронной почте принесет вам достаточно ответов, чтобы сразу же отфильтровать самые странные. Составьте окончательный список, предложите время и место первой встречи — и вперед. Выберите кафе или бар, где не слишком многолюдно (в шумных местах сложно общаться), до которого удобно добираться и которое работает в нужное вам время. Кстати, большинство публичных библиотек предлагает конференц-залы для свободного пользования. Если ваша группа сформирована на работе, то можно воспользоваться конференц-залом компании.
Если же вы решили общаться виртуально, выбирайте любой инструмент группового онлайн-общения, такой как Google Groups () или Yahoo! Groups (), который возьмет на себя управление списком контактов. и предлагают другие полезные функции для организации группового обсуждения.
От первой встречи зависит, что будет дальше. На ней сформулируйте повестку обсуждения, предложите его основной формат и позвольте людям высказаться. Если вы согласны, начинайте дискуссию. Как ведущий, всегда приходите на собрания со списком ваших собственных вопросов для группы и парочкой историй, чтобы поделиться, если люди застесняются.
Улыбайтесь, представьте пришедших друг другу и делайте все возможное, чтобы создать дружественную атмосферу, к которой вы стремитесь в группе. Если кто-то захочет помочь с проведением собраний, назначьте его соорганизатором.
Поделюсь одной хитростью для успешной первой встречи: выберите нескольких человек и встретьтесь с ними один на один заранее. Угостите их кофе, познакомьтесь и попросите поддержать на первом собрании. Такая подготовка снизит степень вашего волнения при первом обсуждении и поможет создать дружественную атмосферу для всех, потому что хотя бы два человека уже знают друг друга. Эту роль может сыграть и ваш приятель, если захочет.
Даже если первое собрание пройдет идеально, некоторые люди отсеются. Это естественно. Им было интересно посмотреть, как это будет, но любопытство испарилось после первого же посещения. А вот оставшиеся — это как раз те, кто вам нужен. Даже если вас только двое, попросите второго участника помочь расширить группу или продолжайте общаться в этой тесной компании.
Простейший формат дискуссионной группы — следовать главам книги, которую вы решили обсудить. Каждую неделю люди читают главу и собираются, чтобы поделиться мыслями, опытом или сделать указанные в ней упражнения. Дочитав одну книгу, выберите другую. Или пусть каждую неделю один из членов группы выбирает пост в блоге либо статью, которую все читают и обсуждают. Кроме этого, позвольте перечислить несколько тем для рассмотрения.
Одна из моих задач, как менеджера проекта, — оградить разработчиков от постоянных отвлечений и построить работу так, чтобы у них были определенные периоды времени для сосредоточения. Проблема в том, что оно нужно и мне, а когда я помогаю своей команде и клиентам, у меня уже его не остается — только поздно вечером или по выходным. Мне нужен совет других МП: как выполнять несколько обязанностей сразу, чтобы удовлетворить запросы и потребности клиентов и команды и при этом выполнить задачи из моего собственного списка.
Одна из моих задач в качестве МП — развивать отношения с внутренними клиентами. Проблема в том, что четыре человека из моей команды тоже общаются с четырьмя разными специалистами из команды клиента минимум раз в неделю. Для меня практически невозможно быть в курсе всех трудностей, с которыми сталкивается клиент, чтобы убедиться, что мы работаем в нужном направлении. Как мне отслеживать все взаимодействия с клиентом и информировать команду, причем так, чтобы никого не раздражать? Буду признателен за тактические и стратегические советы.
У команд разработчиков мало возможности предложить что-то новое, инновационное, отличающееся от организационных или отраслевых норм. Обычно они чувствуют себя чуть ли не каторжниками, которые вынуждены выполнять тяжелейшие технические задачи, зависящие от ошибок, запросов клиентов, прихотей вице-президента или характеристик конкурентов. Как команде подготовиться к немногочисленным возможностям и использовать их, чтобы сделать что-то нестандартное? Как сбалансировать инвестиции в инновации и другие задачи, такие как работа над продуктом?
Главный лидер проекта, мой босс, — болтун. На собраниях нашей команды он тратит время впустую, разглагольствует о том, что никому не интересно (рассказы с «поля боя», больные мозоли, несмешные шутки и т. д.). Он считает себя очень интересным собеседником, но мало кто разделяет его мнение. Так что еженедельные собрания команды превращаются в пытку. Он не соблюдает собственную повестку и не понимает, что тратит впустую время множества людей. Что мне делать?
Когда я пытаюсь провести плодотворное обсуждение со своей собственной подгруппой, сложно убедить людей прийти. Все думают, что каждое собрание будет таким же, как у моего босса (затянутое, скучное, на котором говорит только один человек). Мне сложно убедить людей, что мои собрания будут другими, а когда эти люди все-таки приходят, мне сложно создать нужную атмосферу, потому что присутствующие ведут себя примерно так же, как на общих командных собраниях (молчат и надеются, что скоро все закончится). Что мне делать?
Недавно моя команда разработки провела упражнение по планированию работы в аварийной ситуации. Мы собрались, составили короткий список всего, что может пойти не так, а затем попробовали обсудить, как мы на это отреагируем. (Было весело, вам стоит попробовать… Извините, отвлекся.) Одна из ситуаций вызывала больше всего споров: «За три недели до основного дедлайна вашего лучшего программиста сбил автобус, и он в коме. Вы как раз возвращаетесь в офис из больницы и думаете, что же делать дальше. Что вы предпримете и как вы представите ваши решения команде?»
Наша команда разработки (примерно 15 человек, включая тестировщиков и других сотрудников) пять недель работает над 30-недельным проектом. У некоторых во время изначального планирования возникли серьезные опасения и вопросы, которые так и не были решены. И теперь мы оказались на краю бездны: архитектура некорректна, бизнес-план лишен всякого смысла, внимание команды рассредоточено и мы не двигаемся в одном направлении (некоторые еще тешат себя этой надеждой, но точно не я). Однако работа уже идет полным ходом, и руководство не видит никакой опасности, никаких проблем (хотя есть признаки низкого качества, постоянно вспыхивают споры, а требования расплывчаты). Как мне в самом разгаре проекта предотвратить эту катастрофу? Как защитить команду разработки от серьезных и болезненных изменений (и вероятности шагнуть назад) в течение следующих четырех или пяти недель? Как спасти проект, который сбился с курса?
Мы работаем над версией 3.0 программного продукта для бухгалтерии. Продукт находится на этапе, когда уже включены многие традиционные и важные функции, и проектное решение вполне сформировано. Но дело в том, что эти функции, над которыми сейчас трудится вся команда (специалисты по маркетингу, а также разработчики), — второстепенные, то есть они интересные, но большинство все равно не будет ими пользоваться или использует один или два раза. Я видел, как непомерное расширение и добавление новых функций происходит на других проектах, и со всей ответственностью могу заявить: все тревожные признаки у нас налицо. Из команды по разработке продукта мы превращаемся в фабрику функций. И все относятся к этой перспективе слишком легкомысленно. Как мне убедиться в том, что версии 3.0 и 4.0 не похоронят качественную работу, проделанную нами на более ранних этапах, под тонной новомодных технических и маркетинговых функций и других ненужностей? Как инжиниринг может поддержать основной бизнес и не превратить продукт в кошмар программирования и юзабилити?
Я единственный МП в команде из пяти программистов, трех тестировщиков и горстки других специалистов (по документации, локализации и т. д.). У нас довольно приличные процессы по базовой работе, и в целом мы неплохо сотрудничаем. Однако проектирование — чудовищная «заноза» в нашей жизни. Когда нужно обдумать новые характеристики и их особенности, начинается полный беспредел с швырянием стульев и хлопаньем дверями. Мы спорим, ругаемся, раздражаемся и мучаемся со всеми решениями. Иногда споры касаются UI-дизайна, иногда — высокоуровневых решений по программированию (объектные модели и программный интерфейс приложения), а порой — даже самих требований. В нашей организации в таких спорах часто участвуют управляющие и менеджеры (в качестве главнокомандующих).
Итак, мой вопрос звучит так: в чем заключается роль МП в проектных решениях? МП должны только отслеживать и поддерживать проекты или возглавлять их? А если второе, то насколько активно они обязаны участвовать в рождении проектного решения по программному продукту или сайту?
Перед моей командой стоит выбор: купить дорогой готовый программный продукт или сделать свой собственный? Мы выбрали второй вариант, поскольку инструмент (анализатор результативности) является для нас ключевым, ему предстояло укладываться в рамки наших профессиональных знаний, и мы должны были кастомизировать его в будущем. Через пять месяцев разработок (на месяц позже изначального срока) продукт все еще не работает корректно, и до завершения еще далеко (примерно восемь недель по текущим расчетам). Расходы уже превысили стоимость готового продукта. Когда МП должен взглянуть правде в лицо и убедить менеджмент все же купить продукт на стороне? Или все-таки лучше вложить больше денег и довести внутреннюю разработку до ума?
У меня классический кошмар МП: плохо сформулированные требования, мало спецификаций, короткий срок выполнения, отсутствие дополнительного времени и ресурсов, а главное — это клиентский проект, и если его не выполнить вовремя, удовлетворив клиента, моя компания потеряет значительную часть заказов. Более того:
Меня пригласили вчера, чтобы я навел порядок (вспомните Харви Кейтеля из «Криминального чтива»). Срок — до 15 апреля. Отчаянно нуждаюсь в креативных стратегиях, особенно чтобы справиться со всеми внутренними политическими моментами, успокоить вспыльчивого клиента и подготовить качественный продукт за четыре недели!