如何编写软件开发建议

如何编写成功的软件开发建议。

凯文·朗格多克

软件开发建议书的目的是传达一种解决方案，以供业务人员阅读，因此请使其简洁明了。尽可能远离技术术语。以下概述可以按原样使用，以准备成功的软件开发建议。重要的是要记住，您要提出建议的人员没有太多时间阅读冗长的文档。您可以从我这里得到帮助，在过去20多年的信息技术领域中，我已经写了数百份建议：商务人士只需要足够的信息就可以做出明智的决定。

如果您正在响应投标请求（RFP）并且必须遵守一定的页面范围，因为页面是预先打印的，或者内容要求迫使您提出的建议太长，请考虑使用执行摘要。我在下面添加了概述如何准备的部分。

提案长度

我看过一些模板和讨论，它们提倡可以持续50或一页的提案。相信我，您将在第五页之后失去业务主管的兴趣。提案一旦被接受，设计文档自然将更加详细，因为它们将发给项目团队，并将成为系统的工作蓝图。这将适用于大多数客户，但是（是的，总是有，但是）如果提案是对提案请求（RFP）的回应，那么您必须遵守RFP。此外，政府或军事机构可能会对如何准备软件开发建议书具有严格的指导原则，并且可能会根据系统的复杂性而包含几页（10、20、30、50或更多）。对于可能具有正式提议流程的大型组织，尤其是如果它们是上市公司且必须遵守任何Sarbannes-Oxley或ISO法规或标准的大型组织，此规则仍然适用。

执行摘要

如果提案超过20页，那么您可以考虑提供一份执行摘要，该摘要是提案中各部分的一页。您甚至可以PowerPoint格式提供执行摘要。如果您打算在软件开发提案演示文稿中使用执行摘要，请使用执行摘要来介绍提案，而执行董事可以在以后的某个时刻（例如在商务飞行中）通读该提案。

模板

以下概述实际上是一个很好的模板，可用于准备自己的软件开发建议。在准备提案时，我始终牢记“电梯音高”规则，您也应该如此。基本上，“电梯音高”规定，您的提案应不超过在提交提案的过程中将电梯从一楼的电梯带到建筑物的顶层所需的时间。

项目名称

附有建议书的字幕或摘要信息

提案应具有标题和小节，以概括软件提案的上下文。您还包括该项目打算使用的部门，服务，部门或组织的名称。

如果您要回应RFP（征求建议书），请在RFP中包括所有必需的或必须列出的信息。我还看到RFP要求在首页上添加标题之外的批准签名，但是在本示例中，我将签名放在带有“更改”部分的页面上。

批准书

无论是对RFP的响应，还是来自此模板的响应，还是来自其他来源的响应，本节均对该过程至关重要。本节记录对项目进行的确认，并在项目的各个成员之间提供具有约束力的协议。在获得所有必要的签名并获得项目负责人和利益相关者的承诺后，您才可以开始项目。否则，如果项目被取消，或者项目的范围更改或可交付成果，您可能会陷入困境。

有了批准书，范围和可交付成果的更改就变得更加困难，并且如果有争议，签署批准书将使人们对所达成的协议有更清晰的理解。当然，总会有解释的问题。

批准书应包括该人的姓名，职务，签名，最后是文件签署的日期。



名称	头衔/角色	签名	日期

变化

更改部分提供了对软件开发建议文档已进行或将要进行的所有更改的日志。它没有记录对项目本身或项目其他方面的任何更改。更改部分至少应包括进行更改的人员的姓名，更改日期以及更改的评论或说明。



作者	变更日期	说明或评论

词汇表和首字母缩写词

列出任何术语或首字母缩写词及其定义。不要以为每个人都知道术语或首字母缩写词的含义，尤其是当您计划使用外部顾问并且术语是内部的，嵌入在您的企业文化和术语中时。每个组织都有自己的术语和缩写。只要正确记录它们，就可以在提案中使用它们。

同样，如果使用了任何特定于行业的首字母缩写词，则也需要对其进行记录，以使每个人都对术语和首字母缩写词的含义有清楚的了解，并制定更好的解释。

以下缩写来自当前模板。提供它们作为示例。

RFP：征求建议书
投资回报率：投资回报率
CAGR：复合年增长率
IT：信息技术
资本支出：资本支出
UoM：计量单位

范围

提案的范围应从总体上概括项目的总体细节，包括和排除哪些内容。范围应提供总体描述，项目期限，主要目标。您打算用这项对拟议软件开发项目的投资来完成什么。

时间线

本部分将包括开始和结束日期（估计）。确保建立缓冲区并计划突发事件。一个好的经验法则是为时间轴添加75％的缓冲区。

项目成员

项目成员应包括项目负责人和利益相关者。拥护者通常是执行整个项目和预算的高管。利益相关者通常是内部发起人或发起人。根据项目范围或请求软件开发建议的组织类型，他们也可以是冠军。其余列表包含人们在项目中执行的典型角色。

以下内容仅作为项目参与者可能具有的角色类型的示例提供。有些人可能扮演多个角色。根据项目的范围，项目成员列表可能会很长，或者同一个人可能扮演不同的角色。

该列表应包含能够正确识别人员，他们在项目中的角色，如何联系他们以及他们的职责是什么的任何信息。您可以包括其他信息，具体取决于RFP或将与之合作的组织类型及其内部策略。



队员	角色	联系信息	职责范围
	冠军
	利益相关者
	专案经理
	建筑师
	分析员
	开发者

商业机遇

大多数可用模板将本节定义为“业务问题”或“问题说明”，但是我经常遇到业务领导者，他们冒犯了他们的业务部门或流程存在问题的事实。我记得一位董事从字面上把我赶出了办公室，因为我曾说过我们正在修复一个流程，而她告诉我，不是IT（信息技术）来决定她是否有问题的人。与她的过程或没有。

因此，请谨慎使用措辞。我总是使用“商机”一词，因为最终，该提案是对改进流程，支持流程或使流程自动化的商业机会的回应



商业声明	系统将如何满足要求
受影响的业务流程，情况，问题	拟议的解决方案将如何改善目标业务领域
正在解决什么需求	当前项目将如何解决

解决方案概述

在解决方案概述部分中，您可以提供系统的高级概述。如果建议是针对网站或Web应用程序的，则此概述可以包括导航图。您还可以包括处理流程的流程图。另外，您可以包括系统主要组件的图表。

这里的目的是给做出决定的人足够的信息，以便他们了解系统的本质，系统如何工作以及主要的构成部分。当然，这仅是一个准则，因为组织可能具有正式格式，该格式定义了您需要在提案中提出的内容，特别是在与政府机构或国防部打交道时。

功能和可交付成果

本节提供了一种机制，可将建议的系统功能映射到有形的可交付成果。我也看到了此部分包含完成交付的时间估计，但是我不喜欢使用它，因为它过于严格并且会造成束缚。在项目上工作时，交付的内容可能不完全与书面记录一致，因此，如果您在纸面上承诺在一定时间之前完成交付，那么稍后在实际执行项目时，它会消除或减少任何弹性。

可以添加的另一列是可交付成果所属的发布。如果项目将在更长的时间内交付，并且会有多个版本，这将很方便。这也可以应用于基于敏捷或精益的项目，其中每个功能或用户案例都属于发行版。

这个概念很简单；对于系统中的每个功能，请提供功能名称，简短说明以及哪些可交付项将满足功能要求。



特征	描述	可交付成果

预算和投资回报率

对于某些主管来说，预算和投资回报率可能是最重要的部分。他们都渴望知道系统将花费多少，或者这个项目将对他们部门的预算产生多大的影响。如果该项目在会计年度开始时未包含在资本支出中，则尤其如此。

有时，即使该项目已预算，其他项目也可能会优先于当前提案，并且资金可能会从其预定来源中挪用。为了使一个项目起步，通常在行政和管理层面上会发生一些政治争执，而且往往有不可预见的情况可能会优先于计划中的项目。

因此，准备好与您的利益相关者合作，以帮助进行谈判，或者在预算状况不平衡时灵活主动地提供可行的解决方案。最好使项目适应预算实际情况，甚至将系统可交付成果分散在更长的时间范围内，甚至远离项目。相较于从事一个项目，没有得到报酬并且不得不诉诸诉讼，走开要好得多。

下表仅用于演示目的，目的是使您了解如何准备预算。当然，您将需要添加自己的订单项以适合您的项目。然后填写数量，单价，计量单位和行项目总计。然后在底部汇总订单项总计。

这样可以很好地了解进行软件项目所需的投资。与我合作过的大多数高管都想知道随着时间的推移收益率或该项目的成本，因此，我还使用自己的估计和假设（包括必须是说明中）或使用随附的估算值和假设。



项目项目	量	单价	单位	总
软件许可
机器
服务器许可证
数据库许可证
发展顾问
项目管理
培训（时间+材料）

ROI

ROI的计算非常简单。基本上，公式是收益-成本除以成本。公式如下：

唯一的缺点是计算没有考虑时间，因此ROI对于短期项目而言是不错的选择，但对于长期项目而言，我通常包括CAGR（复合年增长率）。CAGR计算是在特定时间段内的逐年回报率。

复合年增长率

CAGR公式为：

第一部分是最终值除以起始值。在投资的年数中，结果将提高到1的幂。结果值减去1。

好处

在本部分中，您列出了软件项目将提供的业务收益。只要符合整体目标，就可以以项目符号格式列出它们。他们应演示软件或系统将如何提高业务价值。

简而言之，所提出的解决方案将如何帮助企业更加成功并实现其声明目标？使用正面的单词和句子。

约束条件

约束部分应列出您可以预见的任何有形和无形约束。例如，这可能与设备和某些季节性因素有关，例如生产工厂关闭，大多数工厂每年至少执行一次。

尝试淡化这些约束或将其描绘为最小。不要列出软件或系统的负面影响，也可以列出解决方法。