В книге «Постигая Agile» Эндрю Стеллман и Дженнифер Грин рассказывают, как создать идеальную команду для разработки программного обеспечения. Но эти принципы можно применять для любой отрасли. Сегодня поговорим о том, как строить общение в коллективе по гибкому методу. Ведь именно от этого зависит, как быстро будет сдана работа, насколько точно соблюдены пожелания клиента и успех проекта в целом.
Документы не заменят личных встреч
К документации в Agile относятся весьма лояльно. Когда сотрудник пишет очередной акт, то всегда помнит, что цель — вовсе не в написании. Самое главное — правильно донести свои мысли. Важно помнить, что документы — не единственное средство общение и далеко не главное.
Известно, что совместное обсуждение проблемы — самый эффективный способ понять новую идею. У нас гораздо больше шансов запомнить идеи, высказанные во время разговора, чем почерпнутые из документа. Вот почему agile-практики в основном сосредоточены на людях, непосредственно общающихся друг с другом, а не на официальных бумагах.
Чтобы донести важные для проекта идеи, нужно сделать так, чтобы все пришли к единому мнению. Таким образом, каждый участвует в принятии предложенного решения. Когда группа людей смотрит на ситуацию с одинаковых позиций и откровенно обсуждает как ее положительные, так и отрицательные стороны, она в итоге придет к единой точке зрения. Поэтому команда часто собирается вместе, чтобы обсудить детали проекта.
Разработка продукта вместе с клиентом
Обычно схема сотрудничества такова: на первой встрече клиент рассказывает о своих пожеланиях, во время создания продукта два-три раза встречается с разработчиками и затем уже принимает готовый вариант. Предприниматели не спешат тратить свое время на команду разработчиков, потому что им нужно заниматься своими делами. Однако один из agile-принципов гласит: работать нужно вместе с клиентом на протяжении всего времени.
Как этого добиться? Прежде всего команда должна привить клиенту понимание, что делает для компании ценное программное обеспечение.
Общайтесь с клиентом ежедневно. Не стоит полагаться на редкие письма. Источник
Да, можно ждать окончания проекта, когда станут видны результаты работы команды, и уже тогда дать обратную связь. Но внесение правок на этом этапе стоит гораздо дороже. Каждый из участников проекта сэкономит немало времени, если отследит изменения как можно раньше. Ежедневная командная работа на протяжении всего проекта в конечном счете экономит личное время каждого из его участников, в том числе и заказчика!
Понимание ценности работы
Мотивация в Agile — это не только деньги. Здесь каждый член команды знает, что создает значимый, важный продукт. Каждый замотивирован принести пользу компании заказчика.
Есть антистимулы, которые применяются в традиционных компаниях и от которых предостерегают авторы книги:
- программистам предоставляется недостаточно подробный анализ эффективности. При анализе кода регулярно повторяются ошибки (в результате программисты перестают искать неточности в анализе кода);
- тестировщиков награждают за количество ошибок, которые они обнаруживают (тем самым поощряются придирки и плохая отчетность, а также вредит сотрудничеству с программистами, потому что это разрушает доверительные отношения между ними);
- оценки эффективности бизнес-аналитиков базируются на количестве производимой документации (а не объеме знаний, которыми они поделились с командой).
Производительность каждого специалиста должна основываться на достижениях команды, а не на тех ролях, которые они играют в проекте. Конечно, это не означает, что программист, который плохо выполняет свои обязанности, не должен отвечать за это перед руководителем. Но людей нужно оценивать по вкладу в достижение общих целей команды.
О других принципах создания идеальной команды читайте в книге «Постигая Agile»
Обложка поста — pixabay.com
