开发小结-产品类

本文总结了在开发过程当中，产品类的相关经验总结。

开发心得之产品类

产品思惟是发现现有产品的问题而且描述清楚，转化为一个需求，结合上下游资源，造成一项任务，组织一批人将该任务完成，而且以主人公的心态去跟踪，维护该产品。

在作需求分析时，能够从业务角度去思考功能，一些非业务功能，好比性能、可扩展、可复用性、安全性、可测试性，在需求说明书中是不会涉及到的，这些非功能行需求，由开发来全盘掌控。

测试人员要可以从产品需求文档中梳理出可行性的测试案例，若是梳理不出来，或者说对于完成这个功能的正确性有疑惑，那就要在需求评审的时候提出来。针对一个需求来讲，作成什么样的，和作成什么样是正确的是两个层面的思考。

要写一份让开发和测试认为是完美无歧义的需求文档，真的是有难度。需求规定的太细了，开发会揪住太细的地方逐个确认，以防理解有误差。规定的太粗了，开发又会有疑惑，这个地方该如何作。无论怎么说，需求是源头，源头有不肯定性，后面就会逐级放大该不肯定性。考虑到完备性，需求文档中，除了正常场景下的业务流程以外，另外一方面，对一些错误和异常状况下的业务流程，要给相应的解决方案。

一个需求的落地，是落地为组成需求的各个功能模块以及构成的功能点，开发人员根据功能点来开发，测试人员也是按照功能点来测试，而产品人员和最终人员是按照需求来体验。从工做上下游价值链上来看，开发要"测试"产品人员提出的需求，肯定无误后投入开发，测试要测试开发提供的软件产品，肯定无误后上线运维。而运维就在无时无刻测试"测试"提交的产品。

需求讨论

在进行需求讨论时，不要被细枝末节耽误太多时间，分清讨论的重点和非重点内容。关键业务路径要尽可能达成一致。

当有任何需求不明确的地方时，须要将现有问题的现状，预计修改后的状况一一按照案例场景法描绘出来，而后提交到讨论组里面去，因为这个问题相关的人员来一致决定在各类场景下该如何去表现，等到他们作出最后的一致意见后，再由开发人员去按照讨论出的共识去，原模原样的作出来。

在需求到解决方案的思考过程当中，不要考虑改动带来的影响和现有工程中的已实现逻辑，要跳出现有的框架，努力从各个不一样的方向去寻求不一样可能的解决方法，最后综合对比各类状况，从而选择一个最适合当前场景的解决方案。

解决问题的方法可能只是一小行，可是背后的思考和许多验证类代码是必不可少的。对于任意一个Bug修改后的性能、可扩展性以及影响范围，要有本身的思考和判断。对于产品经理提出的不合理的需求，要学会积极主动反驳，就产品功能提出本身的合理化建议。

每一个人都是产品经理，对于功能、需求、交互、UI和实现，不能只管实现已提出的部分，而不顾哪些被需求、设计人员忽略的特例状况和异常状况，从单纯的实现角色转变为对本身负责的模块、甚至是整个总体流程的理解和掌握。

不一样安全级别的业务要作隔离，这样作的好处是当出现紧急状况时，咱们能够将风险隔离在较小范围，作后续处理时的牵挂更少。

动机评估

动机评估，下面从如下几个方面开展：

• 目的分析
  为何要作这个项目，或者说，咱们但愿经过这个项目达成什么样的目的？

• 收益成本风险分析
  项目实现之后，可以获得哪些收益？要付出哪些成本？有哪些实际或者潜在的风险？

• 效率分析,战略分析
  如何在尽量少的成本和风险敞口下，能得尽量多的收益？
  上面提到项目能够替换为[需求、模块、公司]，均可以按照这样的思考框架来进行。

下面就一个具体的需求： “将大型C++项目从依赖MFC环境下移植到Mac环境下”，进行分析：

1. 目的分析
   1.1 软件的大客户提出但愿跨平台使用
   1.2 软件的众多我的用户提出跨平台使用需求
   1.3 公司软件产品将来发展路线

2. 收益成本风险分析
   2.1 收益分析
   • 巩固现有大客户关系，多收钱
   • 提高我的用户忠诚度，依次吸引新用户加入
   • 实现公司前进战略
     2.2 成本分析
   • 全功能移植所需的人力成本很是高
     2.3 风险分析
   • 移植所需时间过长，致使用户放弃跨平台使用该产品
   • 若是移植后的产品质量没法保证，会影响产品口碑，
     不只不会吸引新客户，还会流失旧用户

3. 效率分析,战略分析

根据以上分析，要保证收益，减小成本，避免风险的核心在于开发时间不能太长，软件质量必须保证，若是有可能的话，投入尽量少的开发人员。

通常来讲，在软件开发过程当中，开发工做量、产品质量和所需时间这三个因素不可能都要求完美，在有限的开发资源中，最多只能保证二者达到理想状态，所以，须要对开发工做量进行妥协。在软件的具体使用过程当中，遵循8/2定律，在大多数时候，80%的用户的80%的时间，在使用软件中的20%的功能。据此，咱们须要选择当前软件产品中最核心的20%的功能，争取在最短的时间里，以尽量高的质量进行移植。

目标：在新平台上，实现最核心的功能，若原有code base上的公用组件具有跨平台特性，则可基于公用组件开发。不然，重新设计和实现，不用负担过去的历史包袱。

可靠性理解

理解一个系统的可靠性，这里提供一个思路，能够从反面来思考，当一个系统由于某种故障致使没法提供服务时，咱们就说系统不能可靠的处理这类故障。或者说，若是系统可以处理这类故障，那么能够认为，咱们的系统对这些故障是可靠的。

不一样故障发生的可能性，有高有底。下面从高到底列出典型的故障状况：

1. 应用程序代码有漏洞
2. 系统组件有漏洞
3. 消息队列溢出
4. 网络临时中断
5. 硬件系统崩溃，致使全部进程停止
6. 网络出现特殊状况的中断，例如某个交换机的端口发生故障，致使部分网络没法访问
7. 数据中心遭遇雷击、地震、电压过载、冷却系统失效等。

小结

每一个人都是产品经理，而产品就是本身，要在本身的岗位上作出最极致的产品，对待本身的代码，就要像对待本身的小孩同样，看着它从弱小、不完美，一步步的更加可以适应外部变化，响应外部变化。