在产品推进过程中,遇见太多太多的大规划,但这些,在具体产品迭代过程中,用于限定
需求范围可行,规划与实际计划不符却不可取。成熟的产品迭代团队,每一期迭代一般会
有相对固定的周期。尊重时间周期和需求范围,做好当期需要实现的内容,不过于蔓延需
求,机动时间合理,方可称不负韶光。
做 B 端产品的痛与苦
如果你跟一个负责 B 端产品的朋友喝下午茶的时候,他不小心走神了,请你大方的原谅他
吧。
哪怕他人在你面前,他的脑子里与跟你唠嗑同时并行的事情,可能不下 10 项:
嗯,对面这人在问我奶茶好不好喝,咦,怎么又说到了熔断,熔断是啥? 后天这个产品
版本上线,还有 5 个重要 bug 得改,不然不能上线。 下个版本里得做 20 个需求,数据
权限下沉得涉及多个部门,该怎么推进呢? 某服务的供应商不是说今天上线这个功能嘛
,都这个点了还不通知我们准备,今天还能上线吗? 完了,A 项目和 B 项目会议时间冲
突了,怎么办? C 项目好像也要上线了,当时的需求是什么来着? 有个研发资源好像要
被释放了,好几个产品线和项目在争抢,怎么才能让他来我们团队呢。 ……
焦虑啊~
有人感叹,我有丰富的理论 ...


雷达卡




京公网安备 11010802022788号







