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