接口详细设计文档_软件接口文档

【产品经理技术必修课程】如何与工程师沟通-个人理解 　　

　　一：工程师思维 　　01-个体思维差异 　　每个人的成长背景，经历，个人认知导致量思维差异的形成，尊重并接受这种差异性是形成有效沟通的前提。 　　

　　认知鸿沟是沟通障碍的主要来源 　　工程师思维特点： 　　1.逻辑性强 　　2.分支思维：提新需求时，工程师一般不会在主流程上改，而是将这个主干分支复制出来，开一个新的分支，相当于测试分支，这个分支和主干分支是平行的状态，互不干扰。在测试分支上进行开发或修改，测试没问题后，进行分支合并。 　　3.遍历：查一个表中的数据，会写代码将表中的数据全部的遍历一遍 　　

　　产品经理在写需求的时候可能会只考虑if这个层级，工程师在写的代码的时候，代码会告诉他会有else，可能会有更多的else，所以工程师会考虑的更完善，所以产品经理可以借用这种思维。（只有一个结果，非此即彼） 　　02-与工程师沟通 　　三个原则：重事实：现状，问题，方案——可行性 　　（尊重客观现实，不要天马行空！！） 　　2.讲逻辑：分支覆盖，遍历完整，冲突性——完整性 　　（提出的新需要尽可能想到所遇到的场景问题） 　　3.确定性：工作量，周期，风险预估——可控性 　　（给到的方案，要具体的 不要模棱两可，不要不确定性的） 　　产品经理不仅要设计方案，也要对方案落定的过程有一个把握。 　　二：如何区分现象和问题 　　01-如何高效沟通 　　沟通的本质是取得共识和解决问题；高效沟通的目的是寻找最短路径去取得共识和解决问题。 　　沟通路径：

　　人们往往在发现问题后容易花大量的时间讨论现象（就是讨论说这个问题导致什么样什么样），如这个问题会影响到什么什么，但它对整个过程没有促进作用，还不如将这个时间用在定义问题上，这个问题出现在哪里，这个问题是某某某。（落实问题才好解决） 　　02-区分现象VS问题 　　

　　让讨论以方案为导向，以共识为目的，我们花了太多时间去讨论和重复讨论现象，却恰恰忽略了定义关键问题，现象是影响，问题是原因 　　例如： 　　现象：产品登陆不上去了 　　问题：有没可能是网络故障；有没可能是后端服务故障；有没可能是前端处理异常（可能是前端进入到当时设计时没遍历到分支导致出现问题；要一步步排查定义问题） 　　———————————————————————-现象：提了一个需求，工程师说这个实现不了（千万不要把他当作一个结论，要当成是一个现象） 　　问题：可能是技术边界导致实现不了–要找替代方案；实现起来有难度；时间成本-那可以排期去安排解决 　　03-瞄准问题打方案 　　定义清楚问题，这个问题就已经解决了一半。 　　如： 　　现象：产品登陆不上去了问题：网络故障，后端服务故障，前端处理异常方案：网络排查，前后端分别排查 　　现象：这个实现不了问题：技术边界，难度，时间成本方案：技术边界——找替代方案；难度——找技术攻关小组；时间成本——项目协调、重新排期 　　可以平常经常反问使用一句话：你的问题是什么？ 　　这样就可以具体清晰明确这个问题是什么，这样就可以基于这个问题去判断 提出的这个是现象表达还是真正的问题；明确之后就可以找解决方案。 　　三：如何正确提需求 　　01-提需求的时机 　　根据工程师的习惯，不是每个时候都适合提需求，找准时机，让需求更容易被接受。 　　因为每个人在思考或者在做事时，被人打断了，思路就会断开。就要需要平时多几倍的时间去重连思路。所以找好一个时机十分重要。 　　

