最近，无意中看到阿里云效推出了新的功能，需要进行评测，整好这个方案和我实际遇到的情况比较贴近，所以花点时间写下评测，表达下自己的看法。
用户背景
一线DevOps实践者，平时喜欢研究各类DevOps平台工具，对项目管理和敏捷精益只是略懂，不是专门研究这个方向的，但是遇到过云效业产技所要解决的问题，确实现实中，是有这样的情况，并且很复杂。
文案感受
对于文案的介绍和整体设计，我是很理解，并且认为确实能解决现实中的痛点。项目制和产品制完全是不同的，如果是仅仅做一个项目，或者说你的组织完全按照敏捷实践，产品经理和研发都是在一起工作或者同属于一个部门，确实没有这样的问题。
但是对于产品制的公司，这里可能说的主要是2b的传统软件产品公司，客户诉求，售前反馈，产品经理，需求分析师，再到研发团队，这个链条是很长的，常常上下游的信息是不互通的，只能靠拉会沟通解决，甚至扯皮的情况，比比皆是。从DevOps的角度，研发最终交付的是明确且合理的需求，但是从原始需求到明确可开发的需求，这个过程是很不好管理的，甚至都是没法度量和跟踪的。
云效业产技（BizDevOps）分层协作方案，其实解决的就是这一类问题。
用户体验&疑惑
- 创建项目空间 后，我的第一个疑问是 团队权限问题。 按照云效的设计思想，一个组织（公司）是一个账号，那么组织下的团队呢？团队和项目什么关系呢？
如下图所示：如果是一个团队，下面项目是可以理解的。 如果像宣传文案上的那样，团队的概念在哪里？如果说，这里项目背后就是一个业务团队，也算可以理解
- 在“业务反馈空间” 下创建 原始诉求 后， 不知道下一步该做什么，按照 此次的BizDevOps分层协作方案，这些问题类型 之间，都是有关系的，父子关系，依赖关系等，但是 在新建 工作项 时候没有体现，只是在关系全景图 才看出来关系
如下图所示，每个工作项的类型间应该明确关系类型，比如原始诉求下 只能是某个需求类型，而不是能其他类型，不能随便关联或者随便拆分。
- 比如原始诉求再更改状态时候，是否应该严格限制？必须要关联需求，不然随便改状态，上下游其实是脱节的，作为业务需求方，原始诉求 到底谁再承接处理，谁在设计？
- 以下三个空间里都有缺陷者类型，还有专门的一个缺陷空间，属实让人有点迷惑，难道缺陷不是项目的一部分吗？为什么单独还有个缺陷空间？
- 缺陷-需求之间的关联衔接，建议做些加强，比如这个缺陷引入的原因是什么？谁引入的？有助于做根因分析。
- 经典项目管理空间里， 里程碑感觉没开发完吧，里程碑应该是划分成不同阶段，每个阶段下有不同的任务。目前感觉没有和任何其他部分有关联。
- 敏捷项目空间的需求能分配到传统项目的任务去做？没太理解
总结
先说好的地方，整体方案确实能够解决现实中的问题，现实中，标准的特性团队是不常见的，部门墙是很严重的，云效业产技（BizDevOps）分层协作方案确实能够解决这样的问题，对组织的架构影响是很小的。
再说整体实际操作下来的感受
- 把“业务反馈”，“产品规划”等作为项目来看待，是否合适？不管是从表述，还是理解上，都让人困惑。为什么不把“业务反馈”，“产品规划”分别做成 “原始需求池” 和 “产品规划” 2个功能模块呢？研发项目（敏捷/瀑布）还是项目
- 权限问题，实际企业场景里，部门组织架构是个很重要的概念， 但是在云效整个上面没有体现，组织部门和这些业务什么关系？这些业务需求又和哪个部门有关？这些最终可能涉及到部门的绩效和业绩
- 从工作项（原始诉求，需求，主题，任务）的关联上来看，有点凌乱，是否能够清晰定义工作项的关系和意识，之间的操作衔接感觉不出来。 如果A创建了原始诉求，下一步该做什么？工作流的下一个环节对应的人是谁？他应该做什么？如果按照这个图的设计，怎么流转到下游的空间？没有看出来。
- 从用户视角，比如研发经理，我应该和外部的原始诉求，内部的研发需求都有关系，我到底该去那里看？这里主要问题，还是第一点提到的，业务线是个长期的，项目更多是短期或者周期的，放在一起平等看待是不合适。
- 原始需求池
- 产品规划
- 项目列表
按照这样的业务顺序调整菜单，是否合适？本质上还是一个个库，但是能体现先后顺序。不同的工作项严格定义在不同的空间里（甚至不允许出现同样的类型出现在不同类型空间里）。
最后，再有一围绕某个业务的全局关系视图，更清晰。
- 未来，新版的 项目协作Projex 是否会替代当前的 项目协作？如果是替代，似乎没有看到和下游研发工程（流水线）相关的信息。
