翻老文档的一大乐趣是，看以前自己想法的低劣之处，以及用现在的眼光看以前的材料，翻出一个外企时候统计工作时间的ppt（用途是看是否需要增加人手），发现一些很好玩的事情。
image.png
图中3个表格，左上角为项目（人日大于等于5），左下角为需求（人日小于5），右边为涉及本地外包供应商的项目。
数据理念的发展，早已经从仅仅支持投放广告／买流量，发展到全流程，包括供应／服务，我们不妨拿来分析一下产品流程。
step 1 / step 2
image.png
从一个典型的左上角流程出发，第一步是汇总需求，第二步是根据用户视角，写非技术测试用例。这两个步骤有没有数据可以考核呢？
显然是有的。因为测试用例有“覆盖率”的指标，我们可以延伸到需求覆盖率，在研发、内测、灰度、发布之后，会不断发现遗漏的逻辑，这个覆盖率的曲线可以数字化地看到团队的迭代能力。
step 3
image.png
第三步是充满血泪的变更管理，其实国内项目，往往90%的时间都在变更管理上，因为中国人的文化，真心话都是私下问\私下说，会议上都是套路，所以真实的需求是需要一再撞墙才能尝试出来的。外企相对来说，对事不对人方面稍微好一些，会议上就能激烈撕逼出结果，产生不太会大变的需求，因此变更管理就比较可控。
变更管理显然可以有一个类似优惠券roi分析的，比如说我发50块钱的券，损失了利润，带来了销量，对长期有所影响，变更管理也是这样。大部分情况下，患得患失的情况都是源于，变与不变各有利弊。因此变更管理可以有简单的机会成本的预估和验证，在影响较大的时候支持纯拍脑袋。
step 4 / step 5
image.png
第四步和第五步分别是非技术的功能测试和回归测试，这两项仍然延续开头提到的，需求覆盖率的指标，不过在这个步骤会产生另一个有趣的拍脑袋数字：放弃阀值。
简单来说，举凡一个改动稍大的项目，必定会有一些bug是来不及改完，就必须上线的（注意，是必定），这时候软件行业会用一个所谓紧急程度的指标，类似银行贷款的5级信用打分，比如1就是不修不能上，5就是可以先放弃，以后慢慢修（实际上往往是永远不修）。
微妙的地方在于，这个分是靠专家打的。所以技术圈的话语权斗争，是超出非技术麻瓜的想象的，将熊熊一窝是非常适合的概括。
我们可否尝试用数据来改善呢？这个场景是否很类似风控呢？我们知道大数据现在比较赚钱的领域仍然和金融有关，不再是那么简单的卖保险（唯一需要的就是牌照，也就是类似封建王朝的贩盐的生意），而是稍微复杂到反欺诈。反欺诈最难的地方是既要拦住坏人也要放过好人，是完全互相矛盾和抵触的指标。
项目测试阶段，究竟放过哪些bug，而对哪些问题不修好完全不能上线呢？道理是完全一样的。如果我们积累历史数据，对于I／O指标、用户体验（比如影响几秒）等有一个量化的记录，并且对照上线以后是否回滚的结果，很容易可以得到一个数字化的决策辅助。
我们对比一下现状，现状往往是，涉及钱一定不能过，其他情况，看情况。不难发现，互联网企业自身也是很需要互联网技术改造的。
step 6
image.png
第六步是回顾数据。常规情况我们要回顾的，主要是性能等技术指标是否正常（比如要不要加机柜），商业目标是否达到，预估的效果达成率如何之类。
假如在第一到第五步增加了若干流程指标的话，可以在完成业务需求的同时，评估和提升团队的迭代能力，这对于大公司可能是无所谓的（因为刻意压制个人能力，确保任何人都可以离开，而不影响丝毫），但对创业团队，或者小范围unit，一个牛人带一群小朋友，亟需能力提高的情景下，是值得一试的。
extra step
image.png
最后我们稍微看一眼涉及外包的流程多出来的步骤，即对比和选择供应商。这个步骤非常容易数据化，也就是结合内外部数据的供应商标签管理，将报价加入风险指数的权重，本文就先不多赘述了。
先写到这里了，谢谢阅读，欢迎吐槽。
网友评论