现在每日和yu一起工作，总能从各种细微之处学习到很多。
决定记录下来，日后回顾起来也有个处所。
事1 跨部门沟通技巧
深刻理解项目背景 —— 为什么要做？
在沟通中常常会被质疑为什么要做这个功能，特别是现有的数据不能支持去做，而且需求实现复杂，资源消耗较多，导致对方认为投入产出比不高，对需求不重视，设置较低优先级的时候，需要讲到这部分。
1. 公司层面，因为XX是公司的战略之中，我们的这个需求是战略的一部分。能唬住了最好，更多时候，对方可能会提出，与XX相关的其他功能同样还没有做好，比如YY，YY的优先级肯定比你们高，于是看2
2. 部门层面及用户层面，客观上承认，这个功能其实是对部门有利的，因为我们观察到一些现象（作为垂直部门，肯定要比其他团队看到的问题要深）。这部分也只有自己深刻理解了项目背景及用户痛点之后，才有的说（这也是今天做的不好的地方，需求来回倒腾的时间一长就会忘记自己为什么要做，忘了初衷是件很恐怖的事情）
3. 兄弟部门层面，让兄弟部门介绍对这个功能的计划，以及刚刚提及的YY功能的计划，侧面说明这个功能是一个各方都以达成共识应该做的功能。
抛出问题 —— 如何做？
这次的需求较为复杂，所以前期双方沟通可行性，评估资源与开发量已经很长了。特别是资源这块，如果全量去做，整个项目都有可能完全无法启动。这个时候需要搞清楚几个事情。
1. 需求中是否包含某一部分特别复杂，耗资源？
如果存在，可以评估这部分对整体方案的影响，如果很大，则无法砍，看2；如果不大，则可以考虑分期实现需求，很多时候首先能够让项目启动起来，比推进了一个月什么都没有做来的好。如果不存在，则看2
2. 是否有其他减少资源消耗的方法？
这部分需要调动在场各位的思考。今天的收获是，对方提到一个我们没有想到的解决思路，如果全量推进资源消耗太多，同时真正有需求的用户又是少数，是否可以仅对这部分用户做。（这也是通过介绍我们的项目背景这块，才有的讨论，侧面说明了这部分的重要）
都无法决定做不做 —— 怎么让老大拍？
要求对方给出的资源和工作量的预估是需要基于完整方案的，如果其中有一点不包含，而且这部分还是确认为坑的时候，是需要重新给一个预估的，这样给老大拍的时候，信息才能全面，避免老大拍了之后，又发现功能还是不全。
事2 少点吐槽
有人说，感觉XX团队就是故意拖着不给我们提供测试环境（导致上线延期）放在大多数人那里，这接下来就是吐槽的最佳时刻了（目前确实和XX团队合作不愉快）。而yu听到之后，沉默了一下说，XX不好的地方不要学，其实这次是个好机会把原来XX推动我们做事情的方法反向用在他们身上。你可以找项目管理，让他们去推。
这件事情给我两个启发
１. 原本负能量满满的事情，直接寻找解决方法，比抱怨埋怨有效。
２. 有些事情硬碰硬不行的话，可以从其它路径和资源，迂回想解决方法，比如独立的项目管理部门。
