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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Отпуска

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

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

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

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

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

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

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

Об авторе

Ветеран индустрии программных средств Эд Салливан отдал ей 18 лет. Он получил степень бакалавра информатики с отличием в колледже Мерримака. Позже в Бостонском университете он стал магистром этой дисциплины.

Эд 11 лет трудился и отделении корпорации DEC по разработке ПО, расположенном в Нашуа (штат Нью-Гемпшир). На самых разных технических и руководящих должностях он занимался разработкой инструментальных средств для проверки ОС VAX/VMS. В конце концов он перешёл в консалтинговый отдел DEC, где возглавил разработку и развёртывание ряда специализированных программных продуктов для системы работы с клиентами на основе портативных компьютеров общей стоимостью более 6 млн. долларов.

С 1994 г. Эд в небольшой молодой компании NuMega Technologies, Inc., где сначала совмещал должности менеджера по разработке и менеджера по маркетингу BoundsChecker C/C++, продукта для поиска ошибок в программах. Как менеджер по разработке, Эд полностью курировал создание четырёх выпусков продукта в критический период истории NuMega. Будучи первым менеджером по маркетингу, он сыграл значительную роль в определении стратегии, позиционировании продукта, его популяризации, рекламы и продвижении на рынке.

Позднее, как начальник отдела разработки NuMega, он направил компанию на развивающийся рынок средств разработки на Visual Basic и Java, а также создания ПО для Web. Он одновременно управлял стратегией и реализацией восьми различных продуктов занимающих четыре уникальных сегмента рынка. В период его пребывания на должности директора и менеджера по разработке, программные продукты компании NuMega завоевали множество отраслевых премий, включая призы за техническое совершенство и «Выбор редакции» журнала PC Magazine, шесть призов Jolt Cola, и несколько раз были отмечены различными изданиями «Выбором читателя».

В 1999 г. NuMega Technologies вошла в состав корпорации Compuware. В настоящее время Эд — директор центра разработки NuMega, ставшей одной из лабораторий Compuware. Он возглавляет коллектив из 100 сотрудников и курирует разработку продуктов, дающих ежегодный оборот на сумму более чем 40 млн. долларов.

1

Популярное в США телешоу «Three Stooges» с участием трёх комиков. — прим.ред.