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

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

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

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

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

• Успехи

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

• Неудачи

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

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

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

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

Смена курса

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

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

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

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

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