前言
有幸参与和负责过国内百强企业的Saas产品项目，一直想找个时间把项目全历程总结并分享出来。产品经理是如何从0到1接触并完成整个产品项目的，中间会经过什么环节、什么流程，需要具备什么技能，输出什么内容，取得什么成果……这一切的一切，我都将呈现于笔下。
如有雷同，不甚荣幸。
调研通知
我没想到，身为产品经理的我也需要驻场调研。
距离出差客户现场宣讲已经过去一周了，回到广州的我已经在循规蹈矩地完成着产品经理的工作。就在我喝着茶看着今日的工作事项时，领导走了过来。
领导说：上次现场宣讲表现得不错，上次的内容整理得怎么样，估计到时候要去现场调研。
我疑问道：签下来了？
领导说：差不多了，你准备下到时候去现场和他们商品的人员做进一步的需求沟通。
我有些兴奋道：好啊，拿下来就好，大概什么时候去？
领导估摸着时间，然后说道：这周日先过去吧，你准备下调研的事宜，然后和实施部门的同事规划下调研的内容和时间，做份计划表出来，到时候好安排调研。
我应到道：好，我下午和项目实施部门的同事碰一下。
领导说：好好干。
说完，领导又急匆匆地走了。
我坐着电脑前陷入了思索，这是要去现场做用户调研了？该怎么搞呢？不管了，下午和内部先碰一下头，再规划下调研的事项。
调研准备
上午我在微信提前约了项目实施部门对接的同事的时间，约在了下午4点碰头，早上我先把手头上的事情告一段落。
下午4点，我提前预约了会议室，等待实施部门的同事过来，这是入职以来第一次与项目实施部门接触。
项目实施部门在公司中充当着项目管理部门的职责，在项目前期负责项目沟通、日程安排，项目中期负责需求调研规划、SOW项目计划书的整理修订，项目后期负责上线前各项人员统筹和项目规划等事宜。
项目实施部门的同事到了后，我们坐在会议室里相互简单做了下介绍，然后听实施的同事讲解产品项目前期调研的相关计划。
前期驻场调研的目标，是做业务场景的梳理、客户的需求进行边界划分，以及初步解决方案的制定，最终整理成SOW项目计划书。在双方就项目计划书的内容进行确定和签订后，合作正式开始。
因此，在调研前的准备也分为几点：
1、核心场景的界定
整个Saas产品项目基于标准功能，结合客户定制需求进行开发交付，那么最前期需要进行核心场景的界定，也就是划分边界。
整个产品包含哪几个核心的业务场景都需要罗列出来，示例：核心场景一共有3个，分别是配货、补货、调货。
2、调研日程安排
鉴于界定好的核心业务场景，结合现有产品所覆盖的场景，细分下去。示例：核心业务场景配货中，现有的产品支持哪几个子场景，比如：新品配货。再预留出几天针对现场调研时客户可能会额外增加的业务场景的时间。
将这些都整理成日程表，明确调研中的每一天需要做什么，输出什么。
3、人员职责分工
此次驻场产品需求调研，涉及到我方及客户方哪些关键成员参与，我方及客户方的人员在需求调研过程中的协作方式，以及双方的一些特殊要求的前期确定等。
既然在同一个产品项目中，那么就需要当作一个整体、一个团队对待，每个人需要做哪些事情，提前共享什么资料，都需要提前做好沟通和安排。
4、业务调研提纲
除了上述的内容外，还需要提前准备好我方产品所设计到的业务场景或者流程中，客户方当前的业务模式和操作流。
简单来讲，就是基于现有系统能满足的业务场景和功能，客户方在没有系统之前目前的这些业务是怎么做的，一些业务规则和流程是怎样的…...对于这些问题，需要提前准备好业务问题清单，在驻场产品需求调研前，身为乙方需要对甲方的业务模式有所了解。
经过近2个多小时的内部沟通，我和项目实施部门的同事分工整理，先是由产品经理进行核心场景的边界确定，以及细分的子场景的梳理，然后由项目实施部门的同事规划日程计划，输出一份日程表，内部确定后再拉起会议与客户方进行提前沟通。
调研前会议
在调研准备的资料发出的第二天，我们约了客户方进行远程会议。
调研前会议的目的是双方确定好在未来调研的这段时间中，双方应该提前准备哪些内容，以及在后续现场产品需求调研中，双方就哪些话题进行调研等。
最终给调研一个共同的目标，并且同频这个目标，达成共识。
企业间合作最大的内耗，在于双方在不同的频道聊天，最终双方都谈得很开心，但是项目没有实际的输出。
在会议上，我们首先明确了此次调研的目标和行程安排，双方配合调整日程表的时间安排。
双方尽可能将时间集中在业务没那么紧急的时间，同时也要协调客户方分公司/子公司成员的时间，确保此次调研的内容涵盖往后正在投入使用的关键用户。
对于业务提纲，鉴于集团公司、不同的分公司/子公司可能存在着不同的业务情况，因此业务调研提纲则先发给各个关键用户进行填写，在正式调研前回收并整理分析。
会议结束后，大家对于此次调研的流程和内容都有了大概的认识，心里也有了些底。
调研前夕
又一个周末晚上，当我又一次踏入厦门时，有了种奇怪的感觉，可能会在厦门待很久，直到完全“融入”这座城市。
晚上依旧开了个小会，主要是沟通第二天的工作安排以及往后每一天的固定事项安排。
初步确定除了第一天启动会议外，往后的每一天都按照标准的调研步骤有序进行，大体上分为3个时间段：早上、下午、晚上。
早上主要以标准产品业务场景讲解为主，主要是做业务场景规则的匹配；下午则以客户方业务需求以及额外的业务场景沟通为主；到了晚上，则是双方整理输出当日的调研记录，作为总结和汇报使用。
确定好整个驻场产品需求调研的流程后，我沉沉地陷入了梦乡。
驻场调研
一大早，我们又回到了之前的客户现场的会议室，这一次依旧和上次一样双方分坐两边。但这次不同的是，还有客户方分公司关键用户远程参与。
早上按照惯例先是开场白，告知双方现场成员以及远程参与成员双方的人员组成，明确参与者的身份以及负责的内容。
然后由产品经理顺势切入调研主题。
产品经理在做需求调研时，无论是现场用户调研，还是通过社交软件远程调研，都需要明确一个理念：
调研要以业务场景为主，而不只是说功能如何操作。
这可能是很多产品经理会碰到的一个问题，如果说需要功能操作，那么客服人员、项目实施人员操作水平可能比产品经理还要突出。
产品经理的价值是把业务流程梳理清楚，并就业务场景的解决提供最优的产品方案，这才是一个产品经理的价值。
因此驻场调研应该按照严谨的逻辑结构进行，这里也总结了几点：
1、整体架构
客户实际业务场景是什么流程，以服装行业为例，在整个集团架构下，集团公司下多个管辖区域，管辖区域下有多个分公司/子公司，子公司有多个业务地区，业务地区下有多个门店。这就是一个标准的企业架构，所有的业务流程走向都是围绕着这个集团架构下进行的。示例图：
2、适用范围
第二点是确定Saas产品所适用的范围。基于集团公司架构和商品走向，此次合作的数字化项目在整个集团公司架构或者说核心业务流程下应该要承接哪些范围。
除非是深入绑定合作，一般的Saas产品解决方案提供商只会在业务结构下承担其中一部分的数字化项目工作。示例图：
3、业务流程
确定好Saas产品适用范围后，接下来针对于圈定的业务范围，了解其中的业务流程或者说流程走向。
以服装行业为例，商品在上述圈定的范围中，是如何从上往下流动的，经过哪些节点，最终归宿在哪里。示例图：
4、业务规则
在业务流程双方都达成共识的情况下，下一步则对于其中某一个环节存在的业务规则进行探讨和梳理。
这和产品经理设计产品的方式如出一辙，在产品生命周期全流程中，产品经理想要学习和精进，最好的方式就是先行梳理这个流程阶段，然后在深入到某一个阶段中，了解要完成这一个阶段需要什么技能，什么知识，再针对性地学习和补充。
业务规则部分，需要使用到流程图或者Excel表格记录其中的业务规则及其涵盖的算法逻辑。示例：
由于核心算法和流程步骤属于企业核心机密，这里就不做详细展开。
如上图（网上通用案例）所示，我们细分到核心场景中，梳理核心场景的流程，并就其中的节点梳理业务规则，比如第一步【确定需下单产品及所需下单的数量】中，会蕴含哪些业务规则，涉及哪些算法，数据从哪里来，最好以数学公式的方式呈现出来，并与客户方进行核对。
5、总结并确认
一天下来，双方所针对于核心的业务场景都输出了不少的内容，那么在一天结束时，需要针对于当天调研沟通的内容，输出一份调研记录报告供双方确认。
这是一天的成果表现，也是一个项目阶段性的里程碑，唯有把一个个项目阶段圆满完成，项目最终才有可能取得好的成果。
小结
驻场产品需求调研，对于每个产品经理或者项目经理来说都是不可多得的经历。
不接触客户，不了解客户真正的需求，不真正坐下来和客户面对面交谈，也做不成优秀的产品。
其中让我感受最深的是，当你面对很多人时，思考并回答每一个问题，其中不断加深对行业的理解和认识，每天虽然很累，但依旧快乐。
未完待续
经过这一次的驻场产品需求调研事项，我以为事情应该告一段路了。
我没想到，身为产品经理的我也需要写SOW项目计划书。
未完待续……
如果本专栏对你有帮助，不妨点赞、评论、关注～
