4 交互设计
4.1 交互概论
回顾产品结构：
基于前期的需求分析及市场竞品分析等为依据，将各个需求点以及某种逻辑系统化的组织起来所形成的立体结构。
基于该结构，可以顺利的引导用户行为或将各类信息进行顺畅的流转
操作系统从最初的DOC系统>win98>winXP>win7>win8>win10,从最初专业到普及就是交互设计的不断改进。
- UI 用户界面
- UE 用户体验
- IXD 交互设计
什么是交互：
两个或多个互动的个体之间交流的内容和结构，使之互相配合，共同达成某种目的。
交互设计就是让用户在使用产品或服务的过程保证可用性，提高易用性。
交互设计是一种使得产品易用，有效的把人使用产品的过程变得愉悦的技术。
它致力于把握目标用户和他们的期望，分析“人”本身的心里和行为特点，设计或改善用户在同产品交互时彼此的有效行为，和各种有效的交互方式，并对他们进行增强和扩充。
4.2 交互设计中的基本原则
- 用户心理
现在有一把锁，从不同角度来看- 用户：
- 眼中：钥匙眼+把手
- 心里：锁眼好找好用，把手舒服，向下开门
- 技工：
- 眼中：详细结构+精密连接
- 心里：研究它的材质，连接方式
- 用户：
符合用户的心里：
就是把本来很复杂的事情设计成符合用户日常生活中常用的浏览方式或操作方式；也可以理解为
人性化设计
比如银行转账，在转账时会有历史记录，确保让用户在第一次转账正确后放心转账
- 西克法则
定律内容：一个人面临的选择（n）越多，所需要作出决定的时间（T）就越长
7+-2法则：人们短期记忆每次能处理5—9件事情，作为把导航菜单的元素限制在7个以内的依据，因此根据产品需要，尽可能减少用户的选择项目数。
- 接近法则
线框内的元素特征- 军事，社会，国际是新闻的类型
- 股票，基金，外汇是财经领域的一部分
- 并排放置的频道，都是相近类型
- 微信网页版，MAC版，WIN版只是同一产品的不同类型
- 聊天输入时，可能用语音，图片，表情，红包等功能
- 放置在一起因为他们都是聊天可输入的内容
- 防错原则
- 注销的二次确认是防止用户点击错误
- 复制验证码是防止用户验证码输入错误
防错原则认为：
大部分的意外都是由设计的疏忽，而不是人为操作的疏忽。通过改变设计可以把过失降到最低
- 操作可预期
看到线框内的元素我们会有所预期：
- 我会支付一笔钱
- 我会进入一个商铺首页
比如我们点击倒三角形，我们的预期是下拉出更多内容
- 贴近认知
在国内前两个图表辨识度极高，第三个图表在国内辨识度不高。
所以对于国内网站，尽量不要使用第三个图标
比如看视频，当点击播放时，画面一下子横置，这样就超出了用户基本认知和预期，降低了使用流畅度
7 状态可感知
当用户读完新闻之后，要把新闻列表中读过的新闻灰掉，让用户知道自己处于什么状态了
再比如进度条，当前位置，数据加载等
- 一致性
图中方框部分头像方圆不统一，再有列表头像是可以点击，但是订阅列表页不可点击。
总结
- 好的交互让使用产品的过程更愉悦
- 好的交互有基本的原则可以轻易遵循
4.2 交互设计核心和步骤
交互设计的核心任务
- 表达
- 使用界面语言向用户传递信息，进而实现人机交互
交互设计三步骤
- 概括待表达的信息，清理需求点
- 信息排序，需求点按照一定规则进行分类
- 界面语言翻译，画交互。
案例
做一个新闻资讯客户端的官网
- 概括信息，列举需求
- 内容：形态包括文章，视频，突击
- 频道：推荐，财经，娱乐。。。
- 功能入口：登录，下载app，查看详情
- 运营位：编辑推荐，广告
- 界面形式突出视频及图片
- 排序，需求分类
- 频道：推荐，财经，娱乐…
- 内容：形态包括文章，视频，突击
- 功能入口：登录，下载app，查看详情
- 运营位：编辑推荐，广告
- 突出图
- 界面表达
画出原型图，如图所示：
案例
某直播工具产品
定位：只给有直播权限的用户用于直播
基本功能：登录，选择节目发起直播（节目在后台已配置好）
补充信息：由于每个节目一个单独的直播流，所以若未终止直播，这个节目还可以进去续播（既意外断开或误操作等情况均可续播）
需求：
有场景用户需要临时发起直播，为这个功能设计交互流程
- 概括信息，列举需求
- 用户可以选择节目发起直播
- 用户可以临时发起直播
- 选择节目发起直播需要查看节目列表
- 临时发起直播需要配置基本信息
- 意外退出后登陆还可以续播
- 排序
- 用户可以选择节目发起直播？用户还可以发起临时直播
- 选择节目发起直播需要产看节目列表？
- 临时发起直播需要配置基本信息？
- 意外退出后登录还可以续播？
- 重新梳理用户流程，完成设计
- 用户登录后，主要操作发起直播，次要操作修改信息；查询记录
- 发起直播会遇到两种选择
- 根据不同选择走不同流程
虽然设计之后流程增加的步骤，但是产品体验性更好
总结
- 交互设计的过程需要对用户需求进行充分的了解
- 信息的展示与流程的设置必须遵循基本的原则
4.2 交互
- 在大公司会有专业UI我们需要做的：
- 写交互需求，包含需求背景的描述，需求目标的描述，需求点的列举，或低保真原型图
- 与交互设计师面对面沟通
- 及时督促交互稿完成
- 确认交互稿
- 在小公司需要做的：
- 需求分析
- 需求点分类
- 界面输出
- 根据需求大小选择不同输出方式
- 与leader沟通
- 产品经理的交互图：
- 重点是表述你需要啥功能及其优先级
- 美观需求次之
- 简单快捷的方式输出（手工，PS，画板均可）
- 各个端交互差异
| 区别 | PC端 | 移动端 |
|---|---|---|
| 页面结构的差异 | PC端在页面横向信息量比较大;PC端纵向页面层次信息比较深;PC端可以在新标签打开 | 移动端遵循少即是多原则，剔除不必要的元素，页面层次不要太深 |
| 操作方式不同 | 鼠标键盘，输入更容易，操作更便捷； | 手指输入需要减少输入，降低输入难度；有更多便捷的输入方式（语音）；不要轻易打断用户任务（不好返回首页） |
| 应用场景不同 | 固定场景，适合重度使用产品 | 碎片化事件，产品体验要更轻；更关注网络状态及流量使用 |
总结
- 交互知识是产品经理的必备技能
- 不追求技巧，把握方向
5 原型与需求文档
5.1 原型
- 什么是原型
原型是交互设计师与PD,PM,网站开发工程师沟通的最好工具。而该块的设计在原则上必须是交互设计师的产物，交互设计师以用户为中心的理念会贯穿整个产品。利用交互设计师专业的眼光与经验直接导致该产品的可用性。 - 原型的本质
- 原型的本质是工具
- 工具的本质是用于完成工作提高效率
- 原型的分类
- 高保真VS低保真
- 低保真：利用线框图，把信息的组织架构通过图形的模式展示。
- 高保真：利用高功能性，高互动性完整的把用户的操作流程表现出来
- 纵向原型设计VS横向原型设计
- 纵向：能通过点击交互到更深的层次
- 横向：以切面的形式展现页面跳转
- 部分特殊需求，如对体验效果特别看重，或功能及其复杂需要拟定较好的高保真demo一遍技术实现后的对比
- 高保真VS低保真
- 原型的工具
- Axure
- 墨刀
- sketch
- Mockplus
- 原型的方法
- 分析需求
- 了解功能分布
- 明确页面层级
- 绘制基本原型
- 操作校验原型
5.2 原型案例
- 直播
- 案例背景：主播在直播过程中，有以下几种情况会推出直播
- 不方便，需要关闭画面（如补妆）
- 主动退出，直播结束
- 意外退出（网络中断）
- 结束后的功能
- 生成回顾，完成直播地址的使用
- 继续留在原地址直播
- 用户需求
- 在需要时不结束直播，仅暂停直播画面
- 意外状态下，能尽快重新连接直播地址
- 生成直播回顾
- 功能
- 画面中止
- 直播流终止
- 回顾视频生成
页面层级
- 第一层级：直播过程的界面
- 第二层级：直播结束的界面
- 第三层级：重新连接直播的界面
下面是两个原型，比较两个原型不难发现
- 是否退出尽量只有是和否
- 返回列表之前放的位置太过隐蔽
- 分享应该是下一层级做的事情，如果在这一层级不明确是分享正在直播的地址，还是分享我结束直播后的视频
- 提示可以让更多用户生成回顾
总结
- 原型是一个提高产品设计工作效率的工具
- 不同的需求使用不同要求的原型
5.3 需求文档
PRD 重点描述一个新产品或现有产品改进的需求
- 核心：侧重的是对产品功能和性能等特性（即“产品需求”）的说明
- 作用：
- 指导开发
- 测试依据
- 后续存档
- 目标：
- 准确的描述需求，使得产品最终形态与预期温和
- 能够有效协助产品干系人（视觉，交互，页面，开发，测试）完成与预期吻合的产品
需求文档的结构
5.3 需求文档步骤
- 想需求
- 列特性
- 写初稿
- 补细节
- 想需求
- 不着急下笔，先想清楚需求
- 每份需求文档都是一个文字版的解决方案
- 想的内容：
- 项目核心需求是什么？
- 解决用户的什么问题？
- 主要功能逻辑有什么？
- 回顾产品设计阶段的输出物
- 产品结构图
- 流程图
- 特性列表
- 列特性
- 理解需求后，列出解决方案中应包含的全部特性
- 特性点几个方面
- 功能特性
- 界面特性
- 性能要求
- 数据上报
- 写初稿
根据上面的需求文档的结构图来写需求文档- 需求背景及目标
- 需求背景作用
- 方便参与者了解需求
- 方便后续存档查阅
- 需求目标作用
- 写需求前再次审核需求
- 需求完成后校验需求
- 需求背景作用
- 需求背景及目标
- 列特性列表
- 根据需求拆分特性点
- 拆分标准
- 按照内部逻辑（按照不同的功能模块，不同的页面进行拆分）
- 重要的部分单列特性
- 特性列表作用
- 明确需求模块
- 方便参与者理解需求并开发需求
- 主要逻辑
- 逻辑图灵活使用
- 复杂特性，流程图梳理逻辑
- 简单特性可以用文字描述
- 常用工具
- Visio
- Edraw
- 逻辑图的作用
- 帮助梳理需求逻辑
- 减少细节遗漏
- 逻辑图灵活使用
- 特性功能点
- 描述特性功能
- 流程细节描述
- 正常逻辑，异常逻辑
- 文案内容，性能需求（如发起操作后3S内有反馈）
- 交互图
- 特性功能描述的作用
- 开发测试最关键的依据
- 描述特性功能
性能需求
产品性能，实际上指的是产品的功能和质量两个方面
在进行功能的需求撰写时，也需要关注产品本身的质量，如打开速度，崩溃率，并发能力，负载能力等- 错误：这个应用跑得太慢，你能让他快起来吗？
- 正确：系统内90%的业务操作必须在5秒内得到响应，系统必须支持100个并发用户
数据需求
产品需求在完成时，都应该为最终的检验做好数据采集的工作
标准为：- 能验证本次任务目标的核心数据指标。
- 本次迭代中新增的主要功能的核心指标。
- 案例：需求的核心目标为提高用户留存率
- 统计存留率，对比上线前后数值
- 案例：本次更新的内容为金币商城，包含金币发放，兑换，商城物品展示，信息填写等功能
- 统计每日金币发放总量，用户量；兑换消耗金币量，用户量，兑换次数，不同物品兑换次数，按日统计
- 补细节
- 重读需求文档，补充未尽的细节
- 用挑剔的眼光看文档
- 检查需求描述，是否有歧义
- 检查用户场景是否全部覆盖到（主要看异常逻辑是否被覆盖）
- 假设自己是开发，能否用文档写出代码
5.4 好的需求文档
好的需求文档：
- 能正确满足产品需求，逻辑清晰
- 所有需求及场景都应给出具体的解决方案描述
- 需求描述无歧义，易读
- 每个特性都有优先级
- 需求可验证
- 不给出无法验证的描述；需求可追踪
案例
- 用户登录（完备性）
- 示例：
- 非会员用户，点击登陆后提示，不可使用
- 会员用户，登陆后正常给出操作界面
- 存在问题：
- 非会员提示语是什么？
- 会员登录是否会失败？
- 失败场景有哪些？对应操作是什么？
- 会员登录后，是否有其他应给出的提示？
- 示例：
- 拖拽上传（无歧义）
- 示例：
- 用户拖拽上传
- 存在问题：
- 只能拖拽上传单个文件？
- 用户拖拽到哪里？
- 改正后：
- 用户拖拽文件or文件夹移动到QQ网盘主界面文件展示区（不包含功能操作区）空白处时，则自动将该文件or文件夹添加到上传列表中。
- 示例：
提示用户登录超时（可验证）
- 示例：
- 用户长时间登录不成功时，提示登录失败
- 存在问题：
- 长时间是多久
- 改正后：
- 用户在N秒内登录不成功时，提示登录失败。N请开发建议时长。
总结
- 需求文档时产品方案的进一步完善
- 需求文档及原型成为产品设计中最核心的一个过程
- 示例：
5.5 案例分析
- 需求背景及目标
- 背景：
- 参考会说话的tom猫，做一个会说话的X小狗
- 目标
- 流畅用户体验
- 实现基本互动玩法
- 第一版
- 存在问题
- 仅描述了过程，但不是真正的流程
- 相关角色无法根据需求准确实现
- 改进思路
- 想：需求给谁看？需求目标是什么？
- 列：主要特性有哪些？用户主要操作及反馈是啥？
- 写：启动逻辑图
- 补：根据逻辑图补充细节描述
- 修改后：
- 总结：
- 需求往往很简单
- 准确的表述需求并不简单
- 思考关键用户流程，设计合理信息流转路径
- 文档的细节是否完善，直接影响产品设计工作的后续进程
- 什么时候需要些需求文档
- 外包型项目：由于产品开发团队使用团队分离，为了更好地确保交付后没有疑义所有内容最好用文档形式保存
- 复杂的产品：逻辑功能复杂业务参与方式较多均建议使用文档形式展示需求
- 什么时候不需要需求文档
- 一句话需求（但也需要存档）
- 简单逻辑需求且公司有敏捷项目管理系统
- 背景：
6 产品研发过程管理
6.1 项目管理及研发流程
项目管理是管理学的一个分支学科，对项目管理的定义是：指在项目活动中运用专门的知识，技能，工具和方法，是项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。
开发模式
- 瀑布开发
- 概念：最典型的预见性的方法，严格遵循预先计划的需求分析，设计，编码，集成，测试，维护的步骤顺序进行
- 常见：外包项目
- 迭代开发（每个版本都有预期）
- 概念：是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率
- 常见：互联网项目（微信需要迭代）
- 螺旋开发
- 概念：瀑布模块和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小，当项目被定义得更好，更稳定时，逐渐开展。
- 常见：火箭的研制
- 敏捷开发
- 概念：是一种从1990年开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力
- 常见：互联网开发（先抢占市场）
- 常见开发模式对比
- 瀑布，迭代，螺旋开发都是一种软件开发的生命周期模型
- 敏捷开发是多种软件开发项目管理方法的集合
- 敏捷开发是一种防范，迭代开发是一种开发模型
敏捷开发
- 互联网项目多以敏捷开发为主。
- 敏捷开发的核心理念就是以简单有效的方式快速达成目标，并在这个过程中及时的响应外界的变化，做出迅速的调整。
- 适合小团队，技术产品磨合较好的团队
- 可以去文档，但要有存根
6.2 产品开发全流程管理
项目主流程图
需求准备
- 需求分析
- 个人完成前期的分析初步的结论
- 需求讨论
- 小团队协助需求解决方案的PK及优化建议，是个人完成方案的优化及确认
- 交互讨论
- 交互协助或产品个人输出形成初步原型
- 需求评审
- 多角色参与需求的最终确认
- 需求分析
需求评审会
需求评审会是由产品经理介绍相应的产品功能背景以及初步的设计方案（交互稿），由大家针对现有的方案进行PK，直至讨论出统一的结果的过程。
开会目标- 明确项目目标
- 让大家都能初步了解方案的核心
- 通过会议讨论让大家对方案达到基本认可
会议要点
- 求同存异：不要驶入把观点植入到其他人的脑中（只要大家主要方向一致，不要在意细节）
- 放过细节：不纠结在细节中，学会妥协会后跟进（前端或者后端实现的问题不要再会上深入讨论）
- 人人参与：保证与会着都明确目标及方案
- 把握时间：控制会议时长提高效率（最好控制在1小时内，2小时会议可以拆分两次）
- 评审会内容
- 参与方：设计，后端，前端，运营
- 介绍背景：评审方案细节
- 目标：要做到什么程度
- 规划时间
- 怎么做：技术分工要讨论
- 为什么：讨论得最终方案
- 评审会黄金72小时
- 提前3天确定哪个版本，哪些人，在哪开会
- 提前2天发交互原型，需求文档
- 提前1天收集对评审问题并初步解答
- 会议控制
- 总分总的方式进行解说
- 时刻铭记目标
- 从特性列表到原型再到交互
- 细节解纷时及时跳出回归问题本质
- 部分不重要细节会后再定
- 结束前将重点问题再次确认
- 会议总结
- 及时输出会议纪要
- 待跟进讨论问题明确到责任人
- 督促各岗位人员给出时间评估
- 最终将优化后的文档及原型同步给大家
8.测试用例评审会 - 测试用例：示例
- 测试用例评审会意义：细化需求点，异常逻辑
- 没有测试用例怎么办： 需求文档尽可能完善
- 开发阶段
- 督促进度：确保发布时间，灵活使用站立晨会或日报
- 解决问题，确保产品与预期一致：讨论的结论及时同步测试
- 体验与测试
- 谁，什么时候体验：产品，功能实现了
- 谁，什么时候测试：测试，技术提测了
- 体验目标： 保障功能与预期一致
- 测试目标： 保障可用性
- 发布准备
- 产品层面
- 测试结果验收
- 客服手册
- 运营层面
- 发布渠道准备
- 用户通知
- 推广运营策略制定
- 产品层面
- 产品验收
- 验收的目的
- 确保产品的基本功能与需求一致
- 确保产品能顺利发布
- 谁来验收？
- 不同的公司流程会有不同的验收人
- 常见责任人，对应的产品经理
- 严格要求质量的项目，有专门的验收会
- 验收标准
- 可用性：是否与需求要求一致，用户可顺利完成操作
- 易用性：交互设计手否能否提高用户的使用率
- 验收方法
- 对比需求文档或测试用例进行操作
- 实际工作中，产品经理验收
- 产品经理不是bug发现者
- 测试与设计共同协助完成验收
- 验收的目的
- 客服手册
- 使用者：一切有可能需直接解答用户使用疑问的角色，如运营，客服
- 主要内容：产品基本情况，本次更新功能介绍，使用操作指南，可能的问题及统一答复
- 常用渠道
- 苹果应用商店
- 安卓：应用宝，360，百度，华为，小米 。。。
- 产品经理的渠道相关工作
- 渠道包管理，渠道包验证
- 渠道介绍文案，图片
- 关注渠道下载量，关注渠道评论，渠道引流效果评估
- 用户通知
- 那些需要发布用户通知
- 影响基础服务的需要发布
- 影响用户操作的需要发布
- 如何发用户通知（需要提前发）
- 弹窗
- 小黄条通知
- 那些需要发布用户通知
运营推广
- 判定本次发布内容的重要程度
- 战略性发布：大范围推广，目标新老用户
- 功能性优化：老用户重点推广
- 小优化：简单告知
- 需要产品经理做什么
- 准备运营需要的设计图
- 提前申请广告位
- 与运营同事沟通外部渠道
- 内部渠道确认，用户群，合作产品入口，用户通知系统
- 运营预期管理
- 判定本次发布内容的重要程度
发布留守
- 在产品发布时，产品经理，技术，客服等相关岗位均需至少留守一小时
- 确保服务稳定
- 观察用户使用情况，及时作出反应
- 协助解答可能引起的客服诉讼
- 一般情况发布时间会选择下班前1-2小时
- 回滚
- 什么情况需要回滚
- 新功能不能正常使用
- 新功能的发布引起其他关键功能不能使用
- Bug修复时间不可预期
- 用户投诉极其强烈
- 什么情况需要回滚
- 避免回滚
- 预期管理,预测到可能的影响面，是否可以承受
- 测试完整，功能测试及性能测试尽可能完善
- 技术实现方案尽可能不要耦合
- 汇报
- 项目需要，任何事都要有始有终
- 领导需要安全感
- 团队需要鼓励
- 检验目标，是否达成基本预期
- 存在感
- 组织影响力
- 汇报内容
- 过程总结：是否如期完成，是否顺利，时间评估是否准确等
- 结果总结：是否达成预期
- 资源使用情况总结：技术，设计，运营资源
- 数据总结： 用户量，使用量，收入，成本
- 效果总结：用户反馈，市场反馈
- 上线邮件
- 告知：什么？多长时间？做了什么？
- 感谢：相关领导，技术，设计，测试等同事
- 总结：基本情况小结
- 跟进：告知后续跟进计划
- 数据汇报
- 汇报时间：3天，7天，第一个月
- 汇报方式：邮件
- 汇报内容：基本数据表现，与预期是否一致，数据波动原因，可以继续提高数据的运营措施。
- 筛选反馈
- 已知BUG问题：用心回复
- 已知需求问题：评估优先级，是否需要提高
- 未知BUG问题：立刻联系用户或重现，改进
- 未知需求问题：需求分析
- 反馈跟进
- 普通用户个别问题，若不重要暂时不规划，若与原规划一致，则自然解决
- 普通用户普遍问题，需认真评估优先级，资源限制导致无法完成可向上及时求助
- 特殊用户个人问题，区分需求或bug；需求，区分其真实诉求；bug，建议尽快修改
- 特殊用户普遍问题，需求，尽可能完成，bug，立刻修改。
- 特殊用户是要么影响你的资源，要么影响你的口碑，只要不是完无理的要求，我们需用积极的态度去服务特殊用户
7 风险及沟通管理
7.1 风险管理
风险管理是指如何在项目或者企业一个肯定有风险的环境里把风险可能造成的不良影响减至最低的管理过程
风险不能被预防，但我们也要朝着绝对避免发生而努力
意义：完成既定目标
- 风险识别
- 风险评估
- 风险评价
- 风险管理
案例:
- 场景：某公司，产品经理在老板授意下开始启动X项目，简单沟通未经评审就开始技术投入。技术团队共计投入2年经验后台人员一个，3个月经验毕业生前段一个。预计7日完成项目。暂无完整测试人力投入，待项目完成后视其他项目进行而定测试。
- 风险识别：
- 方案论证不够
- 目标不明确
- 老板需求随时变更
- 前端技术能力风险
- 版本发布质量问题
- 风险评估：
- 方案论证不够
- 由于未评审，该风险较大
- 目标不明确
- 由于未评审，该风险较大
- 老板需求随时变更
- 根据老板性格判断
- 前端技术能力风险
- 看方案，看个人能力，有可能有风险
- 版本发布质量问题
- 看方案复杂程度，有可能有风险
- 方案论证不够
- 风险管理：
- 方案论证不够
- 深刻理解需求并组织评审会
- 目标不明确
- 目标以邮件方式分别与老板及团队确认
- 老板需求随时变更
- 方案拟定后与老板再沟通，邮件确认基本目标
- 前端技术能力风险
- 及时报备技术领导监控过程
- 版本发布质量问题
- 调配测试到位以保证版本发布质量
- 方案论证不够
7.2 风险管理方法
- 预期管理
- 合理的背景分析
- 理性的市场预估
- 风险提前预判
- 获得领导确认
- 案例：领导预期过高怎么办
- 判断领导预期的真实性
- 多问，尝试换角度去问
- 资源分析
- 让领导意识到资源不够
- 过程风险管理
- 合理工作评估量
- 项目节点
- 需求优先级
- 减少不重要需求
- 案例：要发生需求变更怎么沟通？
- 明确原因？技术的，市场的,老板的，产品的
- 技术：积极减少不必要的需求
- 市场：反馈上级，获得支持后积极调整
- 老板：明确必要性，适度调整
- 产品：自我检讨，保障项目顺利进行
- 风险发生后管理
- 根据情况适当调整发布时间
- 及时与关键岗位沟通（老板，运营，运维）
- 及时复盘总结
案例
- 背景：自研开发周期长，外部产品已有现成功能约定指定时间完成，结果对方需求理解有误。不能如期完成。
- 调整：重新明确需求，与领导沟通，与对方沟通。
- 教训：
- 合作项目，做什么一定要明确，文档化。
- 外包项目前期沟通要仔细。
7.3 沟通技巧
- 沟通的目的
- 说明事物
- 表达情感
- 建立关系
- 进行企图
沟通工具
- 文件（需要存档的内容）
- 审批内容
- 评审内容
- 评审结论
- 需求定稿
- 聊天工具（不紧急阶段性内容）
- 聊天讨论
- 资料传输
- 咨询
- 破冰
- 电话（紧急沟通内容）
- 急需决策
- 紧急故障
- 就等不回
- 距离远说不清
- 面谈（复杂内容）
- 文字表达难
- 重要事件
- 距离很近
- 拉近关系
- 文件（需要存档的内容）
各个阶段沟通重点
- 需求阶段
- 明确需求目标
- 明确时间点，里程碑
- 明确产品方向
- 开发阶段
- 明确每日进展
- 明确开发难度
- 减少需求变更
- 多体验保证需求预期
- 发布阶段
- 运营支持沟通
- 数据反馈沟通
- 用户沟通
- 需求阶段
不同角色沟通
- 领导
- 问题：
- 领导一般会说把那个功能进度加快，
- 做一个XX产品，照着XX那样就行。
- XXX老板反映说我们产品他用了几分钟就崩溃了你查一下
- 解决：
- 多问+你的理解+确认
- 凡是有交代，件件有着落，事事有回音
- 定期主动汇报，邮件，面谈，信息
技术
- 问题
- 技术A:性格好，技术一般，从不挑剔需求，勤勤恳恳
- 技术B：火爆男，技术牛，怼你没商量
- 技术C：墨迹哥，任何细节都和你确认，不确认不开发
- 技术D：自认产品感一流，自信满满做需求。
- 解决
- 对技术A：
- 对技术B：对我们帮助最大，多多虚心交流请求
- 对技术C：把需求文档写仔细，减少他耽误我们时间
- 对技术D：
- 问题：
- 测试
- 问题
- 测试人员普遍性质，思维严密，谨慎，一般不多言
- 解决
- 邀请测试人员参加需求评审会
- 及时向测试人员同步需求
- 问题
- 设计师
- 问题
- 这个配色多好看啊，你审美有问题吧，我改不了
- 我不觉得这个按钮小呀，那么大，而且我们老大都通过了
- 解决：
- 尊重
- 引导，控制
- 问题
- 运营
- 问题（和运营的合作关系是双向的）
- 他给你提需求，但是经常被说需求不靠谱
- 给他提需求，但是可能做的结果不够好
- 解决：
- 共同的目标
- 方案把关,保持沟通
- 成果共享
- 问题（和运营的合作关系是双向的）
- 合作需求方
- 问题：
- 他们可能是任何部门的同事
- 也可能是外部公司的需求方执行者
- 会占用你的资源或是需要你对结果负责
- 解决：
- 明确需求及目标
- 沟通结果要记录
- 预期管理
- 问题：
- 下级沟通
- 问题
- 可能是毕业生一无所知
- 可能是老油条深谙职场心机
- 更可能是在专业和管理都不如你的一个普通员工
- 解决
- 信息尽可能对称
- 帮助总结，监督进度
- 对事不对人
- 表扬在人前，批评在人后
- 问题
- 领导
- 建立有效的沟通机制
- 定期沟通机制
- 会议：例会，评审会，头脑风暴会，资源协调会
- 日报/周报/月报
- 邮件：上线汇报，数据反馈，会议纪要，活动分析等
- 非正式沟通
- 小范围聚餐
- 午餐时间聊天
- 定期沟通机制
- 团队磨合上要注意
- 尽可能统一判断的标准（如一切以用户价值为依据）
- 不要试图说服，而是找到中和点
- 充分理解没每个角色的内心真实想法
7.3 产品经理和项目经理
| 主要工作 | 工作背景 | 主要负责 | 目标 | 角色 | |
|---|---|---|---|---|---|
| 产品经理 | 想 | 复合人才 | 规划 | 结果 | 产品的爸爸 |
| 项目经理 | 做 | 技术背景 | 实现 | 过程 | 产品的保姆 |
产品经理与项目经理如何合作
- 产品对实现细节负责
- 项目对实现过程负责
- 提前沟通提前规划
- 明确目标合理妥协
最后更新： 2019年01月20日 18:53
