· 障碍：
发现需求不定，无法达成共识，开发对产品有所抱怨。
· 组织会议大致议程：
1.适当找一个轻松的话题（避免过于正式大家放不开，毕竟是抱怨彼此）（10mins）
2.询问大家最近工作怎么样遇到什么问题（10mins）（最终会引导到正题）
3.讨论提出的问题（40mins）
4.制定下一步行动项（20mins）
· 过程：
把产品和开发团队拉到一起，开始抛出了想要组织一次团建的活动，大家来发表一下自己的看法，可以有效的降低大家的戒备心，你一句我一嘴，说的比较开心，把大家的想法集中了一下投票用。
趁着大家气氛比较好的情况下试探性的问了一句最近工作中感觉怎么样，有没有什么不顺心的地方，感觉士气不是很高涨。一名心直口快的队友直呼：产品那边需求一天改3遍，都没心思写了，刚写完下午就遍了，烦死了。
这似乎是个导火索，打开了大家话匣子，产品和开发团队开始争执。我抛出了几个问题让大家冷静的想一下，想完了再继续争执讨论。
1.产品的变动需求是否合理，是否使产品产品更完善了。
2.开发之前是否对产品的需求彻底解读，是否保留了自己的疑问。
3.针对产品，造成改动的原因是什么？
4.大家认为的怎么做比较合理。
针对这四个问题，让大家进行了讨论，讨论中听到了一些声音：
· 产品的变动大部分是比较合理的，确实可以改善使用习惯和一些特殊的业务场景需求；
· 这个地方当时想到了，我也不敢多说，就没放声，可是后来还是需要改，早知道我就提一嘴了；
· 当时需求评审的时候都没想到这么多，后面开始开发的时候才想到。
· 这个地方当时确实是想的过于简单了，没考虑那么多。
· 我觉得以后开发的时候发现问题还是先问问产品比较好，省的做完了又要改。
· 我觉得以后可以把任务拆的更小一些，每次做少量的任务，避免问题压到一起改动比较大。
· 可能我需求挖掘不够，业务也没有想那么多，后面又想通了。
大家讨论完之后，我觉得他们已经不会再继续争执下去了，而是理性的看待这个问题。我把大家的声音整理了一下，展示给他们自己看，很显然大家都发现了自己的问题，也都大致的想到了一些想要改善问题的方法，值得一试。在这里套用了敏捷的拥抱变化，对大家进行了教导，其实变化不是那么可怕，他正在帮助我们在完善我们的产品，让我们的产品更受欢迎，大家也开始变得比较认同这一点，从他们目不转睛的眼神中就可以得到肯定的答案。
在讨论过程中，团队内部发现自己的问题，内部给自己找到一些解决方案，这一点还是比较值得欣慰的，毕竟自组织团队已经开始在他们内部学着去解决问题，可以从自身找问题找原因，规避了一些像责怪这样的团队毒素，也似乎意识到了团队壁垒这个团队毒素。
最后我们团队共同制定了行动项（公约）
· 任务拆解细化，每次做多少由团队内部共同决定，避免做多改多。
· 发现问题第一时间跟产品反馈，做到及时调整，增加团队透明度。
· 需求评审的过程中尽量多发散，想出更多的可能，要求每个人对功能讲解透彻；跟业务方面的沟通多启发他们获得更多的信息用以完善自己的产品和构想。
· 总结
在观察发现这个障碍之后意识到这个问题非常不利于团队发展，所以立刻想办法去移除这个障碍，为了进一步避免激化矛盾，避免大家放不开的情况，先采取了一个比较感兴趣的话题去打开了这次会议开场，中间利用聆听的方法，听到了很多大家的想法。用教导的方式给大家说明拥抱变化的重要性，也得到了大家的认同。大家也开始从自组织团队内部去发现问题，解决问题，避免了矛盾的进一步激化，这一点非常重要，起码是朝着好的方向进展。最后的团队公约虽然没有具体衡量的标准，但是团队有了要改进的想法也是很好的，本着允许犯错，知错就改的原则，希望团队能够一步一步的得到提升进步，不断的突破自我。
