最近刚加入一个新团队，在推进新项目时，通过观察团队中各个角色伙伴们的工作，跟我之前的经历经验相比较后，发现了很多「问题」，所以我就在每周retrospective会上为此让大家反省讨论一番，提一些建议，但是效果甚微。安静的时候再想一想，觉得可能走了弯路。
思考得到的结果是：以前的经验应该作为参考，而不是以此为标准对当前团队成员的表现进行全盘的批评和否定。每个人有每个人的习惯，每个团队也有每个团队的基因。适合A的方式方法，在B这里也许就不起作用，甚至还有坏处。所以在正式提出意见建议前，需要回顾了解团队的发展历史，搞清楚团队是怎么走到当前这个位置的，以前的项目是用何种方式管理推进的，以前的产品是如何做决策的等。
刚好这两天在medium上看到Facebook一名PD讲了相关的问题，所以翻译过来跟大家分享一下。
1.
去年夏天，我在Facebook内部换了工作团队。第一个项目新项目很简单：重新设计安卓手机（低端）应用—Facebook Lite的注册流程。
我迫不及待地想开始这个项目，看起来是一个比较常规的标准设计问题，减少用户注册时的困惑和摩擦，确保注册流程的使用体验。
接着，我做了很多设计师在面对同样问题的时候会做的事情：回到我的办公桌前，开始搞。研读了相关的UX报告，测试体验了竞品，最终提出了一个我认为非常可靠的方法。
当我把方案交付给我的团队时，期待着他们称赞我的设计方案。相反，只是我一个人的自嗨，我沿着错误的跑道跑到了终点。
2.
我最初的设计违反了作为一个团队的新设计师的三个基本规范：
a. 在团队既有知识和经验基础上进行设计
b. 多做假设
c. 了解团队对成功的定义
由于忽略了团队过去建立起来的知识和经验，于是我提交的方案在当前团队成员看来，就会显得没有前后关联、欠缺科学性、无用。
我本应该首先聚焦在一些「团队是如何到达今天的状态」的问题，而我却浪费了更多时间在细节设计上。
我没有完全理解团队的目标，这意味着我无法清楚地阐明为什么我们应该以一种与团队产生共鸣的方式来构建我的方案。
3.
作为设计师，我们很容易就能在不充分考虑历史背景以及成功的解决方案应该达到什么效果的情况下投入到工作中。
想象一下，你一上来就在一个项目上努力投入，却被告知遗漏了关键的一步，忘记了先问正确的问题，或者完全没有理解项目的目标。
It’s like being told you put your belt on, but forgot your pants.
一旦你了解了团队以前的工作情况，你就会了解他们的目标以及他们如何衡量成功。每个团队都有重要的指标，如果你忽略它们，你就不能很快很好地融入。
当团队中的每一位成员有共同目标且相互认同时，团队就可以顺利过渡到一个健康的协作环境里，团队价值可以保证很好的实现产品价值。
4.
为了创建一个协作环境，并得到更好的设计方案，我学会了在每个项目开始时问三个简单的问题。
4.1. How did we get here?
了解你的产品和团队是如何走到现在的。即使你正在开发一个新产品，你和你的团队也可以从下面这些问题中学习到很多东西。大家一起吃午饭或喝咖啡的时候，问几个问题：
a. 团队已经完成了哪些重要的里程碑？
b. 最自豪的项目是什么？为什么？
c. 哪些项目最想做但还没有机会去做？为什么？
有很多因素影响着产品的发展。我最喜欢的一种探索历史的方法是观察多年来产品发生的视觉变化。Facebook的设计师们在公司内部网站上分享他们的工作，在这个网站上，你可以浏览一个产品的历史版本。它可能并没有说明整个故事，但这是一个令人大开眼界的实践，可以给你提供一些好问题，让你带着问题回到团队。
记录你从团队中听到的，帮助那些将来加入团队的伙伴更快获得你所收集到的宝贵知识。大家了解这个项目是什么，为什么要做，以及最后的结果是什么。
4.2. What’s our hypothesis?
a. 有什么改变吗？
b. 改变影响的是谁？
c. 为什么要改变？
d. 可以在哪里记录这些假设，以便让每个人都能很容易地访问它们？
当你进入设计阶段时，你的假设大纲可以作为你重新审视的向导。通过这个大纲，你可以很好评估提议的设计方案是否靠谱。
我的团队经常通过Facebook群组进行交流，这让我们可以在一个开放的地方讨论，每个人都能自由发言。什么工具并不重要，但如果可以进行协作沟通，效果会比较好。
4.3. What does success look like?
每个目标都有与之相关的指标，诸如「减少异常的发生次数」「增加愿意主动推荐产品的人数」。作为一个团队，应该要在开始一个项目之前回答这些关于「指标」的问题：
你会看什么指标?
你期待的变化有多大?
如果没达到具体的指标，下一步该怎么办?
如果达到了具体的指标，下一步计划是什么?
回答完这些问题，再去定义成功，你就很容易就得到结果并由此启动工作，因为你已经在之前付出了很多努力。
在Facebook，我们有一整套强有力的工具来监控指标。但过程是动态的，不能完全依照死的标准，所以我的团队每周都会留出一些时间来讨论结果。这些会议是跨职能多角色的，在结果有偏差的时候，让每个人都有机会参与讨论，并给出意见。
在项目开始前定义好目标（成功），确保你朝着最终的目标前进，这样使用你的产品的用户才可能拥有最好的体验。
Look back to look ahead
产品的历史版本给你一个机会去了解产品现在的样子。通过这样的机会，帮你排除不靠谱的解决方案，帮你了解基于产品特性的设计约束，并帮你为产品的迭代做出正确的决策。
完。
