转换沟通语言

最新推荐文章于 2024-05-06 19:00:00 发布

NxxCalm

最新推荐文章于 2024-05-06 19:00:00 发布

阅读量233

点赞数

分类专栏：程序员生涯文章标签：产品设计

本文链接：https://blog.csdn.net/weixin_37702639/article/details/121361572

版权

程序员生涯专栏收录该内容

2 篇文章 0 订阅

订阅专栏

https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/thing_03/

用户会探索自己的使用模式，他们会找到一种可行的方法，不管它有多复杂，他们都会坚持下去，提供一种显而易见的做事方式比提供两三个捷径要好。用户说他们想要什么和他们实际做什么之间存在差距，这就是为什么获取需求的最佳方法是观察用户，花一个小时观察用户比花一天时间猜测他们想要什么信息更有用

程序员除了实现软件需求，也要实时处理线上问题，低头撸码的程序员，往往不能善终，总结最近工作中遇到的沟通问题

价值变现代沟

软件本身没有价值，要依附在帮助用户增加效率，完成变现上；用户和商业软件互相成就
然而用户和软件开发者，所处的领域不同，开发者没有用户的行业背景(不能对用户使用场景感同身受)，用户没有开发者的计算机知识背景
用户和软件开发者色看问题角度不同，用户关注的是操作，描述的是现象，开发关注的是实现，描述的是逻辑

沟通第一条

尊重客户，心态第一，不要嫌烦
客户买软件买服务，公司发工资，牢记牢记

将现象转化为问题

最近自己所在业务团队集成另外一个其他团队的功能，简单的说这边统一入口，点击不同按钮，跳转到另一个团队特定业务页面。上线后一线反映有一个款项表单不能报销，当时很急通讯工具上文字反应问题。
用户实施客服可能在问题上面加了自己的思考和语言，这些可能是掩饰了基本点，刚接受这个问题我第一反应是，对应按钮的打开点不对，例如按钮A的点击却是按钮B的。一线人员要求电话沟通，文字说不清，我拒绝了，原话是“我现在也是懵的，电话说估计也我也不能听懂，我先用对应账号操作下，还原下流程，思考下，然后马上联系你”，一线同事同意了。
我打开软件操作弄明白了问题，该款项在原系统中有三个入口，其中两个可以查看不能编辑，一个可查看可编辑，集成到我们系统中刚好选中了两个不能编辑的；用户不是不能报销该款项，而是不能编辑，只能按默认值0来报销。我这样一说，一线人员连忙称是，群里的需要产品也明白了问题。

磨刀不误砍柴功，花时间还原问题，分清是操作疑惑，还是实现问题，或是改善建议。曾经企业用户网络访问不到局域网数据库，让用户找下网管看看，用户不知道网管是啥；不能低估行业背景，有些认知误差不可思议，更不能嘲笑，缓缓引导。

将实现转化为业务现象

还是同一个系统，自己业务团队集成了多个系统，有时要搞定多个系统数据的对应问题。
A系统的一个款项时间为10.01到10.31，B系统中款项款项时间为10.10到10.12，A的一条可以对应B的多条数据，金额累计，产品要求是要时间严格对应的，这样就导致了金额对不上，这也是在线上发现的。
这个问题出现了，从业务上来说，问题中的B记录包含到A记录说的通。产品要求对应时按月份对应，不比较具体时间了，我提议按时间区间包含关系对应，程序实现为A.begin <= B.begin and B.end <= A.end，即A的区间包含了B。当然我对产品说了这个实现，强调和只对比月份实质效果一样(实际业务不会跨月)，会更严谨。

比较简单的逻辑很好用业务语言描述，如果逻辑复杂，可以结合场景讲清除；为啥要把实现给产品讲，第一该逻辑业务中重要经常用，讲了实现产品放心，第二讲给产品，也让产品把把关，尊重人家专业。