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

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

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

• План полёта

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

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

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

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

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

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

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

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

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

• Снижение

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

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

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

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

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

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

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

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

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

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

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

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

Собрания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Успехи

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

• Неудачи

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

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

Внесение изменений

Беспроблемных проектов не бывает. Конечно, есть надежда, что «навигационная система» заранее предупредит о трудностях. Это поможет ликвидировать их, прежде чем они перерастут в серьёзные проблемы. Однако чтобы устранить отклонение проекта от намеченного пути, потребуется изменить направление работы и, возможно, увеличивать её темп. Посмотрим, как можно это сделать…

Смена курса

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

• Собирайте факты, но не перестарайтесь с их анализом

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

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

• Вовлекайте в обсуждение проблемы других специалистов

Собрав факты, обязательно обсудите проблему с ключевыми специалистами группы, включая разработчиков, тестировщиков, специалистов по инженерной психологии, технологов и менеджеров по продукции. Проводите «мозговые штурмы», проверяя различные идеи, и обсуждайте альтернативы. Если решение касается других членов команды, дайте им шанс поучаствовать в обсуждении. Приняв решение (даже если решено ничего не предпринимать), известите о нём каждого. Держите команду в курсе всех важных изменений и их причин, а также планов действий на будущее. Плохая информированность об изменениях проекта ведёт к падению боевого духа коллектива.

• Используйте помощь других групп при разработке и тестировании

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

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

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

• Нанимайте консультантов и исполнителей

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

• Лучше отказаться от части функций, чем расширятъ план

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

Задавайте верные вопросы

Есть хороший способ решить, вносить или не вносить изменение. Для этого нужно спросить у себя: «А что, если я не стану этого делать?» Такие вопросы особенно полезны в борьбе с так называемым «дрейфом функций», который может существенно прибавить работы группе. Однако зачастую изменения вносят без солидного технического или экономического обоснования. Изменение может воплощать хорошую идею, но она может не стоить того риска, которому подвергает весь проект. Конечно, должен быть определённый уровень совершенствования функций, но не до такой степени, чтобы проект был захлестнут потоком мелких изменений. Всегда спрашивайте себя: «А что, если я не стану этого делать?» Это заставит сравнить цену отказа от изменения с ценой его реализации.

Вот примеры хороших вопросов, на которые нужно ответить при поступлении предложения о реализации новой функции.

• Какая часть прибыли будет потеряна, если отказаться от реализации новой функции?

• Скольким клиентами будет полезна новая функция?

• Не сорвёт ли (или подвергнет риску) новая функция срок выхода продукта?

• Снизится ли конкурентоспособность продукта без этой функции?

• Какому риску подвергнется качество продукта при отсутствии новой функции?

• Какое влияние окажет новая функция на использование программы, документацию, а также на процессы её сборки и установки?

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

Стремление к согласию не должно мешать принятию решений

Решать проблемы нужно как можно скорее, не позволяя им долго оставаться открытыми. Так или иначе, решение должно быть принято. Прийти к согласию — ваша задача, но помните, что она не всегда достижима. Кроме того, консенсус означает не единодушное согласие, но согласие большинства. Если после сбора информации и её анализа согласие все ещё не достигнуто (т.е. существуют разные мнения) абсолютно необходимо, чтобы менеджер проекта или один из его ведущих специалистов принял решение самостоятельно. Не откладывайте это и не проявляйте нерешительность — здесь нужна сильная рука лидера. Группе необходимо решение для продолжения работы, задержка с его принятием снижает мотивацию группы, и можно упустить благоприятный момент. Помните: лучше принять неверное решение, чем долго тянуть с его принятием и так никогда не узнать, что правильный выбор был совсем рядом.

Смена темпа работы

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

Когда нужно увеличить нагрузку

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

• Завершить очередной этап в срок

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

• Наверстать упущениое

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

• Справиться с возросшей конкуренцией

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

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

Как увеличивать нагрузку

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

• Определите продолжительность сверхурочных работ

Необходимо чётко определить продолжительность периода сверхурочной работы — он не может быть открытым или неопределённым. Следует поставить конечную задачу: уложиться в заданный срок или достичь определённого конечного результата;

• Создайте комфорт

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

• Поддерживайте боевой дух

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

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

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

