共计 682 个字符，预计需要花费 2 分钟才能阅读完成。
整体准则
排期需要推动
1. 后期沟通, 产品方案设计(判断 –> 真需要 vs 假需要)
– 充沛收集需要, 使所有工作的根底.
2. 技术同时参加
** -- 参加客户需要沟通 **:B 端系统业务逻辑简单. 帮忙评估可行性, 工作量. 与产品经理一起给客户出计划倡议
** -- 方案设计技术聆听技术共事倡议 **: 方案设计过程中, 踊跃咨询技术共事提出的倡议. 计划合理性, 与现有零碎匹配度.
开发测试
几次评审会
需要评审流程
需要评审会
– 常见问题 : 没人听?; 问题发现不了?; 开了也白开, 大家还是轻易改?; 开了很屡次, 需要也打不成一致意见?
什么是需要评审会:产品经理实现设计后, 将需要正式解说、交付给技术团队的会议.
作用:
1. 将需要正式传递给技术、测试、运维等相干团队;
2. 不同角色, 从不同视角 (技术、测试、运维、领导层), 发现需要中可能存在的问题
需要评审会是产品需要, 正式交付 的节点, 需要评审会后, 产品需要成为基线
需要评审会 – 评审会流程
需要评审会 – 会议邀请
需要评审会 – 产品宣讲
需要评审会 – 发问和论断
需要评审会 – 重要技巧
项目管理 – 三封邮件
我的项目打算通报邮件
变更治理
进步变更老本
上线前、后
邀请甲方尽早染指产品体验(非验收)
上线前 BUG 解决
进步客户满意度
问题集中应答 – 需要收集(起源)
问题集中应答 – 需要分类
零散需要推动
零散需要界定
此类需要起源
存在问题
应答形式
其余推动技巧
在约束条件下晋升产品解决方案品质
“5+1” 工作沟通形式
推动别人 (合作者) 口头
充沛告知
交出主动权
升高门槛, 逐步推进
敢于认错, 营造单干气氛
同理心解决问题
多版本定制需要治理
!
一次需要评审会
产品设计, 达成对立意见, 哪些需要最难达成意见
正文完
