CU里程碑版本等等
第二：这个版本核心功能是什么，哪些功能是可以适度削减的（一定要留有讨价还价的空间）
第三：阐述领导的期望。我们做得事情领导时时刻刻都在关注。
第四：加班的不只是技术，而是整个团队。对关键的核心人员做好思想工作。
第五：加班偶然请吃饭。这个非常有效，尤其是长时间加班作战的团队。
这就是美：提升思考层面，让参与者感受到目前的困难和挑战，一起去战斗。
希望技术写出高效的代码
项目迭代节奏很快，需求评审的质量直接影响到最终的产出。为了保证需求评审的质量，我提出了需求初评环节。初评，就是初步的沟通和评审。这个环节有几个好处
1）提前预告需求功能，让技术GG心理有底。研发都追求简洁的代码和优秀的设计方案，提前知道产品规划方向，有助于更好的制定设计方案。在沟通中需要关注技术GG的反 应，希望可以写出高效的代码，提升产品开发效率。
2）发现技术难点，产品方案规避。产品遇到很尴尬的地方就是在需求评审上技术GG说这个功能实现不了，或者说要一个月才能做出来，评审的结果必然是产品修改需求方案，择日再评审。遇到难题，需要明确沟通，可以把产品的烦恼抛出来，让技术也参与到产品方案的设计。
初评中需要注意控制相关的参与人员和评审时间，因为是初评控制好成本，讨论核心问题即可。
这就是美：我中有你，你中有我，相互协助，把活干好。
产品经理无处不在
在项目过程中，目前产品参与的会议包括：需求评审、测试用例评审、迭代计划会，这三个会议都是必须参加的。另外还有一个技术评审会议，一般来说产品经理是不需要参加的。由于本次需求很复杂，涉及到的交互细节也很多，为了防止技术方案中的遗漏关键点，这次的技术评审我主动参与了。
一般来说，是不建议产品参加技术讨论的。
第一：产品听不懂技术的讨论，整个会议感觉异常无聊
第二：浪费你很多时间，说不定一个小时下来你才参与几分钟
我以前做过技术和项目经理，很容易融入到技术讨论中。基于自身的经验，如果要参与技术评审，产品经理需要具备以下条件：
第一：有技术背景。
第二：有移动办公设备。技术评审不是我们的主场，产品只是协助技术团队而已，所以参与感很低。为了不浪费时间，所以需要 有移动设备办公，在技术需要我么的时候，立刻提供协助即可。
重要：技术评审就像一个菜市场，产品要在这个环境下工作，适当时候提供协助。对于个人能力要求很高，如果受到外界影响很大的话，建议不要参加了。等技术需要你的时候，再电话或者来会议室参加讨论即可。
这就是美：适当参与，帮助技术，无处不在的服务精神
4、小结
无论任何一份工作，沟通是一门必修课。或许有千千万万种沟通技巧，本文探讨的感情沟通只是其中一种。用心沟通、让大家懂你，不仅仅带来工作上的高效，也带来了很多小伙伴的认可。一起努力，一起成长，做个优秀的产品经理。