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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Заказчики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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