　　时机分类：上线前 X 　　（产品上线前，工程师是有很多工作要做的，如新旧版本兼容、还有程序升级、还有新功能上线后有出现的新问题；这个时机不适宜提需求）上线后稳定运行 √ 　　（上线运行一段时间后，没有发生什么问题，此时工程师是比较空闲）周期迭代结束 √ 　　（这个开发周期已经结束，难得空出来休息时间 可以提需求） 　　写代码 X 　　（在写和改时 提需求会打乱思路和节奏）改BUG X 　　（在写和改时 提需求会打乱思路和节奏）提交代码 √ 　　（功能开发完成后，给测试人员去测试 此时工程师是有空的） 　　02-提需求的顺序 　　用一个上下文完整的信息并结合问题给工程师提需求，避免干瘪（就是一上来就告诉别人怎么做，教别人做事）的功能性需求 　　顺序：需求：浅层唤醒层面，自定义唤醒词 　　背景（现状，问题，原因）：同时有多台音箱，且唤醒词相同，想要唤醒某一台时，其他音箱同时被唤醒。背景讲明白，一般工程师都不会反驳 　　方案（如何做，可行性）：在软件层面设置浅层唤醒 　　执行（何时做）：这个版本迭代之后，全量发布 　　

　　03-提需求的内容 　　避免凭感觉式的需求描述，需求内容要具体可行 　　做新功能需将以下准备好 　　1.页面原型图——产品/UE2.功能交互流程图——产品3.接口URL及对应参数——产品/开发4.视觉搞/素材/标注——UI 　　

　　PRD文档： 　　1.把背景说清楚 　　2.把方案定明白 　　流程图带交互的原型图接口说明 　　3.把材料备齐全（UI，测试用例，发布上线节奏时间） 　　在我看来没有标准的文档，文档存在的意义，是能把问题描述清楚，把需求讲明白，而不是多好看 　　四：如何评估技术工作量 　　01-技术工作包括哪些 　　技术工作细节远比上面看到的要多，实际过程中的不确定性极强，任何一个环节都有可能延期 　　

　　数据库设计（有新功能后，要想这个新功能有什么数据要调用和存储；如数据库定义了一个字段，这个字段被设计在接口里面）接口设计（后端对功能接口做设计）界面代码（前端写好静态页面）逻辑代码（后端对新功能的逻辑写好）组件复用（对一些多次重复使用的模块组件化，这样就可以给其他人用）代码注释（对写的代码写好注释）单测试（小范围按测试用例测试接口和功能逻辑能不能用）前后端接口联调bug修改部署上线（上线后，可能新老版本的数据迁移导致不兼容、不一致等） 　　02-评估可按需求拆分 　　产品经理无需精确评估技术工作量，也评估不准，但可以把需求进行拆分评估大概周期 　　拆分维度：1.系统：将需求按不同系统拆分，例如按电商优惠券系统，促销系统，运营后台进行拆分 　　2.模块：将需求按功能 模块进行拆分，例如按电商交易流程中的购物车，结算页，收银台进行拆分 　　3.页面：将需求按独立页面进行拆分，例如按电商商品详情页，订单列表页，用户评价页进行拆分 　　根据拆分后的需求，根据复杂度，改动量，过往经验进行工作量预估 　　03-技术组件化 　　组件化也是能够很好帮助我们评估技术工作量的一种方式，一种工具。 　　技术中有句话叫做，不重复发明轮子，是技术组建化的目标，不是所有的功能都需要重复开发。 　　例如现在有三种组件： 　　1.定位组件 　　http://2.IM组件 　　3.列表数据加载组件 　　

　　对于组建的使用是通过集成的方式，不需要开发的 　　五：技术思维在产品设计中的运用 　　01-运用技术思维进行产品设计 　　产品是感性思考与理性设计的结合体，在设计环节，加入技术思维的考虑，会更利于落地。 　　考虑方案的 实现的原理，主要涉及：1.数据结构调整（数据库，接口） 接口就是对数据库的直观反应 　　2.页面调整 　　3.逻辑兼容（新老版本兼容） 　　案例：短信模版 　　

　　技术视角下的短信模版 　　

　　产品工作：1.定义参数 –账号、时间、金额2.确定短信模版：大概在哪些环节需要使用这些参数3.明确接口取值逻辑：接口怎么判断参数值，取值后赋予在短信模板上 　　六：如何持续提升技术思维 　　01-技术思维不等于技术能力 　　产品经理要掌握的是技术思维，而不是技术能力，切记别顾此失彼

　　技术思维：理解程序和代码逻辑设计低复杂度 界面布局判断数据是如何在功能间流转 　　技术能力：能够编写代码实现功能实现前端界面从数据库查询或修改数据 　　02-提升途径 　　技术思维的主要途径：1.需求评审会上，对工程师的问题重点记录，反复思考，翻译成通俗的理解 　　2.阅读数据库设计文档（比如有哪些表，有哪些字段，关系是什么）以及接口文档，建立数据结构的基本认知 　　3.产品升级或设计调整时，是了解其中技术细节的最好时机，包括数据流转，接口分布等 　　4.进一步系统化学习时，可以参考大学教材进行基础知识补充，但不建议太深入 　　对产品经理来说，对产品的理解，对用户的理解，要优先于对技术的理解 　　03-建立自己的技术知识库 　　将复杂的技术概念，转化为自己可理解的常识性概念，持续丰富自己的技术知识库 　　

