Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев

Это не означает, что разработчик должен быть экспертом по визуальному дизайну, а тестировщики – брать на себя управление проектом.

Скорее это признание того, что для создания оптимальной команды нужно исповедовать принцип «роль для человека, а не человек для роли».

Итак, как добиться самоорганизации своей команды?

♦ Команда допускается к планированию, оцениванию и может распоряжаться проектом.

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

♦ Вы ищете людей, способных брать на себя инициативу, то есть тех, кто сам прокладывает себе путь, а не сидит и не дожидается остальных.

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

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

Ответственная и полноправная

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

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

На данном этапе никто не застрахован от ошибок. Но поверьте, игра стоит свеч.

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

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

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

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

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

Многофункциональность

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

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

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

Кто унес мой сыр?

«Кто унес мой сыр?» (Who Moved My Cheese? [Joh98]) – это бизнес-притча о мышах, которые проснулись однажды утром и обнаружили, что большой кусок сыра, вокруг которого им вольготно жилось, куда-то исчез. Его унесли. И теперь мыши в растерянности размышляли, что делать.

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

Аналитик, переходящий к гибкому проекту, осознает, что этап анализа никогда не закончится.

Разработчик должен быть готов к тому, что ему придется писать тесты (и немало!).

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

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

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

А теперь поговорим о ролях.

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

Если у вас возникает вопрос: «А где все программисты, тестировщики и аналитики?» – не волнуйтесь, они никуда не исчезли. Просто при гибкой разработке не так важно, кто именно играет конкретные роли.

Начнем с рассмотрения самой важной роли в гибком проекте – клиента.

Клиент гибкого проекта

«Источником истины» здесь является клиент, сотрудничающий с командой разработчиков, – от него поступают все требования к выполняемому проекту. Ведь именно для клиента пишется программа.

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