【DEVOPS】需求跟踪管理全面落地

1. 现状/背景

近期又被领导问到"如何对项目过程中的需求进行量化和跟踪管理"。这真是一个狗皮膏药似的问题，反反复复地，隔一段时间就得被再次提及。

究其原因，除了过往在传统软件行业中技术团队的发展(现状篇)，【DEVOPS】基于禅道 - 重构研发协作流程分别进行过总结的背景之外：

1. 我们的DEVOPS改良推进路线风格属于彻底的自下而上。除非拿出切实的，已经试点成功的，能够被直观感受到好处的改良结果，领导才会进行明确的站台支持。
2. 上一条属于客观背景，那么这一条就属于自身不足了 —— 一直以来向上管理意识有但是不多。没有做好成果汇报和信息同步，同时缺少宣讲和对外输出。于是出现"我们觉得时机早已成熟，但是领导层对此知之甚少，进而对于改良的推进犹犹豫豫，畏首畏尾"。

本文接下来的部分就是解决上面提出的这两个问题，解释：为什么我们认为现在时机已经成熟，为什么存在一种在没有太大阻力，不放弃底线的情况下，能够将现代化项目管理流程推行下去的可能性。

注：以下内容有个前提，就是如【DEVOPS】基于禅道 - 重构研发协作流程，组织内部已经有了成功的样例。

2. 需求管理存在的问题

以需求为抓手，是项目管理过程中跟踪项目进度，判断风险，量化各个岗位贡献值的基本方法和思路。

但是现在的问题正是，记录需求的变更过程，以提供客观数据去反映各方的工作量，这部分工作没有人做，一是没经验，二是没意愿，而领导出于各类原因始终无法下定决心将这份职责指定给哪个角色。 于是无尽的扯皮在不同的项目组内接连上演：

1. 产品说研发效率太低；
2. 研发说产品的需求总是变来变去。
3. 扯皮的时候"双手赞同要搞标准化项目管理，我要证明自己的清白"，但一旦摆出真的要进行改进的架势时候，各种困难就出来了——哎呀本来就很忙了，哪来的时候记录这个。也就是"这个东西是很重要，但是凭什么要我来做？"

于是又绕回了过往的惯性老路 —— 试图通过降低标准/无限倒退的方式来让规范/改良能够执行下去。

但是有些时候，对于有些已经是基本要求，没有后退之路的底线，这个思路并不适用。

还是以需求的管理为例，对需求进行持续跟踪的前提是有人去记录各个版本的内容，并且建立它们之间的联系，工具只是可以帮助我们减轻这部分工作量，但"对需求进行持续跟踪"这项工作本身最终的质量以及相关方的满意度，还是需要人来把握的。如果相关方连这个都不愿意做，或者糊弄着做，那么我们最终的目的很难达成。

3. 改进思路/措施

所谓"工作量不会消失，只会转移"，正如DEVOPS并不是消除了工作量，而只是将其由人工转交给了机器，项目管理中的"对需求进行持续跟踪"这件事情现在既然不能依靠于产品和相关售前/需求分析人员，那么我们就下移一步，交给有经验的研发团队来主导或占据关键节点，该项目团队的原有其它人员进行辅助填充，让有经验的研发团队推着其他人来适应这个操作流程。

我们来看看为什么这个移交存在可行性：

1. 我们推进DEVOPS就是使用机器操作逐步代替人工操作，在此过程中借助机器操作特点借此来构建标准的工作流程，最终保住产品质量的底线，同时也显著减轻人员工作压力和心智负担。

2. 并且我们在过去几年一直也在推进技术栈沉淀，实现解决方案的标准化，减少人员在所谓"技术难点"上的精力投入。

3. 在禅道推进上，过去几年我们分别在行业部门和基础平台部门结合各自当下现状，对于禅道标准化研发流程进行了自适应改造/本地化改造，做到了真正的落地。

   3.1 这个"真正的落地"的第一层含义： 本地化改造后的流程已经实现了在无需过多外力/监督介入情况下的自运转。

   3.2 这个"真正的落地"的第二层含义： 两个部门内部对于禅道的理解和使用完全不一样，而且和禅道官方推荐的标准化项目管理流程也是差别甚大。

原有团队没有人愿意，也没有一个额外的精力去监督和检查"对需求进行持续跟踪"，那就让被解放出精力，具备了基本需求管理流程经验的研发人员，以及具备禅道本地化改造流程经验负责人来作为主导/关键节点，引导该项目内的需求跟踪管理流程，原项目组的其它人作为辅助参与进来，在这个试点过程中：

1. 实现对当前项目"对需求进行持续跟踪"的基本要求；
2. 同时培养/熏陶出一批具备基本素养的产品/需求分析人员；
3. 并且迭代出一个针对性的流程，既兼顾该业务线/该团队内相关人员的既有操作习惯，又满足基本的标准项目管理流程要求，为之后的流程优化打下基础。

4. 所谓"禅道尚未普及/铺开"

所谓"禅道尚未普及/铺开"正是以上改良措施出现的背景；而且如果禅道已经铺开，本文背景都已经不存在了，也就是不会出现需求变更导致的扯皮问题。

我们提出的对策正是为了应对"禅道尚未普及/铺开"情况。

可以说现在这批人是幸运的，至少公司给了他们这个过渡的阶段。一旦这个流程成型，这样的人就没有机会了。因为到时候你要不是白纸一张，要不就是已经知晓这些流程。一张涂满涂鸦的纸，我们已经没有这个耐心去矫正了。

5. 最后

1. 不要再讨论"要不要用"，而是"怎么用"？ 始终在这起点徘徊，一辈子都到不了。
2. 我们已经完全接受"慢慢来"这个现实，是因为我们承认最终还是人决定了产品的质量，所以我们愿意将这个过程慢下来，克服人性中急躁，急功近利的弱点，拾阶而上，一步步地向目标进发，在这个过程中把人培养出来，把事情做成。
3. 我们并非要求当下马上执行以上试点，我们只是提供一种可能性，一种如何在一个四面楚歌的情况下，让好的变化发生。（相较于过往的改良推进，当下其实已经好多了，毕竟现在已经再是0到1了）

6. 相关

1. 【DEVOPS】基于禅道 - 重构研发协作流程
2. 【DEVOPS】DevOps推进过程中的一些最佳实践
3. 阿里如何定义团队的研发效能？
4. 《UNIX编程艺术》
5. 【DEVOPS】DevOps推进过程中的一些最佳实践3
6. 禅道官方推荐的标准化项目管理流程