结论
1、接到有上线时间要去的需求，一定要给自己留够了解需求、输出文档的时间，不完全了解需求，不组织评审；
2、运营在需求评审上，提出新的需求，要及时制止，不能偏离需求文档。组织评审前，参考第一条。
运营：我有个急单
现在仔细想想，提出来的需求，貌似没有不着急的吧，所以，产品岗要有不被需求提交者影响的心态。
看到运营提的需求，里面有期望上线时间，我不自觉代入到场景里了，把这个时间真的当做上线时间，来反推自己的需求评审的日期。拿到需求以后，第二天上午才有时间仔细了解，虽然运营同事已经把交互做好了，但是，交互之外，还有很多细节，特别是异常情况，数据流，需要考虑。
我在偷懒的情况下，拿着运营给的交互图，下午组织了技术同事进行评审，结果：会上，我被怼的很惨，运营同事，还要在会上讨论其他的发散需求，可以说是做产品以来最失败的一次需求评审。
自己对需求了解不透彻。半天时间，倒不是一定不能了解清楚需求，只是，对于当时的情况，我是没有完全了解需求的。没有了解需求的情况下，就急躁的组织需求评审，遇到开发同事询问异常情况，数据流，以及讨论接口相关问题，我就一问三不知了，给开发留下了不靠谱的印象；
运营同事充当了我的角色。运营同事平常没法聚集不同部门的技术同事，所以，在会上，她嫌我没有说清楚，讲明白，就：我再重复一下，这里主要是有3类情况......整体的感觉，我的角色，就像是把技术同事聚集起来，听运营同事讲需求，最拐的是，运营同事，是按照自己对于业务的理解来讲解的，给技术同事增加了一些理解上的难度。而且，这个需求，除了啥问题，后面背锅的，还得是我。
也是通过这个需求，后续接到需求，我都会给自己留够了解需求的时间，没有了解需求的前提下，坚决不组织需求评审。这是维护自己的形象，也是对技术同事负责。
同时，也深刻感受到，运营同事的思维，和技术同事思维的重合度不高，感受到了产品岗的价值。
网友评论