DevOps｜我们需要什么样的产研项目管理工具

本文主要是介绍DevOps｜我们需要什么样的产研项目管理工具，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

这是一个首先要回答的问题。如果你所在的企业有非常苛刻的数据安全、保护、大量定制开发、信创软件合规要求等，那么只能选择支持私有部署的软件。SaaS软件无法满足你的这些要求。私有化部署也会带来成本高昂，需要专业人员支持等问题，这也是要同时考虑的事情。「欲戴王冠，必承其重」。

除了部署方式之外，我们考虑最多的就是产品的功能。

说话要讲究场合，做选择要考虑场景。在大公司从自己的环境中长出一个适合自己的项目管理工具是最好的，是适配的，也是合理的。但是对于很多中小公司，没有这个实力和无法支付这样的成本去自研一款自己的项目管理工具，那么去市面上找到一款适合自己的工具就是正确的选择。所以我们要有个清楚公司的定位，我们是什么样的公司，处于什么样的阶段，需要什么样的功能。

对于中小公司来说，除了功能之外还有一些需要考虑

产品成熟度。如果产品成熟度太低，虽然一些功能满足，但是还有大量的需求没有满足，选这样的工具就不是一个好的选择。

使用成本：功能很好，用得很棒，但是软件太贵了，企业无法承担，这样的工具也不是你的选择；这里所说的成本不仅仅是购买软件license 的成本，还包括硬件、安装、调试、培训的成本。比如某些行业用 jira多，行业属性非常明显，那么你采购 jira 成本就很低，只是软件license 和安装的成本，后面的培训、迁移都会水到渠成。不用你参与，用户就能找到最适合自己的方式。

从专业的角度去做选择当然有的团队或者个人选择的时候掺杂了太多的其它因素在里面，专家的意见和建议反而不那么重要了。有专家却没有发挥专家的优势。比如某国企老板考虑到公司和阿里云有合作，阿里云效打骨折半卖半送。其实这个时候公司未必需要云效，也未必能用好云效。

还有一种情形就是涉及到团队/个人利益，专家没有给出恰当的意见和建议，这也是存在问题的。如果有人都说的是假话，大家一眼便知；如果有真有假，这个难判断。如果有人只把有利于某方的原因说了出来，其它的没说，这更要命。因为他说的都是对的，把自己想说的话说了出来，并没有从专家的角度给出最优解。

我们考虑事情的时候要权衡利弊，很多老板都不是某个专有领域的专家，非常需要专家的意见和建议，但是专家却缺位了，没有从专家的角度给出专业的意见和建议。「老油条、很油腻」。除了上面的要考虑的因素，我主要从以下几个主要重要流程、动作或者说研发活动来筛选项目管理工具。因为这是产研项目开展过程中必不可少的活动，也是产研项目管理工具所必须要满足的。如果这些功能都没有，那么就要考虑这样的产研项目管理工具功能的完备性。缺失的功能你不需要，还是有其它方法（流程、工具）来补位。

需求拆解成用户故事

项目管理工具需要支持把用户需求文档拆解成一个个独立上线的对用户有价值、容易理解的用户故事（User Story）的活动。

通常来说我们的用户需求文档（PRD）会以一个在线文档的形式存在，有利于撰写、修改、协作和评审。PRD有大有小，优先级有高有低，这个时候我们就要把 PRD 拆解成一个个用户故事录入到项目管理工具中去。如果项目管理工具不支持用户故事，那拆分粒度就会变成一个需求文档，这对工作量评估和后续跟进就会是很大的挑战。一个需求关联很多任务，周期长短不一，导致这个需求久久不能完全全部完成。

UserStory001: 作为用户，当我输入正确的用户名和密码后点击「登录」按钮后就可以登录系统，以便于进入系统中我的工作台

项目排期

当我们把需求拆分成一个个用户故事后，这个时候我们就可以综合考虑用户故事优先级，团队速率等因素，对用户故事进行排期，把用户故事放到一个个 sprint 中去，有节奏地交付。

如果不按照 sprint 交付，设置了交付截止日期的用户故事，实际上也是一种排期的形式。

UserStory001，优先级P0，2人天，涉及前端和后端的修改

用户故事拆分到任务

一旦用户故事的排期确定了，我们就要把用户故事拆分成多个工作任务，评估工作量，然后分配到具体负责的人。

用户故事是按照对用户价值的完整性进行拆分的，我们还需要按照概要设计、详细设计文档中的的技术方案把功能涉及到的项目的实际模块、涉及到变更的范围进行更细粒度的拆分。比如一个上面的用户故事就需要前端和后端两个团队的协作。更多可参考《敏捷任务拆解、工作量评估和指派》

任务进度看板/敏捷看板

任务看板可以把进度可视化、团队协作透明、任务跟进和梳理，且可以通过支持不同的视图，让我们可以从不同的维度去审视我们的项目、团队和人员。具体可参考《敏捷开发之任务看板》

工作进度跟进和流程定制

从需求澄清到价值交付是一个很长的过程，中间还涉及到 coding、code review、building、testing等很多环节。但这段过程实际上是很难跟进的，也非常的不规范。这个时候我们就可以利用一些工具来自定义我们团队的工作流，来适合我们团队的实际情况。

比如我们的每个工作待办需要有：to-do, doing, testing,released 几个状态，此时有一个用户故事，拆解成了两个工作待办

当我们通过git 提交的代码关联到其中一个工作待办时，这个工作待办的状态自动从「to-do」变成「doing」

当我们把代码 MR 到 Master 上的时候，这个工作待办的状态自动从「doing」变成「testing」

当Master 上的代码发布上线后，这个工作待办的状态自动从「testing」变成「released」

同时工作待办对应的用户故事进度变成 50%，如果另外一个工作待办也上线了，那么用户故事的进度就是100%

数据驱动决策

正是因为产研运整个流程很长，很难简单地说清楚产品整体什么状态，每个人现在具体做什么，对整体的影响、做到了什么程度，进度如何。这个时候我们就可以通过各种报告和仪表盘，了解到项目的整体健康状况、进展和可能的问题。数据驱动决策（Data-Driven Devision-Making）

效能度量

在这一点上，很多工具都做得不是很好，好在现在的很多先进的工具都可以通过拖拽、设置维度和周期生成一些简单的度量看板。但是现在很多项目管理工具的主要使用场景还是在任务协同，虽然可以通过插件/hooks集成一些其它的工具，但是还是无法形成全链路的一个工具联动，有些数据难以获取和及时更新。研发效能度量道阻且长。

项目管理百花齐放

做到上面的功能就是一款不错的产研项目管理工具了么？不。具有上面的功能只能说刚摸到产研项目管理工具的门槛，想要成为「不错」的工具还差得很远。现在我们的很多工具很有特色，但是也只是在一两个点上做得不错。

我喜欢 upbase的简洁清爽，它却支持一个workspace有多个board，搞得又有点大了。我个人貌似不需要联合项目。

我喜欢 asana 的漂亮，又觉得有些功能做得复杂了

我喜欢Clickup 贴心的功能引导，吸引我把其它地方的任务导入进来，在这一点上其它任何工具做得都不如它。

相对于青春靓丽的 asana，monday就显得有点老气了

我最喜欢的还是 Team+Kone 的合体，丝一般顺滑

很多时候，我们考察一个工具要看疗效，不能只看广告。到底这个工具带来什么样的价值，要在实践中体现出来。

团队内高内聚，跨团队低耦合

就像上篇文章中所讲项目管理工具就是一个公司管理层思维方式和管理手段的体现。在项目管理工具上，我们也期望能做到「高内聚、低耦合」。每个团队内部管理好自己团队内部的事务，跨团队之间的耦合要低。A团队小朋友AA要关注B团队的某个任务，这样的场景，我认为要仔细分析其合理性。如果仅仅是AA小朋友给B团队提了个bug，B团队用不了多久修复就能上线了，关注与否没太大意义，除非这个bug block你的工作了。真的block很多人的工作，那就不是bug而是事故了。概率太低；如果AA小朋友给B团队提的是个需求，应该由B团队去评估；这两种情况都应该相信B团队的判断，在其团队内部处理和消化。

跨团队协作需要PMO和项目聚合

对于跨团队之间的拉通和对齐，项目进展的更新，一般需要两个团队业务负责人FTO的周期性同步；如果项目较大，可能需要PMO同学的协助，同时需要「项目集」把项目状态、进展和风险暴露出来。这个时候会议上同步的信息已经不是具体某一个工作任务的状态，而是整个项目整体的状况。通用的项目管理工具很难支持，但是支持软件研发领域垂直的项目管理工具就考虑到了这一点。

棒棒的用户体验和高效的任务管理

对于项目管理工具，我主要考察两点：用户体验和高频动作的高效性。用户体验很差的工具通常在工作的高效性上做得也不是很好。心情受到了影响肯定会影响到工作，体现在工作上就是效率低。用户体验好的工具，至少让我有更高的忍耐度。我可以容忍其某些非关键功能方面的缺失，愿意伴随其一起成长。漂亮的UI、丝滑的交互、超出用户预期的实现、时不时的一点小惊喜，那么地让人爱不释手，谁又能拒绝呢？

本文小结

我们要从功能和非功能等多方面来考察一个项目管理工具。对于产研运的小伙伴来说，项目管理工具是每天都要打交道的工具，其工具的用户体验和是否高效，影响着每位小伙伴的工作。我们要慎重选择。同时也期望公司的各位专家们能从自己专业的角度出发给出专业的意见和建议。一旦我们选择了一款工具，不妨「先僵化、后固化、再优化」，用它一段时间看看效果再说。