Великолепная команда. Что нужно знать, делать и говорить для создания великолепной команды
Шрифт:
• Я всегда должен быть уверен, что команда точно следует поставленным целям, не отвлекается на посторонние вещи и не пользуется методами исследования, которые могут оказаться малопродуктивными или уведут команду прочь от ключевых целей.
• Иногда, когда мы делимся своими соображениями по тому или иному поводу, бывает очень сложно прийти к единому мнению, под которым каждый из нас с радостью бы подписался.
• Полностью команда собирается четыре раза в год и обсуждает достигнутые успехи и планы на будущее.
Все без исключения: и менеджер проекта, и члены проектной команды – сталкиваются во время своей работы с подобными проблемами, особенно с теми, что выделены жирным шрифтом. Более того, список Криса Стрингера легко можно расширить. В настоящей главе мы более подробно остановимся на некоторых из приведенных проблем, однако не станем рассказывать о методиках и техниках проектного управления – с этой задачей блестяще справились Стивен Баркер и Роб Кол в своей книге «Великолепное проектное управление». Мы скорее даем короткие и показательные примеры и подсказки, способствующие успешному завершению проекта с точки зрения членов команды и ее руководителя.
ВЕЛИКОЛЕПНОЕ ОПРЕДЕЛЕНИЕ ТЕРМИНА
Проектная команда
Проектная команда – это команда, которая работает над определенным, единственным в своем роде проектом (отдельной частью работы) в пределах определенного промежутка времени, где каждое действие выполняется в заранее запланированном порядке. Ресурсы, которыми располагает команда, тоже, как правило, ограничены. Обычно проектная команда преследует особые цели, для достижения которых сотрудникам приходится выходить за рамки своих повседневных ролей.
Работу проектной команды можно разделить на пять ключевых стадий.
1. Формулирование проекта.
2. Определение целей проекта.
3. Планирование проекта.
4. Реализация проекта.
5. Анализ проекта.
Вас, как члена проектной команды, могут вовлечь в работу коллектива на первой и второй стадиях. Самое главное, что, когда бы вы ни стали частью команды, ваше отношение к работе (а также отношение ваших коллег) и энергия, которую вы затрачиваете на достижение общих целей, станут определяющим фактором успеха или провала проекта. Вы можете облегчить или усложнить жизнь руководителя проектной команды. Попробуйте встать на его место и всегда спрашивайте себя, как вы можете сделать его работу легче и приятнее.
Далее представлены десять дополнительных рекомендаций, которые рассчитаны на тех, кто работает в проектной или схожей с ней команде.
Десять рекомендаций для проектной команды
1. Цели проектной команды
Сперва ответьте на следующие вопросы: «Знаете ли вы, зачем была создана ваша команда? Можете ли вы четко выразить цель (цели) проекта?» Как было доказано в главе 5, цель имеет очень большое значение для команды, поскольку без нее любое действие окажется пустой тратой времени, не приводящей ни к каким результатам.
Вы должны также четко осознать, что важно именно для внешних участников совместного дела, то есть для тех, кто не является частью команды, но при этом заинтересован в ее работе.
2. Составление отчетов
Если вы составляете официальные отчеты для руководства, то и руководитель вашей проектной команды, и другие ее члены должны знать, когда они смогут получить от вас необходимую информацию. Вы обязаны укладываться в отведенные сроки для того, чтобы работа над проектом не останавливалась. Для этого предлагаем вам заранее обсудить данные сроки с коллегами.
3. Ваша роль
Проектная команда добьется конечной цели только в том случае, если вы с коллегами будете четко осознавать, какова ваша роль в ее достижении. В отличие от неспешности, характерной вам в обычной работе, общая цель команды должна быть кратко сформулирована и зависеть от сроков завершения проекта, в которые необходимо уложиться для того, чтобы команда двигалась вперед.
Более того, вы должны четко осознавать роли других членов проектной команды, правильно оценивать и уважать их умения и навыки, которыми они делятся с остальными сотрудниками.
4. Интерес к команде
Уровень вашего интереса к работе проектной команды, частью которой вы являетесь, – одна из переменных успеха или провала проекта. Посещайте совещания, посвященные ходу работы, читайте отчеты, созданные вашими коллегами, выполняйте пусть даже не совсем удобные для вас просьбы. Конечно, последнее может оказаться сложной задачей, если требования, предъявляемые к вам, когда вы играете свою обычную роль на работе, влекут за собой спешку и конфликты. Все мы знаем, что время имеет первостепенное значение, оно – показатель, который поможет команде понять, так ли важен для вас этот проект.
5. Реакция на идеи и предложения ваших коллег
Этот показатель – хорошее дополнение к предыдущему пункту (интерес к команде). Он касается обратной связи с коллегами и с теми, кто находится за пределами команды. Также этот показатель подразумевает под собой положительную реакцию на предложения, идеи и вопросы других членов команды. Конечно, проще всего занять оборонительную позицию, но такое поведение ни к чему не приведет. Вы вольны не соглашаться с чужими мыслями и предложениями, но должны аргументировать свою точку зрения, а не отмахиваться от того, что было сказано вам с благими намерениями.
ВЕЛИКОЛЕПНЫЙ ПРИМЕР
История Джейсона – реакция на просьбы других людей
Я работал в проектной команде, которая разрабатывала новую компьютерную систему для call-центра. Мы быстро поняли, что не сказать нашим заказчикам, какой будет их новая компьютерная система, – ошибка. Однако мы не знали точно, чем именно занимался call-центр и чего он ожидал от разрабатываемой нами компьютерной системы. По этой причине моей команде пришлось несколько раз переделывать проект. Мы постоянно поддерживали связь с заказчиком, предлагая ему все новые и новые версии системы, пока он не услышал именно то, что хотел. Наверное, это очевидно, но по собственному опыту могу сказать, что чаще всего проектные команды (особенно это относится к сфере IT) делают поспешные выводы о том, что необходимо конечному потребителю, даже не посоветовавшись с ним.
Конечно, мы были разочарованы, поскольку потратили уйму времени на корректирование программного обеспечения, а в итоге услышали совсем не то, что ожидали. В довершение ко всему кто-то из call-центра предложил (вполне разумно) сделать некоторые изменения в проекте, что прибавило нам работы.
Вывод всей этой истории таков: мы делали проект специально для call-центра, нашего заказчика, а не для нас самих, значит, именно мы должны были выслушивать их предложения, а не наоборот.