Текст книги "Время — деньги. Создание команды разработчиков программного обеспечения"

Автор книги: Эд Салливан

сообщить о нарушении

Текущая страница: 15 (всего у книги 19 страниц)

Как составить хороший план

Теперь можно сосредоточиться на особенностях составления хорошего плана разработки ПО. В этом процессе три основных этапа: определение задач, объединение задач в группы, называемые базовыми уровнями, и группировка последних в этапы проекта.

Ниже я приведу пример типичного плана с описанием основных структур проекта, необходимых для разработки плана. Легко заметить, что целью планирования не является «микроуправление» каждой деталью проекта. Просчитать, чем будет заниматься каждый член команды в течение шести месяцев, начиная с сегодняшнего дня, скорее всего невозможно. Вместо этого нужно составить план со списком чётко определённых задач, плавно сменяющих друг друга по ходу цикла разработки. Такой план позволяет контролировать работу команды над каждой задачей, а также отслеживать ход реализации проекта со значительной определённостью.

Задачи

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

Затем следует распланировать задачи групп тестирования, обучения пользователей, разработчиков пользовательского интерфейса и технологов. У каждой группы должен быть свой набор задач, определяемый на основе частей проекта, за разработку которых отвечает группа. Эти задачи должны быть организованы так, чтобы их можно было интегрировать и их реализация не слишком отставала от реализации функций разработчиками.

Базовые уровни

Базовые уровни определяют срок реализации группы связанных функций. Каждые 2-3 недели должен быть готов очередной базовый уровень. Помните: соответствующий фрагмент ПО должен устанавливаться с помощью программы установки, а его функциональность должна быть доступна для разработчиков. Реализация базовых уровней – важные краткосрочные цели, на достижении которых необходимо сосредоточить внимание и усилия команды. Вообще ничто не может быть важнее своевременного завершения очередного базового уровня. Если он запаздывает, можно официально говорить об отставании проекта от плана, что требует немедленных корректирующих действий. Ниже приводится ряд базовых уровней (из продукта BoundsChecker, разработанного NuMegaдля обнаружения ошибок в программах).

• Создана библиотека исходных текстов, выполнена первая ежедневная сборка программы, закончена установочная процедура для «скелета» программы.

• Программа позволяет активизировать основные функции для работы с памятью и вести регистрацию их работы.

• Программа выводит первое сообщение об ошибке при работе с памятью с помощью прототипа пользовательского интерфейса.

• Программа успешно обнаруживает утечки памяти типа 1 и 2.

• Программа успешно обнаруживает утечки памяти типа 3 и 4.

• Программа успешно обнаруживает утечки памяти типа 5 и 6.

• Появляется реальный пользовательский интерфейс программы, но без поддержки печати, сортировки и фильтрации.

• Закончена поддержка печати, сортировки и фильтрации.

• Программа интегрируется с другими программами пакета.

Промежуточные этапы

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

У каждого промежуточного этапа должен быть период стабилизации и интеграции (см. главу 6). Напоминаю, что в это время (обычно 1-2 недели) вся команда концентрируется на решении проблем, обнаруженных в реализованных функциях. Периоды стабилизации жизненно важны для проекта, поскольку в это время проводится тестирование, исправление ошибок, устранение неполадок в структуре и интеграции, проводится оценка производительности, т.е. все мероприятия, способствующие стабилизации программы. Не приступайте к реализации новой функции, пока не убедитесь, что только что законченные функции работают хорошо. Помимо всего прочего, периоды стабилизации очень удобны для разного рода доработок. В это время отставшие участники или подразделения команды могут наверстать упущенное и догнать остальных, чтобы вновь работать синхронно.

Внешние промежуточные этапы

В завершении внешних промежуточных этапов участвуют люди или группы, не работающие над проектом постоянно. Внешние промежуточные этапы знаменуют собой критические точки проекта. Вот самые распространённые внешние промежуточные этапы:

• альфа-версия – выпуск, в котором реализован лишь ряд критических функций программы; альфа-версии не предназначены для широкого использования, однако могут быть полезны для демонстрации прогресса проекта или сбора внешних отзывов о работе критических функций;

• бета-версия – выпуск, в котором реализованы если не все, то большинство функций; бета-версии передаются клиентам для испытаний и оценки;

• кандидат на выпуск – в случае успешного окончания тестирования этот выпуск будет передан в производство для тиражирования; появление кандидата на выпуск – знак того, что проект почти закончен и выпуск ПО состоится;

• передача в производство – к этому времени рабочий выпуск будет передан в производство для тиражирования (или опубликован в Web, в зависимости от назначения ПО).

