[请教] 关于程序员与产品经理的恩恩怨怨 进来聊聊

[willzzz]

兄弟们大家好，先讲下背景：

本人产品岗位（但为了更好的推动工作，自学了 PHP 、JAVA 等，按我们公司的程序员来说我这说明找个初级程序员工作应该没问题）

目前本人负责公司的产品团队（大概 20 多人）

近期研发团队提出了一些对产品的问题，产品经理的需求文档规范问题：

这个问题老生常谈了，我们最初的时候是产品经理提供 PRD 的方式= 需求文档说明书：包含需求背景介绍、需求业务逻辑、需求流程图、前后台 UE 截图及文字说明 需求 UE：axure 版本的原型图，原型图内仅体现交互说明，没有需求说明。 现在问题：技术反馈 [产品经理的需求文档动辄上万字，与原型图对比看的太累了，希望可以把需求直接写到原型图上，方便开发人员查看]

其实站在产品的角度按这种方式 UE+需求一起通过 Axure 输出是没问题的，但是这样对于后续需求发生修改、变动、以及与运营团队、外部客户交付的时候会不太方便（我们公司也行业输出，因此对外部会有交付），使用文档的方式直接本地文件即可，使用 axure 要生成 html 文件，对于普通运营来说有一定门槛。

以上。想请教下程序员大佬们，你们在与产品经理协同的方式是怎样的？是文档+UE ，还是 UE 内直接体现需求说明的呀？

其实在我看来，如果哪种方式都是一个形式，重点是产品与研发的协同效率得到提升即可，达成一致即可。

[Amekumo]

产品路过，现在写需求基本只提供原型了，有什么说明页放在原型上了，后续更新只要复制粘贴一个新的页面写好版本号就好。Axure 可以发布到云端啊。

[willzzz]

@Amekumo 都没有文档了么？你们公司都是这种方式嘛？前后端的所有需求都是在 axure 啦？

[haozxuan001]

其实，你最终已经总结出来了， [不管哪种方式，达成一致是核心] ，但这个说起来简单，就像站在研发角度应该写单测一样的，但这个应该需要建立在一定的基础上，既然你负责产品团队 20 人，想必管理能力也是有一定自己的沉淀；从我个人角度（研发）看，研发强势的公司，那就按照研发的逻辑来，反之则是产品，毕竟哪有你也开心，我也开心的局面，都是在侵害对方利益的事情，没有 happy ending 的

PS：最后肯定下，会画 PRD ，把需求写在里面的产品是真的受研发欢迎，毕竟单产品输出时没办法交付给老板项目的，最终是以研发的实现成果作为最终交付产物；

[iOCZ]

不可能单一输出，根据你面向的群体，输出对应的文档。难道你文档更新了，设计稿不更新，肯定要做版本管理。

[GoopleXD]

我也是产品 , 多年跟开发合作下来发现 , 他们从来懒得看需求文档 , 文档写长篇大论也被吐槽 , 文档不写人家也吐槽
现在想开了 , 我连原型都懒得画 , 直接在线 markdown 抽象描述业务问题和对业务思考的具体实现
小团队相安无事

[8355]

研发更关注的是你想实现什么功能，并不关注你的背景，背景本身也许很重要但是你只需要开会讲清楚即可，需求文档需要看很多次，大篇幅的文档再多次观看的时候很难找到重点，写在 axure 图上框框一拉标红即可。文字可以从你的文档中复制粘贴，并不耗费你很多时间。

[dz5362]

原型上直接写需求，然后更新后标注一下，可以用版本号、新页面或者标红即可，我现在也是懒得写文档，觉得不直观

[tabris17]

你把用户文档当产品文档给开发？开什么玩笑

[idolud]

对外部客户（非开发人员）提供文档+UE 等等，对开发人员直接 UE 内直接体现需求说明

[yagamil]

适合的沟通频率. 例会.

太频繁了, 开发会觉得你在催促.

不沟通, 开发到后面偏离里轨道, 这个时候返工也是浪费了精力.

