如何做好SaaS二开定制需求？

文笔

SaaS产品在理论上应该避免二次定制开发，但在实际应用中，由于客户需求的多样性，二次定制开发往往难以避免。
作为SaaS产品经理，面对不可避免的问题，积极寻找解决方案是关键。
今天我们就来聊聊：如何做好二开定制化需求？

五个常见问题
首先，我们先来看几个常见的二开需求的问题。
常见问题1：客户不知道你不知道，而你也不知道客户不知道。
人与人之间最容易出现的就是这类问题——不知道对方不知道。
它的本质是一种信息不对称的状态，即一方没有意识到对方缺乏某种信息或背景知识，而对方也完全不知道自己需要这些信息。
心理学家约瑟夫·卢特（Joseph Luft）和哈里·英格汉姆（Harry Ingham）于1955年提出了一个心理学模型——乔哈里视窗，非常形象的描述了这种现象。
该模型通过四个象限将个人意识划分为不同的区域，分别是： 开放区（Open Area） 、 盲点区（Blind Spot） 、 隐藏区（Hidden Area） 和 未知区（Unknown Area）。

• 开放区：是你跟对方都开放且知道的区域；
  
• 盲点区：是你不知道，而对方知道的区域；
  
• 隐藏区：是你知道，而对方不知道的区域；
  
• 未知区：是你们双方都不知道的区域。
  

乔哈里视窗
举个例子。
客户A希望将员工的考勤异常数据，通过开放接口接入他们的小程序，展现形式与我们App一致，我们初步评估需4人天完成。
但在研发中，客户发现我们App首页显示的员工异常数分为当前自然月和考勤月两种，而他们并不知道，而我们也不知道他们不知道，最终是研发过程中，反复沟通了三次才弄清楚，浪费了不少人力物力。
比如今天是2025年4月25日，按自然月是4月份，但客户的考勤和工资计算可能仍停留在3月份，则员工需要同时可处理这两个月的异常数据。
常见问题2：同一个概念，不同认知造成对需求理解大相径庭。
中国语言博大精深，同样词语在不同语境或认知中，它们所代表的含义就会大相径庭。
举个例子。
客户B希望我们提供定薪/调薪接口，以便在第三方系统完成招聘后自动处理员工薪酬。我们初步评估需要4个接口（5人日完成），但在开发过程中与客户二次确认时，发现双方对定薪的定义存在显著差异：

• 我们系统定薪是针对在职员工，而客户需要针对待入职员工；
  
• 客户不希望先获取定薪项，也不使用自定义工资项，而标准系统能力是必须的；
  
• 客户需要的定薪项，包含额外补贴项，而它们并不在我们系统现有定薪范围内。
  

同样是定薪，因为双方对系统与业务认知的差异，结果就会衍生出完全新的需求，预估人日翻倍（即10人日）。
常见问题3：你觉得是需求问题，而客户觉得是产品规则问题。
有时你认为是需求问题，需要跟客户沟通确认，而客户却认为属于产品规则问题，不应该问Ta。
举个例子。
客户C提了一个二开需求，期望自定义一个报表，显示员工每天的出勤工时、加班工时、请假工时等情况，而当你问她：咱们期望什么样的样式？比如一个员工一行多列，还是多行一列
她可能会说：“这不是你们的规则吗？我们的需求是想确认员工有没有连续出勤超过6天，以及查看其工时。”
甚至可能因为前期沟通不顺利，她还会揶揄一句：“你得发挥你的专业能力，不能什么都问我们。”
常见问题4：客户不认同你评估的结果。
一份完整的二开结果，至少包含需求清单、预估人日、报价、解决方案、预期上线时间等，而客户往往不认同的可能是预估人日，它影响报价。
比如你预估了30人日，客户会以“专业”的眼光挑战你的工期，觉得最多15人日就能做完。
比如客户对上线时间不认同，觉得都付费了，为什么要这么慢？
甚至客户不认同：为什么不接受它的付费需求，觉得都付费了，为什么还不能做？
常见问题5：你交付的结果，不符合客户预期。
当你完成上线，客户验收时，可能会出现与预期不符的情况。
比如客户会说：“为什么报表出来的结果会有2位小数，我们只需要1位小数，并且需要按0.5进行取舍？”
或者“为什么还需要我们手动去同步与计算，不能自动吗？”
有时客户可能不愿意支付尾款，声称承诺的内容未得到履行，并要求退款，甚至可能引发法律诉讼。
有时可能会导致客户不愿意支付尾款，并跟你说：“这都是我们提过且在需求沟通中承诺的内容，你们现在都没做到，我要退费。”
甚至最终落到对薄公堂的程度。
当我们把常见问题定义清楚后，如何有效避免就能水到渠成。
我们可以从三大方面进行优化，确保二开需求符合客户预期的同时，又不因需求问题而多次返工，浪费产研资源。

