Topic: 团队的成熟度思考
最近的项目发生了相对比较多的故事，包括接近通宵去解决产线问题，以及在解决代码安全问题过程中的各种激烈讨论。虽然过程不怎么顺利，但是却发现团队成员的发言却更加敞开，更加毫无保留。在我看来，团队的成熟度相比以前又有了更高层次的发展。
谈到团队的协作，可以参考的书非常多，但对我个人来说影响最大的其中一本书是帕特里克・兰西奥尼（Patrick Lencioni）所写的《团队的五种机能障碍》(The Five Dysfunctions of a Team: A Leadership Fable)。他给读者描述了一个无法正常协作的团队会遇到的五种境况，称其为 “五种机能障碍”
- 缺乏信任
- 惧怕冲突
- 欠缺投入
- 逃避责任
- 无视结果
目前团队的状态基本上已经克服了惧怕冲突。 其他几方面其实之前就一直做的不过，遇到问题都会积极面对，但是在团队讨论中却往往会惧怕冲突。这是一种经常出现并且比较难解决的机能障碍，这一方面是跟文化有关，总要给人一些面子，所以往往话挑好的说，但其实也是在一定程度上的缺乏信任。 面对这两个问题，之前通常做的最多的是鼓励表达。这个有点像面对家庭教育时采用的正面激励。本质上这个问题是给团队成员建立安全感，让他们不会担心自己的想法表达被认为幼稚或者多余。经过多年的项目和团队管理，我越来越意识到其实很多时候真的没有stupid question。哪怕有些问题听起来非常基础，可以说是人所共知，但如果有人提出来，依然能让我们从中发现要么是内容方面的欠缺，要么是上下文不够清晰，甚至可以是宣传途径有可能不够充分所致。所以鼓励发言，鼓励提问是营造团队氛围的一个非常重要的一步。
第二点是一定要把焦点集中在问题本身。让每个人都知道所有人的建议、行为都是为了解决问题，只不过是从不同的角度来考虑。如果不认清这点，那么很容易会把焦点转移到人身上，从而不可避免的引入个人情绪，严重的会导致私人矛盾，所以一定要避免。
第三点是文档记录和衡量指标，可以是代码，可以是metrics，总之用数据说话会让人消除很多口头表达上的误解。这点目前团队相对偏弱的地方，但是如果看国外的项目，数据是非常丰富的，而各个维度的数据也非常有针对性，能很好地定位到问题从而关联上行动步骤。这也是后期需要加强的。OKR之所以流行，也是在很大程度上把Vision变成产品或者服务上的可衡量的指标。如果目标可衡量，那么在过程就更容易执行。
Topic: 关于倾听客户的声音
这已经是一句烂大街的话了，每个做产品或者服务的公司和团队都知道要倾听客户的声音，可是在实际工作中，做的好的其实并不多。阻止这一行为的，有时候是傲慢。最近有个新闻，一辆蔚来测试汽车在上海创新港8号楼3楼坠下，两名试车员不治身亡。事情发生后，蔚来的回应是：
1
这是一起意外事故，与车辆本身没有关系。
面对两条人命，蔚来的这种傲慢冰冷到如同机器，毫无感情。
蔚来也许认为知道自己了解客户，所以在第一时间告诉用户车辆没问题，但同时却也暴露了自己袒护产品和品牌的迫切心态。
我们面对客户的声音，是不是也能先做好倾听，还是说直接告诉用户你应该听我的，应该怎么用我们的产品，用户的提议是多么的肤浅愚蠢？ 这种骄傲的心态，不确定是从何而来，也许是从了解产品的程度自然得到的吧，毕竟自己被用户更加了解产品的产生过程和设计初衷，但是用户怎么使用产品其实根据他们面对问题时候的思路来了使用的，这点上反而是制造产品的人该问的问题。
我印象很深的一次演讲是奈飞的创始人举得一个例子。他用市面上用了很多年的油漆桶做例子，说从他小时候开始，打开油漆桶就是一件非常难的事情。没先到到了自己有了小孩，油漆桶的包装居然几十年如一日没有任何改变。是没有用户给他们反馈吗？ 还是对于这类声音充耳不闻呢？到底是什么原因造成了这种结果？