之前我們談到過能讓產(chǎn)品經(jīng)理在技術人員，包括工程師/設計師眼中迅速變Low的事情，其中有一點是“逼著技術團隊承諾”，有同學不理解，

問：

技術負責人對開發(fā)時間進行評估，并且給出排期承諾，是必須的吧？

答：

我更傾向于認為承諾是傳統(tǒng)瀑布模型下的模式，開發(fā)明確的任務、技術也成熟，可以提前計算好，但互聯(lián)網(wǎng)的敏捷模式下，很多時候會做著做著發(fā)現(xiàn)坑、做著做著需求有不得已的變化，所以應該技術和產(chǎn)品一起做【預測】，心里想著目標，一起面對變化。最核心的區(qū)別，承諾是技術對產(chǎn)品的責任，預測是兩邊一起承擔責任。

當然，這里面有個前提，就是技術同學要很靠譜。

而更可怕的一點，還沒說，那就是容易逼出一系列可怕的大招——

技術人員的Secret Toolbox

Copy&Paste：

不假思索的“復用”，滿足當前需求就好，不考慮邏輯的可擴展，比如A和B現(xiàn)在1對1，不考慮將來有可能1對N，即使是業(yè)務上已經(jīng)做出提示的時候；

Hardcode：

寫死代碼，不用配置文件、變量，當你發(fā)現(xiàn)某個參數(shù)不妥，想要多改幾次試試的時候，發(fā)現(xiàn)工作量超乎想象，而且怎么都改不干凈；

Less Testing：

聽來一個很搞笑的故事，某位技術同學寫完代碼做單元測試，第一次沒過，百思不得其解，于是再跑一次看看，結(jié)果過了，再跑，又過了，于是，就認為第一次是幻覺；

Skip Error Handling：

不考慮異常情況，假設用戶都是正常使用（當然，在某些情況下，業(yè)務方認可的時候確實可以這樣做），舉個最簡單的例子，輸入框沒有做安全上限的長度控制，用戶可以直接把程序搞掛；

Descope：

偷摸減需求，不舉例了，真的會有，驗收的時候產(chǎn)品經(jīng)理負責，發(fā)現(xiàn)了還好，但有時候只驗收主要場景是發(fā)現(xiàn)不了的；

Less Review：

減少設計評審、代碼Review等，我們認為強技術可以少評審，但會動用secret toolbox的同學往往并不是很厲害的人物；

No Autotest：

無測試自動化，工欲善其事必先利其器，磨刀不誤砍柴工，一直不磨刀，整體效率就一直上不去；

……

還有啥招，技術同學不妨自爆……

這樣做，本次交付的時候，會看著很美，需求都滿足了，這時候產(chǎn)品經(jīng)理還會暗爽——就是要逼吧，你看，逼一逼都做出來了，下次繼續(xù)……

但往后，做著做著，你會發(fā)現(xiàn)整個技術團隊越來越不愿意承諾了，承諾的越來越難達到了，經(jīng)常延期？效率好像越來越低？出活越來越少？那就是因為填坑的時間占比越來越大了。

最終有一天，技術Leader面露難色的找到你，說：

“兄弟，業(yè)務發(fā)展太快了，技術架構(gòu)跟不上，要重構(gòu)了”

“啊，要多久”

“兩個月，一半的兄弟都要參與”

“不可能，因為……”

“必須重構(gòu)了，不然說不準什么時候就掛了”

……

熟悉吧，over。

#專欄作家#

蘇杰，好產(chǎn)品創(chuàng)始人，人人都是產(chǎn)品經(jīng)理專欄作家，前阿里巴巴產(chǎn)品經(jīng)理?！度巳硕际钱a(chǎn)品經(jīng)理》、《淘寶十年產(chǎn)品事》作者，七印部落發(fā)起人，期待和同學們一起，用好產(chǎn)品改變世界。

本文系作者授權(quán)發(fā)布，未經(jīng)許可，不得轉(zhuǎn)載。