做好用户沟通，了解用户习惯和用户目标对于一个B端产品的成功来说十分重要。所以今天我想聊一聊关于用户沟通我个人的一些思路。在产品迭代中，按照产品的输出过程，我把用户沟通可以分为以下几个阶段，需求沟通，方案确认，上线培训，产品灰测。
一、用户沟通
从需求方提出需求开始到产品方案的输出期间产品经理和需求方发生的沟通我将其统称为需求沟通阶段。主要是产品经理和用户基于当前产品使用过程中发现的问题或者基于本人/本业务的目标期望而对产品提出的需求和想法进行沟通。在这个阶段最重要的一点是要明确用户到底需要什么（用户需求），他为什么需求（用户价值）。
用户需求定位
通常用户需要一些引导才能得出真实的需求。你可能会问，作为用户，应该是最清楚自己要什么的，为什么要引导，引导什么？举个实际案例，某天用户A提出用户岗位中包含关键字“运输”的用户在填写用户资料时要求强校验用户的“运输工具”是否已经填写，如果未填写则提示保存失败。那么作为产品经理的你要怎么做，是否直接按照用户提出的要求通过岗位名称的判断在填写页面增加用户要求的校验吗？
————（此处请思考三分钟）————
需求方说他想要的真的就是他想要的吗？NO。
在沟通过程中建议用5W1H来定位用户场景，使用5Why挖掘用户真正的需求，同时需要完整了解现状（这个以后有机会我再展开聊）。
在刚刚的例子中，可以试试通过以下简单的问答来真正明确需求。
问：为什么这些用户必须要录入“运输工具”？
答：因为系统需要根据录入的“运输工具”进行派单计费，如果他们没有录入就会影响工资结算。
问：具体是哪些用户会需要根据运输工具派单计费呢？
答：比如调度司机啊、派单人员啊这些。
问：那为什么你提的需求是有岗位名称中有“运输”的人员要求必填呢，两者有什么必然联系？
答：因为现在我给这些人取的岗位名称都有“运输”两个字呀。
问：那岗位命名会一直由你来负责吗，后续如果其他人来处理，他们知道这个规则吗？
答：emmm...也许吧
所以其实用户的需求是，对于要使用“运输工具”的用户进行录入项目的管控，和岗位关键字无关。用户犯了把最终实现结果作为需求的典型错误。
需求价值挖掘
需求价值明确要求需求方在提出需求时明确这个需求为业务带来的价值，并且最好是可量化的价值。
这个阶段需要明确得向业务方问出这个需求的实现能够帮你解决什么问题，带来多大的收益。
要知道，和需求量相比开发资源永远都是不够的，总是有成堆的需求等待开发。所以，明确业务价值可以有助于产品经理更好的判断优先级，完成更好的产品迭代。而需求方自身在思考价值的同时，也可以对该需求进行更加深入和完整的思考，可能会有意想不到的发现哦。
对于比较大的项目需求，甚至需要明确到每个功能点的价值，便于产品经理进行需求的拆分。
二、方案沟通
基于用户需求，产品经理需要根据需求点评估和经验通过产品方案设计来达成用户的需求。在方案确认后正式进入开发前，需要和需求方进行最终的方案确认，通过文档演示的方式向需求方展示需求的实现方式及效果，以确保可以真正解决业务问题。
这里需要注意的是，完整的产品方案除了明确功能实现方式（满足需求）外还应该包括预计交付时间、交付范围、项目推进进度（灰测计划）。
功能需求
功能需求即指能够满足业务需求的整体方案设计，其中包括了功能点、页面、交互等用户可以直观看到、感受到的内容，也就是我们通常所定义的需求文档。
这点其实是属于基本内容，我就不再过多赘述了。
交付时间及范围
站在用户的角度来说，他除了关心自己的需求能否得到解决外，他还关心什么时候可以得到解决，也就是我们提到的交付时间。所以我们在进行方案沟通时，也需要基于实现的难度给业务方一个初步的预估上线时间。
对于实现周期较长的需求，通常需要拆分需求迭代，此时则需要明确每个迭代涉及到的功能点和交付时间。这里通常需要结合功能点价值、业务痛点以及迭代的完整性来指定。前面两个点比较好理解，迭代的完整性是指此迭代上线后应该是一个完整的、可以使用的功能，而不是需要等下个迭代上线后才可以一起使用，那么分期实现就没有意义了。
产品经理在接收到需求后即使是对于实现难度大而暂时无法实现或优先级不高需要暂时搁置的需求，也应该明确的给予业务方答复，做到事事有回应、件件有找落，让需求方可以及时启动备选方案，避免产品的实现过程成为业务瓶颈。
灰测计划/运营计划
在双方确认好产品方案和上线时间后，产品经理需要确认用户在项目上线后的灰度计划/运营计划。
对于推广面比较广的需求，为了避免全面上线带来的风险，通常会选择分区域或分用户群逐步上线，称之为灰度计划，简称灰测。
灰测计划往往是由业务方根据需求特性、业务覆盖面进行定义。并且在产品交付后开始按照灰测计划进行逐步推进，以确保实施的项目能达到预期效果、收获项目价值。
产品经理也有责任确保需求价值的实现以体现自身价值，所以在这个阶段双方也需要对后期的运营确定一定的方案。
（悄悄的说，如果需求方无法明确运营推广计划，那么对于这个需求，他们可能没有想象中那么“急”，我们可能需要重新回头评估下产品的价值，看是否需要把资源安排给其他更有价值的需求了。说实话，我们有时候还是会碰到需求方在需求阶段催着上线，而上线后迟迟不开始使用的情况，确实令人头疼，所以前期的明确还是很有必要的）
三、人员培训
产品正式上线前，为了确保后用户可以正确的使用并且达到使用效果。产品经理通常需要进行上线培训并提供相关功能的操作说明。
上线培训
公司中，基于沟通层级划分的问题，通常需求的提报会是通过各部门内部的收口人向产品经理进行提报，同样的，需求方案的沟通通常也是会由几个代表或负责人和产品经理进行确认。因此在上线前还会涉及到对其他系统使用方的整体培训，主要的内容也会是针对于本次上线的功能点、变更点。
（此处也偷偷说一句，注意培训过程中要把握培训节奏，不要让培训会变成需求收集会，我相信你们都懂的~~）
操作手册SOP
上线前，千万不要以为培训完了就完事儿了哦。不要忘记还有操作手册的更新。完整的操作手册可以帮助新用户快速掌握系统使用，减少大量无效的沟通询问时间。
四、产品灰测
在上文方案沟通中我们提到了产品经理和需求方都是有责任在前期明确运营和灰测推进方案以确保需求落地。因此在实际灰测阶段，产品经理也需要花一定的经历跟进灰测进度，以确保实施的项目能达到预期效果、收获项目价值，并确保灰测过程的异常得到及时处理。
异常跟进、计划调整
灰测过程一定程度是为了能在全面推广前处理可能潜在的风险问题，避免问题的扩大化。所以在灰测阶段，产品经理需要更多的关注线上的异常问题、及时反馈测试和技术进行异常处理，避免影响正常业务运行。
此外，如果真的不幸发生了比较大的异常，则需要重新评估异常点、提出解决方案、快速迭代上线，并及时和需求方一起调整灰测计划，确保正常推进上线。
优化点的积累
此外，在这个阶段产品经理还需要多倾听“用户的声音”，听一听那些“吐槽的声音”，发现需求中的可优化点，判断这些迭代时候是需求中的遗漏点、是否会影响业务操作、是否需要加入下一轮迭代。
结合用户反馈和上线数据进行项目复盘，吸收本次的pros和cons，扬长避短，减少后续迭代中的“坑”。
总结
良好的用户沟通机制可以帮助产品经理建立和用户之间稳定的沟通桥梁。
从上面的文章篇幅其实也可以看出，沟通环节中最核心的其实是在于需求沟通和需求挖掘，正确把握用户痛点了解用户痛点可以说是成功了一半。最初的方向如果错了，后面的沟通可能要多走很多弯路甚至于直接走错路而造成开发资源的浪费。
当然，后续的方案沟通、培训和灰测时的关注等都能帮助产品经理在用户心中建立更好更专业的形象。
以上就是本篇的全部内容，希望本文可以对你有所帮助。
网友评论