之前我们谈到过能让产品经理在技术人员，包括工程师/设计师眼中迅速变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面露难色的找到你，说：
“兄弟，业务发展太快了，技术架构跟不上，要重构了”
“啊，要多久”
“两个月，一半的兄弟都要参与”
“不可能，因为……”
“必须重构了，不然说不准什么时候就挂了”
……
