前微软工程师现身说法：原来Windows是这样开发的！
两天前一位前微软设计师谈论了公司是如何决定在 Windows Phone 中使用汉堡菜单来大幅取代枢轴式 UI 的，这位设计师称这个决定得到了大量数据的支持，同时也是设计组共同讨论的结果，许多非常聪明的团队成员都赞同这项决定。
现在又有一位在 Windows 团队工作了超过10年的前微软工程师现身说法，为我们解释了卓越的创意是如何被糟糕的执行糟蹋的，以及糟糕的创意是如何通过可行性论证并最终成为上市产品的。
他写道：我曾经是一名 Windows 工程师，也参加了那些会议。
通常会有一些性格外向且颇具魅力的项目经理宣布，功能团队已做出了一个决定。最终，这项决定是关于功能性，或者适用范围，或时间线，偶尔也关于功能去留问题的妥协。最初构想的功能特性是朝以下方面发展的：快速、适应性、可配置性、直观性、自我记录，最重要的是用户友好性。
通常情况下这些设计都由具有功能批准权的用户与合作伙伴进行审查。在这个阶段的产品，即下一代 Windows 系统，是非常了不起的产物，请相信我的话。而在产品发布过程中，一连串的决定不断对 Windows 的功能性等各方面进行削减，以至于到正式发布时，最终产品已与最初构想的产品大相径庭。
问题是，在整个流程中，这些决定看起来并不糟糕。决定是由项目管理团队、开发人员与测试人员经过仔细审议达成共识后作出的。这些工程师在会议中花了大量时间来权衡他们的选择、评估每项决定的优缺点、策划出可能的影响，并最终从多个竞争选项中选出最佳选项。（或者决定也可能由上层管理传达下来，但结果是一样的）整个过程是简单细致的，同时保证了照顾到会议室中所有团队观点后得出的最佳结果。
那么问题也来了：谁没有参与到决策会议中来呢？在这个阶段，通常时间周期为4到6周，根本没有时间去咨询用户。
理论上来说，几乎所有微软工程团队中的成员都算是用户的代表。项目管理者们在规划时已经了解了用户的想法，所以这些功能可以预测他们的每一项需求。测试者最先觉察到用户的不满意之处。合作伙伴则有些像用户，但他们更有钱，同时也更有影响力。至于开发者们，他们实际上并不关心用户。
实际上来说，这个流程并不奏效。因为 Windows 工程团队中根本没有人真正与用户接触过。他们实际上在传递着一位通用型用户的理想化形象。
功能团队就是根据这种占卜板式的模式进行咨询的，接着又仔细地将所有空中楼阁式的想法全部合理化，然后就成为了一项决定。但这个决定终归来说还是基于工程团队的想法与创意，而非用户的想法，这仅仅是因为用户并没有机会未出席这些会议。
为一款产品维持多个用户界面是一项额外的工作，我们没有足够时间去测试多重配置。其他竞争者比我们拥有更多的市场份额，如果我们只是复制他们，可能我们能做得更好。所有我们说的这些内容都是真实的情况，所有这些都是支持最终决定的有力理由。但所有这些理由与论证均有微软自问自答来完成。
在会议当天，项目管理会反复强调这项决定是多么有利于用户。他们会列举一些事实来佐证这项决策：我们不想提供过多选项来让用户无从选择；只有3%的人还在用那种方式，很明显需要进行转变了；一致性对微软有利，所以也一定对用户有利。每个人都面带笑容，纷纷点头同意这项决定并一致认为这是最佳决策。接着会议顺利结束，这项功能有了新的发展方向。
虽然最终结果与当初构想的有些差距，也可能用户体验更差，但编写软件是需要妥协的嘛。这是一项可以接受的妥协，无论如何还不算太坏，也是最佳的选择。如果真有用户在现场，他们也会理解的。
以上就是我曾经作为 Windows 工程师时的所见所感。在看过那则视频后，我突然间感觉自己又仿佛回到了那个会议室中。
现在又有一位在 Windows 团队工作了超过10年的前微软工程师现身说法，为我们解释了卓越的创意是如何被糟糕的执行糟蹋的，以及糟糕的创意是如何通过可行性论证并最终成为上市产品的。
他写道：我曾经是一名 Windows 工程师，也参加了那些会议。
通常会有一些性格外向且颇具魅力的项目经理宣布，功能团队已做出了一个决定。最终，这项决定是关于功能性，或者适用范围，或时间线，偶尔也关于功能去留问题的妥协。最初构想的功能特性是朝以下方面发展的：快速、适应性、可配置性、直观性、自我记录，最重要的是用户友好性。
通常情况下这些设计都由具有功能批准权的用户与合作伙伴进行审查。在这个阶段的产品，即下一代 Windows 系统，是非常了不起的产物，请相信我的话。而在产品发布过程中，一连串的决定不断对 Windows 的功能性等各方面进行削减，以至于到正式发布时，最终产品已与最初构想的产品大相径庭。
问题是，在整个流程中，这些决定看起来并不糟糕。决定是由项目管理团队、开发人员与测试人员经过仔细审议达成共识后作出的。这些工程师在会议中花了大量时间来权衡他们的选择、评估每项决定的优缺点、策划出可能的影响，并最终从多个竞争选项中选出最佳选项。（或者决定也可能由上层管理传达下来，但结果是一样的）整个过程是简单细致的，同时保证了照顾到会议室中所有团队观点后得出的最佳结果。
那么问题也来了：谁没有参与到决策会议中来呢？在这个阶段，通常时间周期为4到6周，根本没有时间去咨询用户。
理论上来说，几乎所有微软工程团队中的成员都算是用户的代表。项目管理者们在规划时已经了解了用户的想法，所以这些功能可以预测他们的每一项需求。测试者最先觉察到用户的不满意之处。合作伙伴则有些像用户，但他们更有钱，同时也更有影响力。至于开发者们，他们实际上并不关心用户。
实际上来说，这个流程并不奏效。因为 Windows 工程团队中根本没有人真正与用户接触过。他们实际上在传递着一位通用型用户的理想化形象。
功能团队就是根据这种占卜板式的模式进行咨询的，接着又仔细地将所有空中楼阁式的想法全部合理化，然后就成为了一项决定。但这个决定终归来说还是基于工程团队的想法与创意，而非用户的想法，这仅仅是因为用户并没有机会未出席这些会议。
为一款产品维持多个用户界面是一项额外的工作，我们没有足够时间去测试多重配置。其他竞争者比我们拥有更多的市场份额，如果我们只是复制他们，可能我们能做得更好。所有我们说的这些内容都是真实的情况，所有这些都是支持最终决定的有力理由。但所有这些理由与论证均有微软自问自答来完成。
在会议当天，项目管理会反复强调这项决定是多么有利于用户。他们会列举一些事实来佐证这项决策：我们不想提供过多选项来让用户无从选择；只有3%的人还在用那种方式，很明显需要进行转变了；一致性对微软有利，所以也一定对用户有利。每个人都面带笑容，纷纷点头同意这项决定并一致认为这是最佳决策。接着会议顺利结束，这项功能有了新的发展方向。
虽然最终结果与当初构想的有些差距，也可能用户体验更差，但编写软件是需要妥协的嘛。这是一项可以接受的妥协，无论如何还不算太坏，也是最佳的选择。如果真有用户在现场，他们也会理解的。
以上就是我曾经作为 Windows 工程师时的所见所感。在看过那则视频后，我突然间感觉自己又仿佛回到了那个会议室中。
这位前微软工程师的言外之意是，尽管微软收集的数据与做出的决策并不总是完全正确的，但如果微软内部没有人真正代表用户，那么在有机会反馈时，我们当然就不应该再保持沉默了。所以，大家积极向微软发出自己的声音吧！