夜雨聆风软件的产品项目指的是新开发一个软件，而不是拿已有的软件交付给客户只做简单的修改。
通用的方法大致分为七个阶段，采用的是“瀑布式管理模式”，指的是从计划到完成计划的过程严格前后对应，从开始就是清晰明确的。
还有一种是“敏捷式管理模式”，敏捷管理模式通常是“渐进明细”的管理，即需求在开始并不会那么清晰，在不断的开发和沟通中才渐渐明确。但是每个确定需求和完成需求的子过程也可以视为“小瀑布”。即，瀑布式管理可以视为理解敏捷式管理的基础。
也有分为六个阶段或者八个阶段，其实是将部分阶段进行合并，内容略有不同。每个阶段的输出和下个阶段的输入是一致的。所以分几个阶段并不重要，重要的是其按照输入输出时间顺序所完成的逻辑。
如下做介绍。
第一个阶段：项目立项阶段。
这个阶段的主要任务是完成项目的任务书。包含项目的范围，成本，进度的确认。
输出文档：
《项目任务书》。核心是描述开发的目的。 需要时，应保留项目发起人的沟通记录，以保证项目目的与发起人的意向一致。
《项目开发计划》。描述项目范围，进度，成本，资源等。
《软件质量保证计划》。包含质量目标，评审计划，测试策略，质量记录的要求等。
《风险管理计划》。当发生某些预测的风险和非预测的风险的应对措施。
《保密计划》。相关的保密要求和管理。
《软件管理计划》。包含变更管理，版本管理，基线管理等管理的要求。
有些文档可以合并，例如《项目任务书》和《项目开发计划》。或者采用通用的文档，稍微修改部分内容，例如《软件质量保证计划》，《软件管理计划》等。
第二个阶段：需求调研阶段。
这个阶段的主要任务是完成项目的蓝图。但是宏观的方案的描述。
输出文档：
《方案蓝图说明》。基于软件产品的整体的解决方案和架构的说明。
《需求规格说明》。具体的需求和目标需要明确。
《系统/子系统的规格说明》，必需的。整体的规格和子系统的规格，即基于需求和目标所使用的方案需要明确。
《接口需求说明》，必需的。对于外部的系统的数据交换的说明，也是包含在需求和目标的范围内的。
往往在蓝图说明的时候，会把以上所有的内容都进行说明。有时是合并到一个文档中。
如果在给客户的《SOW》中，以上第一阶段和第二阶段都是要包含的。即可以合并成一个技术文档。内部的可以进行适当的简化。
第三个阶段：产品设计阶段。
基于软件开发的角度，输出必需的文档。
输出文档：
《系统/子系统设计说明书》。一般由产品经理负责编写，对设计做完整的说明。每一个公司的模板会有不同。设计说明书往往是按照模块进行编写，包含了目的，业务流，数据流，功能页面清单，画面原型，数据表结构，数据载入和功能按钮等等。核心目的是给开发人员的，只要开发人员认为可以执行即可。如果需要对客户，那么相关的技术人员认为可以执行即可。
《业务流说明》。按照客户的实际需求实现的业务流转的说明。这部分需要总体做一个宏观的串联，然后每个子系统再放入设计说明书中。
《数据流说明》。按照业务流的目的，同时基于软件特性，对数据流转进行整体的描述。通常这部分根据能力，由产品经理或者开发负责人或者架构师完成。 《产品原型》。即模拟产品最终画面所呈现的样式，这部分有动态和静态之分，有高保真和一般之分。最佳的是高保真的动态原型，几乎和系统一模一样。在设计原型前，公司需要有一个固定的原型设计的标准组件库和准则。包含每个页面的复杂程度的限定。
《接口文档》。即所有接口的清单和协议方案，出参和入参，问题处理等。然后每个接口建议都集中存档。
《数据库设计说明》，或者称为表结构。包含所有字段的设计。在设计数据库前，公司需要有一个固定的设计准则，否则会导致很多的BUG。
本阶段的所有设计，几乎都需要有相关的规范文档作为设计准则。
同时基于产品经理和开发负责人的能力进行工作分配等等。
如果是敏捷式管理，以上的文档并不需要一次性产出。当然即使是瀑布式管理，也是允许变更。
第四个阶段：单元开发与测试阶段。
按照设计实现每个单元的开发与测试。
输出文档。
《代码编写规范》，其实也可以理解这个为输入文档。在每个开发人员进行代码编写之前都需要进行培训，包含环境的载入，包含分成几个单元开发，如何上传，版本的管理等等。都需要进行定义。
《代码注解》，这部分是代码编写规范下的实际代码的注解。
《单元测试计划》，可以理解为质量相关的要求。如何保证软件符合质量所实施的计划。
《单元测试说明》，包含测试用例，测试方法，测试步骤等等。
《单元测试报告》，实际实施测试的记录。
这部分对于实际开发过程并没有明确的要求。如果是采用的敏捷管理，则按照敏捷管理的要求进行。
把一个单元的任务拆解成为更小的独立单元，每个单元通常1-8个小时完成，最高不超过40小时。
且把这些单元按照代码实现顺序进行排序，建立一个任务墙。
每个人按照个人的能力去挑选自己最擅长的单元，擅长的少的先挑。
然后完成一个单元后再去选择下一个单元。每个关联的单元完成之后进行代码合并，联调等。
建议是将关联的单元给同一个人完成，以避免代码合并和联调的BUG。
一个单元所有任务完成后，请测试人员进行测试。
测试完成后，上传到存储的环境中，并标注对应的版本和单元号。
第五个阶段：集成测试。
所有单元完成后，进行整体的测试。
输出文档。
《集成测试计划》。
《集成测试说明》。
《集成测试报告》。三件套。
《软件产品说明书》。一旦测试合格，就要提供产品的说明，包含接口，性能，环境等说明。
《版本说明》。包含版更内容，兼容性问题，已经解决的问题等。
通常我们把这个测试当做α测试，即内部测试。再往下细分，还可以分为多轮次测试。
按照预期的使用说明进行测试，即在完整的指导下完成。
按照不同的使用场景下的测试。即是否满足更多的需求和场景。
在混乱使用的场景下，有时就是乱点击和乱输入，的测试。测试容错情况。
通常我们需要经过这样三轮的α测试才可以认为合格。需要时，还需要进行压力测试。
通过编写一些脚本程序，在很大的数量下，完成接受数据承载力性能相关的测试。
通常在设计时，会根据不同的页面难度给出一个通用的响应时间的，即数据承载能力的标准。
其实一个产品很难经受完整测试条件下合格。全部测试合格的前提是在设计规范上的严格要求，且严格按照设计规范执行。本质是设计规范的根源。
第六个阶段：交付和验收阶段。
在客户使用场景下进行整体的验证。核心是验收报告。
输出文档：
《软件验收报告》。对软件进行整体评价验收的总结。
《软件移交计划》。指的是交付的交接物和计划。
《软件安装计划》。实际安装使用的计划。
《软件用户手册》。
《软件安装手册》。
《软件维护手册》。这三件套可以视为交付和售后必备。
通常我们把这个当做β测试。如果是一个标准产品，目标是通用的客户市场，同时不会只进行一次β测试，即需要在不同的客户中验证。
在交付和验收过程中，需要解决客户的问题，问题包含。
不能使用的问题，严重度为S。
功能不良的问题，或次要功能欠缺，严重度为A。
性能尚可接受，但希望有所提升，严重度为B。
希望有额外的需求，严重度为C。
通常会把不同等级的BUG对应内部的BUG数量进行比较，S级希望是0，A和B级的“外部/内部=5%”是一个通常的评估线。
第七个阶段：售后使用阶段。
即客户长期的使用场景下的问题解决。
输出文档：
《软件维护计划》。
《软件维护报告》。
通常会跟踪一年的时间，并且希望把内外部的BUG比率整体控制在3%以内。
在客户使用过程中，往往不是BUG的问题，而是变更的问题。即一个场景的使用并不符合预期场景，但是客户希望满足。这时候可能会被定义为BUG，或者需求变更。这部分根据实际的场景综合判断即可，有时内外部处理的结论是不一样的。
如果是标准产品，最终还是希望产品满足更多的场景需要。
交付时为了客户把钱交了啥都同意。售后时，也应该是客户提出的需求绝不否定，因为客户的需求总是具有合理性，最终只是成本和解决方案的问题。这部分是是可以沟通的。
作为一个产品的成熟，需要三年的周期，而这个周期内的所有客户需求，尤其是售后的需求，都是推动产品迭代的动力和输入来源。
