公司有一个部门很不稳定，人员都淘换好几拨了，产品还没有做出个样子，这不最近，产品经理离职又带走了大半的骨干，高层派了另外一个部门的主管过来接这一摊子事儿。
领导是做C出身，从业经验也有二十来年了，C方面虽不能说是无所不知，但也是牛人，可这个新部门的产品是 B/S 架构的，基于 J2EE，领导基本上一无所知，Java，Javascript，CSS，Flash这些名词很熟，深了则基本不懂。要不要将核心都换成C？领导犹豫了很长时间，最后为了照顾剩余人员的技术能力，还是放弃了；虽说剩下的精英不多，但毕竟有产品的业务经验积累，如果因为技术架构的选择而导致这最后一批人走掉，完全从头开始，这不确定因素也太大了。
团队要重建，在一时招不到合适的 PM 的情况下，只能从现有剩余人员中提拔。做着做着，问题就来了。
领导在关注产品功能的过程中，不断地听到这样的回答：
这是Java的特性决定的，我们也没有办法！
这里用的是第三方的组件，功能就是这样，不好改！
这项功能如果照你说的实现，技术上会非常复杂！
… …
一开始，领导没有太在意，觉得可能 Java 和 JS 的确有很多局限性，他只说了一个原则：
我相信各位的专业性，你们有责任尽全力做好该做的事情！
可是，伴随着类似的问题越来越多，他发现产品功能离自己的设想越来越远，
虽说不太懂 Java 及 Web 技术，但软件开发毕竟是相通的，
当代计算机有什么样的处理能力，别人的网站能做成什么样，竞争对手的产品有何优劣，
领导开始怀疑不是技术的问题，而是使用技术的人的问题。
老外经常说：不要自己发明轮子。
可是，再好的理论也别泛用！
拿别人的成果来用，虽然一定程度上提高了开发速度，带来不少便利，
但也导致使用者不愿意做研究，对技术不深究。
领导很苦恼：我该怎么证实自己的猜想，怎么解决这个问题呢？
终于，当一个广泛应用于产品界面上的第三方组件发生问题时，大家都声称没办法解决，
领导痛下决心，说：好，我就从零学起，做出一个功能更强的组件给你们看看。
领导凭借自己多年的积累，边学边做，完成了一个功能强大的组件，
但是，时间也过去了两三个月，在这段时间里，管理缺位，方向有偏，暂不赘述。
领导得出结论：有些问题处理起来的确有难度，但并非大家想象的不可解决，
如果用第三方的开源代码用成地雷，谁都不敢碰，那还不如干脆不用。
此后，说不能的人少了，可一旦遇到下一个技术上的槛，是不是又要领导出马亲自去验证呢？
一队人马，后有追兵，而援军未到，
兵不够精，马不够壮，
面对战局，若谋士们有怯敌言败之意，作为将军的你：
是杀？
是逃？
是点将出战？
还是自己一马当先？
