1
昨日，「唯物」第一時間編發了「張小龍最新內部演講：警惕KPI和流程」，閱讀量分分（≈480）鐘沖到了 10 萬+。但也許是因為文中觀點牽扯到每個人熟知的 KPI 和流程，所以即使江湖地位在那擺著，看官們依然眾說紛紜。
不過張小龍顯然早有準備，當“不同的聲音”在「唯物」的評論區出現之后，他又不知疲倦地一一作了回應。以下為對話實錄，由「唯物」整理（略刪減）：
林：KPI和流程并不是原罪，但分崗位和制定是否合理，舉個荒繆點的例子，給派出所長制定績效考核，每個月必須破50個案子，完不成KPI就撤職，然而該地區一向太平，平常案件都沒幾個，那你們說最后事情導向會如何？
張小龍：一個大公司需要有KPI，公司高層需要有這樣一個商業目標，但是，如果我們很多同事直接采取了高管的工作方式來工作，特別是把很多目標數字化，這個是不太合理的。因為當我們提出一個目標方向，我們努力方向一定會隨著這個目標改變，當提出一個純數據目標，努力方向可能會圍繞這個去做。大家在思考問題的出發點上有一些驅動力，不是來自是不是在做有價值的事情，而是來自于我們能做到一個多高的數據，那我會覺得有一點危險。
星辰大海：標題黨，敏捷開發難道不是方法論，不是一種流程?
張小龍：這里所謂的敏捷是什么意思呢？是真的非常快。當我頭一天晚上發現我們這里有一個東西要改一下，我發一個郵件出去，有的第二天上班的時候就發現這個東西改過來了，已經上線了，大多數一個星期上線是不夸張的，無疑這是一種很爽的感覺。
為什么我老是說特別懷念 150 人的小團隊，因為當我們人數增多的時候，我們自己會制造出很多流程出來。我們自己會習慣自己這種效率，而對一個非常小的團隊來說，他不需要開會、也不需要干嘛，大家坐在一起，扭頭就可以說有一個問題我們解決它吧。
唐穎嬰：敏捷還是有適用性的，在一個不合適的團隊強推敏捷只會帶來災難，敏捷的本質是快樂開發，但相當多的產品經理在學習了一套所謂的敏捷項目管理以后，把痛苦的偽敏捷當作敏捷灌輸給公司管理層，導致項目淪為產品經理籠絡行政權的手段。
張小龍：2005 年當我們接手 QQ 郵箱的時候，其實大家也很投入，有非常科學的整個研發設計一套方法論。我現在回想起來那一年我們做的所有事情，用一句話來概括是“一個非常平庸的團隊用了一些非常平庸的方法去做出來一個非常平庸的產品”，而且是不知不覺的。
在 06 年的時候因為糟糕到了極點，郵箱團隊開始思考這個危機，成立了一個很小的團隊，有 2、3 個 web 的開發，2、3 個產品，1、2 個 UI，還有 1、2 個測試，他們組成了我們定義為敏捷團隊。就這么小的一個團隊在后面幾年里面做的事情遠遠超過之前幾十人的努力。
大烏龜：感覺有點天真，規模一旦上去，量變引起質變，就完全是兩回事。舉個例子，微軟做一個 Path，開發也許只是一兩天就搞定，但是跟發布版本的適配，更新計劃，漏洞審查，甚至法務，這些通通都得過一遍，要是哪個環節出了問題，還得打回去重來。能說它不敏捷嗎？不是，只不過出差錯的代價太大了。 想象一下微信用敏捷的方式，一旦哪個環節因為激進而出問題，停個半天，這樣的損失有多大？而如果短期內停個兩三次，這對品牌的傷害是致命的。孰輕孰重？
張小龍：有一天晚上我發了一個微信說：有一些用戶反饋說，公眾號回復里面只能看到讀者評論的次數有多少次，但是看不到作者再評論的有多少人贊，這個事情存在很久了，為什么沒有加上？應該早一點把它加上。但是同時我多了一個念頭，我說這個需求可能大家會做一個計劃，排一個流程出來，可能要等到兩個月以后才會加上去。于是，我就多加了一句話，必須一個星期以后上線，結果過了兩天大家告訴我這個東西已經上去了。
如果按照日常的習慣，我們加一個東西真的要兩個月了，但是其實非要兩個月嗎？其實并不是這樣子的。而是說大家習慣了改一個東西是很大的事情，那么它真的需要兩個月。可是，在當時 QQ 郵箱起來的時候真的不是這樣一個速度。如果這樣的話，它可能也就起不來了。
meteorshower：誰說不反對廣告的，很多人都對廣告有意見，只不過只能被迫接受而已。
張小龍：從微信廣告上線到現在，沒有一個平臺廣告產品能夠像微信朋友圈廣告這樣做到幾乎沒有什么用戶的抵觸。（潛臺詞：我說的是“幾乎沒有”。）
如你所見，張小龍并未現身，但這番對話并非杜撰，每個字均出自張小龍之口。而重點僅在于，你是否熟讀并背誦了「張小龍最新內部演講：警惕KPI和流程」全文，而不是斷章取義。
另外，以上均為典型的“不同的聲音”，至于那些非典型的冷嘲熱諷，我想張小龍看到后可能會回應：“我所說的，都是錯的。”
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
專題
