Управление проектами в условиях нестабильности

Вопросы управления программными проектами давно интересуют специалистов по программной инженерии, и сегодня эта область сложилась как самостоятельная дисциплина со своими методологиями конструирования программных систем: жесткими (тяжеловесные, монументальные) и облегченными (ускоренные, легкие, гибкие — agile). Первые предписывают опираться на сбор максимально полного набора требований и их тщательный анализ для выстраивания последовательного (водопадного — waterfall) либо итеративного (iterative) развития проекта [1]. Вторые отказываются от априорного планирования и делают упор на приоритетную реализацию насущных нужд пользователей [2].

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

Нестабильность команды обычно рассматривается, в соответствии с международным стандартом постановки процесса разработки программного обеспечения SW-CMM, как характеристика начального уровня зрелости (initial) организации. Стандарт предполагает, что, если организация претендует на рост зрелости, она должна стремиться к переходу на следующие уровни: повторяемый (repeatable), определенный (defined), управляемый (managed) и оптимизирующий (optimizing) — путем перманентного повышения проектной дисциплины. При этом полагается, что движение вверх по лестнице зрелости делает организацию устойчивой к нестабильности за счет разработки не только целевых продуктов проекта, но и документов, отражающих принимаемую дисциплину. Иными словами, проектная команда должна постепенно избавляться от влияния человеческого фактора, что по своей сути ведет к жесткой стратегии развития, которую обязаны принимать все участники проекта.

В случае объективной нестабильности команды условие роста зрелости по SW-CMM недостижимо, что, однако, не означает невозможности успешного выполнения программного проекта. Например, если при аутсорсинге сформулировать задачу для разработки внешним исполнителем как замкнутое предложение, если точно и однозначно подготовить договорные документы, то риск невыполнения проекта снижается до приемлемого уровня. Тем не менее неудачи нестабильных команд достаточно часты, и во многом они обусловлены отсутствием подходящей методологической поддержки.

Особенности нестабильной команды

Нестабильные команды разработчиков проектов могут быть построены по-разному, но всегда исполнителей проекта в такой команде можно разделить на три группы.

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

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

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

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

Мини-цикл выполнения автономного задания

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

Рис.1. Жизненный цикл итеративного развития проекта

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

Модернизированная схема дополняет традиционную мини-циклами, отражающими внешнее решение автономных задач. Мини-циклы организуются с помощью расщепления жизненного цикла (рис. 2). В момент, когда осознана необходимость выделения задания для привлекаемых разработчиков (точка A), появляются две ветви: продолжение выполнения начатых заданий и выполнение выделенного автономного задания. Новая ветвь начинается с активности постоянно действующих разработчиков, которые проводят анализ с целью формулировки задания (точка B). После согласования задания и условий его выполнения с привлекаемыми разработчиками (точка C) оно выполняется и предоставляются результаты (точка D). Полученные результаты используются в текущей итерации проекта (точка E) или на последующих итерациях.

Рис. 2. Расщепление жизненного цикла для выполнения автономного задания

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

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

Кадровый координатор

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

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

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

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

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

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

Базовые положения методологии

Как уже отмечалось, одна из проблем нестабильной команды — отсутствие подходящей методологии разработки проектов. Вместе с тем силовое внедрение любой методологии неприемлемо, поскольку предполагает согласие и осознанность разработчиков, а этому препятствует нестабильность. У нестабильной команды организация работы, как правило, складывается стихийно и с нарушением многих общепринятых канонов, но с учетом человеческого фактора. Тем не менее необходимость выбора методологии обычно осознается. С учетом особенностей проектной деятельности в условиях нестабильности можно рекомендовать подход Adaptive Software Development [3] как один из вариантов гибких методологий, применимый к условиям работы нестабильной команды.

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

В проекте, следующем методологии ASD, выделяются три перекрывающие друг друга фазы: обдумывание → сотрудничество → обучение, охватывающие весь жизненный цикл проекта (рис. 3). Оценочные работы отнесены к стадиям, содержание которых связывается с обзорами качества результатов и процесса их получения. Результаты одновременно выполняемых работ (блоки L1, L2 и L3) оцениваются для определения принимаемых решений. Если не получены удовлетворительные результаты и появилась необходимость выполнения новых заданий, происходит возврат к планированию адаптивного цикла, очередная итерация которого учитывает оценку качества процесса. Этот цикл играет двойную роль. Во-первых, он связан с адаптацией к складывающимся условиям ведения проекта на базе полученного опыта, а во-вторых — с обучением для улучшения процесса и его результатов.

Рис. 3. Цикл развития проекта по ASD

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

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

***

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

Литература

1. Шафер Д.Ф., Фатрелл Р.Т., Шафер Л.И. Управление программными проектами: достижение оптимального качества при минимуме затрат. / Пер. с англ. — М.: Вильямс, 2003. — 1136 с. ISBN 5-8459-0413-7

2. Фаулер М. Новые методологии программирования. URL: www.maxkir.com/sd/newmethRUS.html (дата обращения 17.11. 2012).

3. Highsmith, J.A. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. — 2000 New York: Dorset House, 392 pp, ISBN 0-932633-40-4.

Игорь Скопин (iskopin@gmail.com) — старший научный сотрудник Института вычислительной математики и математической геофизики СО РАН (Новосибирск).