Книга: Искусство управления IT-проектами

Что могут и чего не могут технические условия

Что могут и чего не могут технические условия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги