7.8
深览指数
产品人人都是产品经理·AI产品零度··AI 生成
一个项目管理软件的诞生（九）：从 Project 到 Space，企业研发平台如何组织长期工作
本文的核心论点是：企业研发平台信息组织失序的根源，在于将「一次性交付」与「长期产品/团队工作」两种生命周期的对象混入了同一个名为 Project 的容器。作者提出应分离「长期归属」（Space）与「交付上下文」（Project），让工作项在稳定的空间中获取身份，再通过关系进入不同的交付计划，从而解决项目不敢关闭、历史反复迁移、配置不断复制等结构性问题。文章通过对比 Jira、飞书项目、ONES、TAPD 等产品，详细拆解了Space的定义、粒度、视图、工作台设计及从Project迁移到Space的实操路径。适合正在设计或重构企业级研发管理平台的PM、架构师及技术负责人阅读。原文 ↗
核心观点
- ▍一条工作项应有一个稳定的长期归属（Space），可以进入多个交付上下文；不同角色再通过视图读取和操作同一批事实。
- ▍将「项目管理学意义的项目」、「软件里的Project容器」和「日常语言的'项目'」三种语义混用，是导致产品问题被伪装成配置问题的根源。
- 01Jira将Project改称Space，并独立出Projects对象来表达临时交付；飞书项目直接采用空间模型；TAPD保留「项目空间」；ONES仍以项目为主要容器，再通过项目集向上聚合。
- 02低频变化的事实（如工作项归属）不应挂在高频变化的对象（如交付计划）上，否则身份会随计划漂移，导致团队不得不复制需求或不敢关闭项目。
- 03一个长期空间（如支付空间）下的工作项「支持银行卡分期」，可以同时被纳入「收银台升级」专项、第二十三次迭代、三点二版本等多个临时交付上下文，而不改变其稳定身份。
- 04判断空间粒度的标准不是组织图，而是四种稳定性：业务语言是否稳定一致、事实是否需要长期一起查询、规则是否经常共同变化、是否存在明确的长期治理责任人。
- 05一个可运行的视图需回答四个问题：选择什么数据、怎样组织、允许做什么操作、由谁维护。视图是查询与操作入口，不是数据副本，不能重新定义业务规则。
- 06个人工作台应以人为中心，通过统一用户身份与各空间工作项之间的责任关系（如负责人、处理人、评审人）动态生成行动队列，不复制完整详情页，也不能生成第二份状态。
- 07跨空间仪表盘要实现可信，至少需要四层处理：平台基础字段、字段身份（基于ID而非名称）、语义归一（如状态映射）、质量说明（缺失值、权限过滤等）。
反方 / 局限
- — 作者承认，跨空间语义对齐在企业级平台中必然面临取舍：覆盖范围越大，语义往往越粗；语义越精确，可比较的空间可能越少。平台需诚实呈现口径与局限性。
- — 迁移到Space模型时，直接新增一层并挂载旧Project可能会使模型更复杂。作者建议四步过渡：识别用途、拆出临时属性、建立兼容期、清理重复入口，而非一次性重构。
27 分钟 · 3 卡片 · 9 资料
读原文 →