半年多的时间，眼睁睁看着dd运维平台从臃肿到积重难返，很痛心。其中，有公司业务发展迅速的原因，有早期设计方案不合理的原因，有系统开发人员经验不足的原因，等等。本文要讲的，是另一方面的原因: 需求到产品的转化不当。
需求到产品的转化不当，主要体现在两个方面:
- 对需求的把控，不够严格
- 需求到产品的转化，不够严肃
下面，我们以dd运维平台的需求处理过程为例，做简要分析。为了说明问题，过程描述有删减调整。
提出需求
运维系统80+%的需求，来源于SRE(SRE的需求来源于RD需求和运维业务)。由于种种原因，SRE不能完全正确的提出需求，比如：
SRE对需求把控不严格
SRE通常很热心于运维平台的功能建设:-D 但有时，对新需求的过滤不严格，导致过多的、非大众的功能进入运维平台。典型的场景，有:
- SRE个人需求。
SRE个人在使用运维平台时遇到了一些问题，未经SRE团队整体讨论、确认，就抛给平台开发方(DEVOPS)、希望尽快转化为新功能。如果这个SRE个人经验不足, 那么被提出的”需求”常常带有较重的主观色彩、不够大众化，结果就是好心办成了坏事。此时，需要SRE团队集体做需求过滤。 - RD个人需求。
部分RD习惯以激烈的方式，反馈问题给SRE；SRE被动决策，有时候会直接将问题抛给平台开发方、转化为新功能需求；后者的举动，更加鼓励了RD的做法，如此往复加剧。运维平台完善之前，会经常被RD吐槽；SRE帮DEVOPS背了黑锅、承担了很大压力，此处的case情有可原。此时，需要DEVOPS直面RD的指摘、吃自己的狗粮，需要SRE识别RD的需求合理性、尝试引导RD表达合理的诉求
SRE需求分析不彻底
SRE没有拿到RD的真实需求。比如，SRE得到RD反馈后，没有弄清楚RD想要做的事情，或者，没有弄清楚RD所提问题的进一步的原因，只根据表象做需求判断。
SRE没弄清楚自己的本质需求。比如，SRE想要做一件事情，有时自己也没弄明白，为什么要做这件事、为什么要用这种方式做。如果一件事情可以不做，那就不做；如果必须做，优先复用已有方式。
为了提升需求分析能力，需要SRE沉淀需求分析的经验、刻意培训需求分析的能力。
SRE提出需求的实现
对于经验丰富的SRE，有时候会如是行为：正确的拿到需求，帮DEVOPS想好实现方案(产品方案)，然后对接DEVOPS开发人员、告知如何去实现。
如果我们有一位懂需求、懂技术、同时又能做产品设计的OP童鞋，那是所有人的福音。如果在一段时间内没有如此牛逼的大拿，我们最好退而求其次，合理分工，由SRE抛出较纯粹的需求，再由SRE和DEVOPS一起确认产品形态，大家分别做好擅长的事情。
把控需求
SRE将需求提给DEVOPS后，需要DEVOPS做进一步的过滤。当前，这一环节，DEVOPS做的很不好。比如，DEVOPS不能正确区分需求的大众性，习惯性的、无意识的接受”小众”需求。比如，DEVOPS不能正确理解SRE的功能需求，或者不能站在技术角度、协助SRE提取需求&分解需求。再比如，DEVOPS的童鞋不能正确区分功能需求和实现方案，常常会全盘接受SRE的实现方案。
这里，有DEVOPS童鞋经验不足的原因，也有DEVOPS需求把控机制的原因。个人觉得，可以通过两方面来改善:
- 建立集体决策机制。既然我们个人经验不足，又暂时没有统领全局的架构师，那就集体决策、大家一起确认需求是否合理。虽然集体决策会降低效率，但总比做不正确的事情好很多。此处，要 (1)选择合适的决策人群，同时 (2)开放决策过程、及时公布决策结果。
- 提升个人需求把控能力。自不必说，能够把控需求的DEV才是好DEV。
实现需求
在需求的实现上，DEVOPS做的也不够好。主要问题，有：
- DEVOPS缺乏长远规划，被动的让需求推动着平台发展。”随波逐流”，只能”江河日下”，最好也就是原地踏步。说句心里话，DEVOPS团队真心需要一个架构师，来指导平台的长远规划
- DEVOPS往往偏向于
多加功能。KPI驱动模式带来的一个恶果。当然，大部分人都倾向于增加功能，这是人性的一个默认设置，因此，需要DEVOPS的童鞋时刻保持对新功能的克制。可以”以暴制暴”，针对滥加功能这一现象 做一个KPI减分项:-D - 等等。
深夜BB这么一大堆，归根结底，还是因为公司发展太快。在这种情况下，大家只能亦趋亦步、相濡以沫、共同成长! 道路是坎坷的，前途是光明的，欢迎各位大牛加盟。