xp asp 网站建设,包装设计征集网站,网站建设内容模板,常州被约谈企业主公司发讣告0. 目录 1. 现状/背景2. 需求管理存在的问题3. 改进思路/措施4. 所谓禅道尚未普及/铺开5. 最后6. 相关 1. 现状/背景
近期又被领导问到如何对项目过程中的需求进行量化和跟踪管理。这真是一个狗皮膏药似的问题#xff0c;反反复复地#xff0c;隔一… 0. 目录 1. 现状/背景2. 需求管理存在的问题3. 改进思路/措施4. 所谓禅道尚未普及/铺开5. 最后6. 相关 1. 现状/背景
近期又被领导问到如何对项目过程中的需求进行量化和跟踪管理。这真是一个狗皮膏药似的问题反反复复地隔一段时间就得被再次提及。
究其原因除了过往在传统软件行业中技术团队的发展(现状篇)【DEVOPS】基于禅道 - 重构研发协作流程分别进行过总结的背景之外
我们的DEVOPS改良推进路线风格属于彻底的自下而上。除非拿出切实的已经试点成功的能够被直观感受到好处的改良结果领导才会进行明确的站台支持。上一条属于客观背景那么这一条就属于自身不足了 —— 一直以来向上管理意识有但是不多。没有做好成果汇报和信息同步同时缺少宣讲和对外输出。于是出现我们觉得时机早已成熟但是领导层对此知之甚少进而对于改良的推进犹犹豫豫畏首畏尾。
本文接下来的部分就是解决上面提出的这两个问题解释为什么我们认为现在时机已经成熟为什么存在一种在没有太大阻力不放弃底线的情况下能够将现代化项目管理流程推行下去的可能性。
注以下内容有个前提就是如【DEVOPS】基于禅道 - 重构研发协作流程组织内部已经有了成功的样例。
2. 需求管理存在的问题
以需求为抓手是项目管理过程中跟踪项目进度判断风险量化各个岗位贡献值的基本方法和思路。
但是现在的问题正是记录需求的变更过程以提供客观数据去反映各方的工作量这部分工作没有人做一是没经验二是没意愿而领导出于各类原因始终无法下定决心将这份职责指定给哪个角色。 于是无尽的扯皮在不同的项目组内接连上演
产品说研发效率太低研发说产品的需求总是变来变去。扯皮的时候双手赞同要搞标准化项目管理我要证明自己的清白但一旦摆出真的要进行改进的架势时候各种困难就出来了——哎呀本来就很忙了哪来的时候记录这个。也就是这个东西是很重要但是凭什么要我来做
于是又绕回了过往的惯性老路 —— 试图通过降低标准/无限倒退的方式来让规范/改良能够执行下去。
但是有些时候对于有些已经是基本要求没有后退之路的底线这个思路并不适用。
还是以需求的管理为例对需求进行持续跟踪的前提是有人去记录各个版本的内容并且建立它们之间的联系工具只是可以帮助我们减轻这部分工作量但对需求进行持续跟踪这项工作本身最终的质量以及相关方的满意度还是需要人来把握的。如果相关方连这个都不愿意做或者糊弄着做那么我们最终的目的很难达成。
3. 改进思路/措施
所谓工作量不会消失只会转移正如DEVOPS并不是消除了工作量而只是将其由人工转交给了机器项目管理中的对需求进行持续跟踪这件事情现在既然不能依靠于产品和相关售前/需求分析人员那么我们就下移一步交给有经验的研发团队来主导或占据关键节点该项目团队的原有其它人员进行辅助填充让有经验的研发团队推着其他人来适应这个操作流程。
我们来看看为什么这个移交存在可行性 我们推进DEVOPS就是使用机器操作逐步代替人工操作在此过程中借助机器操作特点借此来构建标准的工作流程最终保住产品质量的底线同时也显著减轻人员工作压力和心智负担。 并且我们在过去几年一直也在推进技术栈沉淀实现解决方案的标准化减少人员在所谓技术难点上的精力投入。 在禅道推进上过去几年我们分别在行业部门和基础平台部门结合各自当下现状对于禅道标准化研发流程进行了自适应改造/本地化改造做到了真正的落地。 3.1 这个真正的落地的第一层含义 本地化改造后的流程已经实现了在无需过多外力/监督介入情况下的自运转。 3.2 这个真正的落地的第二层含义 两个部门内部对于禅道的理解和使用完全不一样而且和禅道官方推荐的标准化项目管理流程也是差别甚大。
原有团队没有人愿意也没有一个额外的精力去监督和检查对需求进行持续跟踪那就让被解放出精力具备了基本需求管理流程经验的研发人员以及具备禅道本地化改造流程经验负责人来作为主导/关键节点引导该项目内的需求跟踪管理流程原项目组的其它人作为辅助参与进来在这个试点过程中
实现对当前项目对需求进行持续跟踪的基本要求同时培养/熏陶出一批具备基本素养的产品/需求分析人员并且迭代出一个针对性的流程既兼顾该业务线/该团队内相关人员的既有操作习惯又满足基本的标准项目管理流程要求为之后的流程优化打下基础。
4. 所谓禅道尚未普及/铺开
所谓禅道尚未普及/铺开正是以上改良措施出现的背景而且如果禅道已经铺开本文背景都已经不存在了也就是不会出现需求变更导致的扯皮问题。
我们提出的对策正是为了应对禅道尚未普及/铺开情况。
可以说现在这批人是幸运的至少公司给了他们这个过渡的阶段。一旦这个流程成型这样的人就没有机会了。因为到时候你要不是白纸一张要不就是已经知晓这些流程。一张涂满涂鸦的纸我们已经没有这个耐心去矫正了。
5. 最后
不要再讨论要不要用而是怎么用 始终在这起点徘徊一辈子都到不了。我们已经完全接受慢慢来这个现实是因为我们承认最终还是人决定了产品的质量所以我们愿意将这个过程慢下来克服人性中急躁急功近利的弱点拾阶而上一步步地向目标进发在这个过程中把人培养出来把事情做成。我们并非要求当下马上执行以上试点我们只是提供一种可能性一种如何在一个四面楚歌的情况下让好的变化发生。相较于过往的改良推进当下其实已经好多了毕竟现在已经再是0到1了
6. 相关
【DEVOPS】基于禅道 - 重构研发协作流程【DEVOPS】DevOps推进过程中的一些最佳实践阿里如何定义团队的研发效能《UNIX编程艺术》【DEVOPS】DevOps推进过程中的一些最佳实践3禅道官方推荐的标准化项目管理流程
