新宇

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 112|回复: 0

该如何坚持 异地协作的需求管理

[复制链接]

1

主题

1

帖子

3

积分

新手上路

Rank: 1

积分
3
发表于 2022-11-26 19:22:02 | 显示全部楼层 |阅读模式
产品是由无数个需求汇聚而成,妥善处理好需求的从生到死,就是我们常说的需求生命周期管理。原本面对面的团队,在需求管理中已经处处是挑战。可当一款产品处于早期或是目标市场在海外,很多时候都需要产品团队驻扎现场,与用户市场更贴近。那么产品与开发团队就会出现不在一个地方工作。 又或是随着环境变化科技进步,大家都开始接纳远程办公,那么全团队所有人员都要面临不再面对面协作了。此时,需求管理将会遭遇更大的挑战。各个团队就需要有一套新的合理的高效协作机制,方便反馈与追踪。而产品与开发人员失去了「面对面吵一架」的沟通方式,也需要探索出更深层次适合彼此的交流默契。

让我们先来看看这些棘手的问题

需求从提出到落地的日常工作中,产品与研发都需要非常频繁的沟通与协作。但原本各方利益又可能存在对立,比如产品经理会希望开发团队在最短的时间内尽可能有最多的产出,而开发团队则想着用最小的投入完成当前的工作任务。 因此,经常发生冲突的场景就有:


1. 沟通难上加难

前期需求分析环节:
   • 开发人员不认同产品经理的方案,导致冷嘲热讽 「你这种 idea,我一天能想二十几个」
   • 开发人员认为产品经理输出的需求文档或故事卡,不够清晰,可读性不强,影响自己理解「你这方案前后连得上嘛?」


需求开发与测试环节:
   • 开发人员对产品经理的需求变更带来的代码返工、任务量加重存在抵触心理「你理解客户嘛?」
   • 产品经理缺少技术相关知识,与开发人员沟通效率低下,易引发矛盾「你连技术都不懂,和你说不通」
   • 在开发过程中,产品经理与开发人员的口头或线上沟通调整方案未及时更新到文档,导致后期发生问题双方存在扯皮的现象「文档还是会议纪要,你看看写哪里了?」
   • 测试暴露的问题在需求文档或故事卡中描述的模棱两可,责任无法划清,导致双方相互发生争执「AC 上没写呀,我怎么知道你要什么?」

项目进度把控环节:
   • 在产品推进的过程中,产品经理因不懂需求背后的技术工作量,与开发人员就进度安排存在分歧「你是产品经理,不是项目经理」
   • 产品经理迫于客户与上线压力,继而转移压力催促开发人员,引发开发人员不满「你这么优秀,懂客户看得远,应该直接汇报给董事会呀」

虽然很多矛盾即使面对面也有,但是一旦异地后,开发人员距离用户与市场又远了一步,对产品经理的信任与耐心又降了一级。将会导致更激烈与尖锐的冲突。



2. 分析处处遇坑

产品中的需求大多最终都承载在一份 PRD 文档或一张张用户故事卡上,产出这些需要通过整个团队一起协作完成。当一线人员提出需求后,产品经理 需要与用户、客户、业务人员一起细化需要解决的用户故事,产出前置后置条件、用户流程与规则;之后再与设计师沟通产出原型与设计稿;之后开发团队需要产出数据模型和任务分配;上线前再与市场推广团队一起制定营销方案。

这一整个流程下来,就文档协作最常遇见的坑要数:
  • 无数版本:需求分析过程中来回讨论非常常见,有时候针对文案修改,就需要来回发邮件。如果每次都需要新建一个版本,团队将会淹没在各种文档里,最终迷失。而中间讨论的过程稿,也将不会有人再追踪关心。
  • 可读性不高:需求无论是用文档记在,还是故事卡的形式,本身的目的就是服务功能的开发,但长篇的需求说明对开发人员并不友好,对市场和业务人员反馈也并不方便。
  • 无人维护:开发过程中的需求变更基本是每个项目都会碰到的,新的需求一般都当面或者信息的形式达成协议后,就直接开发,一段时间后就再也不知道这个需求是谁提出来的,什么时候加的。产品经理也很难及时更新需求文档,并保证通知给每一个开发。
因此异地协作的需求管理中,核心问题便在于「信任下降」与「异步确认」这两大难题上。


3. 目标驱动的「沟通协作」

遇到观点分歧而争论时,有时候是因为大家只着眼于各自的立场与利益,缺失对目标的对齐。没有统一目标的争论,即使面红耳赤,也无法解决问题。所以,对于方案的制定,无论逻辑如何,交互如何,技术实现方案如何。至少大家应该要有共同的目标,而这个目标往往是用户或客户的最终目标,或是他们最终需要解决的问题是什么。明确用户在什么场景下解决什么问题后,才能保证每一次沟通都能处于正确的轨道,不做无效的内耗。