Когда работы было особенно много, как правило, все работали сверхурочно, оставаясь после работы. Это было весёлое время, и часто сверхурочные часы превращались в вечеринку. Хотя людям приходилось жертвовать собственным временем и допоздна задерживаться на работе, все знали, для чего это делается, и верили, что наша работа важна для успеха общего дела. Когда работа была закончена, мы решили пригласить на празднование нового выпуска своих родственников. Мы понимали, какие неудобства сверхурочная работа доставила нашим семьям, и хотели как-то отблагодарить их за проявленное терпение.

• Информируйте о прогрессе

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

• Благодарите за труд

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

Общие проблемы и решения

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

Вы уверены, что завершили эту работу?

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

Борьба с нехваткой оборудования

Один из главных грехов фазы исполнения проекта — задержка работы из-за «нехватки оборудования». Если разработчику понадобится более ёмкий жёсткий диск, техническому писателю — новая мышь, а тестировщику — программа для мониторинга, следует доставить их немедленно. Никакие мелочи и пустяки не должны задерживать работу над проектами или снижать эффективность команды. Менеджер проекта должен неусыпно заботиться о личных нуждах, проблемах и потребностях каждого члена группы.

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

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

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

Наконец мы поумнели настолько, что просто купили новый сервер. Если бы мы догадались поменять его в первые два дня, то смогли бы сэкономить три недели работы, времени и усилий.

Навёрстывайте упущенное

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

Миритесь с недостатками своих сотрудников

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

Глава 13

Бета-тестирование

Бета-тестирование — это процесс проверки ПО внешними силами. В начале программы бета-тестирования новое ПО рассылается реальным или потенциальным заказчикам (бета-тестерам) для изучения, оценки и предоставления отзыва о его работе. Задача — получить от бета-тестеров объективную оценку возможностей и качества ПО.

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

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

Ценность бета-тестирования

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

• Проверка ПО в условиях реального мира

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

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

• Оценка работы ПО

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

• Помощь в маркетинге

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

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

• Дополнительная рабочая сила

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

Самая распространённая ошибка при проведении бета-тестирования

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

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

Типы программ бета-тестирования

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

• Фаза 1

К началу этой фазы должно быть написано 60-80% кода. Задача этой фазы — как можно скорее передать основные функции программы для испытаний лучшим бета-тестерам.

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

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

• Фаза 2

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

• Фаза 3

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

• Маркетинговое бета-тестирование

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

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

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

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

Элементы программы бета-тестирования

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

Начало программы бета-тестирования

Прежде чем приступать к набору первых бета-тестеров, надо решить ряд простых, но важных вопросов.

• Каковы основные черты вашего бета-тестера?

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

• В чём основная цель программы бета-тестирования?

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

• Сколько бета-тестеров потребуется?

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

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

• Каковы сроки программ бета-тестирования?

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

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

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

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

Набор бета-тестеров

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

• Потребители (внешние заинтересованные лица, внутренние конечные пользователи)

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

• Персонал технической поддержки

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

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

• Партнёры и союзники

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

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

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

Взаимодействие с бета-тестерами

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

• Определите ожидания

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

• О серьёзных проблемах и найденных решениях должны знать все

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

• Решайте проблемы по мере их возникновения

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

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

• Доводите решение проблемы до конца

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

• Не закрывайте глаза на проблемы бета-тестеров

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

Оценка прогресса бета-тестирования

Чтобы облегчить начало программы бета-тестирования, бета-тестеры должны быстро получить и установить ПО. Это можно сделать, опубликовав ПО в Web или разослав его на CD-ROM. Если выбрать публикацию ПО в Web, можно отслеживать число скачиваний и сравнивать его с числом привлечённых бета-тестеров. С другой стороны, рассылка бета-версий на CD-ROM позволяет быть уверенным, что тестеры получат продукт целиком.

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

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

Завершение программы бета-тестирования

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

• Как долго использовался продукт?

• Удалось ли легко и быстро установить его?

• Помог ли продукт быстро решить ваши проблемы и достичь поставленных целей?

• Какая из функций программы оказалась самой полезной для вас?

• Какая из функций оказалась наименее полезной и почему?

• Какую из функций вам больше всего хотелось бы увидеть в следующем выпуске программы?

• Как можно было бы улучшить документацию или справочную систему ПО?

• Оправдала ли производительность продукта ваши ожидания?

• Собираетесь ли вы регулярно использовать продукт?

• Собираетесь ли вы стимулировать использование продукта в вашей группе? Почему?

• Порекомендовали бы вы его другим? Почему?

• Готов ли продукт? Если нет, то почему?

