Здравствуйте, уважаемые подписчики!

Управление проектом. Функциональная спецификация.

В предыдущей статье я разделил спецификации на 2-е техническая и функциональная.

Так как техническая спецификация это произвольный документ, то далее он не рассматривается. Наши специалисты ведут этот документ в столь разных форматах, что даже не стоит их стараться описывать.

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

Вернемся к функциональной спецификации. Как я уже писал, это документ, который является единственным описанием проекта и используется всеми членами команды и клиентами.

Именно этот документ готовит менеджер проекта, именно этот документ обсуждается между клиентами и менеджером продукта, именно этот документ служит основой для руководителя разработки, архитектора БД и разработчиков.

Что бы все это работало, необходимо, что бы функциональная спецификация постоянно обновлялась и была доступной всем членам команды и описание должны быть на простом «русском» языке с максимальной детализацией работы проекта. Я бы даже сказал что функциональная спецификация это детали, детали и еще раз детали.

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

Если вдруг появится вопрос, на сколько детально описывать или что-то вроде «ну ведь все равно будет сделано по-другому», то ответ один: чем детальнее вы описываете, как система должна работать и выглядеть, тем быстрее выявятся ошибки и результат разработки будет более предсказуем.

Простой пример с обработкой ошибок. Если вы не укажите, где, как и какой текст сообщения должен выдаваться при ошибке, то рискуете сделать сюрприз клиенту, когда при возникновении ошибки (а они имеют наглость проявляться только у клиентов) выдастся что-то типа «Ошибка –22348745. Объект DS234 был убит диспетчером системы».

Можно предугадать вопрос о том, зачем столь детально описывать спецификацию, если потом придется менять? Менять придется все равно и не раз и не два, а постоянно пока живет проект. Я не знаю еще проекта, который бы написали с одного раза, и больше не меняли и не исправляли.

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

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

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

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

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

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

Как надо писать функциональную спецификацию.

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

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

Для лучшего понимания работы проекта спецификация может содержать следующие разделы:

-         назначение приложения;

-         сценарии использования приложения;

-         схема работы приложения;

-         описание приложения. Это детали, детали и еще раз детали.

Для разработки документации мы используем Word.

Раздел «назначение приложения» используется для указания, что вообще такое мы хотим разработать.

«Сценарии использования приложения» применимы в основном для небольших проектов, где всего 1-4 основных функций, а остальные вспомогательные. Надо обладать определенным воображением, что бы суметь представить, как вашим проектом будет работать обычный пользователь. К примеру: некоторое время назад у одного из провайдеров сотовой связи были очень большие и массивные телефонные трубки, которыми можно было в полевых условиях колоть грецкие орехи. Чем не способ применения! Полагаю, что производитель такой «трубки» представлял себе немного иное применение.

«Описание приложения» это главная часть спецификации, которая включает в себя схемы, копии экранов, и само описание экранных форм.

В основном мы используем схемы, что бы показать структуру проекта и переходы между экранными формами. Далее идет так называемая «Screen by Screen» спецификация. Т.е. это описание всех экранных форм приложения.

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

Описание элементов формы содержит информацию о том, что за элементы находятся на форме и какие ограничения к ним применимы. Например: выпадающий список должен содержать список стран отсортированных по возрастанию. Текстовое поле для ввода номера телефона, формат ХХХ-ХХХ-ХХХХ, длина поля – 12 символов, разрешен ввод только чисел и знака «-». И т.п.

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

В конце идет описание функционала. Т.е. какая операция, какие проверки за собой влечет, и как при этом обрабатываются ошибки, текст ошибок и собственно результат функции.

Моя спецификация построена как гипертекстовый документ. В основном ссылки делаются на экранные формы и отчеты. К примеру, если в документе идет описание типа «при нажатии на кнопку «Preview» открывается окно просмотра», то «окно просмотра» - это ссылка на раздел где эта экранная форма описана. Это делает спецификацию крайне удобной для чтения и работы с ней.

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

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

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

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

Т.е. сделав поиск по ключевым фразам в ворде вы получаете все вопросы, которые касаются тех или иных специалистов.

На стадии начальной разработки проекта моя спецификация усыпана комментариями вида [open issue], которые направлены клиентам. И каждый раз, получив новую версию спецификации клиенты, не перечитывая ее, делают поиск по ключу [open issue] и прямо в документе дают ответы поставленные им вопросы и возвращают обратно.

Реальная разработка не начинается пока существуют не отвеченные и не разрешенные важные [open issue]. Как показывает практика лучше все вопросы закрыть до момента программирования иначе программировать можно очень долго и что самое обидное что пока [open issue] не закрыты, то всегда есть большой шанс начать переписывать алгоритмы, а то и модули с самого начала.

Поэтому мы делает столько итераций, сколько необходимо, что бы закрыть все важные [open issue]. В одном из проектов, количество таких итераций доходило до нескольких десятков раз.

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

Использование раздела с версиями позволяет просмотреть историю внесения изменений, особенно когда надо решить, когда и что было изменено. Кем это уже второй вопрос.

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

Если вы считаете, что для успешной разработки достаточно просто выпустить первую версию спецификации, а потом забыть о ней, то вы ошибаетесь. Спецификация должна постоянно обновляться и содержать самые лучшие решения по реализации проекта вашей командой.

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

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

Далее я постараюсь описать сам процесс работы со спецификацией и непосредственно процесс разработки проекта, планирование версий и сроки.

На вопрос «почему нельзя спецификацию класть в сейф» ответ прост. Как только вы ее туда положите, то сразу же придется увеличить количество коммуникаций между членами команды и сделать из менеджера проекта справочную.

С уважением,

Сергей

prj_management@list.ru