解决方案：从产品原则到流程机制
第一是产品原则。构建完善产品原则，在不确定性中寻求确定性。
我始终认为产品经理是挑战人性的工作，需要应对和处理不确定性带来的各种问题。最有效的解决方式是依靠产品方法论和原则，它们能在不确定性中提供一定的确定性。
以二开定制需求为例，我们可以制定以下产品原则：
原则1是资源分配原则：确保二次开发需求占比不超过30%，以尽可能保证不影响标准化产品建设。
原则2是需求接受原则：优先接受具有通用性（包括潜在通用性），且客户愿意付费，且不增加额外运营成本的需求。其次，接受签约两年及以上的老客户或新签客户的需求，如果可以通过插件实现而不影响其他客户，则也可接受。
否则，如果不符合这些条件的需求，则不接受二开。
原则3是需求优先级原则：付费二开（通用）> 付费二开（潜在通用） > 标准化需求（通用/高频/阻塞） > 免费二开（插件） > 免费二开（功能）> 其他需求（低频/小体验）。
第二是流程。构建需求确认流程，确保双方对概念、需求、方案、报价、预期结果的认知一致性。
需求确认的关键流程，采取双重沟通确认的“握手机制”。它是互联网中的一种同步通信机制，用于在数据传输前确认双方的准备状态，从而确保数据传输的可靠性和同步性。
比如发送方先发送请求信令说：“数据已准备好”，对方收到请求后，回复确认信令说：“已做好接收准备”，双方才会开始传输数据。
同理，在跟客户沟通确认需求以及解决方案时，也应该采取这种“握手机制”。
即使用会议录屏+邮件等方式进行，把需求、规则、解决方案等图文内容，采取一轮视频讲解（复杂需求）+邮件正文（或附件）的形式，与客户完成最终确认，并要求客户回复“已确认”的信令后，才正式推进至研发阶段。
注意：
1、关键内容：一定要把需求、概念定义、规则、方案等重点内容，采取正文形式发送确认，并标注关键点，确保双方对关键信息理解的一致性；

2、关键价格：一定要把经过评估后的工作量（即人日），采取最小颗粒度原则，明确进行拆分与标记，增加客户可信度，以及便于客户通过砍需求的方式实现“降级”。

第三是机制。通过建设并践行二开需求机制，确保需求高效落地。
需求确认只是二开流程的“急先锋”，后续包括定价、协议签订、订单处理、研发、交付等环节。为确保项目顺利实施，需建立一套完善且符合公司情况的流程和机制，严格约束各方按约定内容执行。
它们包括但不限于：

• 1）沟通机制：采取文档记录，群里同步的双重信息透明化沟通机制；
  
• 2）方案评估机制：产品经理采取24小时工作制度完成评估（即14:00前的需求，当天完成初步评估；14:00后，则不晚于次日），以及3个工作日内正式评估（即在完成意向评估与确认后，必须正式给出解决方案与人日报价）；
  
• 3）定价/折扣机制：2个工作日内，内部提需人必须完成内部的定价或折扣的申请与评估，并完成给客户的报价；
  
• 4）签署协议机制：3个工作日内，内部提需人必须完成内部的协议签署、盖章，并发送给客户；二开订单流程：2个工作日内，内部提需人必须完成二开订单流程的确认与审批完成；
  
• 5）付款机制：内部完成流程后，内部提需求人必须督促客户在7个工作日内完成打款（可支付不少于60%前期款）；
  
• 6）研发机制：以付款时间为起始点，工作量15人日的需求，1-1.5个月内完成交付；15-30人日的需求，3个月内完成交付；30人日以上的需求（一般不会超过60人日），3-6个月内完成交付；
  
• 7）项目同步机制：当项目进入研发阶段后，每周至少1次项目进度同步，可采取邮件或群周报的方式进行，直至正式上线交付；
  
• 8）项目交付机制：项目上线后，必须采取正式通知客户，并提供对应使用手册，让客户在7个工作日内完成验收。如验收不通过，则重新评估差异，合理且工期在3人日内，则正常进行迭代优化，否则按新需求重新进行二开评估。
  

专栏作家
邢小作，微信公众号：产品方法论集散地，人人都是产品经理专栏作家。一枚在线教育的产品，关注互联网教育，喜欢研究用户心理。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。