　　七：学会与工程师沟通 　　01-向工程师阐述产品需求 　　完成产品设计和PRD后 　　（1）自查所有功能逻辑是否完整：包括正常和异常功能逻辑 　　（2）和工程师沟通。表达方式——第三方讲述法：公立立场，不带个人情感，”无我“ 　　多用：我们一起… 、用户使用时觉得… 　　少用：我觉得、我认为 　　例：发现bug，则问题转移法沟通—— 　　”我们在设计产品时有一个逻辑没有考虑到，但现在我们在实现时发现了这个问题，我们要一块把这个逻辑漏洞补上“（减轻其自负，将问题转移到产品逻辑没能覆盖到） 　　02- 如何从产品角度参与技术讨论 　　工程师会以最小实现技术成本的前提下实现产品功能，容易忽略产品和用户价值，因此讨论技术方案时容易改变产品设计需求。 　　（1）产品经理需要充分理解和把握产品需求，知道为什么这么做，背后的原因是什么。 　　（2）形象化提问：将不懂的技术形象化，以提问的方式让工程师帮忙解答。关键是–引导 　　03-产品需求变动时得沟通方法 　　用户需求和商业目标无时不刻不发生变化，无法避免需求变化。 　　3.1-如何面对拒绝变化 　　从变化表象背后的原因聊起，而非直接沟通变化本身（把握产品变化原则，从事情得本质层面进行深究）。 　　说明背景之后，再讲述事情本身所面临的问题，最后将需要对方做什么或者本次沟通的下一步行动方案 　　3.2 沟通需求从以下四个角度切入： 　　需求背景、功能逻辑、界面设计和技术调整。 　　着重、先讲需求背景（成败关键），之后再谈功能逻辑和界面设计。 　　通过内因驱动的变化方式去沟通，能带来很好的效果。 　　04-非技术背景产品经理的沟通技巧 　　目的型沟通：围绕目的讲需求； 　　通过引导的方式让对方理解。 　　4.1-表达清楚一件事情： 　　①说明实情背景（前因后果） 　　②事情本事及面临的问题 　　③需要对方做什么 / 本次沟通后的下一步行动方案 　　4.2-沟通模型： 　　①发起方表达核心观点 　　②获得对方理解和反馈情况 　　③对沟通结果重复确认 　　④二次确认 　　4.3- ”这个功能做不了“怎么办 　　通过提问引导还原分析问题，挖掘问题本质，做出正确决策。 　　解决办法： 　　①存在技术边界？是全人类的技术客观尚不能实现？ 　　→更换新的产品解决方案 　　②其他人可以，我们的技术储备不足做不到吗？ 　　→更换技术替代方案 　　③是开发进度和时间导致做不了吗？ 　　→业务价值 / 用户价值能否增长？满足其一，耽误整体进度也要做 　　4.4-”这不是BUG“怎么处理 　　根本原因： 　　本质上是交互问题。PRD没有对该细节功能进行详细的设计。不影响使用，有了更好。 　　解决办法： 　　低姿态，哄工程师，说这是PRD没考虑到的内容，属于新增的小特性，不是你的问题。 　　4.5-需求评审会（关键是引导每一个讨论） 　　目的： 　　和工程师等相关人员一起针对产品设计，围绕技术实现角度和用户合理性角度进行整体评审。其他的都要引导回这两个方向。 　　解决思路： 　　当讨论焦点不是技术实现方案，而是产品对用户的理解时（讨论我的工作内容）—— 　　耐心询问两种设计方式在实现上的区别。 　　没区别——选择让用户更有安全感的方式（听我的）； 　　有区别——具体衡量工作量，研究投入产出比（看ROI）； 　　05-用讲故事代替介绍功能 　　拔高自身沟通范围，基于功能背后的目标对象和实际意义（本质）沟通。 　　关键：把产品功能放在一个具体的故事场景里，切忌只讲产品功能。 　　06-总结 　　化解变化是产品经理推动事情往前发展的前提。