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

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

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

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

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

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

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

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

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

Замена инструментов для управления исходным кодом и отслеживания ошибок во время работы над выпуском, как правило, является ошибкой и всегда требует больше времени (см. главу 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» с участием трёх комиков. — прим.ред.