正文
最近两个月我将大量的精力放在了业务分析团队的组建和管理上。不断解决日常中遇到的协作问题，使我学到了一些分析技术以外的知识。由于人多事儿多，所以出现了不少很好的协作案例，值得推广。
分析师尽早介入业务。
运营伙伴做好合理排期。
及时反馈。
利用现有数据源解决问题。
许多时候，我们并不是缺乏数据，而是“懒”，不去挖掘现有的数据集的潜力，导致分析师觉得有很多简单重复需求。
过程中紧密沟通。
不要做“甲方乙方”，而要做“一条绳上的蚂蚱”。
运营不是放大压力给分析师，而是帮助分析师减负。
从业务到分析，这个协作链条的上下游，天然就有“放大压力”的属性。比如运营任务deadline是7天，分析需求就会压缩到3天。更何况我当前所处的环境，很多事务都是1-3天，那么数据需求就大量的是1-2天期限，不少是当天需要完成。
清晰的阶段性规划。
主动地点对点培训。
大批量集中的技能型培训，实际上效果都非常差。真正有效的互相学习，还是自发形成的“一个愿打，一个愿挨”的点对点培训。要想办法创造这种环境：1.招聘自驱力强的人；2.鼓励事情做深做细；3.减少“贴膏药”的事情；4.对有难度的事，给予充分的时间。
通过同理心来实现互相信任。
很多人会说，协作中的问题基本来自“信息不对称”。但以我目前的观察，信息不对称的根源是运营与分析师不够互相信任。如何增强同理心？目前我没有很好的方案，也许“时间能改变一切”？
根据实际情况，再举几个典型的问题，是我们目前没有解决的。但我根据经验给出一些解决的方向，并正在向这个方向努力。希望有经验的读者能在回复中给我们一些好的启发！~
对于取数型的任务（数据描述型的任务），搁置争议，先解决眼前的问题。
对于数据分析不能解决的任务，我们永远要追求“客观性”。一定不能出现“为了结果而分析”，更不能出现“包装结果”。
这其实有两个方面：一是分析师能力不足，不能够解决某个业务问题；二是问题过大，超出数据分析的边界。面对第一种问题，通过换人或者外部请教，一般能解决。面对第二种，我暂时只能控制不出现“假分析”。
但这说起来容易做起来。。。谈何容易。
这点往往与第一点产生矛盾，业务方急着要分析结果，而分析师除了“猜”，不可能给出满意的分析结果。面对“强人所难”的情况，也是我最近“心累”的主要原因。
