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

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

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

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

Кто отвечает за подготовку технических условий

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

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

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

Подготовка технических условий не относится к проектированию

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

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

Описание окончательного замысла и его реализации

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