Правильная ссылка на эту страницу
http://az-design.ru/Projects/AzBook/src/004/02MS0700.shtml

Глава 7. Как подготовить хорошие технические условия

       Однажды у меня зашел спор с программистом, который полагал, что технические условия составлять незачем. Я вошел к нему в офис с объемистой спецификацией, которой требовалось следовать в соответствии с указанием нашего босса, а коллега над ней просто посмеялся (и, к сожалению, надо мной тоже). По его мнению, если то, что я хочу сделать, настолько сложно, что для объяснения этого программистам понадобилось 50 страниц, то создавать это в любом случае не стоит. Необходимость во всем этом процессе и в бумажной работе он рассматривал в качестве сигнала, что общение и координация усилий в команде нарушены и ей не доверяют принимать самостоятельные решения. Он сказал, что нам не нужна такая мощная опека и бюрократия, подразумевая, что в столь детальном планировании потребности никогда не возникало.
       Я улыбнулся, поскольку сталкивался с подобной аргументацией уже не впервые, и спросил, готов ли он утверждать то же самое в отношении технической документации на многоэтажный жилой дом, в котором находилась его квартира, или на трехуровневую дорожную развязку, по которой он добирался на работу. Однако ранее он, видимо, уже слышал подобные вопросы, поэтому улыбнулся мне в ответ. Он сказал, что хотя он рад, что такие сооружения были спланированы весьма подробно, но он не думает, что работа над созданием программ сравнима с работой в той сфере, где царят законы физики и используются строительные материалы (и он приводил доводы в пользу методов с минимальным объемом письменных технических условий, таких как экстремальное программирование).
       Мы быстро пришли к согласию по двум пунктам. Сначала мы согласились с тем, что по сравнению с традиционным инженерным искусством разработка программных продуктов — процесс более гибкий, в него легче вносить изменения и от него вряд ли зависят жизни людей. Но при этом мы признали и то, что для уверенности в результате требуется нечто более осязаемое, чем просто воспоминания о содержимом кулуарных разговоров, тем более в условиях, когда перед нами стоят сложные технические проблемы, работа команды зависит от наших решений, нужно уложиться в бюджет и соблюсти заданные сроки.
       Мы также согласились и с тем, что для проекта нужно что-нибудь подходящее для той работы, которую мы выполняли, и для того типа людей, к которому мы себя относили. Польза от какой-нибудь письменной документации была бы в том случае, если бы с ее помощью решались реальные проблемы, возникающие перед нашей командой, ускорялся производственный процесс и повышалась вероятность получения качественных результатов (и чтобы со временем эту документацию нужно было бы обновлять, не ущемляя чьих-либо интересов). Он сказал, что если мы в состоянии создать что-либо подобное, то он охотно этим воспользуется, независимо от того, как мы это назовем и в какой форме преподнесем. На том мы и порешили, обратив процесс создания технических условий в то, что по взаимному согласию отвечало бы интересам всей нашей маленькой команды. Я вернулся к боссу, пересказал ему наш разговор и подготовил компромиссный вариант. Громоздкий, похожий на налоговое законодательство вариант технических условий ушел в прошлое.
       Самое поучительное в этой истории заключается в том, что при составлении технических условий или документировании работы, как и в любом другом виде человеческой деятельности, не существует единственно верного пути. Технические условия, как и многие другие задачи, стоящие перед командой, должны отвечать потребностям текущего проекта и интересам тех людей, которым предстоит их составлять и выполнять. Так же как веб-сайты и программные продукты для поиска лучших подходов должны пройти процесс проектирования, технические условия, чтобы из них вышло что-нибудь подходящее, требуют вдумчивой работы и многочисленных прикидок.
       Но многие известные мне опытные специалисты попадались в ловушку, будучи уверены, что есть лишь один способ подготовки технических условий (как бы они их ни называли): использование ранее накопленного опыта. Иногда эта цепочка повторений уводила их к самым первым разработкам. Они считали, если эти проекты не были полным провалом, значит, способ составления технических условий (или игнорирование других способов) положительно повлиял на конечный результат. Данное утверждение без каких-либо исследований может быть в равной степени как верным, так и ошибочным (то есть проект, возможно, оказался успешным, хотя процесс составления технических условий был неправильным). Хуже того, если не были подняты резонные вопросы о том, как и зачем написаны эти технические условия, никто в команде так и не поймет, плох или хорош был процесс их подготовки или каков их вклад в работу команды. (Здесь прослеживается полная аналогия с тем, как отсутствие толковых вопросов относительно создания качественного программного кода не позволяет понять, насколько этот код хорош или плох на самом деле.)
       Моей целью в данной главе является объяснение ряда ценных идей. Во-первых, что технические условия должны принести проекту тройную пользу: гарантировать, что создается именно то, что было задумано, предоставить график поэтапной работы, которым завершается стадия планирования проекта, и дать возможность основательно рассмотреть курс реализации проекта и получить о нем отзывы различных специалистов. Значение всех трех составляющих трудно переоценить, и вряд ли какой-нибудь другой процесс, кроме составления технических условий, обеспечит все это одновременно. Лишь поэтому я считаю себя ярым сторонником составления технических условий. Во-вторых, большинство претензий, предъявляемых к техническим условиям, легко устранимы при условии, что авторы разбираются в типовых просчетах, допускаемых при подготовке таких условий, и понимают, ради чего они создаются.

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

       Технические условия, как и концептуальные документы, являются формой организации взаимодействия. Если они составляются в целях реального использования, содержащаяся в них информация подается в простом и понятном виде. Если же должного значения им не придается, то они создаются и читаются с большим трудом и вызывают разочарование у всех, кто бы ни взял их в руки. Довольно часто команды, составившие слабые технические условия, реально ощущают недостаточную отдачу от этого документа (если волки сбиваются в стаи, технические условия становятся досадным недоразумением). Зачастую причиной появления слабых или неудачных технических условий является недопонимание того, что с их помощью можно сделать, а в чем они, наверняка, не помогут.
       Технические условия могут принести существенную пользу проекту в следующих вопросах:
       — Предоставить толковое описание характеристик создаваемого изделия.
       — Заставить проектировщиков разъяснить их решения, поскольку эти решения впоследствии превращаются в технические условия.
       — Предоставить возможность проведения различных обсуждений, опросов мнений и дискуссий в отношении детальных планов перед началом их активной реализации.
       — Стать источником распространения информации от одного специалиста ко многим.
       — Создать общекомандные ориентиры для отдельных планов (и если планы были сверстаны при проектировании, использоваться в качестве документации, по которой сверяется ход процесса1 {Поэтому некоторые команды держат технические условия в режиме управляемой блокировки входящей и исходящей информации. Это позволяет разным людям вносить поправки, не мешая друг другу. (Такое же поведение имитируется веб-приложением GoogleDocs.) Также следует заметить, что ничто так не раздражает, как блуждание по документув поисках отличий от предыдущей версии. Какое бы средство для этого не использовалось,авторы должны регистрировать вносимые изменения, например, “В раздел 6 этот пунктбыл добавлен 20.07.2008”.}).
       — Предоставить четкие контрольные точки для рабочего графика, на которые будет сориентирована команда.
       — Дать гарантию автору (или авторам), что его права не ущемляются2 {Не стоит относиться к этому с сарказмом. На самом деле концепция управления знаниями базируется, в частности, на понятии документирования, без которого некоторые вещи просто исчезли бы, если кому-то, скажем, при подготовке следующего варианта, они показались бы лишними.}.
       — Дать возможность чаще проводить конструктивные дискуссии, повысить их качество и продуктивность.
       — Дать руководителям возможность получать отзывы и устанавливать планку качества работы.
       — Прибавить команде (и автору) уверенности и рассудительности. А вот, чему технические условия не могут и не должны послужить:
       — Исключить всяческие дебаты внутри команды.
       — Доказать команде авторскую состоятельность.
       — Доказать, насколько важна та или иная деталь (и почему от нее нельзя отказаться).
       — Привить людям философский взгляд на окружающий мир.
       — Стать полем демонстрации авторского мастерства в работе с Visio или UML.
       Руководителям нужно составить схожий с этим список, чтобы команда над ним поработала. Перед тем как приступить к составлению технических условий, нужно попросить просмотреть этот список всех, кто будет привлечен к чтению или написанию технических условий, и дать свои отзывы. Возможно, там обнаружатся ненужные для технических условий пункты или список нужно будет дополнить чем-то существенным. Обсуждение должно быть кратким — не более получаса. В ходе даже столь непродолжительного разговора можно установить, чего следует ожидать от технических условий и какие рекомендации нужно дать по их составлению. Такие общекомандные прикидки должны быть учтены при подготовке технических условий.

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

       Все методологии разработки программных продуктов или управления проектами определяют суть технических условий по-разному, и в этом нет ничего плохого. Существует четыре основных вида информации, которые, в конечном счете, должны быть отражены в технических условиях, и самым простым способом их обсуждения станет предположение, что они в конечном счете окажутся в четырех разныхдокументах. А по каким признакам проводить разделение — не столь важно (хотя некоторые люди относятся к этому излишне скрупулезно). Важно то, что нужная информация находит свое отражение в технических условиях усилиями грамотных специалистов и преподносится в подходящем для исполнителей виде. Для небольших команд различные виды технических условий зачастую смешиваются. Для более многочисленных команд может потребоваться их разделение (с сохранением взаимосвязи) и даже создание усилиями различных людей.
       — Технические требования. В целях документирования всего, что ожидается получить от реализации проекта, в технических требованиях в общих чертах намечаются все запросы и обязательства, которым должна соответствовать работа. В них объединяются всевозможные рабочие требования и обеспечиваются ориентиры для всего проекта. В лучшем случае это должен быть список победных достижений, описывающий, как должен выглядеть конечный результат, причем без слишком подробных объяснений того, какими способами всего этого достичь. Во всяком случае, технические требования должны быть определены до начала проектирования (хотя позднее они могут подвергаться уточнениям и дополнениям), и сделано это должно быть на основе положений концептуального документа. Технические требования вместе с функциональной спецификацией должны быть включены в документацию для внесения ясности в суть проекта и помощи в оценке текущей обстановки (будет ли данный план удовлетворять требованиям?).
       — Функциональная спецификация. В функциональной спецификации описывается сценарий использования продукта с точки зрения потребителя. Функциональная спецификация — это первый документ, вырабатываемый в процессе проектирования. В нем описывается функциональность создаваемого продукта через призму пользовательского интерфейса (если его создание предусматривается) и приводится детальный порядок функционирования компонентов с самой нетехнологической точки зрения. В нем должно быть также описано, как изменится характер работы пользователя, когда работа над проектом будет завершена. Туда же должен быть включен простой список работ, необходимых для осуществления общего замысла. Отличие этого документа от технических требований состоит в том, что в нем определяются соответствующие требованиям конструктивные особенности, включая пользовательский интерфейс или другие не столь очевидные элементы проекта. При качественном выполнении хорошая функциональная спецификация может быть простой серией копий экрана, снабженных подробными пояснениями.
       — Техническая спецификация. В технической спецификации детализируются инженерные подходы, необходимые для реализации характеристик, представленных в функциональной спецификации. Степень детализации должна быть достаточной для описания самых сложных или многократно используемых компонентов, которые могут повторно задействоваться другими программистами и служить основой для определения работ по реализации функциональной спецификации. Иногда глубина проработки и техническая направленность функциональной спецификации позволяют вообще отказаться от технической спецификации.
       — Перечень работ. Перечень работ — это примерный эквивалент структурной декомпозиции работ (WBS). Перечень работ является описанием каждого задания на разработку программного кода, необходимого для реализации функциональной спецификации. Перечень должен быть разбит на уровни по степени важности работ с подсчетом затрачиваемых дней на их выполнение (возможно, продолжительность некоторых работ должна быть определена с точностью до дня или до полудня, но это — прерогатива программистов). Создание перечня работ всецело возлагается на программистов, а ведущий программист и, возможно, руководитель проекта должны его просмотреть и провести окончательное редактирование. (С технической точки зрения, перечни работ не относятся к техническим условиям, а представляют собой план реализации этих условий. Но степень их важности и взаимосвязь с техническими условиями не позволили мне найти лучшего места для их представления.)
       — Критерии тестирования и прохождения контрольных точек. Поскольку в технические условия включается функциональная спецификация, должны быть определены и критерии тестирования. В них должны быть включены по приоритетам испытательные тесты для проверки новой функциональности, а также показатели состоятельности программного кода, соответствующие качественным критериям прохождения контрольных точек (описание критериев прохождения контрольных точек вы найдете в главе 15).
       Теперь позвольте предоставить пример того, как эти виды технических условий могут сочетаться. Когда я работал в составе больших команд, составление как функциональных, так и технических спецификаций было обычным делом. Мы получали перечень требований из концептуального документа, просматривали его всей командой в присутствии заказчика, а затем на его основе приступали к подготовке функциональной спецификации. Программисты составляли перечень работ (зачастую в виде простой электронной таблицы, доступной всей команде) и копировали его в функциональную спецификацию или проставляли на него ссылки. Дело завершалось получением единых технических условий, включающих все многообразие только что рассмотренной спецификационной информации.
       Проще всего продумывать все четыре вида технических условий в простом хронологическом порядке: требования, функциональность, техническое воплощение и отдельные работы. Как и многие другие проектные задания, каждая разновидность информации обеспечивает основу для следующей разновидности. Чем многочисленнее команда и сложнее проект, тем, возможно, более формальным должен быть подход к разделению видов технических условий.

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

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

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

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

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

       Несмотря на возможность объединения функциональной и технической спецификаций в единый документ, чаще всего их требуется расположить в разных разделах. Создатель одного из наихудших из когда-либо прочитанных мною образцов технических условий совместил эти два раздела, загнав себя в тупик. Автор, приложив все свои умственные усилия, попытался описать замысел, одновременно объясняя, каким образом этот замысел будет воплощаться в жизнь. Взглянув на документ, я сразу понял, что он просидел над ним немало времени1 {Меня всегда настораживали красиво разрисованные и объемистые технические условия. Это явный намек на то, что руководителя проекта больше волнуют сами технические условия, а не то, что будет получено на выходе, или то, что он не доверяет своей команде. Хуже того, слишком пространное изложение технических условий свидетельствует о том, что сами условия, в конечном счете, так никто и не читал (исключение составляют условия создания ядерных реакторов или высокотехнологичного хирургического инструмента).}. Автор нарисовал большие и подробные диаграммы, отображающие отношения между работами и компонентами, вперемешку с диаграммами о порядке их возможного использования заказчиками. Результат вылился в весьма красочный и абсолютно полный провал. Технические условия выглядели впечатляюще, но после пяти минут изучения в отчаянной попытке извлечь из них хоть какой-нибудь смысл мне захотелось задушить автора (думаю, что у его команды была похожая реакция). Он несколько раз пытался довести до людей содержание документа, что, к сожалению, приводило лишь к росту их негативного отношения и едва скрываемой раздражительности.
       Пытаясь хоть чем-то помочь, я поговорил с составителем технических условий и попытался дать ряд советов. Он признал, что потерял канву документа и что сами по себе технические условия не столь уж и важны, но по-прежнему был уверен, что его подход к их составлению был хорош. Он утверждал, что, поскольку ему известно, что программистам нужны напоминания как об ожидаемом поведении продукта, так и об общих деталях, касающихся взаимоотношений между работами, есть смысл объединить все вместе. Мое мнение выражалось в том, что даже если кому-то нужны оба вида информации, не стоит полагать, что они нужны одновременно или должны быть изложены на одной и той же странице документа. Зачастую намного проще читать и писать о чем-то одном и разбираться в описании по уровням, чем делать это, объединяя уровни воедино. Удачно составленные технические условия часто описывают замысел по уровням: на первом уровне на языке пользователя описываются его будущие впечатления от продукта, на втором приводится обзор основных работ и архитектуры продукта, а на третьем охватываются наиболее сложные и требующие детализации вопросы, касающиеся технического воплощения замысла.

