【翻译】为你的研发团队引入换位思考的方式

原文地址：INJECTING EMPATHY INTO YOUR ENGINEERING TEAM

Don't Ship Your Org Chart 

------  Steven Sinofsky

一般来说，注重工程性的团队发布的产品可用性和用户体验不会太差。但是就算在这样的团队，我以前当项目经理的时候也遇到过不少问题。。。重要的是如何从中学习和如何在下一个版本修复它。

可用性与用户实现既定目标的难易程度有关，而用户体验则包括用户使用产品和服务过程中所有体验。我们都不想做用户体验不好的产品。但是团队对产品缺乏理解，优先级排序不当和没有决定权，再加上没有时间的限制，那终于结果肯定不能让人满意。

为此，尤其对于那些已经有产品在运营的团队，需要将从用户角度的换位思考方式融入到组织当中。其中包括四个方面：提高用户参与，让每一位成员都对产品负责人但只对一个人问责，要转变思维定势的方式，言行一致。

INCREASE CUSTOMER INSIGHT

缺乏领域知识是产品失败最主要的原因之一。在这个需求快速变化的环境，团队很容易就存在盲点，忽视和淡化用户的需求。

"让用户到访"是提升与客户联系紧密程度和提高团队对求认知的方式。如果你的市场不熟悉，或者寻找想法当中甚至有一个比较确定的猜想的时候，用户访谈可以提供你需要的见解。如果你已经有产品，你可以通过意见提高产品的可用性。

我以前谈过“你的开发团队应该融入到你的技术支持团队当中”。这过程很痛苦，但是他可以使开发团队立即获得用户的反馈。每天工作之后，团队都能对产品和用户有一个整体的把握，同时也能观察到设计和技术实现上细微变化，从而提升用户体验。与用户保持联系很重要。你需要在不同的用户需求和你主要市场之间保持平衡。你需要激励你的团队，让他们不会平平庸庸。

MAKE EVERYONE RESPONSIBLE, ONE ACCOUNTABLE

团队每一个人都应该为产品的可用性和用户体验作出努力。从错误信息出发，日志，工作流程，可访问性，一致性等等，每一个细节都是重要。这些细节都包含你每一行代码当中，这就必须让每个人都对产品有责任感。但是你只能让一个人被问责，理由是产品的整体大于各个部分。（这是一个重要观点，但是翻译得不太清晰。）

提示一下，问责和授权是对立统一的。不能授权不问责，问责不授权。

需要被问责的人应该是能处理人与人之间的关系。他应当有能力能带领团队性格，技能完全不同的各位成员在系统约束下做出体验最好的产品。

当你要改进现有的产品的时候，无疑你会陷入“我的产品就是棒”，“用户之前就是这么说的”这样或者那样的自我陶醉。变化很困难的！作为项目的发起人，你的任务是推动这个改进的过程，通过数据说明事实，通过交流使团队理解改进的意义。不断自我否定，并落实到实处。

ADOPT AND ADAPT TO ACCOMMODATE CHANGE

可用性和用户体验是来自整个产品的。相对的，工程管理和项目管理只是处理项目模块划分和管理的事宜。这就是为什么你会看到团队内部的结构和组织会反映到你的产品上。（这是一个重要观点，但是翻译得不太清晰。）

为了解决这样的割裂，你需要留意各个模块之间的联系，想方设法填补之间的空白。尤其是你的研发团队，因为他们本来就是不怎么对外的部分

“Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”

—General George Patton

用户至上的原则不是遥不可及的。沟通和协作是构建一个伟大的产品必不可少的部分。同时，你需要敏捷起来，这样你的团队才能在失败当中快速爬起来。要做到这点，你需要版本控制，你的发布流程和你的产品架构需要修改以协助这看似混乱的产品研发过程。

WALK THE TALK

你对产品的考量决定的你的道路。你必须言行一致。言行当中你表达出你的观点，这为团队定下了基调也知道他们工作。

你要令你的团队不单只是实现功能而且要让他们了解用户的使用环境和用户要解决的问题。这不单是对团队强调用户体验就行的。你还需要形成系统地框架，简化它，让所有人都能了解，从而产出有创造性的解决方案。

为了帮助你的团队，你需要清晰地跟踪各项重要的指标以及各项指标之间的优先级排序。你也需要了解团队的需要，现有资源和技能，从有帮助组织填补组织上漏洞。

最后，公开的奖励整个团队～这才是TEAM-WORK!