上海网站建设技术托管,建站之星破解版下载,潜江市网站,seo综合这是一个首先要回答的问题。如果你所在的企业有非常苛刻的数据安全、保护、大量定制开发、信创软件合规要求等#xff0c;那么只能选择支持私有部署的软件。SaaS软件无法满足你的这些要求。私有化部署也会带来成本高昂#xff0c;需要专业人员支持等问题#xff0c;这也是要…这是一个首先要回答的问题。如果你所在的企业有非常苛刻的数据安全、保护、大量定制开发、信创软件合规要求等那么只能选择支持私有部署的软件。SaaS软件无法满足你的这些要求。私有化部署也会带来成本高昂需要专业人员支持等问题这也是要同时考虑的事情。「欲戴王冠必承其重」。 除了部署方式之外我们考虑最多的就是产品的功能。 说话要讲究场合做选择要考虑场景。在大公司从自己的环境中长出一个适合自己的项目管理工具是最好的是适配的也是合理的。但是对于很多中小公司没有这个实力和无法支付这样的成本去自研一款自己的项目管理工具那么去市面上找到一款适合自己的工具就是正确的选择。所以我们要有个清楚公司的定位我们是什么样的公司处于什么样的阶段需要什么样的功能。 对于中小公司来说除了功能之外还有一些需要考虑 产品成熟度。如果产品成熟度太低虽然一些功能满足但是还有大量的需求没有满足选这样的工具就不是一个好的选择。 使用成本功能很好用得很棒但是软件太贵了企业无法承担这样的工具也不是你的选择这里所说的成本不仅仅是购买软件license 的成本还包括硬件、安装、调试、培训的成本。比如某些行业用 jira多行业属性非常明显那么你采购 jira 成本就很低只是软件license 和安装的成本后面的培训、迁移都会水到渠成。不用你参与用户就能找到最适合自己的方式。 从专业的角度去做选择当然有的团队或者个人选择的时候掺杂了太多的其它因素在里面专家的意见和建议反而不那么重要了。有专家却没有发挥专家的优势。比如某国企老板考虑到公司和阿里云有合作阿里云效打骨折半卖半送。其实这个时候公司未必需要云效也未必能用好云效。 还有一种情形就是涉及到团队/个人利益专家没有给出恰当的意见和建议这也是存在问题的。如果有人都说的是假话大家一眼便知如果有真有假这个难判断。如果有人只把有利于某方的原因说了出来其它的没说这更要命。因为他说的都是对的把自己想说的话说了出来并没有从专家的角度给出最优解。 我们考虑事情的时候要权衡利弊很多老板都不是某个专有领域的专家非常需要专家的意见和建议但是专家却缺位了没有从专家的角度给出专业的意见和建议。「老油条、很油腻」。除了上面的要考虑的因素我主要从以下几个主要重要流程、动作或者说研发活动来筛选项目管理工具。因为这是产研项目开展过程中必不可少的活动也是产研项目管理工具所必须要满足的。如果这些功能都没有那么就要考虑这样的产研项目管理工具功能的完备性。缺失的功能你不需要还是有其它方法流程、工具来补位。 需求拆解成用户故事 项目管理工具需要支持把用户需求文档拆解成一个个独立上线的对用户有价值、容易理解的用户故事User Story的活动。 通常来说我们的用户需求文档PRD会以一个在线文档的形式存在有利于撰写、修改、协作和评审。PRD有大有小优先级有高有低这个时候我们就要把 PRD 拆解成一个个用户故事录入到项目管理工具中去。如果项目管理工具不支持用户故事那拆分粒度就会变成一个需求文档这对工作量评估和后续跟进就会是很大的挑战。一个需求关联很多任务周期长短不一导致这个需求久久不能完全全部完成。 UserStory001: 作为用户当我输入正确的用户名和密码后点击「登录」按钮后就可以登录系统以便于进入系统中我的工作台 项目排期 当我们把需求拆分成一个个用户故事后这个时候我们就可以综合考虑用户故事优先级团队速率等因素对用户故事进行排期把用户故事放到一个个 sprint 中去有节奏地交付。 如果不按照 sprint 交付设置了交付截止日期的用户故事实际上也是一种排期的形式。 UserStory001优先级P02人天涉及前端和后端的修改 用户故事拆分到任务 一旦用户故事的排期确定了我们就要把用户故事拆分成多个工作任务评估工作量然后分配到具体负责的人。 用户故事是按照对用户价值的完整性进行拆分的我们还需要按照概要设计、详细设计文档中的的技术方案把功能涉及到的项目的实际模块、涉及到变更的范围进行更细粒度的拆分。比如一个上面的用户故事就需要前端和后端两个团队的协作。更多可参考《敏捷任务拆解、工作量评估和指派》 任务进度看板/敏捷看板 任务看板可以把进度可视化、团队协作透明、任务跟进和梳理且可以通过支持不同的视图让我们可以从不同的维度去审视我们的项目、团队和人员。具体可参考《敏捷开发之任务看板》 工作进度跟进和流程定制 从需求澄清到价值交付是一个很长的过程中间还涉及到 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 贴心的功能引导吸引我把其它地方的任务导入进来在这一点上其它任何工具做得都不如它。 相对于青春靓丽的 asanamonday就显得有点老气了 我最喜欢的还是 TeamKone 的合体丝一般顺滑 很多时候我们考察一个工具要看疗效不能只看广告。到底这个工具带来什么样的价值要在实践中体现出来。 团队内高内聚跨团队低耦合 就像上篇文章中所讲项目管理工具就是一个公司管理层思维方式和管理手段的体现。在项目管理工具上我们也期望能做到「高内聚、低耦合」。每个团队内部管理好自己团队内部的事务跨团队之间的耦合要低。A团队小朋友AA要关注B团队的某个任务这样的场景我认为要仔细分析其合理性。如果仅仅是AA小朋友给B团队提了个bugB团队用不了多久修复就能上线了关注与否没太大意义除非这个bug block你的工作了。真的block很多人的工作那就不是bug而是事故了。概率太低如果AA小朋友给B团队提的是个需求应该由B团队去评估这两种情况都应该相信B团队的判断在其团队内部处理和消化。 跨团队协作需要PMO和项目聚合 对于跨团队之间的拉通和对齐项目进展的更新一般需要两个团队业务负责人FTO的周期性同步如果项目较大可能需要PMO同学的协助同时需要「项目集」把项目状态、进展和风险暴露出来。这个时候会议上同步的信息已经不是具体某一个工作任务的状态而是整个项目整体的状况。通用的项目管理工具很难支持但是支持软件研发领域垂直的项目管理工具就考虑到了这一点。 棒棒的用户体验和高效的任务管理 对于项目管理工具我主要考察两点用户体验和高频动作的高效性。用户体验很差的工具通常在工作的高效性上做得也不是很好。心情受到了影响肯定会影响到工作体现在工作上就是效率低。用户体验好的工具至少让我有更高的忍耐度。我可以容忍其某些非关键功能方面的缺失愿意伴随其一起成长。漂亮的UI、丝滑的交互、超出用户预期的实现、时不时的一点小惊喜那么地让人爱不释手谁又能拒绝呢 本文小结 我们要从功能和非功能等多方面来考察一个项目管理工具。对于产研运的小伙伴来说项目管理工具是每天都要打交道的工具其工具的用户体验和是否高效影响着每位小伙伴的工作。我们要慎重选择。同时也期望公司的各位专家们能从自己专业的角度出发给出专业的意见和建议。一旦我们选择了一款工具不妨「先僵化、后固化、再优化」用它一段时间看看效果再说。 文章转载自laofo(公众号scmroad 原文链接https://www.cnblogs.com/laofo/p/17964493 体验地址引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构