Упрощение хороших технических условий

       Для людей с техническим складом ума труднее всего решиться избавиться от ненужных деталей и выбрать для этого наиболее подходящий момент. В ходе многочисленных и неимоверно сложных занятий по математике и логике я усвоил, что лучшие преподаватели знали, когда нужно пропустить второстепенные, но все же важные понятия и как к ним вернуться в тот момент, когда студенты (или читатели) подготовлены к их восприятию. При создании качественных технических условий используется тот же прием. Выясняются самые важные моменты. Вникая в работу, люди способны прояснять для себя и ее суть. После чтения технических условий мысленные представления о том, как будет создаваться все задуманное, приобретут более ясные очертания, возрастет и качественный уровень вопросов, которые люди смогут задать руководителю проекта или другим специалистам команды. Стремитесь к получению именно такого эффекта. От всех вам этого, конечно, не добиться, но постарайтесь все-таки приобрести для проекта важных сторонников.
       Конечно, в описании непростой объектной модели или подробно детализированного интерфейса без сложности обойтись не удастся. Некоторые элементы могут потребовать объяснений и времени для понимания их сути, но вы должны убедиться в том, что это действительно необходимо. Зачастую же сложность — это признак несостоятельности, за которой скрывается плохое владение письменным языком или узость мышления. Весь смысл составления технических условий сводится к стремлению описать вещи таким образом, чтобы люди понимали их, прилагая для этого как можно меньше усилий. В самом наихудшем варианте кому-то может понадобиться больше времени для осмысления технических условий, чем для самостоятельного конструирования изделия. Но, как и для многих других письменных документов, эти критерии довольно субъективны. Поиск нужного баланса между доходчивостью и сложностью — вопрос тонкий, и его лучше всего вынести на рассмотрение руководителей команд.
       Тем не менее, во имя качественного составления описаний, я приведу ряд советов и обозначу некоторые положения, появление которых в технических условиях нежелательно.
       — Перенимайте удачные объяснения, встреченные в других технических условиях (даже если их придумали другие люди). Применяйте в разумных пределах гипертекст и, если нужно, заимствуйте полезные обзоры из Интернета после получения соответствующей санкции от руководителей команд. Совсем не обязательно самому все изобретать и описывать.
       — Постарайтесь обойтись без жаргонных и туманных фраз. Не используйте их, если не уверены, что поможете тем самым читателю, что случается крайне редко. Или, говоря более сложным языком, сократите возможную путаницу, возникающую из-за намеренного использования концептуальных вопросов в виде сокращения макропонятий к неоднозначно толкуемым преобразованным понятиям и повсеместной отмены избыточных языковых групп.
       — Придерживайтесь наработок, содержащихся в старых технических условиях. Если вы застряли, пытаясь получше преподнести концептуальное положение или выразить что-то в виде диаграммы, хорошую подсказку всегда можно найти в старых технических условиях. Если вам попадутся удачные технические условия, написанные кем-то другим, воспользуйтесь ими.
       — При составлении технических условий постоянно думайте о специфике восприятия тех людей, которые будут все это читать. Даже если команда состоит всего лишь из десяти человек, то наиболее зависимыми в своей работе от технических условий окажутся, скорее всего, четверо или пятеро их них. Прибавьте для разнообразия какого-нибудь толкового знакомого, не состоящего в команде и не знающего той технологии, которую вы используете. Как бы вы объяснили ему вашу малопонятную концепцию?
       — Не демонстрируйте свою влюбленность в Visio или блок-схемы. Относитесь ко всему доступному инструментарию с платонической любовью. Обычно диаграммы представляют интерес только для их создателя, и зачастую от них значительно меньше проку, чем он себе это представляет. Иногда удачно написанный абзац или набросок дают больше представления, чем UML-диаграмма из 500 блоков. (Лишь то, что диаграмма является единственным средством авторского понимания какого-нибудь положения, не дает никаких гарантий, что ее использование является лучшим способом объяснения этого другим людям.) Но разумное применение инструментария и диаграмм может быть вполне оправдано.
       — Что это, справочник или технические условия? Вообще-то технические условия не должны быть полным справочником по API-функциям или описанием каждого возможного варианта поведения продукта. Разумнее сосредоточиться на объяснении десяти-пятнадцати наиболее общих или важных положений и создать отдельный документ с исчерпывающим перечнем всего остального (с меньшей степенью детализации).
       — Перед тем как с головой уйти в работу, опишите в общих чертах все сложные алгоритмы, воспользовавшись псевдокодом или обычным языком. И, как уже ранее упоминалось, следует учесть, что распределение объяснений по уровням поможет быстрее усвоить материал даже интеллектуалам. Как минимум, важную роль могут сыграть удачно составленные резюме и краткие обзоры.
       А вот еще один прием, который всегда представлялся мне полезным: когда кого-то в черновом варианте технических условий что-то смущает (что сразу же обнаружится, стоит вам лишь уговорить кого-нибудь его прочитать), не пожалейте пяти минут на объяснения. Как только до него дойдет суть сказанного, спросите, какой способ лучше избрать для объяснения этого же вопроса в технических условиях. Иногда вы сможете получить дельный совет, а иногда и нет, но ваше понимание вопроса неизменно упростится, поскольку вы сами себя заставите взглянуть на него шире. С каждым обращением к другим людям вы приобретаете несколько иное осмысление конкретного концептуального положения, повышая тем самым шансы отыскать наилучший подход к его объяснению. Если вы заняты составлением технических условий, следует запомнить, что легче всего получить дельные отзывы, если вы сами к этому стремитесь.

