刘祯 置顶2017-12-07最近就遇上了需求变更，是在项目开发过程中发生的，早先的需求文档讨论都已确认，可在真正开发过程中却发现因为数据结构与真实性考虑，将原有流程重新拆分。此时面临着马上就要发布版本的情况下，好在开发还没做到这一步，临时变动还有挽回空间，只是项目上线压力更大了，最后那个例子看完了真的深有感触，我也希望遇见心态如此淡定的开发同事。
回顾工作，我的经验就是两点：一是需求评审一定要细致；二是产品迭代一定要迅速。
我们总说要设立项目里程碑与节点，可实践中却总是有各种问题，可能和公司整个管理方式有关吧。
继续修行。展开 9
2017-12-07写的很具体，很有参考价值。很喜欢和这样的产品经理一起工作，可以有很多机会蹭烧烤吃哈哈。作者回复: 哈哈哈哈哈哈好哇欢迎
10
2017-12-21站在一个开发角度，结合敏捷实践，谈谈自己的想法：
1. 团队的整体设置一定是快速响应变更的，需求的变更程度和sprint长度成反比，这个对于dev team的要求极高；
2. 做技术的一定要积极投入需求评审会中，不断challenge产品经理，一方面帮助他们更多思考，另一方面探究自己的理解对不对，一定不能闷头执行；这就要求dev team一定是跨职能的，否则在开会时就他妈是走过场；
3. 在技术层面，快速响应变更后面意味着有一套完整的TDD，CI/CD流程，否则无法形成可靠的workflow。
依然在不断践行中........展开 9
2017-12-07哈哈哈哈哈哈我用PS+PPT，不仅做静态原型，偶尔还做小动效。PPT打到屏幕上还是比用网页好的，6的屏幕750*1334，两侧空出黑色留白，视觉效果很集中。作者回复: PPT 的交互效果好像可以做得更酷炫
8
2017-12-07赞同“留给需求发酵的时间”，实际工作中要求是当前版本提测时下个版本就要需求评审，但由于白天时间被各种“会”占据，经常只有晚上才有时间发酵需求，很容易陷入疲惫的循环。二爷能简单讲讲日常产品工作流或精力分配么，谢谢 7
2017-12-21把需求文档凉了半天再去看，发现调整的地方还是有的，以前是不想看自己已经做完的东西，现在要勇敢面对。作者回复: 看过去的东西觉得不完美，也说明自己进步了
6
2017-12-07二爷这都是血的教训的总结啊。我们团队是技术、设计、老板一起讨论需求，让设计出设计稿，大家一起填坑和优化。没有产品经理这个职位。 6
2018-06-07这上下两篇写的好。作为研发，我终于了解了需求变更的前世今生。同时觉得，产品经理真不容易，笑哭😂 4
2017-12-07这不光是硬汉，更是大牛作者回复: 嗯，硬汉一般都挺牛的
4
2017-12-07看过一个段子：
「产品经理经常变更需求怎么办？」
「打一顿就好了……」
有时候需求变更是没考虑周全，这时如果有比较充裕的需求发酵时间，可能可以减少被打的次数，因为没准自己就把自己给打了，自己打自己下手可以轻点。
有时候是不得不变更，比如有更好的满足需求的方案了。感觉无论哪种情况，第一时间「自首」特别重要。跑过去，相视一笑，嘻……嘻嘻嘻，嘿……嘿嘿嘿，「兄弟喝什么奶茶？我请」，等愉快的喝完奶茶后，「这个功能如果我们这么做，你觉得怎么样？」，在奶茶带给人的愉悦感还没消失的时候，一般就不太会被打了，即使被打，也会轻一些。展开作者回复: 哈哈哈哈哈哈哈哈哈哈哈哈哈
3
2018-04-14最近接手了个半路撂挑子的项目，前任不明确的需求在我提给研发的时候收到了负面反馈。
他的意思是我做好了你为什么要改？
我的想法是你做的是错的我这不是新需求只是 提 bug。
不欢而散。
最近越来越觉得，有个认真负责的产品把需求都想清楚，可以避免很多无用功，接过别人几个烂摊子之后就很反感人人都是产品经理这个说法，其实产品的门槛不低，不是人人都能做的来的。展开作者回复: 产品经理进门的门槛不高，但做到合格挺难的
2
2018-01-02虽然是产品实习，但是已开始看到二爷说的所有产品变更的场景。作者回复: 常态，习惯就好了
2
2017-12-26其实我就一直觉得需求评审很无聊，我们的需求评审叫KT～knowledge transfer ，含义就是将需求同步各方。所以其实需求评审，我理解，其实就是需求的最后一步，最关键的都在评审前。
需求变更，我们的定义一般处于评审之后到kick off之前，如果已经开发了，再变更，基本要挨刀子，小的变更还好，出个邮件，更新下文档就可以，开发基本能忍，如果大的改动，基本都要重新需求评审重新走流程，不管开发是否要求，从需求准确性考虑都要这么走，否则，很有可能到时候需求没同步到位，导致坑一大片 2
2017-12-25对于投入产出比的权衡，是一个产品经理很重要的能力，同时也是不断学习的目标。对于二爷提出的通过流程来对抗变更，深有同感啊，看似降低了成本，实则严重降低了效率。作者回复: 嗯 有时候只想着用流程来限制问题发生，却忽视了流程可能带来的伤害
2
2017-12-18原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。
这里有个前提很重要， 找到对的人。 知道谁是对的人这个也是职场需要锻炼出来的。作者回复: 没错，在不知道怎么识别的时候，一般是直接找项目的技术负责人，如果他完蛋，基本项目也就完蛋了
2
2017-12-07拥抱变化，做到不易，即需要开放心态，又要能力过硬作者回复: 情绪也要稳定
2
2018-10-20硬汉 1
2018-01-27我是技术，也是特别讨厌改需求，不过，也是可以理解的，一切都是为了做好产品 1
2017-12-15经历过二爷说的变更基准线的制度，确实会出现这样的问题，做法就是暂停现有的开发，需求方新提需求，再一起重新开发。这样开发流程很长，然而，没关系！领导认可作者回复: 传统软件公司可以理解，互联网企业这么做效率太低
1
2017-12-12关于最后一点，让团队消化需求变更。其实也是产品的沟通能力之一，还有就是公司工作流程问题。需求变更出现在各个层级，领导要求变，ui设计又要变，开发过程中又会变又或许是需求方的业务需求变，那么对于这些场景来说，该用什么样的语言跟对方沟通？作者回复: 对方是什么世界的人，就用什么语言。比如跟开发尽量用技术语言，跟业务多说业务语言，争取打成谅解
1