Искусство управления IT-проектами - [73]

).

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

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

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

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

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

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

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

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

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

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

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

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

Что включать в технические условия

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

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

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

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

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