Гарантия верного хода процесса

       Технические условия определяют ряд намерений и являются основой для следующего утверждения: “Если все пройдет без неожиданностей, то по окончании этой работы мы получим именно то, что описано в документе”. Это означает, что все (или почти все, в разумных пределах) в поведении и функционировании, задекларированное в функциональной спецификации, будет обнаружено по окончании работы в финальном варианте работающего кода. Вполне возможно, что на следующий день после завершения работы над техническими условиями в мире могут произойти изменения, а намерения останутся на уровне, который соответствует дню их написания. Мировые изменения, какими бы они ни были, должны найти свое отражение в изменениях и дополнениях к намерениям.
       На техническом уровне цель технических условий состоит в том, чтобы сообщить об этих намерениях всем заинтересованным лицам. Для тестировщи-ков и контролеров качества это означает предоставление достаточно точного описания ожидаемого поведения проектируемого продукта для составления предварительных контрольных примеров и определения оценочных критериев. Маркетологи, составители документации и прочие специалисты, задействованные в проекте, перед тем как приступить к своей работе, могут нуждаться в ответах на другие вопросы, касающиеся конечных результатов. Специалистам по технической поддержке или рекламным агентам для работы по сопровождению продукта или для ее планирования потребуется представление о том, как он будет работать.
       Людям, ознакомившимся с техническими условиями, лучше всего задать вопрос: “Получили ли вы все необходимое для того, чтобы выполнить свою работу на самом высоком уровне?” Уделяя внимание читателям, вы измените их заинтересованность. Они начнут задавать куда более дельные вопросы и переведут в своем сознании технические условия в разряд документов, востребованных в их дальнейшей работе.

