在整个项目过程中，项目经理需要与业务方进行频繁的沟通。那么，每次沟通的重点是什么？要达成哪些目的？本文作者从自己的实践出发，分立项和实施两个阶段，给大家说明沟通的重点。
To B的数字化项目因其与业务的关联非常紧密，特别在非标业务场景下（如私募、投资行业等），不同公司对于业务的理解、流程、关注点、数据要求等都不相同，项目团队的人员往往很难做到对各种情况都有知识储备或相关经验，需要与业务方保持深度互动，才能使设计和开发的功能满足用户的需求。
笔者作为项目经理，经历了一个为私募股权投资企业定制化开发的投融资业务综合服务系统的完整周期（项目金额270万，周期一年）。因为上一轮的数字化建设成效比较明显，目前正在推动项目二期建设（项目金额281万，周期预计一年）。
基于该项目的实践经验，笔者认为可以从以下几方面着重开展与业务方的沟通。
立项阶段主要是收集业务方的需求，简单来说就是挖掘业务方现在有哪些实际问题可以通过数字化的手段解决，比如哪些流程可以线上流转、哪些报表可以自动出具、哪些文件可以自动生成、哪些信息能够自动获取等等（同时要考虑如何把这些需求有机的嵌入在系统的整体结构中），通过此阶段才能明确项目范围，所以这个步骤非常重要，沟通重点在以下三点：
项目组在初期，对公司的架构、业务和人员都不熟悉，必须有业务方的牵头人员进行总体协助，且该人员的作用在整个项目期间都非常重要，所以务必从一开始就使其对项目建设充满责任心。
我们的经验是不断向其灌输这个理念“这个数字化项目将成为他重要的工作成绩”，同时需要在项目建设周期中，不断提供各类成果供其进行内部汇报以体现工作成效。
在条件允许的前提下（没有条件也最好能创造条件），广泛与各个部门开展面对面的需求沟通会议，建议最好每个部门都聊一遍。
在会议上需要通过一些案例进行引导，让业务方明白系统可以帮助他们解决实际问题，从而打开他们的思路和热情。
把调研收集回来的需求进行加工、汇总之后，请牵头部门协调，组织一场由各个部门负责人参加的需求确认会议。
这样做的好处有两点：
在实施阶段，重点是定期做好以下事项：
我们这个项目采取的是敏捷迭代的方式，固定每个月发一个新版本，需要在每月下旬确认下个月版本的具体需求范围。
最初项目组采取的是根据年初制定的计划进行每个版本的开发，但是发现业务方总会在中途插入各种临时性的紧急需求或者调整需求的优先级，打乱开发计划。
为尽量解决这个问题，我们和业务方协商确立了需求框架会议机制，即在进行下个版本详细需求设计之前，由项目组提出拟安排开发的需求清单，再由业务牵头部门的领导进行调整和确认。
通过实践，发现这一模式确实能大幅降低各类需求插队的情形，因为业务方领导一般不会轻易推翻自己的决策，在碰到需求变更或者插队的情形时会更加谨慎，同时也能更加体谅项目组在面对这些情况时的困难。
在产品经理完成详细的需求文档和原型设计之后，组织开展由需求提出人员参加的需求评审会议，以明确系统功能与其前期口述的需求相匹配，部分业务人员在看到原型之后往往会迸发出许多新的有价值的意见和建议，能有效指导需求设计工作，避免后续返工。
在项目建设实际过程中，我们发现以通知的方式告知业务人员进行UAT测试，往往效果都不太好，因为一是业务人员比较忙，对于UAT测试工作重视程度不够；二是在没人指导的情况下，业务人员进行UAT测试的效率也比较低，最终导致UAT测试流于形式。
为解决这个问题，项目组通过牵头部门的协助，在每个版本上线前会组织一场集中的UAT测试会议，由拟上线功能的需求提出人参加，项目组测试人员现场演示相关功能，业务同事当场实操体验并提出问题和建议。
实践证明，该方案能有效解决版本上线前缺少UAT测试的问题。
这个会议主要是向业务牵头部门汇报上周的工作完成情况、本周的工作计划和需要协调解决的问题，重点是汇报需要业务牵头部门协调解决的问题，尽量把问题提早暴露出来，做到以周为维度推动相关问题的解决，避免问题堆积。
在每个版本上线后，主动去需求提出人员及其领导处进行汇报，告知功能已上线，邀请其进行体验。这样一方面可以尽快进行生产验证，一方面可以展示项目组的工作成果。
每个月定期给业务牵头人提供一些可供汇报的工作成果（比如系统重点功能的使用数据、本月上线的功能为业务办理和公司管理提供了哪些便利等），让该项目成为业务牵头人的重要工作成绩，从而不断提高其对于项目工作的积极性。
本文由 @派大星 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。