这是一个创建于 446 天前的主题，其中的信息可能已经有所发展或是发生改变。
兄弟们大家好，先讲下背景：
本人产品岗位（但为了更好的推动工作，自学了 PHP 、JAVA 等，按我们公司的程序员来说我这说明找个初级程序员工作应该没问题）
目前本人负责公司的产品团队（大概 20 多人）
近期研发团队提出了一些对产品的问题，产品经理的需求文档规范问题：
这个问题老生常谈了，我们最初的时候是产品经理提供 PRD 的方式= 需求文档说明书：包含需求背景介绍、需求业务逻辑、需求流程图、前后台 UE 截图及文字说明 需求 UE：axure 版本的原型图，原型图内仅体现交互说明，没有需求说明。 现在问题：技术反馈 [产品经理的需求文档动辄上万字，与原型图对比看的太累了，希望可以把需求直接写到原型图上，方便开发人员查看]
其实站在产品的角度按这种方式 UE+需求一起通过 Axure 输出是没问题的，但是这样对于后续需求发生修改、变动、以及与运营团队、外部客户交付的时候会不太方便（我们公司也行业输出，因此对外部会有交付），使用文档的方式直接本地文件即可，使用 axure 要生成 html 文件，对于普通运营来说有一定门槛。
以上。想请教下程序员大佬们，你们在与产品经理协同的方式是怎样的？是文档+UE ，还是 UE 内直接体现需求说明的呀？
其实在我看来，如果哪种方式都是一个形式，重点是产品与研发的协同效率得到提升即可，达成一致即可。
 |
1
Amekumo 2023-10-10 09:31:11 +08:00 via Android
产品路过，现在写需求基本只提供原型了，有什么说明页放在原型上了，后续更新只要复制粘贴一个新的页面写好版本号就好。Axure 可以发布到云端啊。
|
 |
3
haozxuan001 2023-10-10 09:51:58 +08:00
其实，你最终已经总结出来了， [不管哪种方式，达成一致是核心] ，但这个说起来简单，就像站在研发角度应该写单测一样的，但这个应该需要建立在一定的基础上，既然你负责产品团队 20 人，想必管理能力也是有一定自己的沉淀；从我个人角度（研发）看，研发强势的公司，那就按照研发的逻辑来，反之则是产品，毕竟哪有你也开心，我也开心的局面，都是在侵害对方利益的事情，没有 happy ending 的
PS：最后肯定下，会画 PRD ，把需求写在里面的产品是真的受研发欢迎，毕竟单产品输出时没办法交付给老板项目的，最终是以研发的实现成果作为最终交付产物； |
 |
4
iOCZ 2023-10-10 09:55:23 +08:00
不可能单一输出，根据你面向的群体，输出对应的文档。难道你文档更新了，设计稿不更新，肯定要做版本管理。
|
 |
5
GoopleXD 2023-10-10 09:55:50 +08:00
我也是产品 , 多年跟开发合作下来发现 , 他们从来懒得看需求文档 , 文档写长篇大论也被吐槽 , 文档不写人家也吐槽
现在想开了 , 我连原型都懒得画 , 直接在线 markdown 抽象描述业务问题和对业务思考的具体实现 小团队相安无事 |
 |
6
8355 2023-10-10 10:01:09 +08:00
研发更关注的是你想实现什么功能，并不关注你的背景，背景本身也许很重要但是你只需要开会讲清楚即可，需求文档需要看很多次，大篇幅的文档再多次观看的时候很难找到重点，写在 axure 图上框框一拉标红即可。文字可以从你的文档中复制粘贴，并不耗费你很多时间。
|
 |
7
dz5362 2023-10-10 10:14:05 +08:00
原型上直接写需求，然后更新后标注一下，可以用版本号、新页面或者标红即可，我现在也是懒得写文档，觉得不直观
|
 |
8
tabris17 2023-10-10 10:16:54 +08:00
你把用户文档当产品文档给开发？开什么玩笑
|
 |
9
idolud 2023-10-10 10:30:19 +08:00
对外部客户（非开发人员）提供文档+UE 等等，对开发人员直接 UE 内直接体现需求说明
|
 |
10
yagamil 2023-10-10 10:48:40 +08:00
适合的沟通频率. 例会.
太频繁了, 开发会觉得你在催促. 不沟通, 开发到后面偏离里轨道, 这个时候返工也是浪费了精力. 越来越发现这工作不好当. |
 |
13
zjuster 2023-10-10 11:18:11 +08:00
我的工作方式：
1. Axure 上原型只做框架图，不做交互。 交互还需要程序员前后端 2 个人分别去尝试，特别容易漏需求。 2. Axure 上原型全部用引导线说明这个按键的交互逻辑，核心的要点全部列原型图上，重点的需要全部标强调（红色、蓝色，最好有一套约定俗成的颜色语言） 3. 如果是改版，小改动直接标记所有改动点，大改动直接重新另外画页面（因为前后端接口大概率要重写） 4. 原型文档另外准备。这个文档是我在画图前就准备好的，是为了帮助自己管理产品思路和迭代，以及核心的功能路程图、业务流程图。 这个文档的主要用户是业务方，给业务方讲解，然后评审的时候，技术也要看这个文档的出技术需求书的。 最后技术实现的过程是对着原型和原型说明一个一个做的，不会去反复查文档。 我们的测试比较辛苦，文档和原型要一一对照的。 如果开发过程需求不变更，我们只开三次会： 1. 需求评审会，根据文档讲业务流程，根据原型讲改动点。 2. 技术评审会，技术出技术方案，技术接口改。 3. 测试用例评审，过图和文档。 |
|
14
zjuster 2023-10-10 11:21:24 +08:00
合作多了哪个开发的性格如何也就比较清楚了。
比较马虎的我会单独顶住他一个 list ，别漏了功能。 比较仔细的我就直接问他什么时候上测试环境，让我验收。 |
 |
15
willzzz OP @zjuster #13 我认为这是比较符合常规的产研协同的流程。我们现在也是类似的方式，但是程序员团队有些新招的 或者是外部来的 带来一些新想法 然后大家（研发团队）就觉得很好，就开始提各种各样的要求。
|
 |
17
yueye115 2023-10-10 13:41:49 +08:00
版本管理是必须的，每次改动标明改动了什么，没人想去做校对。做好版本管理，即便写在文档里也能接受的，当然画在图上更直观
|
 |
18
cnhongwei 2023-10-10 13:43:52 +08:00
和你的产品类型有关吧。比如滴滴类的，就一个打车按钮，后端要实现的东西就多了，在原型图上怎么说得清楚。如果大部分业务在原型图上能说清楚，我感觉直接在原型图上说明就行了。
|
 |
19
jones2000 2023-10-10 16:23:09 +08:00
@GoopleXD 需求文档都是开发组长看， 然后他在切分模块下派任务， 下派任务的会写更详细的说明和技术实现路径等等。产品的文档只能算是原始文档了， 下面的人一般不会看原始文档。。组长这层在了解需求和构架的时候会跟产品沟通，把大的问题了解清楚在开搞。
|
 |
21
horizon 2023-10-10 18:54:25 +08:00
上万字？什么行业
|
 |
22
darkengine 2023-10-10 22:05:57 +08:00
我们出设计文档 + 需求给开发用.
|
 |
23
xingming123 2023-10-10 23:45:21 +08:00
都改成用在线协同的工具会好很多，我司用 figma+notion ，原型和文档也是分开的，但是因为是在线的，修改起来比较方便。
另外，产品文档到了上万字，我猜是没做好版本管理，或者产品写的太啰嗦 |
 |
24
cssTheGreatest 2023-10-11 13:21:51 +08:00
我们的产品以前会给出一份几页的文档（面向开发供应商，也就是外包）
后来我们来了之后加上和设计师的磨合，改成在 figma 设计稿上标注需求描述就搞定了。文档唯一、实时更新、协作性基本都能满足。 |
|
26
willzzz OP @xingming123 也不是啰嗦 我们一般是前后端一起的，我们要求是 功能背景、价值、业务场景、解决什么问题 这些必须要有。然后就是需求的业务流程、功能涉及多系统流程图、前后端的字段说明 逻辑说明等等。甚至还有涉及 open API 的字段说明等等。随随便便上万字了。
|
Select Language