项目投标模板/要求[关闭]


11

在起草项目建议书时,您是否使用任何标准模板?

应该包括哪些功能/信息?有什么好包含的?我应该输入哪种样板信息?

您发现任何设计模式或概念特别有用吗?


这是内部项目建议还是针对客户的建议?
VirtuosiMedia

一般来说,对于一个客户。
隐身

Answers:


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. 解决方案的想法

该文档的链接已断开
mclark1129 2011年

看起来他们改变了他们的网站。我将更新参考。
Paddyslacker 2011年

3

我是否使用标准模板?是

包含哪些功能/信息,很高兴拥有:

  • 封面纸
  • 元数据:客户联系信息,开发人员联系信息,项目名称,日期
  • 客户资料(可选,但不错):包括竞争对手信息,客户出售的产品或服务,当前状况和目标,目标市场,市场地位。一般的小型企业无法提供其中的大多数。
  • 项目概述:包括大纲格式的详细信息。这是定义项目工作的地方。
  • 不包括:项目中明确省略的内容。
  • 初始材料:客户需要入门的清单以及所需的日期。
  • 站点地图:可选,但是如果您正在处理网站或复杂的应用程序,则很好。漂亮的图形。
  • 受众特征:最终用户中的受众特征,通常以精美的图形形式出现。
  • 广告简介:可选。这是针对设计师的,包括沟通历史,消息,个性和语气,受众(当前思维定式)和受众(结果思维定式),竞争对手的网站,受客户青睐的示例网站或产品,公司颜色,样式指南(通常是外部)。它记录了徽标,小册子等现有材料。
  • 项目时间表:在何时完成工作以及最终估计的完成日期的明细。我的模板有一个很大的免责声明,即时间表很大程度上取决于客户的参与。
  • 成本明细:要执行的不同任务的成本。如果可能,本节还包括“投资回报率”分析。
  • 项目协议:付款条款,保证金,100%退款保证,需要单点联系,客户提供的材料和批准需要及时,额外的账单或时间(如果客户改变工作范围,托管信息(用于网站)) ,使用该作品进行自我宣传的权利,适用的法律,源代码所有权声明,软件托管的可用性,签名。
  • 关于我们:包括带照片的公司信息,我们的工作示例,推荐,其他服务以及带照片的团队简介。
  • 结论:谢谢您和联系方式。

锅炉板:尽可能多。以上所有内容都具有某些内容,即使只是填充文字也是如此。这篇文章对我有影响:http : //articles.sitepoint.com/article/bulletproof-web-design-contract

我的建议通常是14到20。


2

有许多不同的方法可以做到这一点。

这是我发现我会认可的一种-它具有自由职业者的方法,但这确实是您想要做的:

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

在线上有很多指南。诀窍是要知道哪一个适合您的需求。我在这东西上教了一堂课。我认可的文章似乎确实是客户想要什么以及应该如何吸引您的本质。

这不能代替项目计划,而项目计划可以完全是更复杂的动物。


您介意对此进行更详细的解释-“认可的文章”如何以及为什么回答所提出的问题?在Stack Exchange上不太欢迎“仅链接的答案”
gnat 2013年

2

关于模板,我发现ReadySET模板非常可靠。这些模板涵盖了主要的生命周期点-项目计划,需求,设计,实施,测试,部署/安装,支持和项目定稿。

但是要记住的一点是,应该修改模板以适合项目和流程。很少有人会从书本或Internet上提取模板并使用它。我发现模板对于确定每个阶段的某个地方应该包含哪些信息最有用,并且可以让项目确定如何以及在何处捕获信息。


0

美国国防部在开发全套数据项说明(模板),DOD-STD-2167A和后来的MIL-STD-498方面投入了大量工作。

有句老话:“海军法规是用鲜血书写的。” 如果仔细阅读DID,您可能会发现它们的每一行都被程序经理的鲜血所写,由于他们忽略了该行中的项目,他们的项目惨死了。

调查这些可能会更糟。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.