文章对以下5块Topic进行描述。
1，前文阐述
2，业、产、技分层协作测评
3，协作思考
4，测评建议
5，测评bug反馈
个人是DevOps岗位，公司目前在使用敏捷开发模式，我们是云效的老用户了，从2018年就在使用RDC，直到今年初正式迁移到云效2020上。从2020年底Flow的第一次尝试使用到现在全栈DevOps平台拥抱使用云效2020，可谓是看着云效成长，盼着云效功能落地。期间提过不少建议，给到云效团队同学，包括聆听采纳的也不少，觉得云效现在推出的业产技分层协作理念与BizDevOps理念非常契合，也是衷心希望云效能帮助众多中小企业降本增效，发挥业、产、技的价值。
本文说到Projex 这款项目协作工具，在这之前我们用的是RDC，有可能打开的方式不对，我们RDC一直是产品存放PRD，质量反馈bug的地方，没有打通全部生产力。这跟以往之前工作过程中，使用的禅道、Jira、Tower(已被ONES收购)等协同工具一样，只是在不同环境但功能相同的替代品。
直到我看到【使用云效管理业务、产品、技术分层协作】，才知道云效产品的与众不同，颠覆了我之前的认知。原来各个部门多年以来的沟通，协作问题，业务跟踪交付问题真的可以通过工具解决的。
下面我们通过教程，分别创建业务反馈、产品团队、技术开发等3个空间，以及一个诉求案例的演变路程来学习下吧。
由于我们账号已经在生产使用了，所以下面请忽略其它数据。
进入云效Projex界面点击导航栏。
创建项目
选择项目空间，分别创建业务反馈管理空间、产品规划空间、敏捷研发管理空间。
【业务】团队选择业务反馈空间创建；
【产品】团队选择产品团队空间创建；
【技术】团队选择技术开发空间创建。
新建空间，按需求输入业务侧相关信息。
此空间，我们定位为渠道，运营，销售等一线业务团队使用。
新建一个原始诉求
便于前线人员收集客户或者用户的真实诉求。方便产品部同事对接评估原始诉求。
此处一线人员遇到一个“我方的支付宝小程序端在使用下单后，需要推送短信”的客户需求。
这里分两大块， 诉求具体内容和诉求周边属性。
内容需要具体详细及真实，周边属性需要定位及标签化，方便后方团队识别。此处可以在参与者@产品同事
当然我们可以对诉求周边属性进行自定义修改
点击客户诉求
添加修改字段，这里是全局字段修改
如果只是单个空间修改，可以进入该空间，进行局部设置字段修改。
也可以对工作流状态修改
这是创建好后的业务反馈空间中的一条原始诉求。
业务团队的工作空间，创建完毕。
现在创建产品团队的空间。
上面来自一线的业务反馈诉求已经录入，后方的产品团队和业务团队的同事已经收到以上通知（诉求中编辑参与者）。产品承接后开始组织对原始诉求进行评审，通过后撰写产品需求文档(PRD)，并对原始诉求建立依赖关系。
此处先创建产品规划空间。
按按需求输入产品侧相关信息。
此空间用于产品、UI团队。
新建个主题
点击页面中新建主题或左侧导航栏主题，新建主题，并填写主题的属性：负责人、归属项目、参与者、价值、工作量、产品线等信息。
这些属性也可以在设置中自定义。
产品对以上业务反馈的原始诉求进行评审后，撰写主题，方便与后端技术团队进行评审对接。
此处产品同事就会对该诉求进行主题响应，同时在抄送者@技术同事。
对“小程序接入短信功能”的诉求进行产品目标拆解，比如大概工作量，需求改造价值，改造内容，改造的大概情况进行描述。
PRD越详细越好，包括不限于图文视频并貌展示效果，产品主题是关键，向上承接需求来源，向下拆解实施过程。
客户诉求与产品主题进行关联
建议使用依赖关联，因为依赖是有向关系，依赖方只有在被依赖方完成的时候才可以完成。此处案例中的
依赖关联是，原始诉求依赖产品PRD。当产品PRD后端被实现，或者状态结束，原始诉求才可以完结，被依赖后状态会自动同步。
当然原始诉求可以有多个产品主题依赖，单个产品主题也可以有多个后端依赖，可以是多对多的关系。
当然有时候主题有可能是一个大方向的需求，有些分散的小需求我们可以单独创建，然后在大方向的主题上进行关联管理。
主题是有多个散点的需求聚合而来的，产品同事对主题负责，进行业务价值规划和评估。
这是关联好的树形依赖，原始诉求和产品需求关联一目了然。
产品向下拆解实施过程中，必须需要技术的支撑。
新建技术空间，按需求输入技术侧相关信息。
此空间，我们定位为开发、运维、质量团队使用。
新建空间完成后，可以新建个需求，响应产品空间关于“支付宝小程序增加短信通知功能”的需求。
此处只是大概罗列了一些技术改造主题，如果复杂，可以创建多个子需求，然后对产品主题进行关联。
对产品空间的需求或主题进行支撑关联
如果有多个子需求，也可以进行关联。
甘特图展示，非常直观，
后续就是技术团队对需求的拆建和研发流程了。
此过程省略500工时...
等研发进入研发流程和应用发布流程的时候需要运维和质量大量支撑，这时需要Appstack一展身手了。
（前期规划评审产品需求的时候，这3个部门是需要一起参与。）
什么是Appstack？借用官方回答：
是一款开发者友好的、以应用为核心的应用交付平台，提供资源管理、应用编排、环境管理、部署运维、变更发布等一站式能力， 帮助企业建立应用交付整体解决方案，加速企业云原生与 DevOps 转型，提升团队研发效能。
在Appstack配置使用过程，本文身略若干图文。
我们需要对以上产品需求的工作项和应用变更进行关联。
这样每次业务需求下达后，技术侧能准确快速响应变更，同时产出CodeUP代码的变更分支，两者关联。
不过在使用云效Appstack 进行工作项关联的时候失败，无法遍历到之前创建的产品主题和需求。
不知道是不是Appstack侧的问题。测试尝试了所有当前项目，新建变更还是当前变更内都无法遍历工作项。
所以怀疑Appstack是不是功能未灰度开放。
后面查到确实是未开放，不过相信大家迟早可以体验使用。
以上就是 三个空间，围绕一个“支付宝小程序下单后支持短信通知”的诉求，在业、产、技三层的协作分享啦。
业、产、技代表三个不同部门，围绕着核心诉求，展开各自专业的分工，将协作融合为一体，最终交付成果。
我们把以上业务侧的原始需求到产品侧的拆解评审，再到研发侧的落地实现，用一张 全景关系图表达出来了。
非常清晰明了，知道需求是怎么被一步步落地实现的。
上文我也提到了，我们当前Projex 有使用，但不规范。只用于产品需求，bug缺陷跟踪使用。只是产品，质量，技术侧在使用。渠道，销售，客服，等同学都没有在使用。来自一线的原始需求，他们是直接传达给产品，产品根据理解润色后再在自己的项目空间里，描述成一个产品的PRD雏形。这样会存在“部门墙”的问题，无法拧成一根绳，无法开展更高效的团队协作和跟踪业务交付生命周期。
这是我们当前使用环境。
建议将规则，提醒和说明，直接写到该栏旁，方便客户识别。
比如项目编号，可提醒为：“用于识别唯一任务ID，任务编号的前缀，支持 4 - 6 位大写英文字母。”
默认的项目状态感觉设计步骤冗余了，点击待确认后，下拉框直接选择设计中、开放中这些变更状态。
现在是需要先点击 已选择这个过渡状态，感觉没必要。
当然这块内容后期可以在 设置-工作流 进行修改。
创建新的文档的时候，无法直接关联和依赖。
需要创建完毕，二次打开才能进行关联和依赖操作。
不清楚为啥不一步到位，直接进行新文档的关联操作呢？
图中可以看出，从原始诉求到产品规划，再到开发设计有了比较大概的流程关系图。
后期可以接入研发流程和发布流程图再到功能验收等。这样就是一个需求从发掘到实现的完整闭环了。
目前全景关系图还是不够全面，只到了Biz这端，DevOPS这块很多必要的功能流程图没有融入进来。
其次，全景关系图的入口需要一个明显的位置展示出来，方便整个需求实现关联的Team成员一目了然。
现在入口是打开一个工作项-查看需求 / 原始诉求 / 主题详情页面-再点击关系全景图才能查看关系拓扑图。
建议将该图直接放到空间列表，比如这里单独呈现展示。
Appstack 无法纳管当前已有的ACK应用，只能是新建的应用。
这样整个BizDeops流程完成还是比较不便的。建议抓紧灰度该功能。
咨询了云效的产品和技术同学，答复暂时不支持。
对Projex中的工作项使用甘特图(横道图)来展示项目进度管理，非常nice，非常专业，给云效产品经理点赞。
建议可以多采用下项目管理方面的知识。比如以上三层空间关系是否可以使用需求跟踪矩阵展示出来，在开发侧使用责任分配矩阵将开发团队相关干系人的职责列出来。
除了业务、产品、技术三层外，其它层的干系人比如项目经理，老板，甲方leader等更想直观的看到整个项目的进度，成本，质量，以及如何控制风险。可以对这些内容进行一些丰富和展示。
还有些其它方面的想法，比如对进度管理的时候进行范围确认，创建WBS的时候展示关联，对依赖进行前导图法展示。如果风险不可控，项目(需求)变更失败，怎么产出数据，查到问题出在哪；对变更流程的控制；如果进度落后，如何缩短活动工期，等等。
关联内容时候，在原始诉求无法遍历搜索到 产品主题。（都是本人创建的）
只能反向在产品主题里关联原始诉求。
关联成功后，再解除关联，就能在原始诉求里搜到和关联产品主题了。
在使用云效Appstack 进行工作项关联的时候失败，无法遍历搜索工作项，尝试了所有当前项目，新建变更还是当前变更内都无法遍历工作项。
Copyright © 2023 leiyu.cn. All Rights Reserved. 磊宇云计算 版权所有 许可证编号：B1-20233142/B2-20230630 山东磊宇云计算有限公司 鲁ICP备2020045424号
磊宇云计算致力于以最 “绿色节能” 的方式，让每一位上云的客户成为全球绿色节能和降低碳排放的贡献者