Кто, когда и как

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

Технические условия — это для одного или для многих?

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

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

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

Какова мера достаточности

       Решение о том, когда считать работу над техническими условиями завершенной, требует трезвых размышлений. Практически всегда обнаруживаются нерешенные проблемы и вопросы или не до конца улаженные зависимости от других компаний или проектов. Штамп “Разработка технических условий завершена” может означать самые разные степени завершенности и качества в зависимости от проекта и команды. Здесь не существует единых правил: иногда риск получения в итоге плохих технических условий перевешивается напряженностью рабочего графика или другими соображениями. Как и в отношении других высокоуровневых аспектов проекта (качества программного кода, стабильности, производительности), решение о величине прилагаемых сил и времени может быть принято только на основе здравых размышлений руководителя команды. И, конечно же, чем более обкатана основная техническая стратегия, тем, возможно, более гибким будет способ составления технических условий.
       И все же есть одно универсальное правило: чем лучше технические условия, тем выше вероятность получить конечный результат в установленные сроки. Вопрос в том, какая степень вероятности вам нужна. Стоит ли тратить время на улучшение технических условий на 5%? Сумеют ли программисты или руководитель проекта обдумать некоторые детали по ходу работы над реализацией проекта? На эти вопросы ответить не легко. Просматривая какие-либо технические условия, я должен был составить о них собственное мнение. Я думаю, что для принятия решения в большей степени нужен опыт управления проектами, а не мастерство программиста или технического писателя.
       Тем не менее, перед тем как работа над техническими условиями будет считаться законченной, важен не сам по себе ожидаемый уровень ее завершенности. Подвести черту можно только после обсуждения технических условий. Поскольку этот процесс весьма субъективен и относителен, единственным способом довести технические условия до требуемого уровня качества является передача их на рассмотрение руководителям команд (и тем специалистам, для которых они написаны) и получение отзывов. (Я опишу этот процесс в следующем разделе.)

