优界网

首页 > 产品经理 > 技术人员的Secret Toolbox

技术人员的Secret Toolbox

24

0

0

2015-05-14 13:37:23

萤火

分享一下,又不会怀孕!

本作品为转载作品,版权为作品原作者所有,感谢上传者的分享!

之前我们谈到过能让产品经理在技术人员,包括工程师/设计师眼中迅速变Low的事情,其中有一点是“逼着技术团队承诺”,有同学不理解,

问:

技术负责人对开发时间进行评估,并且给出排期承诺,是必须的吧?

答:

我更倾向于认为承诺是传统瀑布模型下的模式,开发明确的任务、技术也成熟,可以提前计算好,但互联网的敏捷模式下,很多时候会做着做着发现坑、做着做着需求有不得已的变化,所以应该技术和产品一起做【预测】,心里想着目标,一起面对变化。最核心的区别,承诺是技术对产品的责任,预测是两边一起承担责任。

当然,这里面有个前提,就是技术同学要很靠谱。

而更可怕的一点,还没说,那就是容易逼出一系列可怕的大招——

技术人员的Secret Toolbox

240390-13052422163679

Copy&Paste:

不假思索的“复用”,满足当前需求就好,不考虑逻辑的可扩展,比如A和B现在1对1,不考虑将来有可能1对N,即使是业务上已经做出提示的时候;

Hardcode:

写死代码,不用配置文件、变量,当你发现某个参数不妥,想要多改几次试试的时候,发现工作量超乎想象,而且怎么都改不干净;

Less Testing:

听来一个很搞笑的故事,某位技术同学写完代码做单元测试,第一次没过,百思不得其解,于是再跑一次看看,结果过了,再跑,又过了,于是,就认为第一次是幻觉;

Skip Error Handling:

不考虑异常情况,假设用户都是正常使用(当然,在某些情况下,业务方认可的时候确实可以这样做),举个最简单的例子,输入框没有做安全上限的长度控制,用户可以直接把程序搞挂;

Descope:

偷摸减需求,不举例了,真的会有,验收的时候产品经理负责,发现了还好,但有时候只验收主要场景是发现不了的;

Less Review:

减少设计评审、代码Review等,我们认为强技术可以少评审,但会动用secret toolbox的同学往往并不是很厉害的人物;

No Autotest:

无测试自动化,工欲善其事必先利其器,磨刀不误砍柴工,一直不磨刀,整体效率就一直上不去;

……

还有啥招,技术同学不妨自爆……

这样做,本次交付的时候,会看着很美,需求都满足了,这时候产品经理还会暗爽——就是要逼吧,你看,逼一逼都做出来了,下次继续……

但往后,做着做着,你会发现整个技术团队越来越不愿意承诺了,承诺的越来越难达到了,经常延期?效率好像越来越低?出活越来越少?那就是因为填坑的时间占比越来越大了。

最终有一天,技术Leader面露难色的找到你,说:

“兄弟,业务发展太快了,技术架构跟不上,要重构了”

“啊,要多久”

“两个月,一半的兄弟都要参与”

“不可能,因为……”

“必须重构了,不然说不准什么时候就挂了”

……

熟悉吧,over。

本文由作者:苏杰?授权人人都是产品经理网站发布,转载请注明出处,并保留原文链接

已有0人赞过

+1赞

认真评论的都成大咖了

还可输入1000个字

我要评论 我要评论
  • 刚刚
  • 登录优界网 ×