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:華為是有測試工程師的，在十年前，華為對開發和測試的招聘要求是一樣的。當時我們的工作流程是這樣的：每個迭代開始前幾天，開發會和測試一起去過需求一起寫測試用例。華為的測試也要寫指令碼，寫程式的，他們的工作和開發的工作差不多。

我認為這兩個崗位之間有很多的共通點，如果你想要做好轉型我認為你需要先培養一種快速理解產品的能力，你要了解產品的功能和邊界，這是開發和測試都要關注點。程式設計能力是你現在所欠缺的，以後往這方面努力就可以了。

 

主辦方 ，為新一代智慧專案管理平臺，可助力企業全方位解決企業協作與研發痛點，科學量化團隊表現。不僅如此， 每月舉辦多次線下沙龍分享，旨在透過大咖乾貨分享，構建純業內、純專案專家交流圈，共同推進企業智慧化管理。

 

現場活動花絮