Как справиться с открытыми проблемами

       Независимо от того, насколько хорошо команда справляется с проектированием, в ходе составления технических условий всегда будут выявляться нерешенные проблемы. Если с ними должным образом не разобраться, ждите неприятностей. Многие срывы, происходящие в ходе реализации проекта, возникают из-за неразрешенных или незамеченных проблем, возникших при составлении технических условий. Очень важно, чтобы руководитель проекта взял на себя инициативу по сбору и рассмотрению таких проблем, настраивая команду на их выявление на самой ранней стадии. Эта работа является серьезным испытанием для неопытных руководителей проектов, всецело поглощенных решением других задач по составлению технических условий и не уделяющих из-за этого достаточно времени для разбора открытых проблем. Зачастую, чтобы осознать всю важность выявления проблем на ранней стадии, надо сначала несколько раз “наступить на грабли” при реализации проекта.
       Эффективному управлению открытыми проблемами поможет, разве что, усердная работа. Кто-то должен не только исследовать потенциальные проблемы, но и потратить время на их регистрацию. Здесь нет никакой премудрости. После того как они зарегистрированы, их можно будет расположить по приоритетам, за кем-то закрепить и, в конце концов, разрешить, но если ни у кого на это не найдется времени, избавление от серьезных проблем станет делом случая, а не мастерства специалистов.
       Предположив, что вы действительно тем или иным способом отслеживаете проблемы, пусть даже в виде перечня на офисной доске, я приведу ряд основных вопросов, помогающих их детализировать и распределить по приоритетам.
       — Когда эта проблема должна быть решена? Кто больше всех подходит для ее решения?
       — Нельзя ли как-то изолировать проблему, может быть с помощью специфического компонента или сценария? Влияет ли она на общую функциональность или на весь проект в целом?
       — Чем может разрешиться проблема в случае выбора каждого из вариантов, которые еще находятся в стадии рассмотрения? (Например, если мы решим использовать технологию ASP или РНР вместо JSP.) Как выбор каждого из вариантов повлияет на технические условия?
       — Нельзя ли вообще проигнорировать эту проблему? Как это реально повлияет на пользователя с точки зрения самого приоритетного сценария его работы?
       — Можно ли разбить проблему на более мелкие, которые могут (или должны) быть поручены другим специалистам?
       — Кто или что мешает решению проблемы и были ли предприняты усилия для устранения этой помехи? (Ответ может скрываться в технической или политической сфере.)
       Если накопилось множество серьезных проблем, которые трудно поделить на более мелкие, значит, что-то сделано неправильно, и процесс проектирования и (или) руководство действиями команды осуществлялись не на должном уровне. Пути выхода из этой ситуации лежат в сфере управления открытыми проблемами (см. главу 11).

Устранение пробелов в технических условиях

       Если вы неплохо справляетесь с решением открытых проблем, то можно ликвидировать белые пятна в рабочем графике, проведя оценку времени разрешения этих проблем. Основную идею, часто называемую “усесться на переднем сидении”, иллюстрирует рис. 7.1. При правильном воплощении этой идеи в жизнь технические условия могут считаться подготовленными и рассматриваться, даже если проектные проблемы остаются отчасти нерешенными. Этот прием представляет собой рискованную затею: вы прикидываете, насколько успешно командой будут решены оставшиеся проблемы, а не ждете их реального решения. Тем не менее подобные действия совсем не обязательно связаны с высокой степенью риска. Все зависит от того, насколько хорошо понятна суть этих проблем и насколько верны предположения относительно их решения. Рассмотрим для примера две команды. Команда А располагает длинным, но вполне понятным перечнем проблем, а команда Б — коротким, но малопонятным. Какая команда, по-вашему, скорее всего, уложится в назначенные сроки? Я бы отдал предпочтение команде А (в этом месте звучит гимн команды А). Здоровый скепсис подсказывает, что короткий перечень команды Б свидетельствует о том, что ею еще не выявлены все проблемы, связанные с техническими условиями. Что касается команды А, она уделила больше времени на осознание всех имеющихся у нее открытых проблем и лучше подготовлена к тем испытаниям, которые уготовил ей проект.


