Жизненный цикл команды

Собраться вместе – это лишь начало, не разбежаться врозь – прогресс, а работать вместе – это успех.

Генри Форд

Рассмотрим наши команды программистов с точки зрения того, как протекает их жизнь. Команды не возникают из воздуха и не существу% ют вечно.

Успешные команды развиваются и работают целенаправленно; их возникно& вение нельзя приписывать случаю.

В жизненном цикле команды есть четыре стадии: создание, рост, рабо% та и закрытие. На каждой стадии цель действий своя. Иногда происхо% дит многократное повторение этих стадий в разном порядке, но каж% дая команда проходит через все стадии. Более мелкие команды в со% ставе основной команды разработки проекта проходят через аналогич% ный процесс; это рекурсивная модель. Ниже мы рассмотрим детали, относящиеся к каждой из этих стадий.

Создание команды

Вырисовывается новый проект. Для него нужна команда разработчи% ков. На старт. Приготовились. Марш! Назначается руководитель, и он обязан собрать команду. Участников можно забрать из других команд или специально нанять для этого проекта. Откуда бы ни пришли лю% ди, они должны вместе составить эффективную команду – от этого за% висит успех проекта (и сохранение своего места руководителем).

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

•Необходимо определить место команды в организационной струк% туре. С какими другими командами она будет поддерживать отно% шения? Определите каналы связи между ними, чтобы было ясно, каким образом происходит обмен данными между подразделения% ми и с кем нужно поддерживать контакт.

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

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

добиться, иначе разработка будет останавливаться, пока не найдет%

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

•Выберите подходящую модель команды и озвучьте ее, иначе коман% да примет случайную структуру и хаотическую рабочую практику. Структура команды должна обеспечивать минимум администра%

Это судьба

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

Чтобы команда работала эффективно, нужно научиться прово% дить эффективные совещания. Это не столь сложно; необходимо только немного планирования и дисциплины. Вот руководство из семи пунктов для проведения эффективных совещаний: правила боя. Ответственность возлагается на того, кто созывает совещание.

1.Проводить совещания важно и необходимо. Не стесняйтесь со% звать совещание, когда в этом возникает необходимость. Од% нако обойдитесь без него, если неформальный разговор в ко% ридоре может решить проблемы быстрее и без труда.

2.Заранее объявите о совещании – не за несколько часов, а за несколько дней. Правильно определите участников; их долж% но быть не слишком мало (что толку, если те, кто принимает решения, будут отсутствовать) и не слишком много (толку не выйдет, поскольку каждый будет стремиться, чтобы его вы% слушали).

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

4.Установите время окончания и заранее его объявите. Соблю% дайте назначенный регламент. Тогда участники будут знать, сколько времени у них еще останется на работу. Если вы не укладываетесь в срок, оставьте вопрос для очередного сове% щания.

5.Сообщите каждому участнику, по какому поводу созывается совещание и почему он приглашен. Разошлите повестку дня. Каждый, кому требуется подготовиться, должен знать, чего от него ждут.

6.Все должны быть оповещены о месте проведения совещания. Проследите, чтобы помещение было должным образом подго% товлено: доска, компьютер, достаточно стульев (звучит глу% по, но об этом часто забывают).

7.Распределите роли до начала совещания. По меньшей мере, должны быть назначены:

Председательствующий

Этот человек ведет совещание, направляет дискуссию, что% бы она не уходила от темы, и следит за соблюдением распо% рядка. Его задача – вовремя завершить совещание с при% нятием соответствующего постановления (например, о со% зыве нового совещания).

Секретарь

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

Лица, принимающие решения

За ними окончательное слово по каждому вопросу. Когда нет полномочного лица, дискуссии продолжаются беско% нечно без какого%либо результата.

Уясните цель совещания. Совещания бывают либо с целью рас% пространения информации (бычно это аудитория поневоле), либо с целью разрешения конфликтов (выработать решение насущной проблемы). Чтобы совещание стало полезным, все должны пони% мать его цель и действовать соответствующим образом. Личные проблемы могут быстро увести информационное совещание в про% извольном направлении; председательствующий должен следить за этим и пресекать подобные попытки.

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

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

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

Рост команды

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

Внутреннее развитие команды

Во время совместной работы члены команды знакомятся друг с другом на личном и профессиональном уровнях. В команде устанавливаются система работы и культура кодирования. Поначалу этим процессом нужно тонко управлять, чтобы культура была здоровой и отвечала структуре и задачам команды. Это кристаллизация команды по Тому Демарко – объединение отдельных членов в сплоченную команду. (DeMarco 99)

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

Если еще нет инфраструктуры команды, она создается по мере набора темпа работы. Развертываются такие средства, как система управле% ния версиями и система автоматизации групповой работы. Составля% ются спецификации проекта, уточняются задачи и определяется объем работ.

Внешнее развитие команды

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

Аналитик

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

Архитектор

Авторитет в деле проектирования верхнего уровня, который разра% батывает структуру системы в соответствии с требованиями анали% тика.