因此在需求描述中,首先就应该写清楚,这个方案所针对什么样的用户,在什么场景下,解决他什么样的问题。由此,当技术质疑产品方案时,可以清晰的指出没有满足用户什么目标,而产品要求技术等非功能性指标时,也有了依据。为什么要这样的性能,为什么要这样的分辨率都是对标用户的使用场景。

4. 同宗同源的「文档协作」

碰到「无数版本」问题,首先想到的就是通过在线文档协作解决,协作文档可选的有石墨文档或 Google Doc,主要方式就是由产品经理在其中编写需求文档,再邀请相关核心的业务人员、市场人员和开发人员参与讨论,通过添加评论的方式协作完成与最后评审。
个人觉得这种轻量的协作方式适用的场景,是和不太愿意参与产品开发过程的客户协作的时候使用。因为虽然解决了交流协作的问题,但对产品开发团队内部来说依然存在复杂的长文档,小变更难以维护的问题。并且缺失过程分 析,与版本的比对。

5. 透明可视的「进度管理」

之前我们是在 Trello 或 Jira 等项目管理工具上进行任务分配和进度追踪, 但开发人员对于汇报进度一直都很厌烦。于是我们开始尝试可视化整个研发进度与流程,同时将工作量与整个上下文进行整合,开发人员就可以在一个地方看到完整的需求描述,对应的原型和设计,以及整个讨论过程。


流程实操

下面让我们具体到整个需求管理的流程中实操一遍:



步骤一:记录用户所需解决的原始问题

做产品的知道,需求是无处不在的,可能来自于用户和业务团队的反馈,或是用户行为的挖掘,或是团队内部的 idea,或是商机的要求。但我们不能拿到需求就开发,首先需要记录下来并分析。我们在 BeeArt 中创建了用户反馈板,由产品经理在双周市场会上讨论,确认后哪些反馈将考虑放在哪个 milestone 来开发,哪些现在不考虑放进下一版本分别进行追踪回溯。
步骤二:细化和讨论确定需求

对于确定要排入 milestone 的需求,会有产品经理按计划完成需求描述,通过协作和各方确认需求。其中包括用户流程,用户规则,前后置条件,流程图和原型。分析过程中,设计师与开发人员都将参与其中,通过评论来反馈 和交流相关问题。
步骤三:流程图和产品原型

设计师将前置制作流程图或低保真原型图,以便快速向业务人员展示功能流程,在投入大量时间细节设计前得到早期反馈。
步骤四:评审设计稿

之后的需求阶段很大一部分都是设计师产出细节设计稿,往往此时大家对设计图的评审讨论是最多的,出问题的概率也是最大的。 业务团队和技术团队对产出的设计稿分别进行评审讨论,最终把设计稿的链接也同步至 BeeArt 中需求描述板中。
步骤五:确认开发任务分配

当需求和设计都确认并估点后,就是开发任务了。基于 BeeArt 可以更透明每个开发的进度与风险。
步骤六:确认功能推广目标

在以往的需求文档中,经常会漏掉当需求功能完成后,如何推广与运营。而在 BeeArt 中,由于所有的信息都记录在一处, 运营可以前置到在开发前就考虑好,以保证如何衡量与评判需求上线的推广与效果。

写在最后

当团队开始异地后,仍想要保证高效的协作。必须以「统一目标驱动」信任沟通,「实时协作可视」减少异步确认的不同源。
最后,我们应该衡量如何用工具来解放这些繁复的工作,让专业人员将所有精力都放在价值创造上。




<hr/>


「突破远程协作局限」BeeArt 系列文集一共收录了 10 篇文章,1篇工具推荐。从远程协作的迷茫;到运作机制;到通用的开会和工作坊怎么高效展开;到需求分析和回顾会与线下有什么不同;最后到用平常心接纳所要面对的远程协作。
希望这本文集,可以在你犹豫不决时,获得些许勇气;在你踌躇不前时,获得些许灵感。无论此时的你需要搭建远程会议工作坊,或是正在组建远程团队,都欢迎一起交流。
欢迎免费注册,PC端点击链接,获取「突破远程协作局限」电子文集全稿: BeeArt | 行知蜂 - 数字化产品协同平台
BeeArt 行知蜂【官网地址】:BeeArt | 行知蜂 - 数字化产品协同平台
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|新宇

GMT+8, 2025-3-16 19:26 , Processed in 0.358540 second(s), 20 queries .

Powered by Discuz! X3.4 技术支持:迪恩网络

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表