产品汪,你的产品为什么总是延期？.pdfVIP

产品汪 ，你的产品为什么总是延期 ？ 如果问一个产品经理 ，你最头痛的事情是什么 ？估计十有八 会听到产品/项目延期这个答案 。 项目延期 ，意味着产品没有如期投入市场 ，意味着要开始加班加点赶进度 ，意味着可能加班加点赶 出来的产品存在大大小小的BUG ，你原先设想的XX功能 ，XX体验没办法实现 ，你的KPI可能会有 危险 ，你的年终奖可能泡汤。。。 为什么会延期呢 ？除掉人力资源和开发资源等一些我们无法改变的客观原因之外 ，我觉得重点要关 注以下几个问题 ： 1）前期需求讨论 ，UI评审时间过长 ，压缩了后续开发时间 有的时候我们会陷入对某个需求细节、UI细节的反复讨论。特别是在UI评审的时候 ，对于设计大家 都有各自审美观 ，有的人喜欢留白 ，有的人喜欢紧凑一点 ，有的人觉得页面丰富一点好 ，有的人觉 得简洁干净一点好。众说纷纭 ，好不容易确定下来了 ，时间也没有了。留给开发的时间自然就变 少了 ，但是工作量可一点都没变。开发们也是人 ，再怎么加班加点也不可避免出现延期和代码质量 下降的问题。 面对这个问题 ，产品或者设计师应该要 ： 首先 ，提高自己的专业度。这是你的领域 ，你要展现你的专业说服他人 ，而不是被老板或者其他人 带着走。你要有自己清晰的认识 ，为什么这样做 ？为什么不那样做 ？这样做的目的是什么 ？你的依 据是什么 ？准备多套方案 ，说明你个人最推荐的方案是什么 ？次推荐的方案是什么 ？最不推荐的方 案是什么 ？一定要有理有据 ，如果有数据支持 ，就展示你的数据 ！ 其次 ，要有严格的截止时间点。任何的讨论如果没有时间限制 ，那就不会有结果。你组织评审或讨 论的时候 ，明确地告诉大家我们一定要在某个时间点达成一致 ，如果没有达成一致 ，那就使用我的 推荐方案 ； 第三 ，明确重点 ，不要在细节上过多纠结。有的功能或者设计点 ，并不是最重要的 ，对用户影响比 较小 ，我们就不要在这个上面浪费时间。集中力量放在重点流程和核心页面上。有些时候 ，你留白 多少 ，用户其实并没有感知。那为什么我们要在这样的事情上去纠结呢 ？我一直认为在这些问题上 ，只要不影响用户对产品的使用流程 ，不会让用户在使用过程中产生歧义或者误解 ，没有必要去 纠结。如果你的老板一定要这样改 ，那就改。我们的焦点应该始终放在产品的核心流程上。 2 ）实际开发过程中前松后紧 这个问题在实际工作中也经常碰到。在开发周期的评估时候 ，节奏安排不当。前面慢悠悠 ，后面发 现哇靠时间没有了 ，拼命赶进度。 为什么会这样呢 ？我不是技术出身 ，但是开发同学交流下来 ，感觉有两个原因 ：一是对风险点评估 不充分 ，二是开发人员埋头只关注自己的任务 ，没有考虑相关模块的开发时间。 对风险点评估不充分 ，这个和需求理解程度 ，个人能力都有关系。没有充分理解需求或个人经验能 力没有达到一定程度 ，是不会或者很难预见风险点的。我的建议是开发在评估开发周期的时候 ， 可以 ： 将需求拆解成细化的用例。就是开发完成这一个需求 ，需要涉及到哪些开发工作 ，需要涉及哪些后 端接口 ，需要涉及到哪些模块联调 ，需要测试如何测试等等。拆解成这样的用例 ，既可以把开发周 期更细化 ，也可以发现一些风险点 ； 各自评估 ，集中讨论。将需求拆解成用例或故事要点之后 ，开发同学可以按照各自情况提出自己的 预计时间。如果同一个功能 ，A的工期是1个工作日 ，而B可能觉得要5个工作日 ，两者之间相差较大 。那这时候就要进行讨论 ，为什么会这样 ？是否有风险点没有发现 ？还是谁的技术方法有问题 ？这 样一来 ，大家都可以了解彼此的想法 ，互相弥补自身的思考盲点 ； 3 ）需求变更 需求变更 ，不仅对于程序员来说是一种痛苦 ，对于产品经理来说也是。我们都希望需求确定之后不 要再变更 ，但是现实总是很骨感。毕竟市场和需求可能是变动 ，毕竟前期调研再充分也可能存在 误区 ，现在变更总比开发完成之后再改来的好。 但是变更需求极有可能影响原定的计划 ，我们又该怎么办呢 ？ 第一 ，冷静地判断变更需求的优先级。这和我们评估需求优先级一样 ，不重要不影响用户使用的就 延期安排 ；重要的自然往前排。这点就不赘述了 ； 第二 ，寻找合适的解决方案 ；和开发同学充分讨论 ，实现新需求的方法有哪些 ？找到能解决问题同 时时间成本最小的方案 ，尽量将延期影响压到最低 ； 4 ）只关 自己的任务 ， 这其实是很要命的一点。只关注自己的任务 ，忽视了上下游相关业务模块的联系。吭哧吭哧开发 完了 ，发现和XX模块对接不上啊 ！这个接口设计前端用起来很麻烦啊 ！于是乎 ，我们又一起重新写 一遍