Обязательно поинтересуйтесь, нет ли у бета-тестеров комментариев для пресс-релизов. Оказалось, что авторами лучших отзывов о продуктах компании NuMega были именно участники бета-тестирования. Мы донесли эти отзывы до всех работников компании и клиентов и, конечно же, опубликовали.

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

По окончании бета-тестирования мы в NuMega оцениваем эффективность каждого бета-тестера как высокую, среднюю или низкую. Лучшим бета-тестерам мы посылаем бесплатные программы, фирменные футболки и даже куртки. Средним достаётся только один подарок, а тех, кто не принимал заметного участия в тестировании, мы вовсе исключаем из программы. Со временем мы почувствовали, что можем положиться на наших бета-тестеров как в получении объективных отзывов, так и в испытании новых продуктов при работе над бета-версиями и кандидатами на выпуск.

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

Поощрение лучших бета-тестеров

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

Менеджер бета-тестирования

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

• Определение целей и задач

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

• Набор бета-тестеров

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

• Распространение ПО

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

• Распространение сведений о состоянии бета-тестирования

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

• Управление результатами бета-тестирования

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

• Завершение программы бета-тестирования

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

• Поощрение бета-тестеров

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

Общие проблемы и решения

Начинайте пораньше

Набор бета-тестеров требует времени, как и подписание соглашения о неразглашении коммерческой тайны. Набор непременно нужно начинать задолго до готовности бета-версии программы. Для программы, в которой участвует 200 бета-тестеров, я рекомендую оставлять 60-90 дней.

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

Бета-версии должны быть проверены

Как я говорил в главе 1, выпуск каждой бета-версии знаменует завершение крупного промежуточного этапа в работе над проектом. Таким образом, прежде чем рассылать бета-версию бета-тестерам, нужно завершить период стабилизации и интеграции. Этот период (обычно 1-2 недели) используется для тестирования, исправления ошибок и решения серьёзных проблем. Качество ПО должно быть достаточным для работы на местах бета-тестирования. До выпуска продукта во внешний мир надо подумать о проведении внутренних испытаний, о которых пойдёт речь в главе 14. Бета-версия — это ещё не окончательная версия ПО, однако изложенные в этой главе концепции помогут извлечь пользу даже из неё.

Необходима мощная инфраструктура

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

Как справиться с потоком информации

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

Не жалейте времени

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

Собирайте отзывы

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

Глава 14

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

Вот и исправлена последняя ошибка — всё готово к окончательной сборке ПО, которая станет «кандидатом на выпуск, (relise candidate, RC). Хочется думать, что на этом этапе неприятностей уж точно не случится, однако вероятность возникновения серьёзных проблем все ещё велика. В конце концов, после выпуска с вашим ПО будут работать сотни, тысячи и даже миллионы пользователей. Можно ли быть заранее уверенным в готовности продукта? Как знать наверняка, что последний набор изменений не привёл к существенному падению производительности или что функцию, протестированную на прошлой неделе, не нарушили вчера или позавчера? Нельзя просто сидеть и надеяться, что всё идёт хорошо. Отзыв ПО из производства или из сети после того, как было публично объявлено о его выходе, чреват не только большими убытками, но и потерей репутации компании.

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

Начальные требования

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

• Готовы все функции программы

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

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

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

• Завершена последняя проверка пользовательского интерфейса

Группа уже закончила оценку и доводку пользовательского интерфейса, так что интерфейс останется неизменным вплоть до отправки продукта заказчику;

• Закончено тестирование программы

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

• Все ошибки исправлены

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

Тестирование кандидата на выпуск

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

Создание окончательной сборки

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

• остановить все изменения в системе управления версиями и заблокировать систему управления исходным текстом;

• создать одну полную сборку программы на основе окончательной версии исходного текста (с использованием оптимизации при компиляции);

• прекратить создание новых сборок — с этого дня ежедневная сборка ПО отменяется;

• пометить нужные файлы в системе управления исходным текстом;

• уведомить всех участников команды о том, что кандидат на выпуск готов!

Автоматизированное и ручное тестирование

Одной из трудностей в работе с кандидатами на выпуск является отбор функций, которые должны быть испытаны в окончательной сборке. Помните: полностью протестировать весь продукт ещё раз не получится, так как на это уйдет несколько месяцев (а то и лет). Вместо этого нужно составить конкретный и чётко сформулированный план тестирования кандидата на выпуск, который можно будет выполнить в очень сжатые сроки. При этом ваши вложения в автоматизацию тестирования воздадутся сторицей. Если в своё время тестирование ключевых функций продукта было автоматизировано, затруднений возникнуть не должно. Тестирование избранных функций кандидата на выпуск должно быть на 70-80 или даже на 90% автоматизировано, что позволяет максимально сократить период испытаний кандидата на выпуск. При отсутствии полной автоматизации потребуется дополнительное время на проведение тестирования вручную. Помимо исполнения набора автоматизированных тестов, при проведении ручных тестов следует сосредоточиться на:

