技术人员的SecretToolbox

　　之前我们谈到过能让产品经理在技术人员，包括工程师设计师眼中迅速变Low的事情，其中有一点是“逼着技术团队承诺”，有同学不理解，
　　问：
　　技术负责人对开发时间进行评估，并且给出排期承诺，是必须的吧？
　　答：
　　我更倾向于认为承诺是传统瀑布模型下的模式，开发明确的任务、技术也成熟，可以提前计算好，但互联网的敏捷模式下，很多时候会做着做着发现坑、做着做着需求有不得已的变化，所以应该技术和产品一起做【预测】，心里想着目标，一起面对变化。最核心的区别，承诺是技术对产品的责任，预测是两边一起承担责任。
　　当然，这里面有个前提，就是技术同学要很靠谱。
　　而更可怕的一点，还没说，那就是容易逼出一系列可怕的大招
　　技术人员的SecretToolbox
　　CPaste：
　　不假思索的“复用”，满足当前需求就好，不考虑逻辑的可扩展，比如A和B现在1对1，不考虑将来有可能1对N，即使是业务上已经做出提示的时候；
　　Hardcode：
　　写死代码，不用配置文件、变量，当你发现某个参数不妥，想要多改几次试试的时候，发现工作量超乎想象，而且怎么都改不干净；
　　LessTesting：
　　听来一个很搞笑的故事，某位技术同学写完代码做单元测试，第一次没过，百思不得其解，于是再跑一次看看，结果过了，再跑，又过了，于是，就认为第一次是幻觉；
　　SkipErrorHandling：
　　不考虑异常情况，假设用户都是正常使用（当然，在某些情况下，业务方认可的时候确实可以这样做），举个最简单的例子，输入框没有做安全上限的长度控制，用户可以直接把程序搞挂；
　　Descope：
　　偷摸减需求，不举例了，真的会有，验收的时候产品经理负责，发现了还好，但有时候只验收主要场景是发现不了的；
　　LessReview：
　　减少设计评审、代码Review等，我们认为强技术可以少评审，但会动用secrettoolbox的同学往往并不是很厉害的人物；
　　NoAutotest：
　　无测试自动化，工欲善其事必先利其器，磨刀不误砍柴工，一直不磨刀，整体效率就一直上不去；
　　还有啥招，技术同学不妨自爆
　　这样做，本次交付的时候，会看着很美，需求都满足了，这时候产品经理还会暗爽就是要逼吧，你看，逼一逼都做出来了，下次继续
　　但往后，做着做着，你会发现整个技术团队越来越不愿意承诺了，承诺的越来越难达到了，经常延期？效率好像越来越低？出活越来越少？那就是因为填坑的时间占比越来越大了。
　　最终有一天，技术Leader面露难色的找到你，说：
　　“兄弟，业务发展太快了，技术架构跟不上，要重构了”
　　“啊，要多久”
　　“两个月，一半的兄弟都要参与”
　　“不可能，因为”
　　“必须重构了，不然说不准什么时候就挂了”