建表：根据业务逻辑需要，设计数据库表结构，用于存储数据，主要是后端开发的工作，也有可能是DBA的工作；
写死：
- 是指参数或者配置内容写死，代表着这些内容是要写在代码里，修改需要重新发布代码；如用户注册时选择省/市，可以直接写在前端代码里，无需通过后端提供接口，就省去了建表和写接口的时间；
- 写死的好处就是开发效率高，坏处就是修改不方便，需要重新发布版本；
- 现有的技术根本无法实现，也就是经常说的超出了技术边界，比如想要下载速度达到10G/s
- 受限于公司研发能力和技术栈限制，超出了能力边界，比如原本是做小程序的要求去做人工智能开发
- 平台或生态的限制，不支持这种做法，或者没有开放对应的接口，比如微信没有对外开放获取好友列表的接口
- 现有技术架构不支持，如果要做成本会很高，需要重写底层代码，时间紧、任务重、不划算
- 实现方法比较复杂，没有快速实现的方法，无法满足短时间内实现的要求
- 觉得所提的需求价值不大，没有做的意义，也没有动力去做
- 单纯的不想做
- 烦你
05 和开发友好沟通1. 协调估时方法开发估时主要都由团队中的技术主管来把控，他们有责任来辅助估时、把控进度、协调任务；
【 ide|产品经理要了解技术类知识】因此这里说的方法不是让产品经理来代替开发估时，而是在遇到估时远超预期时，我们所能采取的策略；
判断估时第一步：我们先看总时长，找出将总时长拉长的人的时间节点，看是否是任务安排不合理（个别人任务多）、还是顺序衔接有问题（出现时间真空）、还是有其他任务打扰；
判断估时第二步：解决个别人时长过长，有些人可能任务量正常、复杂度和其他人差不多，但估时就是比别人多；
- 先评估个人能力和所分配的任务是否匹配
- 然后询问原因，可能会发现信息不对称（如对需求的理解不对、对代码库的了解、对某些技术不了解等），产品经理可以引导其找对应的人解决，或者直接帮他解决，进行信息对称
- 最后，这个人可能说不出为什么，也没有意愿去解决时长过长的问题，产品经理有必要让开发对他自己的任务进行拆解，可以按开发步骤、接口数、逻辑点拆解到天，直到无法拆解为止
- 可能有人说，我没这个权力啊，我做不到让开发和我详细拆解任务，很多人确实没有，但问题还是要解决，可以好言好语、可以求助他人，反正是想尽一切办法来解决
2. 任务估时难度判断看逻辑：
- 逻辑本身很简单，没有很多的判断（比如只是增删改查），功能也比较独立的，基本上评估1~2天是比较合理的，手脚快的可能半天就搞定了
- 如果知识纯展示，从几张表中拉去数据，加一些简单的判断，前端的复杂度和交互相关，后端复杂度较低，基本上也就半天一天的事
- 如果只是替换文字内容、图片、简单样式（颜色、大小等），哪怕页面比较多，也可以批量操作完成，可能繁琐但不复杂，可以在短时间内完成，属于举手之劳
- 一般有现成的接口文档和SDK的，实现起来也较为简单，花点时间研究下即可使用
- 有通用组件的，且之前有功能实现过，如果变化不大可以直接使用
- 苹果|苹果最巅峰产品就是8，之后的产品，多少都有出现问题
- 业务|传统企业里，产品经理失去了话语权
- 上海尊宝音响多款产品获《影音极品》器材大赏奖项
- 噪音|聊聊社交产品中的信号与暗示
- 雷曼巨幕LEDPLAY获IT影响中国2021年度创新产品奖
- 副总经理|ZOL观察：创新引领超越 光峰工程投影的起航之路
- iPad|一样是苹果的电子产品，为什么iPhone比iPad贵几千元呢
- 产品经理|人工智能越来越发达，人类一身“毛病”，会被机器人取代吗？
- 产品经理|下一个创业风口你认为是什么？
- 苹果|2022年苹果或将推出这 8 款新产品，可以期待一下