Как записать Анализ проекта или резюме проекта? [закрытый]

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

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

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

Итак, что вы должны включить:

• Общее описание того, что делается - всего пара абзацев. На самом деле он не будет предоставлять никаких деталей, но он задает сцену. Итак, в этом разделе вы говорите, что создаете сайт электронной коммерции для продажи виджетов, что это сайт B2C, а не B2B, что проект охватывает полный дизайн и сборку сайта и так далее.Не более пары абзацев.

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

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

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

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

Другие разделы, которые я бы рассмотрел, в том числе:

• Техническая платформа - если вы считаете важным описать техническую платформу на высоком уровне (в данном случае LAMP плюс любые другие элементы). По моему опыту, это не та область, где действительно возникает кредо прицела, но обычно на это уходит две минуты, чтобы не повредить.

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

• Зависимости - Опять же, это часть того, что находится вне вашего контроля.Если в проекте участвуют и другие стороны (включая клиента), лучше всего перечислить, чего вы от них ожидаете. Кто предоставляет копию, в каком формате (это красиво структурированный файл Excel, который можно легко импортировать, или миллион документов Word)? А как насчет тестовой системы для стороннего приложения, с которым вы должны взаимодействовать? Когда тебе это нужно?

Надеюсь, это поможет.

Edit: Я откопал и немного анонимизировал пару шаблонов, которые использовал в моей последней работе. Они внутренние (то есть мы были внутренней командой, выполняющей работу внутри компании, а не командой, выполняющей работу для других организаций), но структура и принципы остались прежними.

Я включил шаблон мандата проекта, который довольно близок к тому документу, который вам нужен:

http://seventeensix.tumblr.com/post/749062608/a-sample-project-mandate-template

и шаблон спецификации, который также может содержать некоторые полезные элементы:

http://seventeensix.tumblr.com/post/749077647/a-sample-specification-template

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