产品为什么延期

产品延期听起来是个挺悲伤的事情,可是对于那些走错了方向的产品来说还是会有收获的,但是对于正计划快速迭代的团队来说来挺糟糕的,这种糟糕不是产品本身没有发布出去,而是延期变成了一种习惯,习惯到在做这个产品的人自己都没有发觉,也无能为力。大部分正常的延期并不是一个人造成的,这里所谓的“正常”是指,产品事先进行了充分的准备、做好了大量计划,并使用了科学的工具和迭代方法,每个人都是干劲十足的,结果产品延期了。看起来像是每个事先做的计划,每个人在其中所做的所有事情才是根本原因。

很多人做产品前喜欢脑暴,提多很多想法,然后最终层层筛选,然后开始实施,看似毫无问题,其实这个时候做这个产品的每个人身上都是有隐形包袱的,有的包袱在于工程师的某种技术癖好,比如虽然开发经验不是特别丰富但是却又过度设计(当然自己是不这么觉得的)的欲望,喜欢造轮子又造得没有开源的轮子好(很难自己发觉);还有的包袱是做产品的会经常在过程中不断优化,甚至推倒重来,这个虽然是合理的并且无法避免的。说这些是包袱是因为这些是很合理的存在,并且很多人会经历这个过程。

其次是,我们习惯于看到有产品计划是觉得安心,习惯于每天与团队成员开会就觉得进展得不错。其实有计划只是很基本的步骤,对计划进行合理巧妙地统筹规划才是更重要的事情,但是这一步太难了,因为这意味这产品和工程两条线的要对哪个人在什么时候完成什么需要多少时间进行规划,如果硬去做这件事当然是毫无意义的,最理想的办法其实很简单,团队里的每个人都需要理解当前迭代甚至更长的迭代时间里目标是什么,如何去完成,举个栗子:比如原计划一周之内完成一个首页,这时候包括前后端、产品等在内的所有人要知道这个首页需要什么数据,这些数据哪里来,要怎么放到首页上去,怎么交互等等。知道了更多细节你就知道如果一个后端同学不在当天提供好数据给前端,就会让前端停滞一天,导致整个产品延期一天。同样,产品需要知道一些前端在处理浏览器兼容、性能的时候投入产出比要怎么计算,才知道产品的一些细节改如何取舍,知道一些基本的 popup、bubble 是如何交互的才不会开发完后再来返工。一句话就是你如果对别人多了解一点,以为着你的影响力大一点,而你需要顾忌的也会少一点。

在遇到突发情况的时候,比如处理 bug 、维护旧系统花了不少时间之后也很容易打乱计划,这种情况也不是不能避免,如果你能预知一些情况,告诉能跟你互补的同事,让他帮忙处理产品的 delay,这样也是挺理想的。不过现实往往是一个产品里的工程师可能也就 3 – 4 个人各司其职,比较难互补,这个时候前面提到的统筹就比较重要,比如通过调整某几个步骤的顺序并行或者怎样,来尽量弥补。

一直觉得大公司里专门管理项目流程的挺多余的,仅仅为了“符合”公司指定的产品流程,为了提交各种“产品文档”而设立,太浪费了,在有追求想做出好产品的团队中是需要每个成员自己来完成的,自管理之所以非常难,是因为很多人习惯于被管理。

其实我所说的都是不适合于大公司,很多也只是带有情绪的个人迷思。很有感触的还有,在很多大公司里你要多花很多精力在为人行事上,虽然怎么做人做事是基本,但是在需要体现职业和专业素养的时候还是要多花点时间在做“产品”上。

虽然我现在还没完全地成为一个做产品的人,但是还是能体会到完成一个产品这其中有很多值得玩味和思考的东西,产品延期其实跟实施质量差、重复自己是差不多的,毕竟一辈子要做产品很多,这一个个过程看起来比什么时候发布更重要一些。

 

 

Published by

Z.J.T

Product Designer from Wandou Labs