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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

Все это прекрасные книги. Я мог бы предложить также добавить "Требования к программному обеспечению 2" и "Peopleware: продуктивные проекты и команды" (я еще не читал Peopleware, это было в моем списке задач, я боюсь.)

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

По моему опыту, никогда не мешает попытаться разбить большую проблему на более мелкие проблемы. Итерация. Когда вы думаете, что наконец-то получили кусочки, которые будут принимать от 0,5 до 1 дня программиста, тогда вы достигнете точки, где у меня был лучший успех при оценке времени.

Конечно, вы должны иметь в виду, что программисты работают на вас: Алиса могла бы написать судоходное решение через полдня, Боб может занять день, и Чарли может занять два дня, чтобы добраться туда, через час от Боба для проверки кода. Знание сильных и слабых сторон вашего программиста также будет иметь опыт.