【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. 禅道官方推荐的标准化项目管理流程

猜你喜欢

转载自blog.csdn.net/lqzkcx3/article/details/132401447