开发小结-产品类

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

开发心得之产品类

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

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

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

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

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

需求讨论

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

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

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

解决问题的方法可能只是一小行，但是背后的思考和许多验证类代码是必不可少的。对于任意一个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. 数据中心遭遇雷击、地震、电压过载、冷却系统失效等。

小结

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