2 сентября 2008
Небольшой проект, например, сайт из двух статичных страниц можно сделать без проектной документации и итог будет положительным в одном из N случаев. Сложные проекты всегда требуют тщательных и продуманных описаний, схем и диаграмм. Причин этому масса: начиная от того, что над проектом может работать несколько человек и им необходимо понимать друг друга и, заканчивая тем, что проект иногда разрабатывается в течение нескольких месяцев и даже лет, удержать в голове тысячи задач, в таком случае, невозможно.
Прежде чем поговорить о том, из чего же может состоять проектная документация, вот несколько правильных мыслей:
Я пытался составить наиболее полный список всего, что может входить в проектную документацию. Он, вполне дополняем и изменяем, ведь все зависит от конкретного случая, иногда требуются весьма специфические материалы, а иногда достаточно хорошо сформулированной идеи в одно предложение.
Этот список сделан специально для проектирования сайтов, интерфейсов и программ, но в других сферах, например, в строительстве, он почти такой же.
Словарь психологии нам дает такое определение: идея — самовоплощающаяся мысль; представление, наделенное силой действия.
Чем короче описана идея и концепция, тем понятнее и доступнее она будет, для всех кто участвует в проекте. Концепция вполне может быть в одно-два емких предложения. Это хороший и быстрый старт без пробуксовывания и потерь времени. Емкая короткая идея — это динамика проекта, его эмоции, настрой. Нудятина и академичность на двадцати страницах, наверняка не вдохновит разработчиков.
Структурированный список всех экранов проекта, сайта или программы. Роль этого документа подобна карте навигации для корабля. Как составим — туда и поплывем.
Составление карты — это повод провести совещание и мозговой штурм. Многие нюансы всплывут, участники проекта получат предварительное представление. Карта позволит определить начало и конец проекта, и даже приблизительный объем работы для опытного разработчика.
Идеально, если карта будет составлена так, чтобы в дальнейшем она оставалась неизменной. Это путь, указывающий направление движения, если маршрут меняется, то это затрагивает практически все остальные составляющие.
Это одна из самых интересных задач, она творческая и похожа на сотворение мира. Мы берем чистый лист и по частице складываем на нем конструкцию. Из множества элементов рождается целое.
Проиллюстрирую на примере сайта из трех страниц:
В составлении подобного описания важна каждая мелочь и деталь, чем тщательнее все будет описано, тем понятнее это будет разработчикам. Можно и даже нужно описывать все элементы и блоки с примерными размерами, местом расположения на экране и так далее. Это принесет результат. Дизайнер, получив документ, сделает макет без единого вопроса в точности как вы и задумали. Поразительно!
Это проверочный список, который позволит контролировать разработку, смотреть все ли учтено и сделано в итоге. Иногда, при хороших описаниях сценариев использования, карты проекта и других материалов, описание возможностей лишь маркетинговый шаг.
Но, тем не менее, для качественного проекта это необходимый минимум, для длительного проекта критическое условие.
Для примера, представим, что нам нужно сделать программу календарь, вот какой список возможностей может получиться:
Для небольшой программы достаточно. В реальности, особенно в больших проектах список, конечно, не так прост и мал. Более того, в таких проектах список возможностей необходимо структурировать по степени приоритетности, сложности, объему работы.
Сценарии использования — это способ представить, как проект будет работать. Некая фантазия. Поэтому не стоит серьезно увлекаться. Тем более, что в сценариях нельзя учесть все действия и как-то стандартно все описать, учтя все возможные случаи использования. Это будет ошибкой. Всегда найдется такой пользователь, который будет использовать проект, совсем не так как вы задумывали, а может даже таких пользователей будет большинство. Так что важна в первую очередь логика и последовательность, а не конкретика и частные случаи.
Я придерживаюсь того, чтобы в сценариях пользователь был безымянен и неодушевлен, это помогает не думать о нем, а думать о более важных и концептуальных вещах. Например, не думать о том, что кто-то перед тем как использовать чашку отламывает ручку и пьет чай без нее, а думать о том, как сделать ручку чашки удобной для максимального или определенного круга людей. Надеюсь, мысль понятна. Мы просто определяем, что чашкой нужно пользоваться в таком порядке и таким-то образом ее держать. Это наша концепция.
Так же нет особого смысла составлять сценарии абсолютно для всех функций проекта. Как правило, из других проектных материалов, многие действия пользователя будут очевидны. А вот для сложных моментов, для действий, которые проходят в десятки шагов, разветвляясь на уровни — это необходимо.
Не стоит также пренебрегать сценариями, если есть уже визуализированный интерфейс и кажется, что он дает полное представление. По крайней мере, визуализация не всегда отражает работу разных групп людей, допустим тех, кто впервые пользуется, тех, кто пользуется во второй раз и тех, кто пользуется многократно.
Сценарии использования помогут выделить приоритеты, контрасты и расставить элементы и блоки в правильном и нужном логическом и последовательном порядке. Это и есть цель сценариев, они должны отвечать на вопрос: «Как это работает?», а не «Из чего и как это сделано?». Так что если в процессе составления сценариев вы начинаете добавлять новые функции и возможности, то что-то не так было сделано на предыдущих этапах проектирования.
План работы отвечает на вопрос: «Кто, что и сколько будет делать?». В плане работы необходимо учесть все этапы проекта, его разработки и последующих стадий. Для каждого этапа рассчитывается срок работы, назначается исполнитель.
В итоге, план поможет понять:
План тестирования пересекается с планом работы, точнее это часть плана работы. В нем подробно описываются последовательности тестов и действий.
Цель такого плана сделать тестирование наиболее эффективным и осознанным. Проектировщик знает о сложных и спорных местах проекта, и именно он должен правильно указать на это тестировщику.
Составление сметы — это задача менеджера проекта, в сотрудничестве с проектировщиком. Менеджер спрашивает: «Сколько программистов необходимо для разработки?». Проектировщик смотрит на описание функций проекта, на план работы и говорит: «Два». Менеджер вычисляет расходы на зарплату и прочие расходы.
Эскиз можно делать на бумаге, на компьютере — где угодно. Важны лишь такие моменты:
Примеры:
Диаграммы нужно делать для всего, всегда и везде. Например, если библиотеки программы написать не списком, а составить диаграмму с зависимостями и другими подробностями — это будет в сотни раз эффективнее и нагляднее. Тоже касается структуры сайта, архитектуры программного ядра, последовательности действий программы, алгоритмов и прочего.
Аккуратная и эстетически приятная диаграмма вдвойне хороша. Но не стоит увлекаться. Иногда черно-белая блок-схема из типичных и стандартизированных блоков, оказывается более читаема, чем красивый и разветвленный Mind Map.
Чтобы не быть себе врагом и не усложнять жизнь тем, что призвано наоборот ее упростить, стоит определить для себя некоторый набор правил, например:
Составление структуры базы данных требует специальных знаний, поэтому лучше всего, если работа над ней ведется совместно с программистом или со специалистом баз данных. В этом случае можно построить грамотную, гибкую и расширяемую структуру, которая будет удовлетворять всем требованиям, и решать нужные задачи. Такая структура может быть составлена в специализированной программе и потом сразу же перенесена в реальную базу данных, без каких-либо правок.
Если на стадии составления структуры базы данных невозможно привлечь специалиста, то можно обозначить, лишь значимые таблицы, их поля и связи. Непосредственно то, что является концептуальным и составляет основу проекта и его ключевых решений.
UML схемы неоднозначный вид документации. С одной стороны они действительно помогают понять работу, например, отдельного класса программы, но с другой стороны они недостаточны. Некоторые методы класса могут потребовать расширенного пояснения, а сам класс объяснение принципов работы. Поэтому хороший вариант: одновременно с UML писать документацию API. В самой схеме лишь обозначить связи, зависимости, не увлекаясь подробностями и усложнениями.
Цель UML схем продумать и поставить задачу для программиста. Показать, как это должно быть реализовано и как должно работать в теории.
Задача проектировщика вместе с техническими специалистами определить требования нагрузки проекта, требования к ресурсам, операционным системам и к прочим техническим моментам. Это поможет скорректировать и правильно спланировать функциональность, использование и развитие проекта.
Два этих документа большая редкость. На стадии проектирования и даже после разработки проекта мало кто задумывается о том, что же будет дальше. Между тем еще до активной разработки необходимо понимать, в какую сторону и как будет развиваться проект.
В первую очередь нас должна интересовать техническая сторона развития. Поэтому в документе развития нужно выписать, какие функции будут изменяться, например:
Документ поддержки описывает, каким образом и в какие сроки будут осуществляться ремонтные работы, работы по обслуживанию проекта.
Данная статья не преследует цель рассказать, как составлять ту или иную документацию. Цель — наиболее полно показать возможный список документов. Также напомню, что для конкретного проекта список может быть иным. Все зависит от задач, сложности и объема работ.
