前言
现在，早上10点半，来到新公司的快三个月了，谈不上适应与否。正要打开 Studio 开始梳理新需求应该如何编排,就莫名的想停下来一会，写点东西，写点有关业务，但又不仅仅是业务的事情。
最近来到新公司，其实主要负责的是稳定性相关的工作，大家都知道稳定性的治理是一个长期的事情，不可急功，并且还需要时间去验证、去实验，是否对业务具有正向意义。但似乎受公司文化或者说公司阶段性的重点规划的影响，目前的稳定性治理并没有像公司一直宣传的那样追求极致吧，因为经常要求一个性能问题要明天出结果，要知道代码已经是"屎山"了，所以为了达到时间上的要求，我就只能先指标了，让数据好看些。
说这些并不是想表达我的不满，只是突然有感，一个业务开发、包括性能治理的一个相对正确的流程应该是如何的。
有同学可能会问，一个做稳定性治理的工作，为什么要一直在讲业务。
这也是这篇文章我想说了第一点，也是全篇所有观点的支撑点：产品思维
产品思维
产品思维，这个名字似乎有点大。我不是产品经理，也没有相关经验，仅仅一线一名工作5年一线研发的角度，来说点什么
作为研发，我们的每一行代码、写下的每一个变量、方法都在为当下这个产品服务，包括稳定性相关、更包括业务功能。
所以产品思维很重要，我们和产品经理不是对立的，我们是站在一起的，包括数据分析师，都在为这个产品的DAU、留存、ARPU、pv、uv，甚至崩溃率、ANR率，投放归因等数据负责。当然还有用户体验
产品思维还是有点抽象，我想把它具体化，和我们的工作联系在一起。
- 当前的需求是什么，为什么要做这个需求，不做行不行
- 在业务上，我们需要增加哪些埋点来验证功能目标。
- 站在bug的角度，如果线上出现了问题，我们应该提前增加什么埋点来帮助排查原因以及补救措施
- 另外还有应该创建什么实验，来验证新功能上线后的收益情况，如何避免各种实验带来的数据污染。
- 最后就是如何和测试同学一起，完善测试case，发现bug时，如何快速排查出问题。
这五点就是我想表达的产品思维。
当前的需求是什么，为什么要做这个需求，不做行不行
当然一个需求被提出来，参与研发评审，大概率一定是要做的，相信产品经理同学的专业性，但是对于我们研发，为何还要第一时间站在一个对立面去提问这个类的问题呢
- 这样研发才能更加去了解一个需求的前生今世，以及后面的三生三世，
为技术评审以及代码如何编写、如何扩展做准备。 - 了解产品经理和数据分析师想要关注的点，
更好的理解和对埋点以及实验设计提出建议 - 站在研发的角度去看
是否损害了用户体验。 因为产品经理有时间往往只想关注数据增长，而有无意识的忽略了用户体验。这点我遇到的最多 - 最后就是
判断需求的优先级。产品经理可能会提出很多需求，站在他们的角度，肯定是都想第一时间上线，但是时间有限，我们必须对此和产品"battle"，进行优先级的排序。
在业务上，我们需要增加哪些埋点来验证功能目标
埋点对业务很重要，没有埋点的需求，就是一个没有价值的需求。可能说的有点偏激，但是它的确很重要，因为它关系到一切产品数据，我们应该对此敏感。 尤其是商业化类广告需求。
在评审需求时，埋点的评审也一定要进行，这里才是需求的灵魂。
站在bug的角度，如果线上出现了问题，我们应该提前增加什么埋点来帮助排查原因以及补救措施
除了业务类的埋点，我们技术侧的埋点也万万不能少。没有一个需求是没有bug。（似乎又有点偏激？？）
一个需求的代码完成后，会先后经历首轮需求测试，上线前会进行回归测试，上线后还有会有大量的用户反馈。 每一步都可能会有bug，包括业务bug，用户体验、也包括机型适配等等问题。
发现问题后，如何才能快速定位呢，那当然就是技术侧的埋点。
当发现问题（bug）时，我们常常常常常常会听到类似的声音： 【这里没有添加埋点，我添加埋点后，重新发一版本线上收集用户数据】、【在我手机上好好的，你那怎么就不行】、【没有复现，修不了】等等。
如果我们对需求很了解，就会设计出好的技术侧埋点，不多不少的埋点，可以体现出我们的专业性。
另外还有应该创建什么实验，来验证新功能上线后的收益情况，如何避免各种实验带来的数据污染。
在大公司每个功能的上线，都会伴随着大量的实验。通过实验我们可以真切的了解到一个新功能上线后数据变化情况。 但是这里有两个问题需要解决。
- 应该创建什么实验
- 应该如何避免各种实验可能带来的污染
其实这两个问题也可以是一个问题，因为一个好的实验的创建也必定考虑了实验之间干扰的情况。 需要创建的实验一定是建立在同一个维度上的，怎么理解呢，就拿商业化广告业务来举例子。需求是【我们要在抖音推荐feed中增加一个广告位】。
对于这个需求我们可能需要增加的实验有：
- 对照组：无新增广告位
- 实验组1：新增广告位，广告展示形式A
- 实验组2：新增广告位，广告展示形式B
- 实验组3：新增广告位，广告展示形式C
这四组实验，都必须在同一实验层。实验中需要关注的核心指标有：广告主价值、ARPU、还有留存、稳定性、用户人均时长等
还有一个问题就是各种实验可能带来的污染。 比如现在在上述需求外，同时还有一个商业侧的需求：【在抖音推荐feed中再增加一个广告位】
很明显这两个需求都在操纵一个区域 ，也都是一个类型（新增广告位），关注的指标也都一样。 对于这些需求的实验就需要将他们都放到一个实验层。来避免数据干扰。
最后就是如何和测试同学一起，完善测试case，发现bug时，如何快速排查出问题。
这个过程也很重要，有很多公司都会忽略测试case评审，测试同学自己根据需求出测试case就好了。不需要研发深度参与。
这个观点是不对的，关注测试case评审的好处很多：
可以和测试、产品等同学再次回看需求流程，可能会发现很多细节case没有考虑到，更多的是要考虑边界场景。- 可以在自测时，
关注易错case - 可以对需求了解更加细致，有利于
研发排期的准确性
以上所有的流程都是很重要的，同时也是比较耗时的，可能实际情况给研发的时间很少，上面的流程可能执行的不是很好，但是我想表达的还是这种思维还是很重要的，研发不仅仅是靠硬技术，还要靠产品思维这种软技能才能发展的更好。