取舍与可测试

这篇文章谈谈在做产品和研发中被严重忽略的两个点，取舍与可测试。



先说取舍，选什么方向不选什么是取舍，选定了方向做这个还是做那个是取舍，决定了做什么后满足什么需求忽略什么是取舍，这可以说是产品决策层面的取舍。



企业一定会做取舍，为什么这里说取舍还是被严重忽略呢。因为通常取舍集中在了战略层面，不管通过怎么样的机制，长期看合不合理不论，但总归在大的层面是有取舍的。那么忽略在哪里，忽略的是产品层面。虽然MVP、PMF的大家都在提，可在具体做的时候由于各种原因动作就变形了。原因有很多，归纳归纳可能多少都会碰到如下问题。



产品需求面向领导而不是市场。



可别觉得这事儿少，以前就碰到过做运营的伙伴三天两头搞拉新，各种手段，光优惠券就能整出花来，为啥？他也为难，明知是内容上的问题，这样的拉新起不到本质作用，可领导要效果，他也不能让领导看着没事可做，只能多搞活动，做产品的也只能不断应付。说实话，这样的方式对公司资源的消耗非常大，这样的取舍没人做，没人把关，大家就是在做热闹，表面热火朝天，实则都是应付了事，长久受损的就是企业，也是企业中的个人。



面向具体的人而不是共性需求。



通常我们会把具体的人作为用户，但是作为个体其需求也是多样的，甚至是矛盾的，所以在看了《俞军的产品方法论》后，有一点让我印象很深刻，就是我们的用户应该是一类需求的集合，而不是具体的某些人。我们做的产品也应该去满足这个需求集合，而不是去满足具体的某些人。



不做思考满足表面需求。



从市场得到的需求通常是相对表面的，市场需求到产品层面是需要做进一步的思考分析的，做不做，怎么做，受众是谁，范围是否广泛，对企业自身能带来哪方面的价值，不然产品很容易变得臃肿起来。



当然还有其他很多原因，主观的，客观的。对于取舍，本质上是对价值的判断，满足需求并给企业创造合理的价值，是对取舍的基本衡量标准。价值有很多种，带来现金收益，产生社会价值，引来流量，增强用户粘性，等等。总归来说，要是不做取舍，企业将投入很多的无效资源。



取舍不仅在产品决策层面，在研发过程也存在，比如自研还是外包，采用什么样的架构，依托什么样的平台，沉默成本发生是否应当机立断及时止损等。可这些相对都是具体的，更容易在团队内达成一致，在产品决策层面的取舍还是最重要的。



另外再说研发过程中的可测试性。



现在太多的团队研发过程中出现问题多在管理上找原因，在软件工程方法上做尝试。这些都没问题，问题是这些方法被过于神话，比如现在团队九成都用SCRUM，而且在各个环节推陈出新，手段多样。这些有没有用，当然有用，大家能在一个共识内工作，沟通运转的成本就低。但是产品研发质量受很多因素影响，并不是这些方式能解决的。我们不可能想着每个团队都高手如云，方方面面都有强者护航，所以可测试性及做好测试对研发质量更有实际意义，而这点又是常被忽略的，或者有意识但无动作。



现在大家的工作几乎都建立在各种商业或开源框架上，尤其是开源。在选择开源框架时我们选择什么，很重要的就是其自身测试完备而且易于在其基础上构建测试的框架。可以看看各知名开源框架，测试完备性与可测试性上都做的非常好。



研发过程中如果更多考虑可测试性，那么在设计上就会更符合软件工程的原则，可测试性越强，团队间的协作也越容易进行，测试完备性越好，产品质量也越有保证。



当然可测试也有取舍，也需要在企业能接受的范围内。比如旧的我们暂且放置，新添加的尽可能保证可测试性，保证不了很大范围的测试保证核心部分的，做不了UI层面的，做好接口级别的，总之可测试是产品能够不断迭代还能保证质量的基础。如果拿工期紧来推脱测试的话，那就再把取舍加强一点，多舍一点不必要，时间就出来了。