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

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

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

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

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

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