产品经理的日常工作，跟客户的沟通必不可少，被客户DISS也成了“日常”。
昨天又一次被客户在沟通会上DISS了，之所以用“又”是因为它就像北京的大雾（或大霾）一样，指不定哪天就来了。
天无三日晴，心无三日宁。要想做产品，学会理和情。
小提示：为了完整复原”事情原貌“，今天分享内容较多，且与本人工作相关性比较强。如果你无法有效理解内容，不是你的错；如果你不想”浪费时间“阅读，也不是你的错。（但最后的反思与总结两部分内容，希望对你有帮助）。
背景
客户是一家刚新签不久的成交客户，旗下有3-4家子公司，每家子公司有100-200人。签约时，因现有系统无法满足需求，故而给客户二开了两个需求（其中之一就是前天又跟研发同学吵了一架）。
二开：指基于现有系统进行二次定制开发，一般潜台词是付费定制，只专属于某个客户所需。
当初愿意二开的两个原因是：
- 需求合理，且是通用性需求，不局限于此客户使用；
- 客户愿意将签约时间由1年延伸至5年。
起因
周一时，销售跟实施同学找我沟通，客户其中一家子公司，又有一个需求不满足，期望让我看看是否有解决方案。
客户有部分白领员工的上班工时规则比较特殊：
- 每天出勤总工时以打卡时长为准，而不是班次时间。比如7:00来，21:00走，是13.5小时（扣除休息0.5小时）；
- 每个月总出勤时长，只要超过每月的标准工时，就不会有惩罚；
- 每月标准工时 = 当月工作日天数 * 8小时；
- 每月总出勤工时 = 当月每天出勤时长之和
注意：上面是当时实施同学转述的概要信息，并非完整信息。
客户期望结果是：
- 员工可以实时查看，自己当月总出勤工时是多少，还有多少差异工时，从而把控自己的工时进度；
- 管理员也可以实时查看员工的工时情况，便于有效进行管理；
实施目前所能提供的方案有两个弊端：
- 数据不透明：员工无法有效实时且便捷查看工时，必须自己根据每天的打卡与出勤情况，自行计算；
- 操作繁琐：管理员要看到数据，必须每次先操作一次归档，将截止当天的数据进行一次计算才可以同步至另一个模块查看；
经过一轮沟通后，基于目前系统逻辑，确实无法有效解决上述两个问题。于是，他们就回去跟客户反馈，我也没再跟进。
经过
周三时（即2天后），销售又给我发了一个文档，问我：“境哥，这个可以二开吗？”
上述截图信息，不是没截全，而是完整文档如此。所以对于产品经理来说，一定是满头的问号脸。
我说：“规则相对复杂，一般二开人日比较高，所以需要看下客户，是否真要评估？如果需要，则需单独写个需求文档，补全对应规则。比如怎么定义员工有晚餐，要扣除30分钟出勤时长，每月标准工时、每月实际出勤工时的定义等。”
销售说：“好的，那我跟客户沟通下时间，咱们拉个会。”
跟客户约定了周五上午10:30-11:30沟通。
会上
周五（即又1天后）上午10:30，我、销售、实施跟客户的采购、3位子公司的HR开会，会议因客户其中一个HR晚到，延误了大概10分钟。
第一轮：”正常”开始
先是销售同学介绍了大概背景。
“各位老师好，针对XX子公司的白领弹性工时，系统无法满足问题，今天我来了咱们技术的同学跟大家沟通下，咱们是否有更好的解决方案？”
实施同学补充到：“境哥，背景就是那天跟你说的那个标准工时的问题，目前我们是在工资模块搭建了一个自定义公式，每天将考勤月报数据进行归档后，同步至工资。但每天操作比较繁琐，并且标准工时的计算只能是整月，而不是截止至今天。”
“嗯，目前系统确实没办法有效解决，咱们需要聊下需求规则，看看是否还有别的方案？”我说道。
第二轮：切入正题
其中一位客户（即需求提出者）说：“我们的规则很简单，就是员工弹性上班，只要核心时段在岗就不会有异常，每月最终看总出勤工时，如果超过标准工时即可。现在系统无法满足，所以XX说拉你们技术的人看看，有什么解决方案。”
我说：“咱们班次8:30-17:00，员工10:00来，也不会有迟到，是吧？”
她说：“是的，文档里都有描述。”
我说：“咱们是怎么定时标准工时的？是按照法定标准日历的工作日天数，还是按当月排班的天数？”
她说：“就是日历上的工作日天数。”
我说：“如果遇到法定调休工作日，也正常算，是吗？比如10月、9月法定放假后，都会有调休的工作日。”
她说：“是的。”
我说：“好，如果员工有请假的时候，咱们是怎么计算工时的？比如全天、半天或几小时。”
她说：“我文档里都有写。”她边说边开始分享屏幕，并把鼠标拉到文档的那句话，并说到：“各种申请假期都是从8:30开始，17:00截止。”
我说：“举个例子。如果员工请假全天，那当天的实际出勤时长是8小时，还是？”
她说：“8小时。”
我说：“如果请假半天呢？比如请假上半天，回来是否还需要打卡？”
她说：“我们要求员工回来必须打卡，请假时长和出勤时长就是员工当天总出勤时长。”
我说：“如果按小时请假8:30-10:00，员工却在9:30打卡上班，晚上17:00打卡下班，那9:30-10:00既是请假时间，又是打卡范围内的时间，咱们期望怎么处理？”
她没有回复我的问题，而是会上问了另一个子公司的HR：“XX，你们那边是怎么处理的？”
对方回复到：“我们这边没有这个问题，按原则说，肯定不能重复计算时长。”
我追问到：“目前我们可能不一定可以去重，这个必须处理吗？”
第三轮：客户被激怒了
她说：“你们到底有没有认真对待我们的需求？你们有没有提前做准备？我们今天几个人开会，需要的是一个解决方案，而你在这东一句西一句的问，很多问题我文档里都有写，你们也不认真看，你们可以分享今天会议做了什么准备吗？当时实施很快，运行一个月下来，员工反映比较强烈，今天把采购一起拉上，就是需要一个解决方案，你们内部到底有没有重视我们的需求？”
销售紧急补充到：“咱们的需求我们肯定重视，我们内部也沟通多好几次，但技术伙伴有咱们的需求规则有些需要了解，也是期望了解清楚后，可以有个好的解决方案。这个问题是怪我，没有提前梳理一个文档，提前发给咱们这边，那你看咱们今天是先这样，我们梳理好问题后再沟通，还是继续沟通清楚后，境哥看看能不能直接给出一个解决方案。”
说实话，此时我心里也有了些许情绪波澜，但强制自己压住情绪。
“耐心”地解释道：“因为咱们之前的方案，基于现状肯定不行，所以我需要回到需求本身，了解清楚你们的细节规则后，才可能评估是有有新的方案。我提问的逻辑是从每月标准工时的定义，到每月实际出勤工时的定义，最后就可以得出一个当月差异工时。但实际出勤工时会涉及到每天怎么计算，请假怎么算，加班怎么算，外出怎么算，出差怎么算等细节问题。那咱们今天是继续沟通，还是梳理个问题清单后再沟通？”
她说：“继续吧。”
第四轮：DISS后的小心翼翼
我心里的情绪缓少了些许，但小心翼翼的情绪多了一些。所以就选了一个最容易切入的问题。
继续问道：“文档里提到员工当天有晚餐，就要扣除30分钟实际出勤时长，怎么定义有晚餐？系统可能需要规则。”
她说：“你们系统可以有个地方，让员工每天勾选一下，有晚餐，或没晚餐。有就扣，没有就不扣。”
我的情绪又起了波澜，但我理解她对系统认知的有限性，耐心的回答到：“这个可能不太行，咱们是否可以有别的定义？比如每天晚上打卡时间超过9点就算有晚餐。”
她说：“好像也可以，每天晚上打卡超过7点就算。”
我说：“如果员工当天有请假，比如请假上半天，那晚上打卡超过7点，也还是正常算晚餐吗？主要是考虑请假时，要不要有什么特殊逻辑，因为有的企业在扣款或补贴时，都会考虑请假的情况。”
因为有了前面被DISS的经历，所以我开始刻意补充为什么问。
她说：“不用，不管是否请假，只要吃晚餐就扣。”
第五轮：渐入佳境
我说：“好，那咱们员工有外出、出差什么的吗？”
“有。”
“咱们外出、出差的最小单位是天，还是小时？”
“外出可以按小时或半天，最少0.5小时，出差只能一天。”
“那外出、出差时，是否需要打卡？还是直接申请就可以了？”
“不需要打卡，审批就行。”
“那外出、出差时长，最后也算出勤工时，对吧？”
“是的”
“好的。最后，再给你们对齐下需求。”
第六轮：收尾阶段
“咱们期望员工可以看到哪些数据？是只要每月标准工时、实际出勤工时、差异工时就行，还是必须有每天明细？”
“主要是每月统计数据，每天明细最好也有。”
“咱们期望员工在哪里查看？比如手机端、电脑端”
“如果手机端麻烦的话，咱们可以先在电脑端，至少先让员工可以查看。”
“好，那管理员端呢？”
“管理员也一样，可以看到员工的工时情况。”
“咱们有几个管理员？”
“现在有4个，我是管理全部员工，还有3个考勤专员，XX是管理XX，YY是管理YY。”
“好的，那我这边基本了解清楚了，我今天会梳理方案，预计下周一下班前跟你们一个回复。”
此时，销售问道：“那老师们还有其他需要沟通的问题吗？如果没有，我们下周一给咱们一个答复。”
“没有了，咱们今天就到这吧。”
“好的，拜拜。”我说道。
会议结束后，我花了周五大半天的时间，重新梳理了方案以及预估人日，准备下周一给客户报价，咱们未完待续。
反思
首先，会议目标不一致。客户预期目标是沟通会上有解决方案，而我的预期目标是沟通清楚需求。这就造成双方预期目标，在会议开始前就有了偏差。
第二，信息差严重。客户会认为需求提前已经同步给我们的实施、销售同学，你开会前一定是知道了全部信息，而当我问到一些细节问题时，她会觉得你不用心，你没做准备工作。
第三，思维方式差异。客户对系统是“小白”级别用户，她们的思维方式不会非常严谨，都是基于问题和“需求”展开，属于感性思维；而产品经理的思维方式，跟研发、测试打交道较多，就会形成“专业化”思维，确保逻辑闭环、规则明确，属于理性思维。
第四，沟通方式。沟通能力对产品经理是一项关键软技能，如果你无法有效提问和沟通，容易激发客户的防御心理，产生一种被“咄咄逼问”的感觉，情绪累积到一定程度后，就会产生像男女朋友之间的吵架模式，从一个点转移到一条线，开始细数你的“不是”，你的产品的“不是”。
最后，情绪管理。沟通能力是可以有效提升，前提是你需要懂得情绪管理。比如在客户情绪激动时，你不能继续火上浇火，你一定要控制自己的情绪，其次才是解决客户的情绪，最后才是沟通需求与规则。
总结
第一，提前做好问题清单。如果产品规则复杂时，跟客户沟通前，一定提前梳理好问题清单，并提前发给客户，让对方心理有预期，也让客户看见你的诚意。比如案例中，对我而言，所需提问的内容，基本上就是一个公式：差异工时 = 实际出勤工时 - 标准工时，只要把每个定义沟通清楚，基本就结束了，但对客户来说，你就是在”瞎问“。
第二，对齐目标与预期。会议开始时，提前跟客户就目标、预期先达成共识，再开始沟通需求与细节。比如案例中，开会前双方预期就存在较大差异，而没有达成共识。
第三，提前与客户同步你的想法与意图。比如案例中，提问开始前，应该先解释说“咱们现在的解决方案是有问题的，这条路不通，所以我可能需要花一点时间，提前跟你们沟通清楚原始需求，我会从标准工时、实际出勤工时的计算逻辑开始沟通，最后跟你们对齐你们的预期，然后我在基于今天的沟通情况，提供咱们一个解决方案，你看可以吗？”
第四，提问时，多解释“为什么问”。比如“咱们班次请假时间从8:30-17:00开始计算，但我们系统会有三种的请假方式，所以可能需要跟你确认下规则，否则影响实际出勤工时的计算。”
第五，不要连续追问超过3次，否则容易激发防御心理。如果一个问题需要多轮询问时，一旦超过3轮后，最好就缓冲一下，比如垫一句“这块场景可能有点复杂，但又比较重要，所以需要问的细致些。”
最后，不要问让用户“难堪”的问题。有时，你心理会预设用户“傻白甜”（比如如果员工晚餐就扣减30分钟的问题），期望展现你的“专业性”，结果往往会导致客户在这“输”的（比如请假时间与打卡时间重叠计算问题），全在别的地方找补回来。
写在最后
产品经理每天的日常工作，都在跟不同人打交道，他们角色、岗位不同导致立场跟思维方式有差异，我们不应该采取“专业化”、“标准化“的手段，抱着一种“我要赢你”的心态进行沟通，否则一定会产生各种吵架、DISS。
比如跟研发、测试沟通，他们需要的是严谨、闭环、合理的确定性，而会忽略用户场景、用户频次，甚至企业成本；
跟设计沟通，他们需要的是用户场景、设计感、审美，而会忽略产研实现成本；
跟销售沟通，他们需要的是达成目标，完成签单，而会忽略你的感受以及企业的成本，只要可以签约，即使承诺需求而“浪费”产研资源也无所谓（典型的公地悲剧）；
跟客户沟通，他们需要的是解决问题，而会忽略你的逻辑、规则以及成本。
所以，作为产品经理，你就需要跟不同人沟通，采取不同沟通策略。有时需要“小白思维”，有时需要“老板思维”，有时需要“产品思维”，而有时只需要“正常人思维”（即常识判断），真正做到“见人下菜碟”。
今天所分享的全部内容，本质就是产品经理的两大软能力的体现：同理心、沟通能力。
我还有很长一段路要走，虽然好像已经工作多年，却还在这方面反复跌倒。
咱们未完待续。
