答案永远在现场

答案永远在现场

   中国历史上，中华民族和外族开战败多胜少，仅仅从军事的角度开来，这也是正常的。无论是契丹突厥，还是满金匈奴，他们的指挥官都是在一线，反应迅速，战略战术调整及时；中原的指挥官都是在庙堂之上，妙算天下，某些王朝末年，还出现要等皇帝老子赐下战阵图摆阵的无厘头时间。两者一对比，一头狼咬一个行动迟缓的胖子，基本这就输定了。

   同样，一群从来没有到客户现场，看过客户是怎么使用我们产品的研发经理，舒服的坐在办公室里，深思熟虑后，忽然一拍脑袋，我们应该加个XX功能/器件，这样就能方便客户怎么，怎么使用我们的产品，多么让人激动的产品设计啊――这样的产品，估计也好用不到哪里去。

   躲在后方，屏蔽掉一线真实的声音，通过冷冰冰的系统，就会把一线的一个个呼唤和需求，变成一个量化的数字游戏。所以一线明明在呼唤，我们需要XX，需要XXX。但是对于后端，看到的是一张张project表格，这个功能需要三个人月，这个功能需要六个人月，这个功能分分钟的事儿。如果要我四个月出版本，我只能做到XX、XX功能。同样，bug也是。可能一个bug对客户来说，是紧急的致命的。但是流转到后端，就是高中低，难易间的无数bug中的一个而已。

   2009年开年，任正非向华为全体员工发出了振聋发聩的呐喊：让听到炮声的人呼唤炮火！让一线直接决策！没有对企业经营管理本真的全神贯注，没有对答案永远在现场的心领神会，没有对每一个滋生官僚癌细胞的深恶痛绝，没有头拱地不找借口解决问题的地头力，就发不出这么强势的呐喊。借用尼采的话说，这仅仅是力的事业：具有本世纪的一切病态特征，但要以充盈的、弹性的、再造的力来调整。

   从心理的角度：

   网上有一个流传已久的程序员的段子：如果你给程序员说：你的程序有bug！程序员会说：是你丫脑残不会用吧？但是如果你给程序员说：你看来来，我是不是不会用，这个地方老是搞不定？程序员心理就会想：我擦，不会又有bug吧？

   同样，你给一个研发经理说：你设计的产品有问题！研发经理会说：怎么可能，是你不会用吧，我们可是专业的人精心设计的，你知不知道目前主流的交互习惯和工程学？但是如果你让研发经理自己到客户现场，看客户使用产品的场景――研发经理心理就会想：我艹，又傻X了，这个地方回去要改。

   从沟通的角度：

   层层反馈注定会是失真的，各种资讯机构用烂的一张图，再次秀给大家。所以到一线去，听听客户真实的需求是什么，看准目标比盲目努力，更事半功倍。

   此外，专注于研发的研发经理，经常会困扰于市场方向产品经理的一个个需求：我要这么这么做，这个地方加个按钮，一按就有什么什么效果，或者加个功能，实现什么什么功能。这种描述，是产品经理个人的明确要求，我要什么，我告诉你怎么做，你就去研发吧。实际上，客户本身的需求，可能有很多的实现方式。而产品经理，往往因为种种原因，选不到最好的方式，甚至选择的实现方式，在框架上会和很多业务逻辑冲突。要相信，研发人员在自己的领域里面都是聪明人，研发经理会找到更好的解决方案，所以，只需要把研发经理和客户，放在一起，然后产品经理充当翻译器和买单者就ok了。

   从管理的角度：

   打破山头主义和小圈子，调岗是必须存在的事儿。
   前段时间，业内一个朋友咨询我一个问题，一个业务领域的前后两个团队，大家互相抱怨彼此的交付质量差，要不要建立详细的操作手册，检查表，去规范两个团队的交付件。我回答他说：没有必要――看起来严格的检查和流程，会让大家就事论事，区分责任归属，但实际上会让两个团队的对立情绪越来越重，最后导致厚重的墙。我建议两个做法：针对基层员工，开会宣导合作和互帮互助，并且自己带头不说抱怨的话，只做积极的事儿。如果发现有基层员工有抱怨和推诿，第一次私下谈话，第二次点名批评，依次升级。如果中层管理者有抱怨，则立刻两个人轮岗，既然你说别人做不好，那么你自己过来做一下看看，是不是有不得已的苦衷？

   华为的轮值制度很大程度上打破了部门墙，所以与其让研发经理一次次的抱怨一线的朝夕变化，还不如让研发经理走到一线去，看看为什么会有这种现象？说不定一个技术宅，就能更好的解决了这个问题呢？

   温室里面，培养的不仅仅是娇嫩的花朵，也培养了娇嫩的产品，经受不起市场的风吹雨打。

   所以，寻找解决问题的真正答案吧，而答案，永远在现场。

敬请关注我的新浪微博@叁石而厉