微软 工程师,微软工程师是做什么的

　　前两天，一位前微软设计师谈到公司如何决定在Windows Phone中使用

汉堡菜单来大幅取代枢轴式 UI的

　　现在又有一位在Windows团队工作了10多年的前微软工程师出现了，他向我们解释了优秀的创意是如何被糟糕的执行所糟蹋的，糟糕的创意是如何通过可行性论证并最终成为上市产品的。

　　他写道：我曾经是一名Windows工程师，也参加过那些会议。

　　通常，一些外向且有吸引力的项目经理会宣布职能团队已经做出了决定。最终，这个决定是关于功能，或者应用范围，或者时间表，偶尔是关于功能的妥协。idea的原始功能特性在以下几个方面得到了发展：快速性、适应性、可配置性、直观性、自记录性，以及最重要的用户友好性。

　　通常，这些设计由具有功能批准权限的用户和合作伙伴进行评审。这个阶段的产品，也就是下一代Windows系统，是一个很棒的产品。请相信我。在产品发布的过程中，一系列的决策不断削减Windows的功能，以至于到了正式发布的时候，最终的产品已经和最初的产品大相径庭。

　　问题是，在整个过程中，这些决定看起来并不糟糕。这个决定是由项目管理团队、开发人员和测试人员在仔细考虑并达成共识后做出的。这些工程师在会议中花了很多时间来权衡他们的选项，评估每个决定的优缺点，规划出可能的影响，最后从多个有竞争力的选项中选择最佳选项。(或者决策也可能由上层传达，但结果是一样的。)整个过程简单而细致，同时保证了兼顾会议室所有团队观点后的最佳结果。

　　那么问题也来了：谁没有参加决策会议？这个阶段的时间周期通常是4到6周，根本没有时间咨询用户。

　　理论上，微软工程团队的几乎所有成员都是用户的代表。项目经理在计划时已经知道用户的想法，所以这些功能可以预测他们的每一个需求。测试人员最先感知到用户的不满。合作伙伴有点像用户，但更有钱，更有影响力。至于开发者，他们并不是真的关心用户。

　　其实这个过程是行不通的。因为Windows工程团队没有人真正接触过用户。他们实际上是在传达一个通用用户的理想化形象。

　　团队根据这个占卜模式进行咨询，然后仔细理顺所有空中楼阁的想法，再做决定。但最终，这个决定是基于工程团队的想法和创造力，而不是用户的想法，仅仅是因为用户没有机会参加这些会议。

　　为一个产品维护多个用户界面是额外的工作，我们没有足够的时间来测试多个配置。其他竞争对手比我们拥有更多的市场份额。如果我们只是复制他们，也许我们能做得更好。我们所说的都是真实的，所有这些都是支持最终决定的有力理由。但所有这些理由和论证都是微软自问自答完成的。

　　在会议当天，项目管理人员会反复强调这个决定对用户是多么有益。他们会举出一些事实来支持这个决定：我们不想提供太多选项让用户别无选择；只有3%的人还在用那种方法，很明显需要改变；一致性对微软有好处，所以一定对用户有好处。每个人都在微笑，点头同意这个决定，同意这是最好的决定。然后会议圆满结束，这个功能有了新的发展方向。

　　虽然最后的结果和最初的想法有些出入，用户体验可能更差，但是写软件的时候还是要妥协的。这是一个可以接受的妥协，反正不算太差，也是最好的选择。如果现场有用户，他们会理解的。

　　这就是我做Windows工程师时的所见所感。看完视频，我突然觉得自己又回到了会议室。

　　这位前微软工程师的言外之意是，虽然微软收集的数据和微软做出的决策并不总是完全正确的，但如果微软内部没有人真正代表用户，那么

在有机会反馈时，我们当然就不应该再保持沉默了