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

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

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

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

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

• формулирование требований к функциям программы с целью облегчения её технической поддержки в дальнейшем;

• привлечение внимания разработчиков к важным проблемам с качеством и реализацией функций во время бета-тестирования продукта и после его выхода;

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

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

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

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

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

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

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

• поиск, проверка квалификации и привлечение кандидатов в бета-тестеры;

• распространение инструкций и ПО среди бета-тестеров;

• рассылка кандидатам в бета-тестеры анкет и других необходимых материалов;

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

• постепенное усовершенствование процесса бета-тестирования.

Типичные проблемы и их решение

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

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

Даже самым талантливым людям нужно объяснять их роли и обязанности. Они должны представлять, что от них требуется, чтобы знать, чему посвятить своё время. Формулировки обязанностей должны быть подробными и ориентированными на решение тех или иных задач. Но не переусердствуйте с этим, иначе эти формулировки станут слишком формальными и жёсткими. Вряд ли нужно, чтобы участники группы лишь цитировали описание их задания, когда пора уже выпускать продукт. Главное — избежать основных просчётов при исполнении проекта, а не пытаться управлять всем и всеми, даже в мелочах (см. описание обязанностей специалистов, приведённое в этой главе);

• Дисбаланс подразделений

Одно лишь наличие модели, которая поощряет равновесие навыков и опыта специалистов различных подразделений не означает, что обеспечение проекта кадрами осуществлялось как надо. Постоянно следите за балансом ресурсов функциональных подразделений проекта. Например, хватает ли в группе тестировщиков для реализации проекта? Бессмысленно держать 4-5 тестировщиков на 100 разработчиков, даже если первые обладают необходимыми навыками. Отношение числа разработчиков к числу тестировщиков критично для проекта и должно быть сбалансировано. Значение этого отношения зависит от потребностей проекта, но большинство организаций стремится поддерживать его между 2:1 и 4:1. Даже если не соблюдать такое отношение, тестирование всё равно придётся проводить, только в этом случае оно займёт больше времени.