CORNERSTONE對話騰訊&華爲敏捷專家

由CORNERSTONE主辦的「深圳敏捷狂歡大會」圓滿落幕。這次活動集齊了敏捷領域的大咖與近百位敏捷研發愛好者到場，會上你們經過提問互動與敏捷大咖產生了精彩的思想碰撞，你們就敏捷開發如何落地及技術人員如何轉型晉升這兩個話題作了深度探討.

如下爲敏捷專家薛軍和李林在敏捷狂歡大會上的演講分享

爲何騰訊產品最好

2017年5月份，網上有一份關於移動APP月活躍度的排名數據，在這份排行榜中，前十四名裏，騰訊的產品就佔了七款。 這個耀眼的數據足以說明，騰訊的產品是有多受歡迎。

騰訊的產品爲何會那麼好呢？其實這和騰訊的創始人馬化騰以及其企業文化有關。馬化騰是一個天文學愛好者，愛好天文學的人最喜歡作的一件事就是遠距離思考規律，因此馬化騰的這種愛好延伸到產品上就是，爲了作好一款產品，他們會花時間去觀察和研究用戶的行爲習慣，而後找出這些行爲背後的規律，再根據規律去優化本身的產品，只爲更好地知足用戶需求。因此一個產品之因此能成功，離不開它的企業文化，而企業文化的核心是它的創始人。就像當年爲何李彥宏能作好搜索引擎，由於他自己的技術就很牛逼。

騰訊產品創新之道

騰訊的產品創新之道由三部分組成， 即產品、研發和運營，這是一個閉環的過程。第一步，先由產品遠距離觀察用戶尋找規律。但這規律並不必定是真理，也不必定是可以成立，因此須要研發用敏捷開發快速對規律進行迭代驗證，把這些規律變成一個產品、一個迭代或者一個模塊，快速試錯。運營要在後方發力，及時收集用戶反饋，幫助產品優化，這個過程是持續循環的。騰訊的優點就在於這個循環的效率足夠快，一個APP理論上來講都是兩週一個版本，而像H5，小程序，WAP這種網頁類的通常都是一週一個版本或者兩週一個版本，若是按照這個循環規律去執行，那麼一個產品若是是雙週一個版本，那麼在一年內大概就會有22個版本，若是是一週一個版本，那麼一年的話大概就會有44個版本，也就是騰訊的產品在一年以內最少都有22次試錯調整的機會，這種機會越多，產品就能優化得越好。

產品如何作減法

騰訊更加註重Evolution（進化），而不是Revolution（革命），它所追求的不是那些特別先進或者複雜的技術，它所追求的是是否能作出超出用戶指望的產品，給用戶不同的體驗。而優化用戶體驗最直接的方式就是爲產品作減法，經過大數據挖掘出用戶的高頻行爲，而後在用戶高頻行爲上加大投入，這就是騰訊爲產品作減法的實現形式。

研發如何追求本質

在研發上，騰訊無止境追求的是功能的本質性，以微信語音聊天功能爲例，用戶在公共場合接聽語音擔憂會被聽到，因而微信開發出了聽筒模式，可是這個功能是由用戶自主設置的，不少用戶都不會特意去設置它，也就是說這個功能在那時候的開發程度並無很好地解決用戶「傾聽」的問題，後來微信團隊花了一年多的時間去尋求解決方案，終於經過算法實現了微信語音自動切換模式的功能，這個功能的實現結合了人體工學結構，是經過檢測手機在三位空間中有沒有一個近似90°的弧線，加上距離感應器在四釐米之內觸發，兩個條件加在一塊兒，大大下降誤觸的可能。所謂研發的本質，一是好用，二是天然。

運營如何借力

好的產品是沒有用戶教育成本的，因此咱們在設計產品的時候，應該考慮產品的外顯性，外顯性體如今用戶在使用一個產品時傳遞出來的信息，能自帶傳播功能。像微信的打飛機遊戲、語音聊天、搖一搖等功能就屬於外顯性功能，它們集趣味性與互動一體，使微信自帶運營效果。

提問互動環節

Q:微信在迭代過程當中是如何挖掘出用戶的需求和痛點的？

