Как написать анализ проекта или краткое описание проекта?

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

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

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

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

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

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

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

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

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

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

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

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

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

надеюсь, что это помогает.

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

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

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

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

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

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