Любой из внешних промежуточных этапов требует распространения ПО за пределами команды или даже компании. Так как это очень важное событие, перед каждым промежуточным этапом нужен период стабилизации. Он позволяет команде сосредоточиться на его качестве, интеграции; выполнить «подгонку» частей и устранить оставшиеся неполадки перед выпуском продукта. (Подробнее о бета-версии и кандидате на выпуск см. главы 13 и 14)

Пример

Чтобы закрепить основы, давайте шаг за шагом рассмотрим подробный пример (табл. 11-1). В таблице показано упрощённое описание проекта, откуда удалена часть информации, обычно имеющейся в нём. Тем не менее, этот пример достаточно детализирован, чтобы продемонстрировать стыковку всех частей проекта. Ниже приводится ряд допущений, сделанных при планировании этого примера.

• Принципы планирования.

* С каждой функцией связан список технических задач. В этом примере они не показаны, однако их легко перечислить в реальном плане. На выполнение одной задачи отводится не более 2 недель, а на большинство – неделя или даже меньше. В зависимости от приоритетных требований к ПО, в первую очередь реализуются необходимые функции, а затем – менее важные.

* Тестирование функций осуществляется по мере завершения их разработчиками. Тестирование некоторых функций будет автоматизировано, другие же придётся тестировать вручную. Подробное описание испытаний приводится в плане тестирования.

* Специалисты по обучению пользователей составляют описания функций по мере их завершения. Работа по составлению документации должна как можно меньше отставать от реализации функции. Подробно эти действия описаны в плане обучения пользователей.

* Специалисты по инженерной психологии оценивают качество реализации всех функций пользовательского интерфейса, консультируют по поводу внесения изменений и контролируют впечатление от продукта по мере реализации проекта. Детали работы специалистов по инженерной психологии описаны в специальном плане.

* Во время работы над выпуском ПО сразу же создаётся простая сборка программы и установочная процедура. Затем сборка и установочная процедура будут регулярно пополняться новыми функциями, таким образом, они будут включать все большую долю функциональности готовой программы. Они также поддерживают подключение новых функций по мере их готовности. Конкретные усовершенствования функций и возможностей программы будут описаны в плане работы над выпуском.

• Участники работы над проектом:

– Мэтт – ведущий разработчик, занятый полное рабочее время;

– Джон – программист;

– Джим – ведущий тестировщик, также отвечает за автоматизацию;

– Фрэнк – тестировщик, исполняет автоматизированное и ручное тестирование функций;

– Сара – ведущий специалист по обучению пользователей;

– Кенни – ведущий специалист по инженерной психологии;

– Боб – ведущий технолог.

• Промежуточные этапы, внешние и внутренние.

– План проекта состоит из 4 базовых уровней, на реализацию которых отводится по 2 месяца, и 2-х главных промежуточных этапов. Будут выпущены 2 бета-версии, 1 версия – кандидат на выпуск и 1 версия для тиражирования.

– Каждый промежуточный этап образован 2 базовыми уровнями. Первому промежуточному этапу будет соответствовать наполовину законченный проект, а второму этапу – полностью законченный проект.

– Работа над бета-версией 1 займёт 1 месяц. Функции 14 и 15 будут добавлены во время работы над бета-версией 1, а оставшееся время будет потрачено на тестирование, настройку и исправление ошибок. У каждого участника группы есть некоторый список действий на время работы над бета-версией 1.

– В бета-версии 2 не будет новых функций по сравнению с бета-версией 1. Внесение значительных изменений в главные функции не допускается, разрешено лишь тестирование, настройка и исправление ошибок. У каждого члена группы есть список задач на это время.

• Кандидат на выпуск.

Версия – кандидат на выпуск будет готова к концу работы над бета-версией №2, если её тестирование пройдёт успешно и не будет обнаружено серьёзных ошибок.

• Контрольные собрания.

– Проведение собраний для контроля за состоянием проекта запланировано на каждый понедельник. Если достигнуть базового уровня вовремя не удалось (или все говорит об этом), придётся вносить изменения, чтобы наверстать упущенное.

Табл. 11. Примерный план.

Цифрами обозначены функции, состояние функций обозначено следующими буквами:

Ф – функция запрограммирована, выполнено блочное тестирование и завершены все связанные с ней технические задачи;

А – тестирование функции автоматизировано:

Р – функция протестирована вручную;

Д – функция документирована:

И – проверена простота использования функции.

Добавления в бета-версии

