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

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

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

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

Совместное размещение рабочих мест

Есть одна вещь, которая помогает радикально увеличить КПД вашей команды, – все должны работать в одном месте.

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

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

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

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

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

Привлечение клиентов

В наше время все еще существует масса программ, которые пишутся командами разработчиков совершенно без участия клиентов. Это прискорбно и просто преступно.

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

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

Стимулируйте незапланированное сотрудничество

В книге о компании «Пиксар» (The Pixar Touch) Стив Джобс рассказывает, как сильно успех фильмов этой компании зависел от незапланированного сотрудничества. После выпуска фильма «История игрушек-2» (Toy Story II), который чуть не поставил всю компанию на грань банкротства, руководство осознало, что сотрудники оказались слишком разобщены, изолированы друг от друга. Все могло закончиться крахом, если бы не собрали всех участников работы над фильмом вместе.

Именно для этого студия «Пиксар» приобрела участок 20 акров в Эмеривилле, штат Калифорния, и собрала всех сотрудников под одной крышей. Результат последовал незамедлительно. Контакты наладились, сотрудничество оптимизировалось, и коллеги смогли выпускать крупный фильм каждый год.

Вот почему гибкие методы (например, экстремальное программирование и скрам) предлагают бороться за участие клиента в работе. Это выражается в выделении особой роли « заказчик в команде » (on-site customer) и в существовании в скраме специальной роли « владелец продукта » (product owner). Это очень важная работа. Подробнее все роли мы обсудим чуть позже.

Следующий принцип также проясняет, почему любой успешный гибкий проект требует участия клиента.

Вы можете спросить: «А что делать, если мой клиент не хочет участвовать в работе?» Возможно, клиент просто не может идти в ногу со временем или ему не особенно нужен этот проект, а быть может, он просто не считает, что вы движетесь к цели.