本次的主题是“沟通”。
运营的一个活动需求到我这了，从开始到结束，用一个字概括，就是乱，而乱的原因就是各方面信息的不到位。
感悟4里谈到的是产品面对开发人员要做的流程，即产品要跟开发说这个需求是要做来干嘛的，怎么给用户感知到这个需求，然后开发实现这个需求，我们姑且称这种需求是“一手需求”。
而现在运营给产品的需求，相当于运营跟产品说这个需求要做来干嘛的，要达到什么目的，然后用户做这个大概是个什么样的流程，比如一个活动，则流程是用户怎么参与活动，参与活动后又能干嘛等等流程，越细越好。然后产品这边来让用户怎么感知到这个需求，再交由开发，我认为是比较合理的二手需求提出。
运营应该跟产品细致说明好这个需求的目标和用户流程。具体用户感知到这个需求，则是产品的事了，而不是仅仅说是只有目标，告诉产品我们要干嘛，这样必然会导致混乱，理解不到位。
以身作则，总结一下这个乱的流程和项目管理上的不足和提升：
1. 运营需求的评审不够充分。重现一下当时的场景，运营拿了一份文档说明他们要做什么，为什么要这么做，这么做后会产生说明数据表现。大概是这三个问题，而且这三个问题的答案他们都回答得非常好，把大家都说服了。加上公司的一些特性，这个需求其实你反对也还是要做的。所以大家基本也没什么意见，有些问题就提了一下就这样过了。而后，细思极恐，这个活动需求其实建立在一个不是那么完善的产品功能的基础上的，要完善这个功能就必须花时间，然而活动特性不可能花太多时间，处于快速上线的需求。所以，这其实在放大自己的缺陷，太扯了。
稍微吐槽一下，用一个不那么完善的功能来搞东西，出来后还说这个功能这么那样不行，其实评审时有提出这个问题，回答说不是那么care，到现在这个功能却成为一个被吐槽的点，真是奇葩。
说到底，运营给产品提需求跟产品给开发提需求有点类似，但不尽相同（后面再展开），开发再评审时会提出很多问题，那么产品在评审运营需求时就应该提出问题，让运营意识到他做的东西，产品功能本身可能还没跟上，是会有什么对策，这是要说明好的。
2. 运营提需求时其实可以更好。正如以上所说，除了要给大家说明的三大问题之外，还需要补加一个流程，即运营应该给出一个真实用户怎么参与到活动的需求流程，越细越好。运营是第一需求方，产品是二传手，所以产品未必完全了解运营的需求，这必然导致两者需要不断沟通，一来时间多，二来越沟通可能越多问题，然后再重复沟通，浪费时间，那倒不如运营先把流程铺开，产品这边先过一次，提出问题，总比空空地沟通好多了，然后再根据流程画交互，写需求，这样就节省了好多时间。
而本次由于少了这一步，沟通成本加大，到最后大家都懒了，互相反馈都严重滞后。
运营的需求需要明确目标，用户流程，数据监控。
3. 沟通不足。需求到了产品这边，产品需要摸清整个需求的来龙去脉，这时就要去找运营去问，因为产品要根据APP或web等等本身的一些交互去呈现这个需求。事实上，刚开始的沟通会比较积极的，但多了就懒了。产品接到需求后会与运营进行沟通，到了后面沟通就少了，沟通少的一个最大弊病就是导致信息不对称，最后做出来的需求不符合运营的期望，即验收不过，然后又要大改特改。这次运营的需求有跟其他事业群合作，运营与事业群同事开完会后，没有同步信息给产品，到最后这儿缺了，那缺了，这儿不对，那儿不对，然后上线时间紧，又要改，则就少了很多思考时间，其实这个需求可以更好。
沟通是很有必要的，但沟通多了未必是好事，尽量把需求，流程想清楚，信息同步到位。
以上的三个问题导致这次的项目，从头乱到脚，产品和运营的需求理解不同，产品没法get到运营的点，做出来的东西不符合需求，同时双方沟通不够，很多信息都缺了，改动时间多了，问题层出不穷。
总之，运营方要提出需求目标和完整的用户流程，用户流程手绘的都OK，说得清就行。同时产品要主动去沟通需求，双方的信息都得同步到位。
