Особенности коллективной разработки ПО

Их задача:

·    сконцентрироваться на выпуске продукта;

·    выработать общее представление о проекте.

Для эффективной работы проектной  группы требуется соблюдение следующих  правил в отношениях между людьми:

·             доверие — делает действия людей согласованными, при этом все следуют принципу «мы делаем то, что обещали сделать»;

·             уважение — люди признают способности других, следуя правилу «каждый из нас необходим нашей группе»;

·             согласие — все должны знать и поддерживать цели проекта и верить в его успех — «мы завершим проект, и точка»;

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

 

Менеджер продукта

Менеджер продукта должен вовремя реагировать на потребности  заказчика. Его главная задача —  сформировать общее представление  о поставленной задаче и о том, как ее решать. Он должен ответить на вопрос «Зачем мы делаем все это?»  и убедиться, что все члены  группы знают и понимают ответ  на него.

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

Менеджер программы

Задача менеджера программы  — вести процесс разработки с  учетом всех ограничений. Руководитель этого направления должен понимать разницу между понятиями «руководитель» и «начальник». В своей книге «Dynamics of Software Development» бывший директор отдела программного менеджмента Microsoft Джим Маккарти пишет:

«Запомните, что  ваша цель — повысить авторитет  каждого члена группы, а не подавить его своим».

Главная обязанность менеджера  программы — выполнить все  стадии разработки так, чтобы нужный продукт был выпущен в нужное время. Он координирует деятельность других членов группы. И хотя иногда ему  придется подгонять своих сотрудников, он не должен и помышлять о диктаторском стиле управления.

Разработчик

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

 

Тестер

Задача тестеров — испытание  продукта в реальных условиях, дабы 
определить, что в продукте работает и что не работает, и нарисовать таким образом точный «портрет» приложения. Естественно, для проведения тестов нужно отлично разбираться и в требованиях пользователей, и в том, как их удовлетворить.

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

Инструктор

Цель группы обучения —  повысить эффективность труда пользователей. Поэтому инструкторы «принимают сторону» пользователей подобно  тому, как менеджеры продукта представляют интересы заказчика. Однако перед пользователями инструкторы выступают в роли представителей проектной группы.

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

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

Логистик

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

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

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

 

Размеры группы и масштаб проекта

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

 

Крупные проекты

В своей книге «Rapid Development: Taming Wild Software Schedules» бывший сотрудник Microsoft Стив Макконнелл пишет: «Для реализации крупного проекта необходимо, чтобы в организации был наработан опыт формализованного и непрерывного обмена информацией. ...А это возможно при наличии иерархической структуры, то есть небольших групп, в каждой из которых есть сотрудник, отвечающий за взаимодействие с другими группами и менеджерами».

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

Тематические группы

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

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

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

Функциональные группы

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

Приведем еще один пример. Иногда группу разработчиков требуется  разделить на три подгруппы, каждая из которых занимается одним уровнем  архитектуры (пользовательским, прикладным или уровнем данных). Довольно часто  в крупных отделах разработки группу 
программистов подразделяют на группу решений и компонентную группу. Первые создают собственно приложение, «склеивая» вместе его компоненты, разработанные вторыми.  Кстати, это разделение часто оказывается и разделением по языкам программирования: разработчики решений, как правило, работают с языками, позволяющими быстро собирать приложения из готовых компонентов, тогда как выбор языка для разработки повторно используемых компонентов, пригодных для многих проектов, определяется прежде всего соображениями эффективности.

Небольшие проекты

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

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

 

Поиск руководителей

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

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

Зачем нужны именно лидеры? Потому что исполнителей и так  избытке. Важно понимать, что деление сотрудников на лидеров и исполнителей не умаляет деловых качеств и квалификации последних. Чтобы лидер добился удачи, он должен набрать отличных исполнителей. Однако между лидерами и подчиненными должно быть взаимопонимание. Группа обсуждает, что нужно делать, а затем выполняет принятое решение, поэтому все, и руководители, и подчиненные, одинаково важны для проекта — в отсутствие кого-либо и них успех проекта невозможен.

Руководители должны обладать:

·    умением понимать и помогать;

·    коммуникабельностью;

·    авторитетом внутри организации и за ее пределами;

·    чувством ответственности за поставленные цели;

·    умением принимать конструктивные решения;

·    уверенностью в своих силах;

·    достаточной для решения поставленных задач квалификацией;

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

 

Повышение эффективности

коллективной работы

Вот какие отношения друг с другом и к работе возникают  в такой группе:

·    заинтересованность;

·    надежда, оптимизм, готовность к работе;

·    определение задач и решений;

·    проявление взаимопомощи;

·    доверительные уважительные отношения;

·    единение.

Последнее очень важно: эффективность  работы группы при этом выше всего.

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

Общее представление о проекте

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