Шаблоны проектных предложений / требования [закрыто]

11

При составлении проектного предложения вы используете какой-либо стандартный шаблон?

Какие функции / информация должна быть включена? Что приятно включить? Какого рода информацию о плите котла я должен добавить?

Считаете ли вы какую-либо модель или концепцию дизайна особенно полезной?

Инкогнито
источник
Это внутреннее проектное предложение или предложение для клиента?
VirtuosiMedia
В общем, для клиента.
Инкогнито

Ответы:

5

Вы когда-нибудь смотрели на шаблон требований Volere ?

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

Они здесь:

ВОДИТЕЛИ ПРОЕКТА

  1. Цель продукта
  2. Клиент, клиент и другие заинтересованные стороны
  3. Пользователи Продукта

ПРОЕКТНЫЕ ОГРАНИЧЕНИЯ

  1. Обязательные ограничения
  2. Соглашения об именах и определения
  3. Соответствующие факты и предположения

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

  1. Объем работ
  2. Сфера применения продукта
  3. Функциональные требования и требования к данным

НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

  1. Требования к внешнему виду
  2. Требования к юзабилити
  3. Требования к производительности
  4. Операционные требования
  5. Требования к ремонтопригодности и мобильности
  6. Требования безопасности
  7. Культурно-политические требования
  8. Правовые требования

ПРОЕКТ ПРОБЛЕМЫ

  1. Открытые вопросы
  2. Готовые решения
  3. Новые проблемы
  4. Задания
  5. выработанных
  6. риски
  7. Расходы
  8. Пользовательская документация и обучение
  9. Зал ожидания
  10. Идеи для решений
Paddyslacker
источник
Ссылка на документ не работает
mclark1129
Похоже, они изменили свой сайт. Я обновлю ссылку.
Paddyslacker
3

Я использую стандартный шаблон? да

Какие функции / информация включена, приятно иметь:

  • Титульный лист
  • Метаданные: контактная информация клиента, контактная информация разработчика, название проекта, дата
  • Профиль клиента (необязательно, но хорошо): включает информацию о конкурентах, продукты или услуги, проданные клиентом, текущую ситуацию и цели, целевой рынок, положение на рынке. Средний малый бизнес не может обеспечить большинство из них.
  • Обзор проекта: включает детали в формате схемы. Здесь определяется работа проекта.
  • Не включено: Вещи, специально исключенные из проекта.
  • Исходные материалы: список вещей, необходимых клиенту для начала работы, а также даты, когда они требуются.
  • Карта сайта: необязательно, но хорошо, если вы работаете с веб-сайтом или сложным приложением. Хорошая графика.
  • Демография: конечного пользователя, обычно в форме красивой графики.
  • Creative Brief: необязательно. Это для дизайнеров и включает в себя такие вещи, как история общения, сообщение, индивидуальность и тон, аудитория (текущее мышление) и аудитория (возникающее мышление), веб-сайты конкурентов, примеры веб-сайтов или продуктов, предпочитаемых клиентом, цвета компании, руководство по стилю (обычно внешний). Он документирует существующие материалы, такие как логотипы, брошюры и т. Д.
  • Сроки проекта: разбивка того, когда все должно быть сделано с окончательной предполагаемой датой завершения. У моего шаблона есть большой отказ от ответственности, сроки которого сильно зависят от участия клиентов.
  • Распределение затрат: стоимость другой задачи, которая должна быть выполнена. Когда это возможно, этот раздел также включает анализ «возврата инвестиций».
  • Соглашение о проекте: условия оплаты, реальные деньги, 100% гарантия возврата денег, требуется одно контактное лицо, предоставляемые клиентом материалы и согласования должны быть своевременными, дополнительный биллинг или время, если клиент меняет объем работ, информацию о хостинге (для веб-сайтов) , право использовать произведение для саморекламы, применимые законы, заявление о владении исходным кодом, наличие условного депонирования программного обеспечения, подписи.
  • О нас: включает в себя информацию о компании с фотографиями, примеры нашей работы, отзывы, другие предлагаемые услуги, профиль команды с фотографиями.
  • Вывод: спасибо и контактная информация.

Котельная плита: как можно больше. У всего вышеперечисленного есть что-то, даже если это просто текст наполнителя. Эта статья оказала влияние на меня: http://articles.sitepoint.com/article/bulletproof-web-design-contract

Мои предложения обычно выходят с 14 до 20.

bogeymin
источник
2

Есть много разных способов сделать это.

Вот тот, который я нашел, и который я бы одобрил - он использует подход фрилансера, но на самом деле это то, чем вы хотите заниматься:

http://tutorialblog.org/writing-a-project-proposal/

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

Это НЕ заменяет план проекта, который может быть более сложным животным.

CokoBWare
источник
Не могли бы вы объяснить это более подробно - как и почему «одобренная статья» отвечает на заданный вопрос? «Ответы только на ссылки» не очень приветствуются на Stack Exchange
gnat
2

Когда дело доходит до шаблонов, я считаю шаблоны ReadySET довольно солидными. Эти шаблоны охватывают основные моменты жизненного цикла - планирование проекта, требования, проектирование, внедрение, тестирование, развертывание / установку, поддержку и завершение проекта.

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

Томас Оуэнс
источник
0

Министерство обороны США проделало большую работу по разработке полного набора описаний элементов данных (шаблонов) для DOD-STD-2167A , а затем для MIL-STD-498 .

Есть старая поговорка: «Военно-морские правила написаны кровью». Если вы внимательно прочитаете DID, вы, вероятно, придете к выводу, что каждая их строка написана кровью руководителей программ, чьи проекты погибли ужасной смертью, потому что они пренебрегали пунктом в этой строке.

Вы могли бы сделать хуже, если посмотреть на них.

Джон Р. Штром
источник