Легко заметить, что реализация двух задач в этом примере запланирована на период работы над бета-версией 1. Во время работы над любой бета-версией надо воздерживаться от добавления новых функций, особенно важных и сложных. Однако иногда есть смысл планировать включение в первую бета-версию функций, реализация которых не требует больших затрат и не вносит особого риска. Чем дольше задерживается передача программы в руки бета-тестеров, тем больше времени займёт сбор отзывов о качестве реализации и работе функций программы. Часто польза от раннего цикла бета-тестирования превышает риск включения небольших функций после начала программы бета-тестирования.

Хотя включить несколько дополнительных функций время работы над первой бета-версией ещё допустимо, в период работы над последней бета-версией реализацию дополнительных функции лучше не планировать. При работе над последней бета-версией функции остаются неизменными, и усилия команды концентрируется на качестве, производительности и интеграции. (О тестировании бета-версий см. главу 13.)

Неожиданные проблемы

Создавая план согласно описанным в этой главе принципам, вы, вероятно, будете планировать проект, как обычно. Однако разработка ПО – это не точная наука, и до проблем всегда рукой подать. Чтобы заметить малейшее отклонение проекта от намеченного пути, нужно регулярно проверять ход выполнения плана и после завершения каждого промежуточного этапа сравнивать фактическое состояние проекта с планом. Если работа отстаёт от плана, надо определить проблему, изменить план и постараться завершить очередной промежуточный этап в срок. Все так просто? Однако это та самая ситуация, когда от менеджера проекта и ведущих специалистов требуется полная самоотдача. Поскольку очень сложно вести работу над проектом, не отставая от графика, в третьей части основное внимание уделено именно этому вопросу.

Типичные проблемы и их решение

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

Ничего не получается!

Создание хорошего плана требует серьёзных усилий, поэтому легко понять, почему некоторые группы используют планы без особого энтузиазма. Бывало, что, пересилив себя, некоторые люди всё же пытались спланировать проект, но часто из-за множества неожиданных проблем им приходилось оставлять план. Если план не отражает действительность, он будет в значительной степени игнорироваться.

Бесспорно, планирование – задача не из лёгких, однако решить её необходимо, поскольку план – это руководство к реализации проекта. Если вы намерены завершить программу в срок, нужно уяснить объём предстоящей работы и время, нужное для её выполнения. Описанные в этой книге методы упрощают планирование, делают его более предсказуемым и менее рискованным.

Это сложнее, чем кажется на первый взгляд…

Кажется, что втиснуть задачи в рамки 1-2 недель так просто, но это может быть настоящим испытанием. Наверное, в плане всегда найдётся задача, на выполнение которой отводится 3-5 недель. Такую долгосрочную задачу лучше разбить на несколько меньших. Чем чаще контролируется прогресс проекта, тем проще обнаружить отклонения от плана. Как правило, трудности при разбиении задачи возникают из-за неполного её понимания, а это тревожный признак. Чтобы лучше разобраться в том, что предстоит сделать, решение нужно смоделировать.

Потеря согласованности

В плане должны быть периоды синхронизации. Помимо стабилизации ПО, они позволяют остальным участникам команды наверстать упущенное/ Нельзя предусмотреть все проблемы заранее, но некоторые из них можно предсказать. Какими бы они ни были, в плане надо выделить время для их решения.

Часть 3
Исполнение проекта

Глава 12
Держим курс

Итак, основное планирование закончено – остаётся лишь «нажать на рычаг и выдать готовый продукт». Хотя процесс выглядит довольно механистичным, всё равно приходится постоянно следить за ходом реализации проекта и бороться с повседневными проблемами. В этой главе мы обсудим, как эффективно следить за состоянием проекта и какие меры принимать, чтобы не дать проекту отклониться от намеченного пути.

Анология с самолётом

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

• План полёта

План полёта разрабатывается задолго до взлёта. Среди прочего в плане описаны этапы полёта, следуя которым экипаж может привести самолёт из пункта отправления в пункт назначения (например: «лететь 100 миль на запад, в пункте X повернуть на северо-запад, затем 500 миль держать этот курс» и т.д.).

Аналогично работа с прототипом и моделью использования ПО позволила сформировать базовое представление о том, что создаётся в рамках проекта и на что это будет похоже в готовом виде. Грамотно проведённое планирование позволило наметить основные этапы создания продукта и определить сроки их выполнения. Таким образом, основное внимание во второй части этой книги (главы 12, 13,14) мы сосредоточили на создании «плана полёта» для проекта.

• Элемент непредсказуемости

