Шаблони / вимоги проектних пропозицій [закрито]

Під час складання проектної пропозиції ви використовуєте будь-який стандартний шаблон?

Які функції / інформацію слід включити? Що приємно включити? Яку інформацію про плиту котла я повинен засунути?

Чи вважаєте ви будь-яку модель дизайну чи концепцію особливо корисною?

Ви коли-небудь переглядали шаблон вимог до Volere ?

Хоча вона містить трохи занадто багато деталей на мій смак, особливо для пропозиції (вона краще підходить для детальної специфікації вимог передньої частини), заголовки розділів є чудовим контрольним списком, щоб переконатися, що ви думали про всі різні рухомі частини раніше надання кошторису або створення документа пропозиції.

Ось вони:

Драйвери для проектів

1. Призначення виробу
2. Клієнт, Замовник та інші зацікавлені сторони
3. Користувачі Продукту

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

1. Обмежені обмеженнями
2. Названня конвенцій та визначень
3. Релевантні факти та припущення

ФУНКЦІОНАЛЬНІ ВИМОГИ

1. Сфера роботи
2. Сфера застосування продукту
3. Функціональні вимоги та вимоги до даних

НЕФУНКЦІЙНІ ВИМОГИ

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

ПРОЕКТНІ ПРОБЛЕМИ

1. Відкриті випуски
2. Позаставні рішення
3. Нові проблеми
4. Завдання
5. Cutover
6. Ризики
7. Витрати
8. Документація та навчання користувачів
9. Зал очікування
10. Ідеї ​​для рішень

Чи використовую я стандартний шаблон? Так

Які функції / інформація включена, приємно мати:

• Обшивальний лист
• Метадані: контактна інформація замовника, контактна інформація розробника, назва проекту, дата
• Профіль клієнта (необов’язково, але добре): включає інформацію про конкурента, продукти чи послуги, продані замовником, поточну ситуацію та цілі, цільовий ринок, позицію на ринку. Середній малий бізнес не може забезпечити більшість із них.
• Огляд проекту: включає деталі у форматному форматі. Тут визначається робота над проектом.
• Не входить: Речі, конкретно пропущені в проекті.
• Початкові матеріали: Список речей, необхідних замовнику для початку роботи, а також дати, які вони вимагають.
• Карта сайту: необов’язково, але добре, якщо ви робите веб-сайт або складну програму. Гарна графіка.
• Демографічні показники: кінцевого користувача, як правило, у вигляді приємної графіки.
• Творча резюме: Необов’язково. Він призначений для дизайнерів і включає такі речі, як історія спілкування, повідомлення, особистість і тон, аудиторія (поточний набір розуму) та аудиторія (результуючий набір розуму), веб-сайти конкурентів, приклади веб-сайтів або товарів, які надають перевагу замовнику, кольори компанії, посібник зі стилів (як правило, зовнішній). Він документує наявні матеріали, такі як логотипи, брошури тощо.
• Хронологія проекту: Розбиття, коли слід виконати роботу з кінцевою передбачуваною датою завершення. У моєму шаблоні є велика відмова від жиру, що терміни сильно залежать від участі клієнтів.
• Розбиття витрат: вартість різних завдань, які необхідно виконати. Коли це можливо, цей розділ також включає аналіз "рентабельності інвестицій".
• Проектна угода: Умови оплати, зароблені гроші, 100% гарантія повернення грошей, потрібна єдина контактна точка, матеріали та погодження, що надаються клієнтом, повинні бути своєчасними, додатково виставляти рахунки або час, якщо клієнт змінює обсяг роботи, інформацію про розміщення (для веб-сайтів) , право використовувати твір для самореклами, діючих законів, заяви про право власності на вихідний код, наявності програмного забезпечення, підписів.
• Про нас: Включає інформацію про компанію з фотографіями, прикладами нашої роботи, відгуками, іншими послугами, що пропонуються, профіль команди з фотографіями.
• Висновок: Дякую та контактну інформацію.

Плити котла: якомога більше. У всьому вищесказаному є щось, навіть якщо це лише текст заповнення. Ця стаття була для мене впливовою: http://articles.sitepoint.com/article/bulletproof-web-design-contract

Мої пропозиції зазвичай виходять з 14 до 20.

Існує багато різних способів зробити це.

Ось я знайшов, що я схвалюю - він має підхід до фрілансера, але насправді це те, що ви хочете робити:

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

В Інтернеті є багато путівників. Хитрість полягає в тому, щоб знати, який з них відповідає вашим потребам. Я викладав клас з цього матеріалу. Моя схвалена стаття, здається, є сутністю того, чого хочуть клієнти, і що повинно вам зайти у двері.

Це НЕ замінює проектного плану, який може бути цілком витонченою твариною цілком.

Що стосується шаблонів, я вважаю, що шаблони ReadySET є досить міцними. Ці шаблони охоплюють основні моменти життєвого циклу - планування проекту, вимоги, проектування, впровадження, тестування, розгортання / встановлення, підтримка та завершення проекту.

Однак слід пам’ятати, що шаблони повинні бути змінені відповідно до проекту та процесів. Дуже рідко можна просто спустити шаблон із книги чи Інтернету та користуватися ним. Я вважаю шаблони найбільш корисними для визначення того, яку інформацію я повинен мати десь на кожному етапі, і нехай проект визначає, як і де збирається інформація.

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

Є стара приказка: "Правила ВМС написані кров'ю". Якщо ви уважно прочитаєте DID, ви, швидше за все, зрозумієте, що кожен рядок із них написаний кров'ю керівників програм, проекти яких загинули жахливою смертю, оскільки вони знехтували цим елементом у цьому рядку.

Ви могли б зробити гірше, що загляньте в це.