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

奋斗的小禾

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

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

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


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 | 行知蜂 - 数字化产品协同平台