开发小结-产品类
本文总结了在开发过程中,产品类的相关经验总结。
开发心得之产品类
产品思维是发现现有产品的问题并且描述清楚,转化为一个需求,结合上下游资源,形成一项任务,组织一批人将该任务完成,并且以主人公的心态去跟踪,维护该产品。
在做需求分析时,可以从业务角度去思考功能,一些非业务功能,比如性能、可扩展、可复用性、安全性、可测试性,在需求说明书中是不会涉及到的,这些非功能行需求,由开发来全盘掌控。
测试人员要能够从产品需求文档中梳理出可行性的测试案例,如果梳理不出来,或者说对于完成这个功能的正确性有疑惑,那就要在需求评审的时候提出来。针对一个需求来说,做成什么样的,和做成什么样是正确的是两个层面的思考。
要写一份让开发和测试认为是完美无歧义的需求文档,真的是有难度。需求规定的太细了,开发会揪住太细的地方逐个确认,以防理解有偏差。规定的太粗了,开发又会有疑惑,这个地方该如何做。不管怎么说,需求是源头,源头有不确定性,后面就会逐级放大该不确定性。考虑到完备性,需求文档中,除了正常场景下的业务流程之外,另一方面,对一些错误和异常情况下的业务流程,要给相应的解决方案。
一个需求的落地,是落地为组成需求的各个功能模块以及构成的功能点,开发人员根据功能点来开发,测试人员也是按照功能点来测试,而产品人员和最终人员是按照需求来体验。从工作上下游价值链上来看,开发要"测试"产品人员提出的需求,确定无误后投入开发,测试要测试
开发提供的软件产品,确定无误后上线运维。而运维就在无时无刻测试"测试"提交的产品。
需求讨论
在进行需求讨论时,不要被细枝末节耽误太多时间,分清讨论的重点和非重点内容。关键业务路径要尽量达成一致。
当有任何需求不明确的地方时,需要将现有问题的现状,预计修改后的情况一一按照案例场景法描绘出来,然后提交到讨论组里面去,由于这个问题相关的人员来一致决定在各种场景下该如何去表现,等到他们做出最后的一致意见后,再由开发人员去按照讨论出的共识去,原模原样的做出来。
在需求到解决方案的思考过程中,不要考虑改动带来的影响和现有工程中的已实现逻辑,要跳出现有的框架,努力从各个不同的方向去寻求不同可能的解决方法,最后综合对比各种情况,从而选择一个最适合当前场景的解决方案。
解决问题的方法可能只是一小行,但是背后的思考和许多验证类代码是必不可少的。对于任意一个Bug修改后的性能、可扩展性以及影响范围,要有自己的思考和判断。对于产品经理提出的不合理的需求,要学会积极主动反驳,就产品功能提出自己的合理化建议。
每个人都是产品经理,对于功能、需求、交互、UI和实现,不能只管实现已提出的部分,而不顾哪些被需求、设计人员忽略的特例情况和异常情况,从单纯的实现角色转变为对自己负责的模块、甚至是整个整体流程的理解和掌握。
不同安全级别的业务要做隔离,这样做的好处是当出现紧急情况时,我们可以将风险隔离在较小范围,做后续处理时的牵挂更少。
动机评估
动机评估,下面从以下几个方面开展:
-
目的分析
为什么要做这个项目,或者说,我们希望通过这个项目达成什么样的目的? -
收益成本风险分析
项目实现以后,能够得到哪些收益?要付出哪些成本?有哪些实际或者潜在的风险? -
效率分析,战略分析
如何在尽可能少的成本和风险敞口下,能得尽可能多的收益?
上面提到项目可以替换为[需求、模块、公司],都可以按照这样的思考框架来进行。
下面就一个具体的需求: “将大型C++项目从依赖MFC环境下移植到Mac环境下”,进行分析:
-
目的分析
1.1 软件的大客户提出希望跨平台使用
1.2 软件的众多个人用户提出跨平台使用需求
1.3 公司软件产品未来发展路线 -
收益成本风险分析
2.1 收益分析- 巩固现有大客户关系,多收钱
- 提升个人用户忠诚度,依次吸引新用户加入
- 实现公司前进战略
2.2 成本分析 - 全功能移植所需的人力成本非常高
2.3 风险分析 - 移植所需时间过长,导致用户放弃跨平台使用该产品
- 如果移植后的产品质量无法保证,会影响产品口碑,
不仅不会吸引新客户,还会流失旧用户
-
效率分析,战略分析
根据以上分析,要保证收益,减少成本,避免风险的核心在于开发时间不能太长,软件质量必须保证,如果有可能的话,投入尽可能少的开发人员。
一般来说,在软件开发过程中,开发工作量、产品质量和所需时间这三个因素不可能都要求完美,在有限的开发资源中,最多只能保证两者达到理想状态,因此,需要对开发工作量进行妥协。在软件的具体使用过程中,遵循8/2定律,在大多数时候,80%的用户的80%的时间,在使用软件中的20%的功能。据此,我们需要选择当前软件产品中最核心的20%的功能,争取在最短的时间里,以尽可能高的质量进行移植。
目标:在新平台上,实现最核心的功能,若原有code base
上的公用组件具备跨平台特性,则可基于公用组件开发。否则,从新设计和实现,不用负担过去的历史包袱。
可靠性理解
理解一个系统的可靠性,这里提供一个思路,可以从反面来思考,当一个系统因为某种故障导致无法提供服务时,我们就说系统不能可靠的处理这类故障。或者说,如果系统能够处理这类故障,那么可以认为,我们的系统对这些故障是可靠的。
不同故障发生的可能性,有高有底。下面从高到底列出典型的故障情况:
- 应用程序代码有漏洞
- 系统组件有漏洞
- 消息队列溢出
- 网络临时中断
- 硬件系统崩溃,导致所有进程中止
- 网络出现特殊情况的中断,例如某个交换机的端口发生故障,导致部分网络无法访问
- 数据中心遭遇雷击、地震、电压过载、冷却系统失效等。
小结
每个人都是产品经理,而产品就是自己,要在自己的岗位上做出最极致的产品,对待自己的代码,就要像对待自己的小孩一样,看着它从弱小、不完美,一步步的更加能够适应外部变化,响应外部变化。