• проверке установки и функций, связанных с лицензированием;

• тестировании базовой функциональности продукта, а именно:

— ключевых функций;

— основных элементов пользовательского интерфейса;

— важнейших ссылок в справочной системе;

— программ-примеров и электронных учебников;

• самых необходимых тестах производительности и нагрузочном тестировании;

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

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

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

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

Для работы над кандидатами на выпуск в NuMega обычно приглашают только лучших бета-тестеров. По завершении внутренних тестов мы посылаем программу тестерам кандидатов на выпуск с просьбой вынести в течение 3-5 дней вердикт: готово ПО или нет. Администратор бета-тестирования остаётся на связи с тестерами: если возникают проблемы, тестеры получают приоритетную поддержку, часто прямо от разработчиков. Когда сильно поджимают сроки, отзывы клиентов могут быть как весьма обнадёживающими, так и очень тревожными. После начала поставок продукта мы часто дарим нашим тестерам его копию вместе с футболками разработчиков в благодарность за их труд.

Обеспечьте «мягкую посадку» проекта

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

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

• разработчиков;

• тестировщиков;

• группы по обучению пользователей;

• группы инженерной психологии;

• технологов;

• технической поддержки;

• менеджера продукта;

• администратора бета-тестирования.

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

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

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

Если что-то идёт не так, стоит задуматься

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

• Прояснить проблему

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

• Оценить затраты на исправление ошибок или внесение изменений

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

• Решить, делать ли новую сборку программы

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

Если решено создать новую сборку, следует назвать её с учётом схемы именования RCn+1, где n — номер версии последнего кандидата на выпуск. Проследите, чтобы номер сборки нового кандидата стал известен каждому.

• Выполнить повторный цикл тестирования кандидата на выпуск

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

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

Если всё в порядке, можно заканчивать

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

• Технические специалисты

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

• Менеджеры продукта

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

• Группа технической поддержки

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

• Заказчики

Виза заказчиков означает, что продукт готов к использованию в их производственном или коммерческом окружении.

Когда продукт готов, можно передать его заказчику

После того, как все дали «зелёный свет» можно передавать проект заказчику и принимать поздравления с окончанием работы! Но прежде, чем считать проект завершённым, обязательно прочитайте следующую главу, «Закрытие проекта» (вот тогда проект действительно будет закрыт).

Общие проблемы и решения

Отсутствие руководства

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

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

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

Ответственность

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

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

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

Автоматизация

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

Глава 15

Закрытие проекта

Наконец, проект завершён, программа отправлена заказчикам! Это все, не так ли? Ещё нет. Завершить работу над проектом — это больше, чем просто вынести его за дверь и уйти домой. В проект вложено много времени и сил, команде пришлось принести большие жертвы, теперь критически важно должным образом провести закрытие проекта, не забыв никого из участников. Если отказаться от этого этапа, можно упустить прекрасную возможность отблагодарить людей, выразить команде признательность за внесённый вклад и подготовить её к работе над следующим проектом.

Почему это так важно?

Закрытие проекта венчает работу команды. Оно также позволяет участникам осознать всю важность проекта, а также почувствовать, что их вклад и самопожертвование получили признание и были оценены по достоинству. Слишком часто упадок сил после завершения проекта ведёт к неразберихе и даже к депрессии. Люди должны быть уверены, что их усилия, сверхурочные часы и бессонные ночи не пропали зря. Они могут спросить себя: «Была ли моя работа замечена? Стоило ли так на напрягаться?» — или, что ещё важнее: «Буду ли я выкладываться в следующий раз?» Правильно проведённое закрытие проекта даёт ответ на эти вопросы. При правильно проведённом закрытии необходимо:

• известить всех об окончании проекта и о передаче программы заказчику;

• выделить индивидуальные достижения, вклад и преданность делу;

• отметить общие усилия и эффективность работы команды в целом;

• помочь участникам команды увидеть их ошибки и извлечь из них урок;

• решить текущие проблемы с кадрами или проектом;

• начать подготовку к следующему проекту.