Рис. 7.1. Устранение пробелов, оставшихся при проектировании и составлении технических условий

       Важно отметить, что устранение пробелов не означает прекращения проектных работ, требуемых для окончательной реализации принятых решений. Это значит, что руководитель проекта пытается ненадолго отступить на шаг назад и все тщательно обдумать ради соблюдения графика работ.
       Облегчить устранение пробелов поможет рассмотрение следующих вопросов, касающихся каждой открытой проблемы:
       — Существуют ли работы, которые нужно будет выполнять независимо от того, какой вариант выбран? Если существуют, работы должны быть рассчитаны и добавлены в технические условия. При необходимости к выполнению таких работ можно приступить еще до завершения подготовки технических условий.
       — Может ли эту проблему решить руководитель проекта или проектировщик? Выразится ли закрытие этой проблемы в появлении новых работ? (Например, может быть появится возможность действовать параллельно с программистом, который приступает к обдумыванию работ, в то время как руководитель проекта занимается решением открытых проблем.)
       — Каковы находящиеся в стадии рассмотрения альтернативные варианты решения этой проблемы?
       — Какие из возможных альтернативных вариантов наиболее затратны? Проведите оценку работ с данной точки зрения и попробуйте превратить технические условия и перечень работ в наихудший вариант конструкторского замысла.
       — Относится ли проблема к центральному или ключевому компоненту? Когда программист должен воплотить его в жизнь? Можно ли спроектировать компонент позже, в стадии разработки? Принадлежит ли проблема к чему-нибудь, от чего, по имеющимся прикидкам, зависит ряд других компонентов?
       — Может ли проблема быть изолирована, сужена, поделена на части или проигнорирована? Если нет, то поместите ее в верхнюю часть списка проблем, отсортированного по важности их решения.
       Устранение пробелов не всегда венчается успехом. Возможно, вы приложите массу усилий и сдвинете дело с мертвой точки, но обнаружите, что все еще далеки от победы. Даже в этом случае усилия по устранению проблем принесут пользу. Неопытные команды зачастую нуждаются в том, чтобы их принуждали к борьбе со всеми возникающими у них проблемам (как технического, так и иного плана), и руководители могут не понимать всей важности отложенных проблем, пока те себя в полной мере не проявят. Можно найти массу веских аргументов в пользу предупредительного, а не выжидательного метода устранения пробелов, подвергающего рабочий график существенному риску.

Важность завершения подготовки технических условий

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

СОВЕТ
       Лучше лично высказать свою признательность людям за их работу. Благодарность всей команде, посланная по электронной почте, не будет должным образом воспринята каждым сотрудником. Нужно обойти всех сотрудников или обзвонить их по телефону. Краткий разговор вызовет намного больше эмоций, чем любые слова благодарности, посланные по электронной почте.

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

Обсуждение документов и получение отзывов

       Пожалуй, самая большая ошибка при составлении технических условий — это ожидание начала некоего формального процесса обсуждения и получения отзывов на содержание документов. Документы должны обсуждаться для совершенствования их содержимого, а не для того, чтобы принимать окончательные решения при первом же ознакомлении с ними. Это еще одно подтверждение важности проектирования: проектные решения должны пройти множество прикидок, а у авторов должны быть возможности включить в них дельные советы. Руководители команд должны способствовать этому процессу, устраивая неформальные обсуждения на ранней стадии и публикуя черновые варианты технических условий в корпоративной сети. Но это не означает, что обсуждение технических условий должно идти легко и гладко. Каждый должен включаться в этот процесс с абсолютно ясным представлением о том, что он ожидает увидеть в данном документе.
       Существуют различные способы обсуждения технических условий, но большинство из них предполагает проведение встреч, на которых документ зачитывается и обсуждается в целях удовлетворения чьих-то интересов. Насколько формально проводятся такие встречи, во многом зависит от позиции руководителей команд. Но, как бы то ни было, цель состоит в том, чтобы ответить на одни и те же два вопроса: “Достаточна ли степень детализации технических условий для того, чтобы на их основе вести разработку?” и “Будет ли результат удовлетворять требованиям и целям этой части проекта?” Разумеется, наберется еще много различных специфических вопросов, но все они вытекают из этих двух ключевых. Процесс обсуждения технических условий должен быть направлен на получение уверенного ответа на оба вопроса.

