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

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

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

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

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

Технические условия могут принести существенную пользу проекту в следующих вопросах:

• Предоставить толковое описание характеристик создаваемого изделия.

• Заставить проектировщиков разъяснить их решения, поскольку эти решения впоследствии превращаются в технические условия.

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

• Стать источником распространения информации от одного специалиста ко многим.

• Создать общекомандные ориентиры для отдельных планов (и если планы были сверстаны при проектировании, использоваться в качестве документации, по которой сверяется ход процесса[42]).

• Предоставить четкие контрольные точки для рабочего графика, на которые будет сориентирована команда.

• Дать гарантию автору (или авторам), что его права не ущемляются.[43]

• Дать возможность чаще проводить конструктивные дискуссии, повысить их качество и продуктивность.

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

• Прибавить команде (и автору) уверенности и рассудительности.

А вот, чему технические условия не могут и не должны послужить:

• Исключить всяческие дебаты внутри команды.

• Доказать команде авторскую состоятельность.

• Доказать, насколько важна та или иная деталь (и почему от нее нельзя отказаться).

• Привить людям философский взгляд на окружающий мир.

• Стать полем демонстрации авторского мастерства в работе с Visio или UML.

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