专栏名称: 人人都是产品经理
产品经理不再是一个单纯的职位,而是一种思维方式,这种思维是所有互联网人必备的,做互联网的人不能不懂产品,关注产品,改变生活。
目录
相关文章推荐
三节课  ·  还没做小红书的,有福了! ·  1 周前  
人人都是产品经理  ·  服务号悄悄 “变脸” ·  3 天前  
人人都是产品经理  ·  转岗产品经理,涨薪40%,我是如何成功实现职 ... ·  4 天前  
人人都是产品经理  ·  先用后付,专坑用户? ·  5 天前  
51好读  ›  专栏  ›  人人都是产品经理

产品汪,你的产品为什么总是延期?

人人都是产品经理  · 公众号  · 产品  · 2016-10-30 21:41

正文

如果问一个产品经理,你最头痛的事情是什么?估计十有八九会听到产品/项目延期这个答案。

项目延期,意味着产品没有如期投入市场,意味着要开始加班加点赶进度,意味着可能加班加点赶出来的产品存在大大小小的BUG,你原先设想的XX功能,XX体验没办法实现,你的KPI可能会有危险,你的年终奖可能泡汤。。。

为什么会延期呢?除掉人力资源和开发资源等一些我们无法改变的客观原因之外,我觉得重点要关注以下几个问题:

01 前期需求讨论,UI评审时间过长,压缩了后续开发时间

有的时候我们会陷入对某个需求细节、UI细节的反复讨论。特别是在UI评审的时候,对于设计大家都有各自审美观,有的人喜欢留白,有的人喜欢紧凑一点,有的人觉得页面丰富一点好,有的人觉得简洁干净一点好。众说纷纭,好不容易确定下来了,时间也没有了。留给开发的时间自然就变少了,但是工作量可一点都没变。开发们也是人,再怎么加班加点也不可避免出现延期和代码质量下降的问题。

面对这个问题,产品或者设计师应该要:

首先,提高自己的专业度

这是你的领域,你要展现你的专业说服他人,而不是被老板或者其他人带着走。你要有自己清晰的认识,为什么这样做?为什么不那样做?这样做的目的是什么?你的依据是什么?准备多套方案,说明你个人最推荐的方案是什么?次推荐的方案是什么?最不推荐的方案是什么?一定要有理有据,如果有数据支持,就展示你的数据!

其次,要有严格的截止时间点

任何的讨论如果没有时间限制,那就不会有结果。你组织评审或讨论的时候,明确地告诉大家我们一定要在某个时间点达成一致,如果没有达成一致,那就使用我的推荐方案;

第三,明确重点,不要在细节上过多纠结

有的功能或者设计点,并不是最重要的,对用户影响比较小,我们就不要在这个上面浪费时间。集中力量放在重点流程和核心页面上。有些时候,你留白多少,用户其实并没有感知。那为什么我们要在这样的事情上去纠结呢?我一直认为在这些问题上,只要不影响用户对产品的使用流程,不会让用户在使用过程中产生歧义或者误解,没有必要去纠结。如果你的老板一定要这样改,那就改。我们的焦点应该始终放在产品的核心流程上。

02 实际开发过程中前松后紧

这个问题在实际工作中也经常碰到。在开发周期的评估时候,节奏安排不当。前面慢悠悠,后面发现哇靠时间没有了,拼命赶进度。

为什么会这样呢?我不是技术出身,但是开发同学交流下来,感觉有两个原因:一是对风险点评估不充分,二是开发人员埋头只关注自己的任务,没有考虑相关模块的开发时间。

对风险点评估不充分,这个和需求理解程度,个人能力都有关系。没有充分理解需求或个人经验能力没有达到一定程度,是不会或者很难预见风险点的。

我的建议是开发在评估开发周期的时候,可以:

将需求拆解成细化的用例

就是开发完成这一个需求,需要涉及到哪些开发工作,需要涉及哪些后端接口,需要涉及到哪些模块联调,需要测试如何测试等等。拆解成这样的用例,既可以把开发周期更细化,也可以发现一些风险点;

各自评估,集中讨论

将需求拆解成用例或故事要点之后,开发同学可以按照各自情况提出自己的预计时间。如果同一个功能,A的工期是1个工作日,而B可能觉得要5个工作日,两者之间相差较大。那这时候就要进行讨论,为什么会这样?是否有风险点没有发现?还是谁的技术方法有问题?这样一来,大家都可以了解彼此的想法,互相弥补自身的思考盲点;

03 需求变更

需求变更,不仅对于程序员来说是一种痛苦,对于产品经理来说也是。我们都希望需求确定之后不要再变更,但是现实总是很骨感。毕竟市场和需求可能是变动,毕竟前期调研再充分也可能存在误区,现在变更总比开发完成之后再改来的好。

但是变更需求极有可能影响原定的计划,我们又该怎么办呢?

第一,冷静地判断变更需求的优先级

这和我们评估需求优先级一样,不重要不影响用户使用的就延期安排;重要的自然往前排。这点就不赘述了;

第二,寻找合适的解决方案

和开发同学充分讨论,实现新需求的方法有哪些?找到能解决问题同时时间成本最小的方案,尽量将延期影响压到最低;

04 只关注自己的任务

这其实是很要命的一点。只关注自己的任务,忽视了上下游相关业务模块的联系。吭哧吭哧开发完了,发现和XX模块对接不上啊!这个接口设计前端用起来很麻烦啊!于是乎,我们又一起重新写一遍。延期的红色警报又要响起来了。

解决这个问题,我们可以试试:

阅读需求文档时,请不要只看自己负责的模块,把所有需求都过一遍,理解需求的上下逻辑关系;提前和相应的同事沟通技术方案。这一点全靠自觉,毕竟不这样做最后返工的肯定有自己。

开发负责人可以在正式开发之前组织大家集中花一个时间段,把需求疑难点,需要彼此配合的拿出来讨论。磨刀不误砍柴工,这会让大家后面工作的更有效率。

每天站立会议沟通开发进度,就说自己做到哪里了,有发现什么风险,需要哪些同事或者模块来配合?也不要发什么日报,就是每天面对面沟通一下,这个比什么效率都高。日报只是起一个总结和汇报的作用,冷冰冰的几句文字比不上同事之间面对面的交流。这点对小团队来说特别重要,就那么几个人你还非要搞那么多流程,何必呢?

作者介绍

肥寒,微信公众号:chanpingdog,人人都是产品经理专栏作家。九年产品经理。做过数字阅读,电商,社区,目前致力于在线教育。

本文原创发布于人人都是产品经理。未经许可,禁止转载。


↓↓↓ 点击"阅读原文" 下载APP