A:有兩種方式，第一種方式就是前面咱們提到的，經過數據統計的方式挖掘出用戶的高頻行爲，而後在用戶高頻行爲路徑上加深研究，以此來知足用戶需求。第二種方式就是把本身想象成用戶，並且必須是各類不一樣的用戶，好比你把本身想象成一個老年人，那麼你可能會以爲字體過小你看不清，那這時候你就會知道須要加上一個功能來調節字體的大小。

Q:剛剛一直聽老師您在強調要在用戶高頻行爲路徑上作投入，那麼是否是能夠理解爲作產品如今更看重的是作數據分析，而再也不須要創造力了呢？

A:咱們前面講的都是一些方法論，是我把微信團隊這些年來所作的事情掰碎了講給大家聽，因此大家纔會以爲作這些事好像也不難，但若是我讓你把這些方法論拿回去實踐，你能保證你的團隊就必定能作出來嗎？

微信團隊用了三年的時間，去進行磨合，才把整個敏捷思惟在團隊中傳播開來，只有你們都理解並認同這種文化，才能迸發出更好的創造力。就像剛剛咱們提到的，微信如何識別用戶的耳朵，而後自動切換語音模式這個需求，聽起來就很胡扯，但微信作到了，微信的開發人員接受了，換到別的團隊，人家只會以爲你是瞎鬧。

Q:老師，我想問下產品經理如何才能更好地和團隊進行溝通呢？就像你剛剛提到的微信語音的例子，開發若是不能接受，我要如何才能說服他？另外我是作硬件工程的，我知道軟件用敏捷開發會有很好的說服力，可是硬件產品用敏捷彷佛成本會很高？

A:關於團隊溝通，能夠用敏捷的方法論去實現，若是大家團隊目前尚未達成統一的意識，那麼我建議大家創建一個「特性負責制」。什麼叫特性負責制呢？就是由產品、開發、測試組成的一個小團隊，這個小團隊專門爲某一個特性負責，之後有關於這個特性的用戶反饋，改進意見等均可以直接與責任人溝通，時間長了，反饋次數多了，這個功能早晚是會被優化的，由於總有一個理由會說服到他們。

至於硬件這塊，我認爲是你對敏捷有誤解，以特斯拉爲例，他們就用了敏捷開發。他們是怎麼實現的呢，就是用超配去實現，由於他們知道硬件是改變不了的，可是軟件的配置能夠進行更改升級，建議大家參考一下特斯拉的模式。

IT行業進入了一個史無前例的繁盛時代?

隨着5G時代的到來，計算機幾乎已經成爲了當今大學最熱門的專業，無數非相關行業的從業者轉行成爲開發者，IT行業彷佛已經進入了一個史無前例的繁盛時代，華爲花200萬年薪招收應屆博士生正印證了這點。

大量開發者陷入對將來的焦慮

行業需求日益飽和，不少IT企業開始清退35歲以上員工，這使得程序員面臨的壓力驟增，對將來感到焦慮迷茫。這樣的狀況讓IT行業成了時代的圍城：城裏的人想出去，城外的人想進來。

程序員是個吃青春飯的職業嗎？

我想是也不是。說是的緣由是對於大多數程序員來講，他們從入行第一天到30多歲，幾乎一直從事着初級程序員的工做，年紀越大，經驗沒有獲得積累，精力卻一直在衰退，天然競爭不過年輕的程序員。而說不是的緣由，是其實市場上真正有經驗的技術管理者如此之少，以致於我接觸到的大量公司都受困於在市場上根本招不到合格的技術管理者。甚至有些中小企業還去外包CTO,這是多麼魔幻的一件事，但它恰恰就發生了。

如何能從一個開發者轉型成爲一個技術管理者？

和大多數人預想的不一致的是，我認爲通向管理者的重要門檻是學會合理的評估開發週期。另外還有一個很重要的點是要避免陷入技術的具體細節，培養大局觀，學會從產品的角度思考問題。在我看來一位合格的開發者必須擁有主觀能動能性，不能簡單地作個機械命令的執行者，要明白能力越大，責任越大，要用於擔當。

爲何評估項目開發週期這件事如此困難？

