2019-10-26其实老师的课程提到一点：核心需求；经历过一些企业，和一些同行沟通过，如何梳理出真实的核心需求似乎是个典型问题或者说通病。
最核心最有价值的东西展现或挖潜出来才可能绕着去做：其实之前有学习极客时间里关于产品的课程，今天的课程中所提及的MVP的概念以及需求的价值，就像为什么DevOps是提升效率；当我们结合产品就会发现其中的核心理念是有所相通的。
进一步举例说明：产品经理为何很多时候和技术对立；可是如果是真正懂技术或技术转产品的会更加明白其中的方式方法。其实DevOps同样是一个产品：技术团队本身的产品。作者回复: 这个观点很新颖，很有启发，技术团队本身就是一个产品。产品思维和开发思维本身就是两种思维模式，这一点相信你也有所感受，如果产品人员懂技术最大的挑战就是两种思维模型并存，又不会互相干扰，实际上我见过很多技术人员做的产品，还是浓浓的工程师风格，但是用户不是工程师，所以这一点我觉得对于产品未来的发展也是一个挑战。
3
2019-11-081.卡洛模型我们的产品团队也有在用，但很遗憾的是，收效甚微差距巨大，但我深知不怪我们的产品团队。因为作为2b的业务，产品的价值都是业务方提出或者评定的。然后这个价值评定就是笑话，风风火火搞一两个月的大项目，原本业务提出能接入xxx客户，带来xxx价值，结果接入廖廖无几。当站在最前面的一波人都是来搞笑的，你后面再怎么折腾也翻不起浪。深刻觉得业务方都停留在我觉得，而没真真走出公司站在市场，用客观的数据和长期经验来评定需求价值。
2.mvp前面还有个mvp，在最小可行产品出来前，应该要筛选最小价值产品（v=valuable）。挖掘追小价值产品方案，排优先级，然后再制定最小可行产品，去试验反馈改进升级。业务驱动往上再看一点是价值驱动。但这种模式偏爱短期价值，势必会导致长期价值的产品难以推行。但就当下而言还是比较适用的，因为变化太快，长期价值的风险系数太高，贴现率太低了，远不如短期价值来得靠谱。展开作者回复: 很有感触，最开始做持续交付的时候，感觉自己找到的银弹，花了大力气建立了持续交付体系，等到给老板汇报的时候却发现很难量化证明自己的价值。对于IT团队来说，面对的情况就是这么尴尬。一个需求扔过来到底有没有价值，没有人知道，IT团队只需要把需求如期完成上线，然后就没有然后了。这个需求的业务价值从来不会跟IT团队透传，所以除了无穷无尽的需求，IT团队很难找到价值认同点。即便到了现在，也是如此，业务方没人敢碰，所有的体系能力都是从产品经理接受需求的时间点开始，到需求交付上线位置，始终缺少业务层面的价值体现，这也是目前我在思考的问题吧。
1 2
2019-10-31一切技术还是要围绕业务的需求来展开，作为后端的技术支持团队其实也可以主动影响业务需求的定义，从而适配之后整个开发流程。也许一个好的DevOps工程师就是一个业务和技术的翻译官吧作者回复: 我觉得翻译官的观点很有趣，我之前总说是桥梁，其实是一个道理。我老板之前问过我一个问题，当技术研究到一定阶段，下一步的方向和空间在哪里？他的观点就是业务。不是说技术不重要，但当你越参加高层的会议，就越发现讨论的都是业务数据，所以多留心业务方面总不是坏事哈。
1
2019-10-27关于用户需求故事的拆分，再进入每一个迭代，能否举一个具体例子？这样会更好理解一点。作者回复: 你好，关于用户故事的拆分，比较经典的有9种方法，其实主要用到的还是工作流步骤拆分（核心流程/支撑流程），接口可变性拆分（分享二维码/链接/通知），主要投入拆分（典型平台接入/其他同类平台接入），业务可变性拆分（根据热门排序/销量排序），以及业务操作拆分(功能拆分，比如管理用户/邮箱/留言)
另外，关于用户故事，有一篇非常经典的文章推荐给你，虽然是全英文的，但是讲解的非常透彻，值得一读：
[https://www.jpattonassociates.com/tag/product-discovery/](https://www.jpattonassociates.com/tag/product-discovery/) 1
2019-10-28感觉又把ACP的课上了一遍，不过老师你讲的挺好。作者回复: 感谢你的支持，加油，实践者
2019-10-28记得2015年我们公司负责推行敏捷开发的领导来培训敏捷，培训完毕后采用的是“自顶向下”的路径推行敏捷开发。
当时团队领导拿到需求后先拆分，将拆分后的需求写在纸条上面，贴在看板上让大家去领任务。
刚开始大家的积极性很高，每天有任务进度汇报，早上还有“站立会”。可是久而久之大家就疲惫了，没有人去关注看板上面的东西，也不再开站立会，又回到了原来的状态。
由此可见，知道容易，做到是很难的，尤其是在一个庞大的协作体系内。展开作者回复: 敏捷转型如果涉及到组织结构调整，那么也只能自顶向下来推了，说白了之所以疲惫了，两方面原因，要么是因为没有看到敏捷带来的好处，该半夜上线还是半夜上线，只不过迭代速度快了，压力大了，事儿多了而已；要么就是节奏绷的太紧张，没有劳逸结合，比如最简单的例子，每个迭代周期里面，有多少业务需求，有多少改进类需求，有多少技术预研需求，很多我猜都是120%的业务需求，那要如何坚持下去呢。