团队合作的心得和感悟
啊…?一转眼公众号就鸽了一个月?
其实9月上旬已经写好一篇?PSSD Methodologies & Tools?的分享，考虑到很多是老师课件上的内容，觉得还是申请一下许可比较好，结果老师看完表示?‘I prefer not to post them online’ (Orz…)。加上这门课讲的还是比较基础的，跟自己从工具书上学到的方法并没有太大区别，分享课程内容的想法就被搁置了。
假期终于把这段时间的notes、照片和文件都回顾了一遍，发现其实短短一个月经历了好多事情，有很多不同的观念方法?INPUT?进来，也有挺多想和大家分享的。这次就先结合最近结课的小组项目，跟大家聊聊团队合作的感悟吧，毕竟这也是很多人都要面对的事情。
01
? 首先关心人本身?
有时候我们太关注于项目，而忽略了「人」才是一切合作的基础
“开FUN” 社群策划人刘立言在分享他们团队合作的方法时，提到每次开会前后都会预留15分钟的时间?’Check In’ 和 ‘Check Out’?，这个阶段不聊项目而是了解队友的心理状态。
刘立言 – 开FUN的食物社群怎么玩起来
之前IDEO的实习生也分享说，每天在公司被问得最多的就是?‘How Do You Feel & How Can I Help?’，他在一开始被这样问的时候，会下意识地汇报项目进展，而对方总是会解释:「我不是在问项目，我想知道的是你的感受」。
想起之前看到的一段话:「管理人的本质就是管理情绪。因为人情绪正常的时候，理性自然会引导他的行为」。回想这次小组合作中，很多低效的讨论和没有意义的argue都是因为当时大家状态已经「不对了」。
所以，下次小组合作前，不妨花一点时间了解彼此的感受和心情；在项目讨论中，发现双方情绪不对时，也可以先找借口缓一缓，而不是继续争吵。
02
? 理解并尊重差异?
小组合作中，非常容易出现对一件事情的理解和预期不同的情况。因此，在项目开始前，大家先坐下来聊一聊各自习惯的思维模式、工作方式非常重要。
思维模式和工作方式上的差异，常常引发无关方案的冲突
例如，我们项目在进行ideation的时候，有的组员有了一个很好的点子，就会想直接开始develop这个方案，但我就很难接受在还没有分析其他可能性时，就确定一个「看上去不错」的方向。
一开始我们以为问题在于方案，后来才发现是思维模式的不同。有的人是找到一个不错的点，就先走走看不行再换另一条路；而有的人是先广泛涉猎不同的点，了解全局后才能决定选择哪个点深入。「直觉型」的人是先看到了一个可行的image（结果），然后再去寻找背后的逻辑支撑；而「分析型」的人需要先找到逻辑证据，然后才能一步步分析到最后的结果。
同样的差异也体现在工作方式上：例如有的人喜欢先自己思考，得出insights再和团队分享；而有的人需要在和别人的交流中，才能得出insights。
借助能力模型和性格测试，快速了解组员在团队中适合担任的角色
米理PSSD的课程开始，就有一位心理学老师上的 Team Building 的课，作为之后其他小组合作项目的基础。根据四倍的分享，这门课上大家先是分国家介绍自己，有哪些文化习惯和禁忌（比如有的同学不允许摸头和拥抱）；然后分享各自的时间观念（比如有人直接说:「我说的五分钟到是一个小时」）；接着做性格测试，了解不同性格在团队里的角色以及和这样的人合作的优缺点；最后每个组还要一起制定一份规则并发表，包括解决分歧的方法等。（具体介绍可以戳这里）
16personalities里十六种不同的人格类型
合作的意义在于优势互补
我一直觉得团队合作是为了达到1+1>2的效果，而不仅仅是把项目平均分成几个部分，每个人把自己的部分完成再拼到一起。所以大家存在能力、思维上的不同其实是好事，关键在于如何理解分歧并找到中间的平衡点。
比如我们组在第二次调研地点选择时，就出现了不同的意见。有人觉得用户的需求已经相对明确，应该去跟system联系更紧密的地点调研；而另一些人觉得我们还没有采访到Target User，应该去目标用户群较多的地点调研。我们没有再继续争论到底哪一点更重要，而是分成两个组同时去调研，最后这两部分的调研都对我们的方案产生了积极影响。
03
? 表达要考虑影响?
可能是因为一直都处在鼓励自由表达的环境中，小组讨论时，我也会习惯有任何想法都说出来，但的确有时候忽略了表达的目的和给团队其他人带来的影响。于是整理了一下需要注意的方面（也算是对自己的提醒吧）：
不是所有看到的问题都要立即说出来
首先要注意说的顺序：先提底层的问题再讨论表层，先整体后细节。比如服务设计，先关注整体的system，再讨论具体touchpoint；交互设计先提框架层的问题，再去说视觉层面的事情。
然后要注意说的时机，在其他人都非常认同一个方向时，如果自己不认同但是又没有足够的理由，可以先放一放，等仔细思考后或者形势出现转变了再说。
否方案时，要思考替代方案
哪怕在你有充分的理由来证明一个方案不可行时，如果并没有想出更好的替代方案，最好也先把这部分理由保留，以防让整个项目陷入困境。
04
? 从课程目的出发?
相信很多做设计的小伙伴都会有点「理想主义」倾向，我自己也不例外，价值导向型的设计师会希望设计本身是有意义的，而不仅仅是满足某个课程的评价标准。
很巧的是，这次合作的小伙伴大部分是比较功利主义/现实导向型的人，他们会觉得对于一个并不期望落地的课程项目，主要目的就是满足课程和老师的要求。
说实话，以前我会有点反感这样的motivation，但是现在想想也挺有道理的。既然是小组课程项目，那么大家最容易达成一致的motivation，就是好好完成这门课，而至于个人的motivation，比如你想做一个什么样的设计，其实不该强加到其他组员身上。
学会去理解课程目的和老师的期望
记得很久之前听一期「异能电台」的节目，邀请了ACCD GPA第一的学霸分享。其中一个有趣的问题是:「当自己想做的方向和老师期望的方向冲突时怎么办」，她说她会去思考老师这门课程布置这个作业的目的，比如是想看到手绘能力还是建模能力、调研能力还是表达能力，然后在作业中首先体现自己具备了这部分的能力。在完成老师期待的内容后，再抽时间去探索自己想做的方向，可以是在原来方案的基础上改进或出两个方案，但不管怎样，都会保证作业中老师期待的能力她已经具备并表现出来了。
客观来讲，上一门课就是应该努力去学习这门课答应教给你的东西，完成课程目标。比如「产品服务体系设计的方法论和工具」的课程介绍中就写着目的是帮助学生：
① 建立设计的全局观
② 利用工具推进项目并将过程可视化
③ 利用工具触发利益相关者的参与
同济大学本研一体化教务系统
如果从这个角度思考的话，就很容易理解在最初给老师介绍方案时，老师为什么会说: ‘Don’t focus on one point and lose the whole picture’了，因为服务设计就不仅仅是关注某个用户的某个痛点，而是要考虑到所有的利益相关者和整个系统。
而课程的第二点，我们只做到了「可视化」，并没有真正利用工具来推进。所以，结课后也有组员说，觉得我们不应该是先定了方案，再用工具去表达，而是过程中就应该利用工具来推进方案。至于课程目的的第三点，感觉更是被所有人忽略了。
项目永远不会完美，先Focus在一个小的阶段目标上反而比较容易接近完美
回到最开始说的设计师容易出现的「理想主义」和「完美主义」倾向上，就像你没法通过一门课就学到所有需要的设计知识，我们也不该期望自己通过一个项目就锻炼到所有方面的设计能力。
也许和「理想主义」和解的最佳方式，就是像 Elon Musk 一样将宏大的理想拆分成一个个可实现的小目标。与其怀着「我要做一个超赞的方案」这种说了也等于没说的理想，不如把「超赞的方案」所需的元素拆解，比如可能有：理解客户（老师）需求的能力、洞察用户需求的能力、团队沟通合作的能力、设计表达的能力等等，然后可以每个阶段focus在其中一方面能力的提升上，这样能避免因为一些不可控因素而对自己/方案产生全盘否定的感觉，长期来看反而更容易实现「理想」。
?
-?END –
好像写了很多建议
其实大部分是自己没做到的方面hh
总之感谢组员的包容和（emm不杀之恩？）
下周又要开新课了
期待结束的时候再回头看
或许很多想法又会发生变化
（封面图来自小组视频的布景，Photo by Ray）