1. 不少初中級的開發者不能真正理解一個需求的含義。缺少經驗的開發者很難第一時間發現一個需求所隱含的分支需求、邊界條件、技術難點以及可能發生的阻礙。
2. 不少初級的開發者不明白完成是什麼意思。事實上我花了好久才接受了這個使人沮喪的現實：大量開發者對完成的定義是寫完代碼。在不少狀況下，不少開發者在開發計劃的最後一天交付給測試人員的，僅僅是一個勉強能運行的版本。這致使了大量功能修復BUG的時間幾乎超過了當初開發這個功能的時間。
3. 永遠不會有所有的時間能用來開發。預估5天的任務，須要5天時間來開發，而實際上不多有組織中的程序員在5個工做日中能擁有完整的5天開發時間。程序員除了寫代碼，還須要參加各類和開發相關的會議，多是設計會議、QA會議、需求講解和澄清會議，還有一些關於以前版本或產品的維護工做。根據經驗來講，開發者用於寫代碼的時間通常不會超過60%。

從管理者到優秀的管理者

太多人認爲管理意味着統治，領導意味着權力。而我認爲領導意味着知識，應該向他人展現本身的方式是正確的和最佳的，以作到說服或引導他人。領導還意味着服務，管理者應該扮演着僕人和清道夫的角色，集中精力幫助研發人員清除前進道路上的障礙。

面對海量的需求你須要利用你的經驗來講服和引導產品經理/客戶，讓他們放棄高投入/低價值的需求，從高投入/高價值和低投入/低價值的需求中選取部分實現，保證低投入/高價值的需求能夠順利的完成。要爲了你的團隊勇敢說不。

我認爲身爲管理者必需要學會的重要的一課，是保護本身的團隊成員，免受組織中每日氾濫不絕的各類問題、爭議和「瑣事」的干擾，不作傳話筒、 不粘鍋式的領導。

提問互動環節

Q:如今團隊成員年輕化，僕人式管理確實很關鍵，但僕人式管理意味着我要下沉到細節裏，這會增長個人工做量，個人領導認爲我應該關注大方向上的問題，但確實又有不少細節須要我去處理和引導，因此這讓我很疑惑我到底該怎麼作？

A：我剛剛說的僕人式管理，並非真正去作一個僕人。運用僕人式管理確實是須要下沉到團隊當中，但這並不意味着任何事情都須要你去操心，你應該把目標聚焦在大方向上，篩選出什麼是適合你來作的，或者由你出面能更好解決問題的場景，再介入。

例如上個星期，咱們在平安的項目遇到了一些問題須要和平安高層去溝通，那這時候就應該由我去出面解決，由於相對於駐紮在那邊的同事，個人身份會更好一些，說話也更有份量。但若是這個場景換成是某位同事他不會敲某行代碼，那這個就不屬於我該管的範疇。

我認爲在管理上，要有預見性。提早預估可能發生的障礙能夠幫咱們更好地把握方向，這樣就不至於陷入自我矛盾中。

Q:請問下華爲有測試開發工程師這個崗位嗎？華爲內部是否也在運用敏捷開發的模式管理團隊？我想從測試人員轉型成測試開發工程師難度大嗎？

A:華爲是有測試工程師的，在十年前，華爲對開發和測試的招聘要求是同樣的。當時咱們的工做流程是這樣的：每一個迭代開始前幾天，開發會和測試一塊兒去過需求一塊兒寫測試用例。華爲的測試也要寫腳本，寫程序的，他們的工做和開發的工做差很少。

我認爲這兩個崗位之間有不少的共通點，若是你想要作好轉型我認爲你須要先培養一種快速理解產品的能力，你要了解產品的功能和邊界，這是開發和測試都要關注點。編程能力是你如今所欠缺的，之後往這方面努力就能夠了。

主辦方CORNERSTONE，爲新一代智能項目管理平臺，可助力企業全方位解決企業協做與研發痛點，科學量化團隊表現。不只如此，CORNERSTONE每個月舉辦屢次線下沙龍分享，旨在經過大咖乾貨分享，構建純業內、純項目專家交流圈，共同推動企業智能化管理。

現場活動花絮