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

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

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

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

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

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

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

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

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

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

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

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

• Недостаток масштабируемости

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

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

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

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

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

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

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

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

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

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

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

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