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

Исчерпывающая документация и матрицы трассируемости – это особенно коварные источники проблем для командной среды и поддержки внутри команды. Вместо обстановки доверия они поощряют CYA-среду (cover your ass, что можно перевести как «каждый спасает свою шкуру»), когда команда двигается в сторону «переговоров по контракту», а не сотрудничества с клиентом.

Тестировщики в CYA-среде прежде всего стремятся убедиться в том, что каждое условие протестировано, а не в улучшении качества ПО. Разработчики соблюдают требования буквально, не затрудняя себя мыслями о том, действительно ли они создают ценный для клиента продукт. Потому что иначе, работая в CYA-среде и пытаясь сделать то, что нужно клиенту, они рискуют получить выволочку за то, что не следуют спецификации. Бизнес-аналитики и владельцы продукта в CYA-среде заботятся прежде всего о том, чтобы сфера охвата пользователей и требования выстраивались в идеальную линию. Поэтому они нередко пренебрегают докучными требованиями, которые не вполне совпадают с существующей документацией, независимо от их значимости.

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

Альтернатива CYA-среде – доверие. Компания, разрабатывающая только документацию, необходимую для проекта, создает среду, в которой команде доверено делать именно то, что надо, когда происходят изменения. В agile-команде с отношением «мы все вместе» в случае провала проекта все разделяют вину и никто не «прикрывает свой зад». Им проще внедрять изменения, потому что не нужно придерживаться всей этой ненужной документации. Вместо этого они могут работать лицом к лицу, решать реальные проблемы и записывать только необходимое. И они могут делать это, зная, что компания верит, что они сделают все правильно – даже если проект займет больше времени.

Наш проект «Электронная книга» определенно выиграл от улучшения коммуникации. Помните интенсивные встречи, на которых бизнес-аналитики совместными усилиями тщательно выводят обширный список исчерпывающих требований? Эти требования начинались вовсе не как циничная CYA-схема. Каждый в команде искренне полагал, что если он будет последовательно отстаивать свою точку зрения по поводу полноты спецификации, то это поможет создать более успешный продукт.

Рис. 3.