Как это делается?

Провести закрытие проекта несложно, но для этого нужно решить множество задач.

Передача программы

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

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

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

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

Заключительное письмо

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

Празднование нового выпуска

Один из самых замечательных моментов, наступающих после выхода программного продукта, — праздник по случаю нового выпуска. Чувство выполненного долга, после которого приходит праздник, — это что-то потрясающее. Чем дальше отстоят эти моменты во времени, тем меньшее впечатление от праздника. После выпуска ПО можно:

• открыть бутылку шампанского;

• подать всем мороженое прямо на рабочие места;

• пригласить команду на ужин в ресторан;

• устроить совместный поход в кино;

• собраться на пикник в доме одного из участников команды;

• отправиться в боулинг и т.п.

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

Общественное признание

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

• Должны быть отмечены лишь значительные достижения

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

• Необходимо отмечать отличную работу на любом поприще

Следует поощрять отличившихся работников всех отделов, а не только какого-либо одного.

• Излагайте суть достижения коллективу

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

• Благодарностъ должна быть материальной

Памятный знак или премия сделают поощрение по-настоящему запоминающимся.

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

Практически каждый месяц в NuMega проводятся общие собрания компании. Сотрудники в полном составе заслушивают новости, поступающие из разных групп. В завершение собрания мы присуждаем награду «Спасителю компании». Ею отмечается беспримерный вклад работника, который помог решить критическую проблему, выйти из затруднительной ситуации или существенно увеличить прибыль. Эта церемония всегда сопровождается рассказом о действиях работника или группы, чтобы убедить всех в том, что награждаемый сыграл важную роль и награда получена заслуженно. Отличившиеся получают на память бейсболки с надписью «Я спас компанию», которые они с гордостью носят или держат в своём кабинете.

Личная благодарность

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

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

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

Премии, подарки и акции компании

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

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

Памятные фотографии и «пасхальные яйца»

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

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

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

Группа специалиста NuMega, работавших над программой BoundsChecker, поместила в программу «пасхальное яйцо». Те, у кого есть эта программа, могут увидеть его. Для этого нужно вызвать диалоговое окно «О программе» командой меню Help/About, навести указатель на клетчатый значок продукта, затем при нажатой клавише Shift трижды щёлкнуть правой кнопкой.

Что дальше?

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

Учимся на ошибках прошлого

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

Классический способ анализа законченного проекта — это обсуждение его на итоговых собраниях. Как правило, такое собрание проводится с участием всей команды вскоре после выхода нового выпуска. Оно служит для обмена мнениями о том, что удалось, а что нет, а также для «мозгового штурма» проблем. Цель такого собраний не в том, чтобы кого-то обвинить или отыскать личные просчёты, а в том, чтобы сообща извлечь уроки из прошлых ошибок и наметить, что нужно сделать во время следующего проекта. Эти собрания идеально подходят для подготовки почвы для грядущих изменений.

Усиление инфраструктуры

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

• Рабочие процедуры

Как следует изучите все рабочие процедуры: создание ежедневных сборок ПО, базисные тесты, формулирование требований, планирование, оценку практичности и набор антикризисных мер. Как налажен обмен информацией с командой? Адекватны ли планы и методики задачам проекта? Нуждаются ли эти сферы в улучшении?

• Автоматизация

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

• Оборудование

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

• Инструментарий

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

Работа с кадрами

Вложения в кадры не менее важны, чем в инфраструктуру. Как это сделать конкретно?

• Анализ эффективности работы

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

• Взаимное обучение

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

• Повышение квалификации

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

• Отпуска

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

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

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

Общие проблемы и решения

Чувство опустошённости

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

Истощение сил

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

Нужно довести проект до конца

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

Оглавление

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

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

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

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

Внесение изменений

Общие проблемы и решения

Глава 13 Бета-тестирование

Ценность бета-тестирования

Самая распространённая ошибка при проведении бета-тестирования

Типы программ бета-тестирования

Элементы программы бета-тестирования

Набор бета-тестеров

Менеджер бета-тестирования

Общие проблемы и решения

Глава 14 Кандидат на выпуск

Начальные требования

Тестирование кандидата на выпуск

Общие проблемы и решения

Глава 15 Закрытие проекта

Почему это так важно?

Как это делается?

Что дальше?

Общие проблемы и решения

Часть 3

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

Глава 12

Держим курс

Глава 13

Бета-тестирование

Глава 14

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

Глава 15

Закрытие проекта