技术人员的Secret Toolbo
之前我们谈到过能让产品经理在技术人员,包括工程师/设计师眼中迅速变Low的事情,其中有一点是“逼着技术团队承诺”,有同学不理解,
问:
技术负责人对开发时间进行评估,并且给出排期承诺,是必须的吧?
答:
我更倾向于认为承诺是传统瀑布模型下的模式,开发明确的任务、技术也成熟,可以提前计算好,但互联网的敏捷模式下,很多时候会做着做着发现坑、做着做着需求有不得已的变化,所以应该技术和产品一起做【预测】,心里想着目标,一起面对变化。最核心的区别,承诺是技术对产品的责任,预测是两边一起承担责任。
当然,这里面有个前提,就是技术同学要很靠谱。
而更可怕的一点,还没说,那就是容易逼出一系列可怕的大招——
技术人员的Secret Toolbox
Copy&Paste:
不假思索的“复用”,满足当前需求就好,不考虑逻辑的可扩展,比如A和B现在1对1,不考虑将来有可能1对N,即使是业务上已经做出提示的时候;
Hardcode:
写死代码,不用配置文件、变量,当你发现某个参数不妥,想要多改几次试试的时候,发现工作量超乎想象,而且怎么都改不干净;
Less Testing:
听来一个很搞笑的故事,某位技术同学写完代码做单元测试,第一次没过,百思不得其解,于是再跑一次看看,结果过了,再跑,又过了,于是,就认为第一次是幻觉;
Skip Error Handling:
不考虑异常情况,假设用户都是正常使用(当然,在某些情况下,业务方认可的时候确实可以这样做),举个最简单的例子,输入框没有做安全上限的长度控制,用户可以直接把程序搞挂;
Descope:
偷摸减需求,不举例了,真的会有,验收的时候产品经理负责,发现了还好,但有时候只验收主要场景是发现不了的;
Less Review:
减少设计评审、代码Review等,我们认为强技术可以少评审,但会动用secret toolbox的同学往往并不是很厉害的人物;
No Autotest:
无测试自动化,工欲善其事必先利其器,磨刀不误砍柴工,一直不磨刀,整体效率就一直上不去;
……
还有啥招,技术同学不妨自爆……
这样做,本次交付的时候,会看着很美,需求都满足了,这时候产品经理还会暗爽——就是要逼吧,你看,逼一逼都做出来了,下次继续……
但往后,做着做着,你会发现整个技术团队越来越不愿意承诺了,承诺的越来越难达到了,经常延期?效率好像越来越低?出活越来越少?那就是因为填坑的时间占比越来越大了。
最终有一天,技术Leader面露难色的找到你,说:
“兄弟,业务发展太快了,技术架构跟不上,要重构了”
“啊,要多久”
“两个月,一半的兄弟都要参与”
“不可能,因为……”
“必须重构了,不然说不准什么时候就挂了”
……
熟悉吧,over。
专栏作家
苏杰,好产品创始人,产品经理专栏作家,前阿里巴巴产品经理。《产品经理》、《淘宝十年产品事》作者,七印部落发起人,期待和同学们一起,用好产品改变世界。
本文系作者授权发布,未经许可,不得转载。
关键字:产品经理, 协作, 沟通, 技术
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!