做为项目经理，在项目过程中，难免遇到需要将产品经理、技术、设计、测试等流程拉通的情况。
场景1：测试部反馈这个重大特性测试不通过，好不容易把产品经理拉到研发座位后，产品经理彪了一句“这不是我设计的本意，请看我XXX月的设计图”，听完这句话后，心里默默念出“一万头X你马”
场景2：即将要发布版本到测试部，研发人员看着很忙，但是就是不能输出到版本。不能急“版本经理”所急。还在原地悠闲的码代码，等到去问研发的时候，研发随口说了句，XXX需求不清晰，给产品经理打了XXX个电话没有回应，所以XXXX。我的天，心里又是“一万头X你马”
飞过。
场景3：好不容易把产品经理、设计、技术拉倒一起评审需求，把中间的逻辑弯弯道道都理顺了。但是快到交付日期了，技术依然未反馈完工。去技术那里问为何还没有按时完工，技术一句说设计没有给出交互的细节设计。产品经理没有给出异常的流程。所以没有人或者流程图告诉我要往哪里去，所以我停在原地，等你。
有些公司，产品经理和设计基本都是复用，特别是小公司，这种人力复用率尤其严重。然后产品经理基本属于“甩手掌柜”，接完市场或者老板的需求，大致转换发给研发后，不管研发最后设计的结果怎么样，不论测试部是否通过，不论最终的效果是否回归初心本意。一方面是产品经理有心无力，太忙了，没有时间管结果。一方面，这个产品经理他可能以为只有需求与我有关，尚不知，需求也是需要闭环的。在测试部验证后，产品经理也需要给出自己的评判标准作为功能是否完全符合的依据。
出现这种种种的问题怎么办呢？什么是好酒，惟有杜康。出现这种场景后，往往是因为信息的不对称而导致某个人或者环节成为了项目开发的瓶颈。而这种瓶颈如何解决和梳理?愚以为拉通每日“十分钟”站立晨会，严格执行“To-do”“Doing”“Done”的看板工作模式，其实每天6小时高效工作以及是不得了了。另外通过这种工作模式，把项目组成员拉到一起，形成信息的对称和互补，当面把问题“打开”来看，看看瓶颈在谁那里，并有针对性的去推动。如果通过这种模式，依然出现如上类似的问题，那么只能对那个一直“瓶颈”的小伙伴说“呵呵”了。
做好第一步，理清需求和各自信息对称；
做好最后一步，需求的验收和信息确认。
以上场景，纯属虚构，如有巧合，请勿对号入座，不喜勿喷。
