Разумеется, у всех сохраняются основные обязанности и люди обычно занимаются тем, в чем они особенно хороши. Но в гибком проекте такие узкоспециальные роли, как аналитик, программист и тестировщик, на самом деле не существуют – как минимум не существуют в традиционном понимании этих ролей.
Вторая деталь, специфичная для гибких команд, заключается в том, что анализ, проектирование, написание кода и тестирование идут постоянно, то есть не прекращаются.
Это означает, что все этапы работы перестают изолироваться друг от друга. Люди, выполняющие работу, должны быть объединены в единое целое и вместе ежедневно заниматься проектом.
Третий аспект, который нужно прояснить заранее, – насколько важна для гибкости работы такая концепция одной команды и командной ответственности.
Качество выполнения гибкого проекта от начала до конца – задача всей команды. Отдела обеспечения качества (Quality Assurance, QA) нет, качество обеспечиваете вы сами, когда проводите анализ, пишете код или управляете проектом. Качество гарантируется на каждом шагу, поэтому в гибком проекте вы не услышите вопроса: «И как отдел гарантии качества проморгал эту ошибку?»
Итак, размытие ролей, постоянное сосредоточение на разработке и ответственность всей команды за все этапы проекта – вот что наверняка встретится вам при работе с гибкими командами.
Теперь давайте рассмотрим некоторые типичные дела, которыми занимаются гибкие команды. Это поможет нам самим успешно набирать такие команды.
2.2. Принципы действия гибкой команды
Прежде чем вы со своей командой начнете добиваться успеха, придется побороться за некоторые вещи, а также заточить команду для этих успехов.
Совместное размещение рабочих мест
Есть одна вещь, которая помогает радикально увеличить КПД вашей команды, – все должны работать в одном месте.
Команды, члены которых работают рядом, действительно показывают более высокие результаты. Ответы на вопросы находятся быстро. Проблемы решаются сразу же после их появления. Уменьшается количество трений между различными звеньями. Люди быстрее начинают доверять друг другу. С такой маленькой командой, работающей как единый организм, очень сложно соперничать.
Итак, если команды, работающие в одном помещении, так хороши, означает ли это, что удаленная команда не сможет выполнять гибкие проекты? Конечно, сможет.
Работа в удаленной команде стала для многих специалистов образом жизни. И хотя плотно сбитая, работающая в одном офисе команда всегда будет иметь некоторую фору перед удаленной, есть секреты, помогающие минимизировать это преимущество.
Например, в самом начале реализации проекта можно выделить определенный бюджет на то, чтобы собирать разработчиков вместе. Даже если такая встреча продлится всего несколько дней (еще лучше, если удастся поработать в таком режиме пару недель), время, потраченное на знакомство друг с другом, привыкание к юмору коллег и совместные обеды, чрезвычайно помогает превратить разношерстную команду в крепкий, высокопроизводительный коллектив. Итак, постарайтесь для начала собрать всех вместе.
В конце концов, в вашем распоряжении масса технических средств (Skype, видеоконференции, социальные сети), помогающих превратить удаленную команду в группу, не уступающую по производительности работникам из маленького офиса.
Привлечение клиентов
В наше время все еще существует масса программ, которые пишутся командами разработчиков совершенно без участия клиентов. Это прискорбно и просто преступно.
Как у команды может получиться выдающийся, инновационный продукт, если сами люди, для которых он пишется, не участвуют в работе?