越来越发现这工作不好当.

[willzzz]

@tabris17 很怀疑你的阅读理解能力

[willzzz]

@yagamil 哈哈哈啊哈哈

[zjuster]

我的工作方式：
1. Axure 上原型只做框架图，不做交互。 交互还需要程序员前后端 2 个人分别去尝试，特别容易漏需求。
2. Axure 上原型全部用引导线说明这个按键的交互逻辑，核心的要点全部列原型图上，重点的需要全部标强调（红色、蓝色，最好有一套约定俗成的颜色语言）
3. 如果是改版，小改动直接标记所有改动点，大改动直接重新另外画页面（因为前后端接口大概率要重写）
4. 原型文档另外准备。这个文档是我在画图前就准备好的，是为了帮助自己管理产品思路和迭代，以及核心的功能路程图、业务流程图。 这个文档的主要用户是业务方，给业务方讲解，然后评审的时候，技术也要看这个文档的出技术需求书的。
最后技术实现的过程是对着原型和原型说明一个一个做的，不会去反复查文档。
我们的测试比较辛苦，文档和原型要一一对照的。

如果开发过程需求不变更，我们只开三次会：
1. 需求评审会，根据文档讲业务流程，根据原型讲改动点。
2. 技术评审会，技术出技术方案，技术接口改。
3. 测试用例评审，过图和文档。

[zjuster]

合作多了哪个开发的性格如何也就比较清楚了。

比较马虎的我会单独顶住他一个 list ，别漏了功能。
比较仔细的我就直接问他什么时候上测试环境，让我验收。

[willzzz]

@zjuster #13 我认为这是比较符合常规的产研协同的流程。我们现在也是类似的方式，但是程序员团队有些新招的 或者是外部来的 带来一些新想法 然后大家（研发团队）就觉得很好，就开始提各种各样的要求。

[Amekumo]

@willzzz 后端的我个人因为比较懒，直接写完了之后放到 Axure 去了

[yueye115]

版本管理是必须的，每次改动标明改动了什么，没人想去做校对。做好版本管理，即便写在文档里也能接受的，当然画在图上更直观

[cnhongwei]

和你的产品类型有关吧。比如滴滴类的，就一个打车按钮，后端要实现的东西就多了，在原型图上怎么说得清楚。如果大部分业务在原型图上能说清楚，我感觉直接在原型图上说明就行了。

[jones2000]

@GoopleXD 需求文档都是开发组长看， 然后他在切分模块下派任务， 下派任务的会写更详细的说明和技术实现路径等等。产品的文档只能算是原始文档了， 下面的人一般不会看原始文档。。组长这层在了解需求和构架的时候会跟产品沟通，把大的问题了解清楚在开搞。

[GoopleXD]

@jones2000 我感觉我兼了这个开发组长........

[horizon]

上万字？什么行业

[darkengine]

我们出设计文档 + 需求给开发用.

[xingming123]

都改成用在线协同的工具会好很多，我司用 figma+notion ，原型和文档也是分开的，但是因为是在线的，修改起来比较方便。
另外，产品文档到了上万字，我猜是没做好版本管理，或者产品写的太啰嗦

[cssTheGreatest]

我们的产品以前会给出一份几页的文档（面向开发供应商，也就是外包）
后来我们来了之后加上和设计师的磨合，改成在 figma 设计稿上标注需求描述就搞定了。文档唯一、实时更新、协作性基本都能满足。

[willzzz]

@horizon 零售数字化行业，涉及 tob erp scrm ，还有一堆 toc 的

[willzzz]

@xingming123 也不是啰嗦 我们一般是前后端一起的，我们要求是 功能背景、价值、业务场景、解决什么问题 这些必须要有。然后就是需求的业务流程、功能涉及多系统流程图、前后端的字段说明 逻辑说明等等。甚至还有涉及 open API 的字段说明等等。随随便便上万字了。

[willzzz]

@willzzz #26 当然可能技术不看，但是我们要求必须要有。同时技术团队要求做功能前必须要了解背景 价值 等等。