Хотя план полёта и регламентирует действия экипажа во время рейса, он не может и не должен предсказывать или решать все проблемы, которые могут возникнуть в полёте. Haправление ветра, турбулентности атмосферы, колебания тяги двигателей, пробки в воздушных эшелонах и масса других факторов влияют на полет и потенциально могут отклонить самолёт от курса и выбить его из расписания.

Проект тоже столкнётся с тысячами проблем, которые нельзя ни предсказать, ни запланировать. Любая из них может сбить его с курса или стать причиной задержки. Как и самолёту, проекту нужна система быстрого реагирования на события, происходящие во время полёта.

• Навигационная система

Удерживать курс самолёта помогает навигационная система, которая постоянно (примерно каждые несколько минут) определяет его координаты и сравнивает результат с координатами пункта назначения. В полёте навигационная система постоянно вносит небольшие коррективы, чтобы вернуть самолёт на намеченный курс. Принцип работы навигационной системы состоит в допущении, что самолёт всегда летит в неверном направлении, и его нужно вернуть на правильный курс (рис. 12-1).

Рис. 12-1. Навигация в непредсказуемых условиях.

Проекту тоже нужна «навигационная система». Нужно почаще проверять состояние проекта и вносить небольшие коррективы, прежде чем он успеет сильно отклониться от намеченного курса. В ходе разработки надо регулярно оценивать прогресс проекта и своевременно вносить соответствующие изменения.

• Снижение

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

Проект также нужно безопасно «посадить», не допуская никаких промахов при приближении конца пути. Надо организовать процесс плавного «снижения», направляющий завершающие этапы проекта. Этот процесс нужно спланировать заранее, а не создавать в спешке во время «захода на посадку». Из-за важности последнего этапа я решил полностью посвятить ему главу 14.

Процесс измерений и мониторинга состояния проекта

Как сказано в главе 9, план проекта – это совокупность описаний отдельных его этапов, каждый из которых харак-теризуется определённым уровнем законченности некоторых функций программы, который должен быть достигнут к заданному сроку. Эти этапы можно формально рассматривать как контрольные точки для оценки прогресса проекта. Если функциональность программы реализуется в срок, в заданном объёме и работает должным образом, значит, вы не сбились с курса. Обратная ситуация является проблемой, которую нужно сразу решать. Если программа собирается каждый день, в любой момент её можно установить и её тестирование ведётся параллельно разработке, значит, у вас есть необходимые инструменты и процедуры для регулярного контроля проекта. Кроме того, обладая планом, в котором отмечены даты и параметры контрольных точек, всегда можно определить, на каком этапе находится проект в данный момент. Сравнив текущее положение проекта с планом, можно узнать, в верном ли направлении идёт работа.

Внесём ясность в значение понятий, рассмотренных выше. Если работа над проектом только начата и через две недели должен быть закончен первый этап, во что бы то ни стало нужно закончить его вовремя. Если вы всерьёз собираетесь уложиться в конечные сроки, следует устанавливать промежуточные сроки и выдерживать их. Если для этого придётся работать по ночам и по выходным – работайте. Не дожидайтесь конца работы над проектом, чтобы наверстать упущенное: тогда будет уже слишком поздно. Следует успевать выполнить намеченное к определённому сроку прямо перед наступлением этого срока. Удалось уложиться в срок – это хорошая работа, и успех обязательно нужно отметить всем вместе. Но если работа просрочена, соберите группу, выясните, в чём дело, и устраните проблему. Также необходимо составить план навёрстывания упущенного. Чтобы закончить проект к намеченному сроку, группа должна работать очень серьёзно и напористо, выдерживая промежуточные контрольные сроки.

А есть ли способ заранее узнать, удастся ли достичь следующую контрольную точку вовремя? Завершение отдельных этапов проекта – формальные события, с которыми обычно связаны объективные параметры. Но их, как правило, разделяет несколько недель, а для мониторинга проекта в периоды между соседними контрольными точками нужны дополнительные инструменты.

Решению этой проблемы и будет посвящена остальная часть главы. Я расскажу о правилах сбора текущих сведений о проекте и о том, как при необходимости менять направление и темп проекта. Помните: срыв плана в конце работы над проектом случается не вдруг, а назревает потихоньку, день за днём.

Определение состояния проекта

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

Ежедневные сборки и базисные тесты

Как сказано выше, ежедневные сборки программы и базисные тесты – это пульс проекта. Оба мероприятия критичны для определения состояния проекта. Если в течение нескольких дней или недель вы не в состоянии скомпоновать программу, проект в беде. Возможность сборки ПО нужна для поддержания его внутренней согласованности, интеграции и визуализации изменений. Если нельзя выполнить сборку программы, оценить состояние проекта также невозможно.

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

