"Работа в команде" - эти слова стали уже привычным атрибутом газетных объявлений о найме в современную компанию, причем не только софтверную. Судя по всему, умение "работать в команде" - очень важное качество для специалиста, наряду с квалификацией и опытом. Почему это так? Ведь раньше ни о какой работе в команде если не думали, то уж точно не говорили вслух и не печатали об этом в газетных объявлениях. Что такое "работа в команде"? Почему она так важна? Может быть, ответы на эти вопросы станут понятны из данной статьи, которая является продолжением материала "Что такое eDevelopment" (см. 20/2000). Статья посвящена вопросам формирования команды и управления процессами, происходящими внутри команды разработчиков, включенных в процесс eDevelopment.

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

Эволюция команды

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

Древовидная (иерархическая) модель

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

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

Модель бригады главного программиста

Модель бригады главного программиста (или модель хирургической бригады) появилась во время первой технологической революции в программировании в 70-е годы. Долгое время эта модель являлась доминирующей при разработке программного обеспечения. При этом главный программист выполняет роль руководителя проекта, а прочие члены бригады ассистируют в определенных рамках своих ролевых функций. Руководитель проекта - это единственный из участников, который вовлечен в проект от начала до конца.

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

Модель команды-сообщества

В последние десятилетия, в связи с бурным ростом софтверной индустрии и частыми изменениями технологий и идеологий разработки, появилась необходимость создания модели команды, которой была бы присуща максимальная функциональная гибкость. Так появилась модель команды-сообщества (community team), ярким примером которой является команда Microsoft и методология разработки программных продуктов Microsoft Solutions Framework. Это наиболее демократичная модель, поскольку в ней нет явно выделенного центра. Команда-сообщество - это команда равных. Схематически ее принято изображать в виде цикла, где все роли равноправны и связаны друг с другом. В подобной команде (в отличие от двух других вышеописанных моделей) взаимодействие участников проекта происходит на уровне сотрудничества.

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

Вот откуда появилась фраза "умение работать в команде" из объявлений о найме на работу - это не просто для красоты сказано.

От теории к практике

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

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

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

Команда строится по принципу бригады главного программиста (хирургической бригады), но с небольшими дополнениями:

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

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

Руководством постоянно проводятся мероприятия по улучшению качества команды. За основу берутся положения наиболее продвинутых систем повышения качества, таких как People CMM (People Capability Maturity Model) и SPICE (Software Process Improvement and Capability dEtermination), которые адаптируются под специфические особенности компании. Ниже перечислим основные мероприятия:

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

Вместо послесловия

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

Анатолий АЛИЗАР,
Максим БАШАРИН,
EPAm Systems