软件开发总结--一些关于需求的感想

一些比较细碎的感想

用户/客户是谁，我们用什么打动用户/客户？

我们用价值打动用户/客户，如果我们不了解用户/客户， 不去关心他们真正需要的是什么，则不知道什么对用户/客户有价值。

如果我们不清楚用户/客户是谁，不知道价值是什么，很可能我们会将力气用偏。

【开发人员都是完美主义者，用户不一定需要这样的完美主义者， 用户怕不能给他们提供价值，不能尽快给他们提供价值】

紧盯用户和价值

 

做需求的时候，需要紧盯用户和价值，如果忽略价值，会忽略掉很多的工作，例如为参加展会开发高拍仪，如果忽略价值，则1） 不会将为展会准备PPT与开发联系起来，产品规划人员就不会主动与开发人员沟通是否能达成想法 2） 不会关注谁在展会中讲解，是否需要提前为他/她提供培训或交流。

再如，为某个软件提供配置界面其实不是一个需求，而是一个解决方案，而且用户/场景不明确。 如果睛紧用户和价值，则会出现：1） 为运维人员提供快速配置的价值， 2） 为使用者提供场景切换的价值，例如本校和跨校使用。 这样一来，可能会出现更多的想法和解决方案，例如针对价值1可以提供批处理，远程配置等

 

测试思维

写了十几年代码后才发现，开发需要有测试的思维才能把开发做好。由单元测试开始，将这种思维运用到需求分析，功能实现，发现开发中的很多流程豁然贯通。我将单元测试与需求联系起来时，用户故事和满意条件提供了很大的帮助。满意条件不就类似于单无测试的测试用例吗。如果满意条件太复杂，可能说明用户故事本身有问题，不就是单元测试的接口重构吗。没有满意条件，开发如何知道这个用户故事完成或没完成？如果开发不了解用户价值，没有生动的用户场景，没有对满意条件和价值达成一致，如何开发，碰到疑难问题，如何能真正的讨论起来？

 

测试阶段向前延展

测试人员应该站在用户的角度进行测试，特别是系统测试和验收测试。 从这个角度出发，当前的测试角色不具备这个能力，这应该是产品责任人（Product Owner）或产品经理来承担这个职能， 也可以理解为测试人员还应该有一定的产品经理角色。

如果测试提前介入产品经理角色的工作，也就是将测试工作提前到需求阶段， 从验证产品，查找缺陷到设计产品，理解产品意图，了解用户满意条件这一块上来了。

什么是成功的产品

1： 销售愿意卖

2： 用户愿意用

3： 解决实际问题

4： 能够【有机会】向纵向和横向发展（发展生态）

开发与Product Owner互为客户/用户

1： 开发是Product Owner的客户和用户

Product Owner需要向开发提供的价值：

概述

1） 确保开发的需求有价值： 能为用户解决问题，能得到销售人员的认可和支持，能与公司的发展保持一致并提供正向助力。

2） 确保是真实的用户需求

3） 能知道做到什么程度就够了

细节

1） 指明开发版本的目标， 该目标经过QA检验并与开发，QA达成真正的理解一致。

2） 为该版本提供一个特征组合，以支撑该目标，不要让开发人员只看到一个个具体的功能。

3） 找出真正的客户和用户： 特点，代表的联系方式（或者有Product Owner代理）

4） 明确为客户/用户提供的价值

5） 保证产品尽快上线（开发完就能用上），尽快与客户/用户磨合，尽快成熟

6） 逐步丰富应用场景

7） 明确每个用户故事（需求）的验收标准，且通过QA的检验

8） 能够与开发方便的沟通

9） 确保用户故事（需求）没有跑偏

10） 咨询（收集）过市场的意见【避免闭门造车】

11） 与公司的特点相吻合【例如偏硬的公司，开发软件就不是特别适合】

2： Product Owner是开发的客户

开发需要向Product Owner提供价值

1） 完成用户故事（需求）， 确保与验收条件一致。

2） 可以演示给客户/用户代表（真正的客户/用户）

3） 客户/用户（真正的客户/用户）能够立即使用，且能用

4） QA认可【思考中，待确认】

5） 确保理解与Product Owner真正的一致