Как проводить обсуждение технических условий

       Обсуждение должно проводиться в составе команды. Имея в центре внимания сам документ и людей, которые его составляли, обсуждение проводится в целях подтверждения того, что все, кому предстоит работа над реализацией проекта, согласны с положениями технических условий. Проще и быстрее провести этот процесс, собрав всех вместе в одной комнате, чтобы все узнали ответы на все прозвучавшие вопросы. Я был свидетелем проведения обсуждений через электронную почту или в режиме телефонной конференции и не могу сказать, что был удовлетворен результатами. Как только возникал спорный момент, мне тут же хотелось оказаться в одной комнате с командой и дать немедленные разъяснения, воспользовавшись классной доской или показав все “на пальцах”. Чем сложнее технические условия, тем сильнее вам захочется собрать людей в одной комнате. (Если вы вынуждены вести работу в виртуальном пространстве и считаете, что в обсуждении должны участвовать все заинтересованные лица, соберите их в небольшие группы от трех до пяти человек. При работе над такими сложными задачами, как обсуждение технических условий, телефонные или видео конференции в составе больших групп быстро превращаются в трагикомедию.)
       Для проведения одно-двух часовых встреч в течение нескольких дней должен быть заранее зарезервирован средний по размерам конференц-зал. Если технические условия уже готовы к обсуждению (по мнению автора и на основе критериев, заданных руководителями групп), это должно быть указано в приглашении на встречу. Насколько я помню, самому мне это удавалось сделать всего лишь несколько раз. Чаще всего я объявлял о встрече заранее, за неделю или около того, и сообщал каждому, что он получит документ по электронной почте за 24 часа до начала обсуждения. Кому-то это не нравилось, но я пришел к выводу, что это — наиболее продуктивный способ предоставить людям обновленную версию документа и заставить их ее прочитать. Если людей предупредить заранее, то они смогут спланировать свою работу в эти последние сутки таким образом, чтобы спокойно прочесть документ.
       К тому же, я полагаю, что вполне справедливо потребовать от участников обсуждения технических условий предварительного ознакомления с документом. Вполне естественно, что люди, которым действительно нужно прочитать документ, смогут найти время, потому что для них это наиболее важное из всех текущих дел. Независимо от того, что они скажут, если они действительно не смогли найти время хотя бы для беглого просмотра документа в поиске наиболее очевидных проблем, значит, работа для них не самое главное и им не место в аудитории.
       Обладая достаточными полномочиями, я ввел в правило для всей команды чтение технических условий до их обсуждения. Тем самым гарантировались следующие две вещи. Во-первых, я избавлялся на обсуждении от случайных людей. Сразу падали шансы на то, что комната будет заполнена некомпетентными “горлопанами”. Во-вторых, обсуждение проходило значительно быстрее, поскольку стартовые позиции в понимании вещей у всех были одинаковы. По задаваемым вопросам сразу станет видно, кто не читал технических условий. Если вопросы заданы по существу, то их надо рассмотреть, но если ответы на них уже имеются в самом документе, то вполне уместно указать на раздел, который следует прочитать, и предложить обратиться к автору технических условий по окончании встречи.

Кто должен присутствовать и как все должно происходить

       В зале должен быть хотя бы один представитель от каждого ключевого подразделения (от программистов, тестировщиков и т.д.) плюс по представителю от других, не менее важных подразделений (от бизнесменов, проектировщиков, составителей документации). Обсуждение должно быть открытым для всей команды: если тестировщики и программисты заинтересовались техническими условиями и нашли время для их прочтения, то их присутствие должно только приветствоваться, даже если они не задействованы в реализации какой-то конкретной характеристики. Руководители команд должны приглашаться дополнительно, их участие во встрече определяется их собственным решением. Если они хорошо справляются со своими обязанностями, то могут быть осведомлены о деталях документа в достаточной степени, чтобы посещать только те встречи, на которых разгораются наиболее жаркие споры. С другой стороны, если команда не имеет достаточного опыта работы, их присутствие может требоваться на каждой встрече.
       Встречу должен открывать руководитель проекта или автор технических условий. Сам процесс довольно прост — нужно отвечать на вопросы. Если вопросов нет (это уже из области фантастики), а все нужные люди, которые присутствуют на встрече, полностью удовлетворены техническими условиями, то обсуждение заканчивается. Некоторым руководителям проектов нравится устраивать прогон окончательного прототипа, воплощающего само совершенство. Другие же предпочитают рассматривать документ по разделам. Лично я считаю это пустой тратой времени (если я составил хорошие технические условия и все их прочитали, то зачем снова проходить по всему документу?), но некоторым командам этот метод нравится и повсеместно ими используется. На самом деле важно лишь то, чтобы люди были заняты продуктивным обсуждением, задавали толковые вопросы и все вместе пытались сгладить шероховатости.
       Присутствующие должны обсудить ответ на любой из поднятых вопросов к удовлетворению того, кто его задал, или добавить новый пункт к списку открытых проблем, прилагаемому к техническим условиям. Когда вопросы иссякнут, руководитель проекта рассматривает список открытых проблем (для представления его новых пунктов вполне подойдет классная доска, установленная в конференц-зале) и принимает решение о том, есть ли там что-нибудь, достойное обсуждения на следующей встрече. Если до уровня дополнительного обсуждения ни один из проблемных вопросов не дотягивает, технические условия считаются рассмотренными, а вновь выявленные проблемы — ожидающими своего исследования и решения.
       После завершения обсуждения технических условий у руководителя проекта должен быть готов график реагирования на новые вопросы или проблемы, поднятые в процессе встречи. Сразу же после встречи все приглашенные для участия в ней должны получить по электронной почте сообщение с кратким перечнем открытых проблем, датой новой встречи (если таковая запланирована) и графиком работы над открытыми проблемами, требующими решения. Это приобретает особое значение, если какая-нибудь открытая проблема препятствует работе кого-нибудь из команды. Проблемы, препятствующие работе, должны быть выявлены и взяты под особый контроль в процессе обсуждения технических условий.

