程序猿与产品经理沟通需求的分歧点!

0 评论 2433 浏览 9 收藏 9 分钟

在工作中,总是会出现一些两人之间会出现分歧的情况,产品经理与程序猿之间也不例外,那分歧点都有哪些场景呢?可以看看下面的文章了解哦!

做产品也有些年头了,在工作中也时常会遇到和程序猿沟通需求而产生分歧;那这些分歧有一些是可以调和的,而有一些是真的需要各自调整心态后重新讨论的。可以总结为以下几种场景:

一、完全不能理解业务场景

和程序猿同事评审需求前,是需要先简单介绍场景的。

就像是一个故事,你是需要用简单易懂的语言,给大家去简述这个需求的背景、发展和之后的一些蓝图规划的。也可以说是对需求的一个全局观了解,否则在评审中途,你会有被无数次打断的可能!

比如医疗行业,在开场前去铺垫一些故事场景,医学知识,可能会对之后架构、库表关系的建设上有一定的帮助。

二、需求评审阶段的分歧

1. 产品考虑的流程中有明显的逻辑漏洞的

给程序猿呈现需求的业务、功能流程,他们能在细微的流程变化中帮助产品发现漏洞。比如我之前做的一个项目中,就一个挂号预约流程,资深的程序猿总是能在细微的变化中,问你一些异常情况的处理方案。

如:患者预约挂号流程

(1)第一步:校验是否已经绑就诊人。

(2)如果就诊人未绑,添加就诊人信息时需要校验是否已经被其他用户绑定,如果已绑定,需要处理解绑后再绑定的新的用户下(这一步骤的校验,可根据实际情况来添加)。

(3)校验该用户绑定就诊人是否已超过个数限制,如果已经超过,需要给予对应提示。

(4)否则提交成功后才可以真正进入挂号预约流程。

这个流程中的第二步校验,就是评审过程中他们所提出来的,足以看出他们对整个流程的严谨!

2. 需求功能边界的范围划分

其实这一点,是需要大家真正去明确的,所有的需求功能点在规划初期可能会全部列举出来,但是在本次评审的范围内,一定需要划分出功能边界范围。否则很容易让程序猿们和测试同事产生混乱和误解。

一般会用两种方式,一种是直接在PRD中标注本次版本范围并标注出优先级,另外一种则是拆分本次版本内容,单独提供出PRD,这两种方式各有优缺点,主要还是看团队以往的协作风格和沟通方式!

(1)页面交互需求评审时的谈论

这点分歧,大多存在于C端产品的评审环节中;评审一般大多是和大家来宣讲某一版本的流程、实现范围和涵盖的大致内容,而页面交互,产品经理在评审会议中会酌情提到,但是并不会就每个元素的交互都来讲一遍,只会过大的功能流程交互点。

所以页面交互一直建议是大点弹框讲到,PRD写清楚,再过细碎的就实现过程中沟通讨论,可能对评审效率的提升有很大帮助。

(2)无关痛痒的需求文案分歧

文案的提示分歧,其实在产品评审过程中经常会有,毕竟仁者见仁智者见智,可是像这种放在评审会上讨论,很容易让人产生一种无力感。文案没有好坏之分,只有场景合适性的考量。

它体现不出程序猿的逻辑推理能力,也体现不出一个产品人的用户思维。所以只要是恰当的文案,就讨论一分钟划走即可,没必要花太大力气在评审会上专门讨论。

比如:当用户想要删除自己已经取消的历史订单时:

(3)需求实现难易程度的分歧

需求实现难易程度,我觉得这个可以放在技术方案讨论会上说,如果放在需求评审会上,不太恰当。毕竟需求评审会,大多时候是需求诉求的阐述和想要实现的方案。而实现方案,短时间内会上讨论只会显得有些仓促,通过充分调研给予合理的方案的建议才是解决事情的王道。

三、需求实现阶段的分歧

1. 需求优先级

需求优先级的问题大多出现在多项目并行的情况下,而出现这种问题时,穿插于多项目中的程序猿,就会有一些迷茫和排斥。遇到这种分歧,大多情况可提出现状和困难点,由产品经理(兼项目经理)OR项目经理协调,明确优先级和排期冲突时间的调整,以便后续工作的正常开展。而遇到真正不能解决的,可能就需要上升到更高的管理层去协调沟通解决。

当一个公司业务量上升期,需求与产品规划都比较紧张,繁杂。所以需求池的管理,需求分析、排期都是需要相关人员知晓和合理安排的。

2. 实现工期节点

之前在实现阶段还遇到过实现工期的分歧问题,很多时候一个大项目的时间节点,都是建立在可预期和充足人员支撑的情况下。

一个项目预期上线时间和技术评估时间的问题,大致分两类:

  1. 工期节点相差小的,加班是常有的事。
  2. 工期节点相差太大的,那就得通过一些其他方式解决了。

比如:

  • 排需求优先级,列举优先实现的节点,分版本来完成;
  • 申请从其他项目组调人员来支持。
  • 项目组扩招人员(建立在公司的资金与资源的充足性之上)

3. 测试、验收环节bug问题

不影响主流程的bug,一般都需要在版本节点范围内解决处理,而对于一些未考虑的细节优化点,非主流程的漏洞点完全可以记录下来,在下一个版本中快速迭代处理。最忌讳的是在开发中途修改主流程需求和增加新的功能点,战线太长不说,还会影响整体的项目进度和人员情绪。

以上就是自己工作中一些小小的总结,欢迎大家指正和补充!

专栏作家

木北的产品成长路,微信公众号:木北的产品成长路,人人都是产品经理专栏作家,互联网产品经理,曾担任医药产品经理和电商产品经理,经历主导过电商平台的系统整合规划。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!