6. 新技术的风险其实没你认为得那么高
　　没什么比提及 .NET 新棒的 JavaScript 框架版本更让软件开发经理感觉恐惧的了。
　　这已然成为了大家心照不宣的雷区。
　　曾几何时，每隔一年左右软件供应商才发布框架或补丁的新版本，因此，错误的代价会相当高。
　　曾几何时，大部分源代码是封印在“墓穴”中的，不允许其他任何人访问的，所以一旦该公司不再支持它，你会进退两难。
　　但是现在，情况有所不同。
　　如今的框架，有时甚至是在每天的基础上发布补丁，并且大多数流行框架都是开源的，所以风险并不高。
　　当然，你也可以破罐子破摔，但这种情况不多，并且只需要稍作修改即可，而不是大刀一挥，好的坏的都割掉。
　　所以，如果编程经理依然还活在 1980 年，那么你可能需要为他指出事情发生了什么变化，以及为什么停留在框架或库的旧版本比升级它更危险。
　　恐惧策略中的安全漏洞是一个很好的突破口。
　　7. 画蛇添足的业务分析师和项目经理
　　我知道接下来我可能会得罪不少人，但我不在乎。我在这里说的都是真话，我是那种看到什么说什么的人。
　　当然，首先要声明的是，还是有一些好的业务分析师和项目经理的——但说实话，大部分的业务分析师和项目经理毫无价值。
　　曾经一度这些角色是开发项目所必要的。
　　但是现在，在大多数情况下，我们不再需要他们了。
　　软件开发人员应该直接与客户对话，以便于让他们自己搞清楚客户的需求。所以我们不需要业务分析师。
　　这是一个残疾岗位，因为他们做的是软件开发人员应该做的工作的一半，却对另一半工作于事无补。
　　而项目经理更神奇，他的目标似乎是奔着妨碍我们开发，将一切搞得一团乱而来的。
　　我知道他们是好意，但在当前的敏捷世界，项目经理已经发挥不了作用了，所以还要他们干什么呢？他们四处走动试图让自己显得重要，试图找出他们可以做的事情，终却只会妨碍大家。
　　很多软件开发经理的想法仍然停留在过去，停留在那个职位更有意义的年代，他们听信了世界 500 强咨询公司的所谓的“潮流”——据这些公司所言，很多软件公司需要更多的高薪顾问人员来满足这些工作岗位。
　　如果你的经理还是不懂，那么的解决方法是接受敏捷教育。
　　我不建议你直接告诉你的老板说“业务分析师和项目经理纯粹是在浪费氧气”——这可能也不那么容易被接受——所以，相反的，我会专注于说明一支敏捷团队应该如何工作以及需要哪些角色。
　　然后很明显在一个真正的敏捷环境中，是没有业务分析师和项目经理的，他们可能更适合作为 Scrum 管理员或产品所有者。
　　积极主动
　　当然，上面我说的这些东西，有的我可能会用一种开玩笑的口吻说。但在现实中，软件开发经理和软件开发人员之间对于软件开发的理解常常是脱节的。
　　我敢肯定，软件开发经理会抱怨说，软件开发人员不懂业务方面，不知道安排会议安排的难点——但那是另一回事了。
　　无论如何，关键点是：这不是一个对立的局面，而是一个可以解决的关于沟通不畅的问题——至少在一定程度上——可以通过合理的交流沟通解决。
　　采取积极而不是对抗的的方式，往往才是解决这些问题的佳途径。