Список вопросов

       В результате многолетних наблюдений за отклонениями от нормального хода событий у меня появился ряд вопросов, которые стоит задавать при каждом обсуждении технических условий. Даже если эти жесткие вопросы не выявят конкретных проблем, они заставят команду более критично подойти к своей работе. Следует помнить, что это еще не окончательное испытание: о том, какими будут эти вопросы, все могут знать еще до того, как они заданы. В ваших же интересах убедиться в том, что все вовлечены в подготовку к обсуждению.
       Поскольку проектирование и составление технических условий ведется с оптимистическим настроем, участникам обсуждения следует настроиться на скептический лад и стремиться выискивать любые упущения. (Не впадайте в крайности. Критический подход не требует чрезмерной жестокости и стремления кому-то навредить. Если команда в процессе подготовки к обсуждению технических условий впадает в уныние, ответственность за это, скорее всего, лежит на руководителе проекта, а не на отдельных ее представителях.) Даже если у команды есть достойные ответы, кто-то все равно должен к ним придираться, дабы убедиться, что ответы выдерживают критику.
       Вот мой перечень вопросов, пересмотр и дополнение которого только приветствуется.
       — Соответствует ли техническим условиям перечень работ, составленный программистами? Каким образом каждый главный компонент технических условий соотносится с каждой работой? В каком месте проекта наиболее вероятно обнаружить пропущенные работы?
       — Где самые узкие места проекта? Каковы самые слабые компоненты или элементы интерфейса? Почему они не могут быть улучшены?
       — В чем самые сильные стороны проекта? В чем самые слабые? В чем мы более-менее уверены? Проецируются ли сильные стороны и уверенность в успехе на наиболее важные компоненты?
       — Приемлем ли уровень качества? Будет ли конечный продукт столь же надежен, производителен и полезен, как того требует концепция проекта? Являются ли реалистичными тестовые оценки?
       — Не лучше ли упростить замысел? Неужели нам на самом деле нужна такая сложность и функциональность? Какие у нас основания или веские аргументы против упрощения конструкции?
       — Какие взаимозависимости характерны для данного замысла? Существуют ли технологии, корпорации, проекты или другие технические условия, провал которых воспрепятствует его осуществлению? Располагаем ли мы планами на случай непредвиденных обстоятельств?
       — Какие элементы замысла, скорее всего, могут подвергнуться изменениям? Почему?
       — Располагают ли полной информацией, необходимой для их успешной работы, связанные с проектом специализированные подразделения по тестированию продукта, его документированию, рыночному продвижению и т.п.? В чем суть их основных опасений и что с ними делать? Или, существуют ли веские причины для того, чтобы проигнорировать эти опасения?
       — В чем суть основных опасений, касающихся технических условий со стороны руководителей проекта, программистов и тестировщиков? Есть ли такие опасения относительно отдельных функций?
       — Существуют ли возможности для совместного использования или заимствования программного кода других функций, создаваемых в рамках данного проекта?
       — Удалось ли нам добиться соответствия требованиям относительно доступности и локализации пользовательского интерфейса?
       — Каковы угрозы безопасности данного проекта? Почему бы их не устранить? Задокументированы ли эти угрозы в технических условиях, включая потенциальные средства восстановления (например, есть ли модели угроз)?
       — Располагаем ли мы достоверными доказательствами, свидетельствующими о том, что конкретные пользователи могут успешно работать с данным интерфейсом?

Выводы

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

Упражнения

       1. Возьмите большой набор элементов LEGO-конструктора и пригласите другого руководителя проектов. Разделите элементы на две кучки с одинаковым количеством и типом элементов. Сядьте друг к другу спиной, а затем кто-нибудь из вас пусть соорудит какую-нибудь конструкцию (неважно, какую именно). Как только она будет готова, ее создатель, пользуясь только словами, должен проинструктировать своего коллегу, как создать точно такой же объект. Сравните результаты. Затем повторите все сначала, поменявшись ролями.
       2. Почему руководители проектов пытаются использовать технические условиядля продуктов, которые не в состоянии создать? Какую проблему они пытаются (и не могут) решить?
       3. Как можно по качеству технических условий судить о руководителе проекта? Можете ли вы, основываясь лишь на технических условиях, предположить, каким будет качество программного продукта?
       4. Изобразите что-нибудь из привычных и заученных действий, вроде завязывания шнурков, установки будильника или запуска DVD. Запишите, как вы это делаете, чтобы кто-нибудь мог последовать вашим инструкциям. Сделайте набросок, иллюстрирующий ваши действия. Попробуйте в точности последоватьтому, что вы написали, или попросите об этом кого-нибудь другого. Обратите внимание на результаты, пересмотрите инструкции и повторите попытку.
       5. Найдите самые неудачные из когда-либо встречавшихся вам технических условий (попросите об этом друзей, товарищей по команде, любого человека, который работал в тех сферах, где создаются технические условия). А теперь попросите показать самые лучшие технические условия. Составьте свой собственный список найденных общих признаков, как положительного, так и отрицательного свойства.
       6. Как убедиться в том, что технические условия обладают достаточным уровнем детализации? Можете ли вы придумать способы определения слишкомглубокой или слишком поверхностной детализации?
       7. Вам знаком какой-нибудь человек, увлеченный Visio, UML или другими инструментальными средствами? Есть ли у вас доказательства, что эта увлеченность приводит к созданию плохих технических условий? Сделайте для команды полезное дело: организуйте протест против применения Visio. Пригласите всех, кто пользуется его техническими условиями, соберите их подписи под петицией об ограничении использования документов, созданных с помощью Visio, и передайте эту петицию руководителю проекта. Приобщите к ней список, какие технические условия могут и не могут быть выполнены с помощью инструментальных средств.
       8. Если вы знаете, что работа над техническими условиями завершится всего лишь через несколько дней, как можно убедиться в том, что оставшееся время используется эффективно? Можете ли вы предложить остальной части команды помочь вам в работе? Что можно сделать, чтобы максимально увеличить шансы на успешное обсуждение технических условий?
       9. Представьте себе следующий сценарий: вы создали великолепные технические условия, с замечательными иллюстрациями, ясным изложением и полной документацией. Но вашим лучшим разработчикам они не понравились. Имне понравилось не только, как они написаны, но и идеи, которые в них представлены. До сдачи технических условий осталось только два дня. Что нужно сделать? Что можно сделать в следующий раз, чтобы предотвратить подобную ситуацию?




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:56 MSK


Постоянный адрес статьи:
http://az-design.ru/Projects/AzBook/src/004/02MS0700.shtml