早上跟教头聊到，“越是忙碌就越是应该主动出击……”刚一听的时候，觉得完全讲不通，我都忙死了，还要主动揽事，不是找死的节奏吗？然后听他的进一步解释，主动出击的目的主要在于掌握做事的主动性，当自己把握了主动权，就能有选择权，选择更重要的事情来做，而不是被动接受被动挨打。这让我想起近期的一个案例:
pm模块接连出了好几个外场问题，项目经理着急了，怎么这么基础的问题都没有测出来？于是发动整个项目的测试大军，集齐大家的力量一起来测试pm模块，提了一堆故障。整个过程中，测试大军们“苦不堪言”，因为对pm模块也许场景并不熟悉，所以提了一堆不痛不痒的问题，而那些故障放在那里，导致pm模块的故障大爆发，出现了严重阻塞，甚至有一些影响功能的外部故障，因为“债多了不愁，虱子多了不痒”，也被埋没在那一堆故障里，团队还需要制定各种措施想办法去清理这一堆故障，SE们也反馈说，怎么故障处理那么不及时，故障堆了那么多，怎么一直处理不下来……
我们来看看，这里面究竟出了什么问题？
首先，项目经理的出发点是很好的，通过复盘发现pm模块有不少基本功能的故障，想着可以发动更多的力量去帮助pm模块发现问题。可最终的收效目前看起来却并不十分明显，副作用也不少……
如果事情可以回到一开始，如果pm团队的速度足够快，主动出击，定下一些团队为了提升重灾模块而想要做的事情。比如:对重点功能模块的自动化防护网建设，并逐步梳理出可以小步叠加着去完成这件事情需要的支撑和投入，并以此向项目申请资源的援助，也许情况会大不一样。
因为站在项目经理的角度来讲，他很着急，却看不到团队的动作，或者认为团队动作不够，所以才会主动帮着团队出了“狂提故障”的想法，如果团队能主动出击，掌握主动权，并且准备做的事情能得到项目的认可，就更好更完美的借助项目的这次力量去达到更好的效果。
感悟:主动出击，更加系统和全局的来把握这些事情，才能对团队所必须做的事情掌握一个主动选择权，当你得到的信息量越大，越能支撑你做出一个更好的选择。放到项目、产品上也是同样的道理，一个软件系统的发展如果完全按照各个不同用户的意愿来做，是不可能实现的。相反，一个成功的产品，既能把握住用户群体的需求，又能引导用户的使用习惯，引导权应该掌握在产品设计者的手中。今年团队改进，内部做了很多尝试，效果却并不很明显，后续需要加强和项目的连接，更好的学会借力，做好取舍和选择，才能更省力。
