我们可能会在不同的场合听到过，要把用户满意度放在第一位。
大家都知道提升用户满意度是很重要的，但也难免人云亦云，不知道其中的原因。
本文想向大家分享一下，我对用户满意度的理解，以及在提升用户满意度时我常用的办法。
各行各业都有提升满意度的说法，而我个人的水平十分有限，难以写出大而全的指导方针来，
所以，下文就仅限于工程团队，谈一下我的看法吧。
为什么要提升
要想解决问题，首先我们得弄清楚问题是怎么来的。工程团队/基础架构团队 相比于 业务团队，有很明显的特殊性，主要体现在以下几点：
工程团队是提供开发者服务的，用户是开发（会写代码），业务团队的用户一般是老百姓
工程团队的价值必须依靠业务团队体现出来，工程建设也是为了更好的交付业务价值服务的
做工程一个人推不动事情的，必须借助业务团队来帮忙（资源投入、配合实施）
因此，工程团队离开业务团队就转不起来了，我们可以简单的算一笔账。
从效能层面来看，一个 100 人的开发团队，每人每天提效一个小时（按每天工作 10 小时算），那就能节省 10% 的人力。那么组建一个 10 人工程团队，就是划算的（大部分工程建设其实很难提效这么多，所以人数还要再少一些）。
从人力角度来看，10 人工程团队每天只能产生 10 人日的工作量，要想交付更多价值，只能依靠业务团队来帮忙。一个共赢的工程建设方案，可以调动起业务团队 100 人的开发资源，交付 100 人日的工作。
根据上面的分析可见，工程团队只有跟业务团队站在一起，才能更有效的交付价值。
如何提升
（1）跟用户搞好关系
工程团队跟用户的关系一定要好，因为业务开发开始给我们饭吃、养活我们的人。
没有业务需求，工程团队就没有必要存在。业务需求减少，工程团队就应该减员。
所以我们应该像对待衣食父母一样，维系好跟业务团队之间的关系。
只有放下架子才能做到急用户之所急、感同身受。工程和业务本来就是不同技术领域的事情，谈不上谁更专业或者谁更优秀。
知道用户在哪里：要有自己的用户群，提升工程团队的存在感
让用户可以找到我们：明示用户向我们反馈问题的流程，应该如何向我们提需求
帮用户记录问题：让人感到放心的一个办法就是记下来，持续更新进展，好过被遗忘 和 充耳不闻
（2）在人多的场合，维持好的印象
有时候会有个别用户，在人比较多的场合（大群中）找我们反馈问题。
这样不但会干扰到其他人的视线，也不利于问题被解决。而且，对工程团队的印象也是有损的。
比较好的办法是，及时识别问题的相关者，拉小群更聚焦的解决问题，事后到大群中同步进展。
保持好形象：别人对我们的态度，取决于我们向别人造成的印象
在人的场合注意言辞：语言是最有杀伤力的武器，不要冲动，想好了再说
小群解决问题、大群同步进展：很多人不关心问题是如何解决的，那就不要让细节干扰他们
（3）一切以用户需求为出发点
工程团队存在的价值在于能够解决问题 —— 满足业务团队的工程需求。
所以一切不能满足业务需求的工程化方案，都是耍流氓。
所以我们应该不留余力的去验证自己的假设，到底我们要解决的问题，是否用户所预期的。
不断的收集反馈、对齐预期：不要制造问题，减少提前猜测那些可能会出现的问题
敏捷的验证想法、保持迭代：不断调整工作方向、工作重心，有变化及时更换策略
（4）互相理解，引发共情
单纯的用户至上其实并不是最理想的结果，最理想的结果是团结一心。
所以工程建设的难处，也是可以跟用户交流的，事情不必一个人扛着。
我们还得意识到，我们的用户也是开发，他们也许在软件开发这项技能中比我们还更优秀。
没有事情是不可以谈的：有难处大家一起来解决，解决不了是不是事情想复杂了
用户也是开发：这个要点值得说三遍，不要帮用户决策，他们比我专业
结语
提升满意度的方法还有好多，以上只是我常用方法的一个小总结。
希望能跟大家多做交流，一起把工作做好、把事情理顺、让事业有成。