从前端实现来看，首先是界面开发，设计样式类别，以及UI特效等，数量越大，工作量也越大。样式是否全新设计
采用通用样式还是自定义样式，都会影响到开发量的评估。同时，在前端的各个流程里面，受到外部元素影响越大，涉及的异常场景越多，开发工作量也就越大。
然后再看功能开发，是否已有现成方案和功能，如果没有，再看功能复杂度，视频播放器和图片展现的工作量完全不一样
评估和服务器对接开发工作量，服务器设计的接口简易程度以及数据安全性等也会影响工作量的评估
从后端实现来看，不仅仅评估业务功能点的数量，还要考虑数据量有多大，用户量有多大，并发数有多大，即时性的要求是什么，现有架构是否能支持这种并发量，是否需要重构。同时还需要考虑到后台配合前端，设计接口，商量通信协议，处理前后台联调等。
评估和服务器对接开发工作量，服务器设计的接口简易程度以及数据安全性等也会影响工作量的评估
技术人员是一群理性严谨、逻辑思维强，相对而言，是比较固执的人,计算程序的世界里,只有0和1,对就是对,错就是错的,自己写的功能能不能行,自己是清楚的
产品经理的换位思考是思考些什么呢？产品经理应该思考的是：
❑ 我的这个方案实现的技术逻辑是什么，难点应在哪些方面？
❑ 技术人员每天所写的任何一行代码，解决一个bug，实现一个功能，也都是前所未有的新课题，每天的工作也都是新的，需要我提供什么样的支持？
❑ 期待技术人员来提问，从而把可能没有表述清楚的地方更好地说清楚。很多时候，产品的精彩离不开技术人员
（2）信息同步
产品经理在提出需求时，应明确告诉技术人员，其需求的产生背景是什么，期望达到的目标是什么，实现的价值是什么
产品经理在讲解需求时，应该尽可能将需求背景、需求目标以及产生的市场价值同步给技术人员，产品经理对整个项目的背景、结构、前提、目标早已有了代入感
所以觉得每个细节都理所当然是这样的，但是对技术人员而言，他们并没有得到完整的背景信息，对细节的理解就可能会出现偏差和误判。
对彼此功能点的关系，相互的联系了解得支离破碎，那么这个系统实现起来也就难免出现不尽如人意的地方
产品经理的信息同步是同步什么呢？产品经理应该同步的是：
❑ 需求产生的背景，期望的目标，让技术人员更好地理解需求。
❑ 需求产生的价值，让技术人员感觉到更有成就感。
❑ 需求可能产生一些影响，方便技术人员对应来做一些应对处理
产品经理在与技术进行互动的时候，可以作如下的工作：
❑ 让技术提前了解需求，阅读需求文档，这样在做需求评审时，不会出现单向沟通，只有产品经理在讲，技术人员来不及消化而无法沟通的情况。
❑ 在沟通需求的过程中，营造良好的沟通气氛，让技术人员勇于表达自己的观点和看法。
❑ 在问题的讨论中，鼓励技术人员表达自己的解决方案
自上而下，结论在前：首先说明汇报目的，然后引入整体的进度及待办，让信息受众首先明白本次沟通的主要基调是什么，可以带着问题和目的展开后续沟通内容
❑ 层次清晰，结构简单：在汇报待办事项时，将事项进行分类并概括，有助于信息受众减少识别词语并建立联系的成本，可以专注于理解沟通的内在含义。
❑ 完全独立，互相穷尽：同级别的逻辑结果做到“无交叉、无空白”，各部分相互独立且所有部分完全穷尽
与优秀的产品经理合作,是比较舒服的,开发工程师也是,更考验的是前后端开发工程师,业务的能力,而具体的代码工程能力,也是为具体的业务服务的
如果业务没有理解清楚,在具体的实现,也会存在偏差的,比如一些边界条件,特殊情况等,在需求评审时,原型设计稿里,都需要标注,方便工程师的实现