Собрания

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

• У собрания должна быть определённая цель

На контрольном собрании участники группы сообща обсуждают крупные достижения, неудачи и трудности. Сосредоточьтесь на том, что удалось и что не удалось. На собрании также поднимают важные проблемы, требующие внимания одного или нескольких участников группы.

• На собраниях должны быть все

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

• Не посвящайте собрание решению частных проблем

Собрания часто становятся местом встречи нескольких участников группы, которые хотят обсудить свои проблемы. Несомненно, эти проблемы важны и требуют разрешения, но контрольное собрание – не место для «мозговой атаки», решения технических и других серьёзных вопросов. Если попытаться охватить проблемы всех участников группы, то лучшую часть дня придётся потратить на собрания, при этом значительная часть времени остальных участников группы будет потеряна зря: люди должны знать суть решения, а не его подробности.

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

Столь же неправильно докладывать на контрольном собрании о всех задачах, над которыми пришлось работать за неделю. Нужно лишь сказать, идёт ли разработка проекта по намеченному пути. Если нет, надо перечислить причины, всё остальное несущественно.

• Не затягивайте собрание

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

• Ведите список нерешённых проблем

Во время реализации проекта обычно возникают проблемы, которые надо решать. Чтобы не забыть о них, в главе 5 я рекомендовал регистрировать такие проблемы, назначать ответственных за их решение и обязательно разъяснять найденное решение другим. Аналогичную концепцию можно применить при проведении контрольных собраний. На собраниях проводится анализ нерешённых проблем, назначаются ответственные за их решение и устанавливаются сроки. Таким образом, каждый будет знать, что все проблемы будут рассмотрены и решены.

Из собственного опыта

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

«Управление мимоходом»

Очень полезна технология «управления мимоходом» (Managing by Walking Around, MBWA). Контрольные собрания – формальность, но менеджер проекта и ведущие специалисты, даже просто находясь в группе, могут встречаться с участниками для неформального обсуждения тех или иных проблем.

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

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

• Такая практика допускает спонтанное обсуждение важных предметов и проблем, в ходе которого часто рождаются совершенно новые подходы к их решению. Замечательные идеи не рождаются в два часа пополудни каждый понедельник. Чтобы они возникали, нужно поощрять внеплановое, неформальное и нерегламентированное общение.

• Поскольку почти все ведущие специалисты когда-то были просто инженерами, они очень не любят отрываться от компьютера и покидать свой офис. Но происходят просто удивительные вещи, когда кто-то мимоходом спрашивает их: «как идут базисные тесты?», «что нового с проблемой X?» или «ну как, уже заканчиваем второй этап?»

• Хороший менеджер проекта и ведущий специалист обязательно проводит некоторое время наедине с участниками группы. Такие встречи не обязательно должны быть формальными или проводиться по расписанию. Одного короткого визита участника по какому-нибудь личному или рабочему вопросу достаточно для поддержания сосредоточенной и слаженной работы. Кроме того, это замечательный способ избавиться от проблем с кадрами или иных трудностей при реализации проекта прежде, чем они возникнут. Если вы не хотите получить неприятный сюрприз во время контрольного собрания или, что ещё хуже, накануне сдачи проекта, как можно чаще общайтесь со всеми участниками группы и с каждым по отдельности.

Обмен информацией

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

• Успехи

Отмечайте каждый крупный успех и делайте его достоянием группы. Это важное доказательство того, что проект живёт и здравствует. Поэтому, создав ежедневную сборку программы, первый вариант установочной процедуры или закончив важную функцию ПО, не забудьте разослать участникам группы поздравления по электронной почте, разделив со всеми это радостное событие. В торжества по поводу особо важных событий необходимо вовлекать большую часть коллектива: отделение или даже весь персонал компании.

• Неудачи

Неудачи необходимо как можно скорее обнаруживать, сообщать о них всем участникам команды и устранять. Не стоит ожидать от команды абсолютно безупречной работы. Знайте: проблемы возникнут непременно. Работа команды заключается в том, чтобы как можно скорее найти их и решить. Худший способ борьбы с проблемами – замалчивать их или вовсе не признавать их существования, так как это не поможет ни решить проблему, ни вернуть проект на намеченный путь.

Чтобы не допустить этого, менеджер проекта и ведущие специалисты должны быть доступны и открыты для общения. Если у члена команды возникает ощущение, что неудачи или проблемы не получат профессионального решения, сокрытие проблемы и неверие в её существование станет хроническим источником бед.