技术人员的Secret Toolbox

之前我们谈到过能让产品经理在技术人员，包括工程师/设计师眼中迅速变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。

-----------------------------

@iamsujie的产品线：

--图书：《人人都是产品经理》；《淘宝十年产品事》

--课程：企业内训；高校入门课

--品牌：@七印部落，代表作《启示录》等

--网络平台：公众号、微博、知乎、豆瓣等（统一@iamsujie）