大的需求可以在prd以外，尝试用word写一下：《业务方案》和《系统整体设计方案》，用于描述具体实现以外的东西。这些有相对固定结构和模板，可根据实际情况调整。可以参考一下这个模板：

《业务方案》

因为什么要做这个业务

2.业务诉求

做这个业务要解决的问题

进行了哪些评估来决定做这个事情

关键时间节点及事项

二、业务调研

1.干系人（组织架构）

业务参与者和负责的事情，当前的和未来规划

2.业务流程

这里注意不要和系统流程搞混，业务流程包含系统内和系统外的。画流程一定要注意所有节点是同级的。

3.业务目标

希望达到的目标及现状

三、业务需求分析

1.业务问题

当前业务上遇到的问题

2.基于业务的诉求

要通过系统解决的问题及优先级

3.流程图

结合上一点的新业务流程

《系统整体方案》

1.系统定位

需要哪些系统给哪些人用来干什么事情。

2.整体架构

应用架构图，业务涉及的系统

3.功能抽象

每个系统的功能模块、功能点

二、系统细节设计

大业务模块的重要细节，按需要：实体建模&信息架构、页面地图、权限、系统流程图等等

《每个模块或功能的PRD》

做的是《系统整体方案》里的那一部分，业务和系统设计那些地方参考上面两个文档哪些部分。

2.需求清单

按流程或模块从前到后列出需求点，后面文档结构也按这个来

1.AAA流程

流程概述（非必须）

1.1AAA流程下的aaa需求

1.1.1 业务规则

需求描述、业务规则、逻辑图、字段等、约束等

线框图和交互需求

*我自己觉得这样写会比较顺，就是把不同级别的内容放到不同级别的文档里面，免得一个文档里面出现不同层次的东西很乱，从上到下：业务——架构——功能。

抛砖引玉。

这是一个特别有意思的问题，你的困难其实不只是“帮开发理解业务”，要比这个更复杂，看完描述后，从我的角度来看，你至少在3个方面的处理有问题：

不过问题描述信息有限，也可能是我武断了，先告声“得罪”。

向上管理（只考虑绩效层面，不考虑政治）的核心目标只有一个：期望管理。引申一下，如果是降低期望管理，你需要让老板清楚并且理解“为什么我要降低期望”，这个原因和理由要越具体越好，越是客观实际的原因，老板越容易被说服。从问题描述看，你们把这个原因归咎于“开发总监能力不足”，这是一个非常不好的理由，不够具体，且太主观了，你能说服你的老板接受开发总监能力不足的问题，开发总监的老板认可吗？你让你的老板去怼另一个老板下属能力不足吗？即使真实原因就是他能力不足，那也不能从你的嘴里说出来，要让开发总监他自己说出来，你需要通过一系列操作，比如已经具备可实现性了（后面“产品抽象”部分我会举例解释），但他就是不会做，要让老板自己得出这个结论。

平行管理（仍然只考虑绩效层面，不考虑政治）的核心目标也只有一个：结盟（再次强调一下，不考虑办公室政治，只考虑绩效）。你需要找到利益共同体和绊脚石，通俗来讲就是要分辨出谁是战友，谁是敌人。注意：即使是同一个项目，同一件事，同一个人，在不同场景下这两个立场也会发生改变。比如这个开发总监，你和他沟通需求实现的过程中，你和他是敌人，你要和他PK需求合理性，产品方案合理性；如果他的质疑是合理的，或者你觉得是应该考虑的，那么你们在与老板沟通的过程中，你和他是战友，你们要共同和老板PK产研开发的合理性（这也对应了上面的“期望管理”）。从你问题的描述中来看，你应该是一直把这个开发总监当做敌人，固然有可能是他能力不足，但是否也有可能，确实在实现上有问题，但他不会表述或者表述不清，你们忽略了？换位思考一下，有没有可能把他变成“战友”，从期望管理的角度，解决这个问题？（或者换句大白话说，老板这个需求是不是本身就不靠谱，是他想简单了？）

最后是产品抽象。由于你的问题描述没有细节（“要做某个新平台的抽象化架构设计，给出了一张业务图，以及一个业务示例”，“开发总监觉得无法基于这个图做抽象化设计”），我只能基于我的理解进行解释。先问几个问题：

• 问题描述中的“业务图”和开发总监提到的无法基于“这个图做抽象化设计”是一个图吗？
• 你是否对业务，或者这个业务图先进行了“产品抽象”
• 你抽象出了什么？

如果你没有进行过“产品抽象”，那么我很能理解开发总监为什么说不行。通常来说，一个产品或者业务上线，要至少依次进行3次抽象：

3次抽象都能完成，这是最理想的状况（如果产品即业务，那么业务抽象也要由产品负责）；最差的情况是，缺乏前两次抽象，直接让技术进行实现。这时候99.9%的技术一定是一脸懵逼的，剩下那0.1%能完成技术抽象，也一定是替业务和产品完成了前两次抽象，这种技术应该是大神，能力绝对够了，但这种工作环境应该没机会留住他。从你的问题描述来看，业务抽象应该没有的，产品抽象不确定有没有（猜测是没有，或者不够）。

所以，回到你最初的问题，“如何帮助开发理解业务，以便于做抽象化架构设计”？

• 如果是业务抽象不够，要么你替业务抽象
• 要么你拉着他（战友）一起去PK老板（期望管理）
• 如果是产品抽象不够，那就好好抽象产品（业务抽象如果足够好，产品不可能抽象不出来，除非产品能力不足）
• 如果前两个抽象都没问题，技术说还不行，那就拉着他（敌人）一起去讲给老板（朋友），让老板看到他的不行，让老板自己得出“他技术能力不行”的结论。

当然，以上所有内容，都是我基于不全的信息给的建议，也可能都是错的。

你是干产品的，不是干开发。

从你的问题说：带着副总来找我，说没有给出具体的业务模型，不好做抽象化设计。

是你要把整个业务收梳理清楚、流程、产品架构。如果开发需要开发你这个的，你还要做做需求分析细化、原型交互设计，而不是仅仅一个word文档/ppT文档。——》直接说吧，ppt/word文档写的是总体的解决方案，一般是给你的领导和老板看的，开发的人只需看交互原型和需求说明书，开发想要开发，都是基于交互原型的需求评审来进行开发设计的。 即使你给他看PPT他也不会，除非你做的VR/AR/AI 这样的项目，如果你做的互联网这种信息化的产品，那开发就一定是基于交互原型和需求说明书来进行开发设计的。

开发出身的产品岗，跟开发总监 产生沟通不畅，我觉得不仅仅是 几张图，或者几个文档能解决的。

应该再分析下 问题背后的问题吧，肯定是哪里做的不对。

用word只是形式，单单把 图 改成 文字，肯定是不够的。

我觉得至少 从 开发身份对开发沟通 或者 产品身份对开发沟通，都没有对到点儿上。

我个人，建议 学下     EA（Enterprise Architect）  这个工具。

个人经验，大多数产品和研发在沟通过程中出现此类问题时，根因是产品自己就没搞清楚业务。

你这问题提的，我怕你自己都没理解是什么需求。