前段时间， Atlassian 发布消息称，其将于明年 2 月，停止销售新的 Jira Server 版本产品许可证，并于 2024 年 2 月，停止对这部分用户的支持（下图）：
图片来自：Atlassian 速递公众号（Atlassian 中国官方公众号）
对正在使用 Jira Server 版本的用户来说，这是一个坏消息。Atlassian 给到用户两种选择：转用 Data Center 版本，但该版本只面向 500 人以上的企业，且一年订阅价格是原来购买价格的3-5 倍；或（被）上云。
Atlassian 之所以做出这个决然的决定，是为了集中精力打造下一代产品，加速拥抱云原生。Jira 从 20 年前的缺陷管理工具不断扩展为研发管理工具平台，其架构潜力已经耗尽，必须集中精力重构。
Agilean基于多年的敏捷咨询经验，打造出了全新的创新管理中台产品-知微，她具有人事合一、支持产品项目双模和端到端管理、中台组件化等Jira 不具备的先进特征，而这些特征，全都是新时代企业管理的刚需特征。下面，就让我们来一条一条的剖析对比，相信读者读完会明白，应该直接放弃 Jira，拥抱知微。
1
更先进：人事合一 VS 以事为主
目前，市场上许多软件工具，包括 Jira 都是以管事为主的思路，人在系统中只是一个用户而已，针对人的分析相对简单，而组织在系统中的目的往往是授权单位，呈现树状组织结构，针对组织结构的分析和展现更为薄弱。
知微在设计之初就强调人事合一，人和事一起管理，交叉统计。事情是人做的，要管事，要先管人，以人员效能、组织效能评价作为推动力让事情发生。为了做到敏捷组织的效能统计，知微支持组织结构自由定义，支持树状，网状，甚至三维组织架构，而许多工具只能支持树状组织结构。
针对组织内的成员，知微支持增加各种自定义标签，实现对组织成员数据的各种数据实时分析，如开发测试比、行编外包比、产品开发比等。在国内多家银行，他们都用知微实现了全行的科技人力资源看板，实时管理行员外包的人力分布情况。
图 / 知微管理人力资源和结构示意图
同时，基于灵活的组织架构，知微可以把吞吐量、处理时长等事情处理情况的指标，展示到组织大屏上，让组织效能一目了然，建立组织效能数字化反馈机制。
知微还支持组织目标管理，将组织目标和量化结果和事情关联起来。让做事的人明确目标，以终为始。
图 / 使用知微影响地图功能进行目标管理
对管理软件来说，实现人事合一的管理，更符合新时代组织管理的需要。将人、事、组织、目标结合，有助于提升成员做事时的「使命共振度」与「任务价值度」，不断优化组织的协同力，并促进组织架构的不断演进。
2
更全面：创新管理 VS 研发管理
Jira 一直以研发为核心场景，界面比较复杂，这对研发人员尚可接受。但随着创新团队的逐步专业化，业务人员、产品经理、设计师、运营人员等，都需要参与协同。这时 ，Jira 的低易用性就成为创新团队日常的槽点了。
知微采用了全新的界面设计理念，从第一天开始，知微就以业务人员能接受作为界面交互基本要求，快速简易满足 80% 常用需求，而又提供进一步进阶功能来满足研发人员的进阶要求。
以过滤为例，知微提供自定义视图模板的能力，组织管理员可以为团队大多数人直接配置默认菜单和视图，让团队只看到自己应该看到的内容，例如某小队的系统任务看板、列表等。
同时，知微提供了快捷过滤功能，能够让小队成员可以快捷过滤，例如本小队，某个版本的系统任务。对于进阶用户，也可以利用组合过滤，来实现复杂的过滤需求。知微的所有过滤功能都是零代码实现，不需要用户编写复杂的 JQL。
知微从 4 年前编写第一行代码开始，就确定了零代码的设计目标，我们希望将可视化、数字化管理能力，以零代码配置化的方式，提供给零基础的业务团队、管理团队，实现管理分析能力的普及化。
3
更拟合：产品为中心 VS 项目为中心
「项目」是 包括 Jira 在内许多管理工具的核心概念。这一点都不难理解，这 20 年来，项目管理一直是主流的企业内部管理方式，万物皆项目，一家企业一年 1000 个项目也不奇怪，这其实是对项目的误用。
这完全是对项目管理的误用。项目管理作为一种管理手段，应该主要用于少数场合（构建新产品，产品重大升级等）。一家成功的企业，日常管理模式应该是产品管理，而不是项目管理。
《How Google Works》中写道，提供出类拔萃的产品是企业成功的关键，产品甚至比掌控信息、垄断渠道和强力营销更重要。因为项目只能给企业带来线性成长，而产品才能给企业带来幂律成长。
因此，一家成功的企业，需要同时使用产品管理、项目管理两套管理体系。这方面 Jira 非常呆板，因为 Jira 已经内建了自己的术语体系：项目（Project）-史诗（Epic）-用户故事（User Story）-子任务（Subtask）都是内建写死的。需要用户去适应 Jira 的术语体系。
我们在导入了产品管理机制的客户处，在他们使用 Jira 时，经常听到这样的绕口令：「我们的 A 产品是一个 Jira 项目，构建产品 B 的项目 X 也是一个 Jira 项目 」。这无疑是定死的呆板术语造成的一种管理混乱。
知微在构建之初的另外一个初心就是空杯心态。知微是一个中台，我们只提供基础能力，如卡片、关联、指标、行为等。知微是一个空杯，让客户按自己的想法去染色，完美契合成熟企业在发展过程中的自有术语体系，从而降低宣导和理解成本，而不是把我们的术语强加给他们。
对于初级用户，知微会和行业解决方案专家一起，提供行业标准的轻量级解决方案，无障碍直接上手使用，先使用再逐步优化，逐步找出适合自己的模式。
因此，知微更像是一个「企业自己的软件」，管项目、管产品、管业务，知微都可以做到更灵活更适配。
4
更自然：价值流 VS 状态机
Jira 描述事物状态的方式是状态机，如下图所示，是一个网状结构。
状态机是适合机器的状态表达方式，对人类来说过分复杂了。人类对状态的理解基本上是线性的，这也是为什么大多数 Jira 客户，是在用状态机实现了一个线性价值流。
然而，Jira 为了状态机的这层复杂性，付出了非常大的成本。客户为了展示看板，还得自己再定义状态机和看板价值流的映射。
知微正是意识到了 Jira 和其他产品在这方面的不足，才创新性地直接用价值流来表现事务状态，这非常符合精益思想。
这一简化，为知微带来了非常的能力提升，例如，知微可以非常容易地提供分段的时效统计，做完一件事，每段花了多少时间，如下图所示：
一个需求从提出到上线30天，需要知道需求编写、设计、开发、测试等环节各花了多少天，由此找出哪个环节慢了、哪个环节影响了整体交付速度，并进行有针对的改进。使用价值流的知微可以轻松实现这种分段时效统计功能，这正是基于线性结构的灵活性实现的；使用状态机的 Jira 却很难实现。
因为简单所以强大，其实底层模型越复杂，上层能力会越受限，知微在这个方面大胆简化底层模型，从而更用户带来更强大的功能。
5
更开放：中台 VS 平台
Jira 是一个孤立生态，靠插件完善自己；知微是中台，主动融入客户工具生态。
相信大多数读者对 Jira 的插件都有所了解。Jira 的思路是自己作为一个平台，用户可以用插件扩充平台能力，并嵌入 Jira 的插件体系中。种类繁多的插件丰富了Jira的能力，但是也需要客户付出了额外购买成本和维护成本。
Jira 「生而孤立」，企业可以用 Open API 来调用 Jira ，反过来却很难将 Jira 整合到自身的工具体系内。
知微诞生于中台时代，将自己定位成是组织工具体系的一环（ 如 DevOps 工具链），既可以作为独立的产品，提供完整的数字化管理能力；同时也可以被整合到企业工具体系中。
图 / 知微作为中台提供的效能分析能力（部分）
例如，2019年，知微作为效能分析和研发成本管理中台进入了一家 3000 人规模金融科技公司的工具体系，在不改变该公司已使用多年管理系统的前提下，通过微前端等技术，嵌入其自有系统，将其不同系统、工具的数据同步到知微中进行分析，以中台的形式，让企业直接获得如研发行为分析、数字化效能分析、工时管理、成本资本化等能力。
图 / 知微微前端技术
6
更快速：微服务 VS 单体应用
从底层上，Jira 是单体应用，知微是微服务架构。
单体应用问题就在于横向扩展困难，难于支持高并发。之前大家对 Jira 的使用都是零散的，但随着敏捷站会机制的普及，Jira 即便使用 Data Center 版本也无法支持几千人同时开站会的高并发场景。
而知微采用最先进的微服务架构，由十几个微服务组成，天生具备横向扩展能力，可以通过横向扩展来支持这种该并发场景。
现在，是时候重新选择
这次停售事件后，企业是时候重新选择了。至于未来的替代方案 Data Center ，也需要考虑上文我们对比的几个方面：
是只管项目，还是产品+项目？
是只管研发，还是业务产品研发全流程？
选能力全面且适应的，还是不停的用插件去补短板？
让工具融入自身体系，还是逼自己去适应工具？
几十人，百人，千人，还是万人？
所以，是时候重新考虑你的选择了。正如文中所说，知微是一个中台，理所应当的支持 Jira 等工具/系统的数据迁移和同步，能够实现从 Jira 到知微的稳定平滑过度：
工具不存在绝对的最好，只有「是否合适」与「是否更好」。是否合适，需要结合企业实际情况来看，或许可以参照上一节的几条。但无论如何，只有适应企业的工具，而不应存在适应工具的企业，削足适履必然引发更大的问题。
如果认为知微更适合您，想要更深入了解，欢迎在公众号回复「试用」免费试用知微，或在公众号回复并留下联系方式与我们沟通，也欢迎您提出遇到的、想解决的问题，相信我们一定能帮到您。
847
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
