敏捷开发：不要把头脑风暴会议和方案确定会议放在一起
产品经理由于自身认识方面的不足，是需要经常向团队其它专业成员请教或讨论的。而这种讨论呢，有时候可以组织个会议进行头脑风暴，
有时候甚至根本不需要多人会议，而是产品经理直接去进行一对一的讨论。
当这些讨论与了解差不多，产品经理综合出的方案需要开会确认通过了，
这时候围绕的一个中心就是方案尽快“定”下一个可以确认执行的版本。
关于执行环节中的“定”和“盯”。
如果在执行环节的会议上还同时想进行头脑风暴，那么会议的主题就无法控制在一个方向上。
本来一二次就可以通过的主体决策会议，可能要讨论到三四次以上才能达成。
甚至最终是因为大家都疲惫于会议了，草草的说好吧，就这样做吧。
其中任何一个创意点都是可以不断发挥并展开讨论的，
但是在执行的层面上，一定有适合当前最应该决策的主要部分。
个人建议把头脑风暴或学习留在平时零散的交流中，
而不是动不动组织会议，大家你一言我一语地去讨论。
所谓快速开发就是在执行环节使用最成熟有效的经验，不要在执行环节再讨论太多的创意，、
对于创意可以在执行环节之外，头脑风暴时自由讨论，
把其中讨论比较成熟的部分在下一个迭代周期更新上去，
始终保持先线上的产品简单成熟可信赖，这样一步步让产品走向极致。 学习。 中国盛产：批评家，教育家 有道理，时间就在无效的会议中度过了 很有道理，有时间往往在需求评审会上争扯不休，正题和方向反而不重视了。 有时候太过于追求细节，忽略了大方向的把控 唉，我现在最害怕的就是和老板开会，每一次都会有新的想法，还言辞凿凿的让贯彻下去，导致需求经常改变 深有体会啊，总想符合大家的品味，并且一步到位的话，问题是好大的！ 好！学习！ 我们公司也是敏捷开发，正在学习中 学习， 头脑风暴的一个原则就是不要否定。 根据这个原则头脑风暴会议只适合获取创意， 而不应该产生任何定论。 1# 尹广磊
学习~~~ 在第一次做一个终端主产品的时候就犯过这样的错误，在执行过程中发现之前没有考虑周全的地方临时改变方案及设计思路，导致项目没有办法按预期执行。现在是吸取教训了 受教了 有道理，具体实施看公司吧 真实感受，和1到2个人是讨论，和3个人以上就变成争论了，再然后就是无休止的。。。。一轮又一轮。努力学习沟通技巧，还有下回：试着把脑风暴和方案确定分开:hug:
页:
[1]