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

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

  前两天,一位前微软设计师谈到公司如何决定在Windows Phone中使用汉堡菜单来大幅取代枢轴式 UI的。设计师表示,这个决定是有大量数据支持的,也是设计团队共同讨论的结果。许多非常聪明的团队成员同意这个决定。

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

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

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

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

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

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

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

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

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

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

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

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

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

  这位前微软工程师的言外之意是,虽然微软收集的数据和微软做出的决策并不总是完全正确的,但如果微软内部没有人真正代表用户,那么在有机会反馈时,我们当然就不应该再保持沉默了。所以,让我们让微软听到我们的声音吧!

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: