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

Управление проектом

В качестве примера структуры оптимальной системы управления небольшой компании я подробно остановлюсь на организации управления в NuMega, позволившей ей справиться с трудностями. Как и любой молодой компании (и большинству начинающих групп разработчиков), нам требовалось выполнить большую работу в сжатые сроки, при этом ресурсы были сильно ограничены. Мы знали: чтобы воспользоваться всеми преимуществами талантливых сотрудников, которых нам удалось привлечь с таким трудом, необходимо их эффективно организовать. Нужна такая структура организации, которая позволила бы оперативно реагировать на возникающие трудности, сводить к минимуму разного рода издержки и которую можно было бы расширить в дальнейшем. Чтобы реализовать сформулированные требования, мы решили задействовать простую модель структуры организации, в которой за все аспекты разработки продукта отвечает один менеджер проекта. В сферу его ответственности входит наблюдение за всеми программистами, тестировщиками, технологами и разработчиками документации, т.е. за основным составом группы. Важнее всего, что все способные сотрудники были собраны под началом одного менеджера.

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

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

• Гибкое использование ресурсов

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

• Ответственность за распределение специализированных ресурсов

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

• Централизованное принятие решений

Поскольку проект целиком находится в ведении одного менеджера, он может оперативно принимать критически важные решения, разрубая «Гордиевы узлы», когда не удалось достичь согласия.

• Более чёткое взаимодействие

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

• Инициативная ответственность

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

Из собственного опыта

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

Ведущие специалисты

Мы также назначили ведущих специалистов в каждом из функциональных подразделений. Ведущий специалист является экспертом, возглавляющим работу во вверенной ему области. На протяжении всего цикла он очень тесно сотрудничает с менеджером и ведущими специалистами других подразделений. Ведущие специалисты играют важную руководящую роль, управляя разрешением проблем и принятием решений во вверенных им ключевых областях. Такая система позволила без труда увеличить число сотрудников функциональных подразделений, поскольку их возглавлял человек, управляющий созданием данной части продукта. Связи между менеджером проекта и ведущими специалистами функциональных подразделений показаны ниже (рис. 3-1).

Рис.3-1. Связи между менеджером проекта и ведущими специалистами функциональных подразделений.

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