异地团队管理：需求协作及原型、设计的评审.pdf

异地团队管理 ：需求协作和原型、设计的评审 摘要 ：做产品的都知道 ，需求是无 不在的 ，可能来自于用户的反馈 ，业务团队的反馈 ，用 户行为的挖掘 ，团队内部的idea或者上级的要求 ，人人都是产品经理也就是人人都可以提需 求吧…既然有需求就要细化需求文档 ，制作原型 ，设计界面 ，这是几乎每个产品团队都会做 的流程 ，本文不涉及如何更好地写需求文档 ，只聊一下作为异地的产品团队怎么针对需求 文档、原型和设计评审进行协作。 我所谓的异地的产品团队 ，可能会和远程工作有较大区别。远程工作是大部分人员都不在一起工作 ，就像 《Remot e》说的那样 ，异地的产品团队是说一个团队里产品开发人员和市场业务人员不在 一个地方工作 ，这个在一些瞄准海外市场的早期产品团队里是比较常见的 ，我们就属于这种情况。 在异地协作的创业团队 ，尤其是存在时差的情况下 ，会遇到的最大的问题就是对于无论是需求 ，还 是原型和设计 ，都存在一个异步确认的过程 ，不能面对面吵一架解决 ，那就需要合理的协作机制能 方便的讨论 ，反馈和追踪。 需求文档需要协作的内容 我这里说的产品需求文档(PRD)就是对于一个产品或者某个单独的功能 ，PM需要通过与整个团队一 起来协作完成的需求描述 ： 与用户、客户、业务人员或产品团队内部的沟通后梳理出需要解决的User St o ry 细化功能需求的前置条件和后置条件 ，用户流程和规则 完成产品原型 和设计师沟通输出设计稿供团队评审 开发前与开发团队沟通数据模型和任务分配 上线前和市场推广团队一起确认功能的T racking Goal 这个过程不同的团队不尽相同 ，但都是需要整个团队一起来协作完成产品需求文档(PRD)的过程。 以前遇到过的坑 先说一下以前我自己碰到过的坑 ，也就是这些坑让我们不断思考如何更好的去协作 ： 第一 ，无数个版本的需求文档 我最早做过的一些项目几乎都是用Wo rd来写PRD ，无论是像中国电信这样大型国企 ，还是在海豚 这样的创业团队 ，在做需求的过程中就会发现一个需求来回讨论确认是很常见 ，有时候仅仅就是对 某个文案的修改 ，但来回沟通就要发邮件 ，新建一个版本 ，然后就会变成下面这样… 文档里面还有更多小版本修改的说明 ，显得很专业的样子…但是wo rd的评审功能都在本地完成 ，有 时候一个细小的改动也要传文件找修改 ，实在很o ut ，而且以前的版本在那儿根本没有人去看过 ，真 的想去看讨论中到底做了什么修改的话 ，做个Dif f 也是真的很困难。 第二 ，确认的需求文档开发人员根本不看 做需求文档的目的就是服务功能的开发 ，但长篇的需求文档真的对开发人员极不友好 ，对某个特定 功能需求的搜索和反馈都不方便。 第三 ，产品迭代中没有人去维护需求文档 开发过程中的需求变更基本是每个项目都会碰到的 ，新的需求一般都当面或者邮件的形式沟通好直 接就开发了 ，一段时间后就再也不知道这个需求是谁提出来的 ，什么时候加的 ，因为PM很难及时 去更新Wo rd的PRD ，而且保证每个开发都看最新的PRD开发。 基于文档协作平台(Google Doc)的需求协作 碰到 无数个版本的需求文档”问题很自然的想法就是通过在线的文档协作平台来解决 ，协作平台选 择的是Google Doc ，协作主要的方式就是由PM把整个PRD放上去 ，邀请相关核心的业务人员(可能 就是Product Ow ner) ，市场人员和开发人员参与讨论 ，通过Co mment 的方式来协作完成PRD及相 关文档的审阅 ，用来组织周期性会议(Sprint Meet ing)。 我自己觉得这种轻量的协作方式适用的场景是和不太愿意参与产品开发过程的客户协作的时候使用 ，因为虽然解决了交流协作的问题 ，但对产品开发团队内部来说依然存在复杂的长文档 ，小变更难 以维护的问题。 基于项目管理平台(Redmine)的需求协作 我们从5年前开始接触项目管理平台 ，开始就是需求文档做好以后通过项目管理工具(Redmine)进行 任务分配和进度追踪 ，大家做开发的都懂 ，写代码大家都还挺high ，但不停汇报进度就很烦躁了 ， 我们通过Redmine REST A PI开发[git hoo ks][5]让开发可以通过标准格式的co mmit message提交代 码就能更新任务进度来改进流程 ，得到了开发人员的推崇 ，这5年来经过不下50个开发人员都使用 的很愉快 ，没用什么学习时间 ，大部分的开发任务都能拿到较完整的代码提交上下文。 但在做项目的过程中 ，我们还是不断遇到上面说的需