解構(gòu)微信(三):揭秘微信的”敏捷”開發(fā)與流程管理
《解構(gòu)微信》為系列文章。作者深入微信團(tuán)隊(duì),圍繞微信產(chǎn)品誕生與繼續(xù)完善,從產(chǎn)品開發(fā)、團(tuán)隊(duì)工作、品牌推廣、流程等方面進(jìn)行深入研究,干貨較多。點(diǎn)擊可查《解構(gòu)微信(一)》和《解構(gòu)微信(二)》,分別講述了微信誕生、發(fā)展以及團(tuán)隊(duì)。
敏捷開發(fā)
敏捷是一種態(tài)度,試錯(cuò)是一種信仰?!⑿艌F(tuán)隊(duì)Harvey
敏捷開發(fā)是一種常用的軟件開發(fā)模式,與傳統(tǒng)的“瀑布式開發(fā)”相比,敏捷開發(fā)能夠持續(xù)滿足不斷變化的需求變動(dòng)。微信團(tuán)隊(duì)的情況正是這樣,“整個(gè)開發(fā)過程中產(chǎn)品會(huì)不斷修改,這是我們的特色?!盚arvey說,“哪怕在發(fā)布前的十分鐘,我們也要允許產(chǎn)品決策者提出變更?!薄盀榱私o產(chǎn)品決策者提供最大的自由度,敏捷原則成為整個(gè)開發(fā)流程的指導(dǎo)原則,”“極度敏捷”也成為技術(shù)團(tuán)隊(duì)乃至整個(gè)微信團(tuán)隊(duì)的追求。
微信團(tuán)隊(duì)的開發(fā)流程同樣包含瀑布式開發(fā)中的主要步驟,“決策——需求評(píng)審——細(xì)化產(chǎn)品設(shè)計(jì)——交互設(shè)計(jì)——開發(fā)——迭代——灰度發(fā)布——測(cè)試——上線運(yùn)營”,“但是這個(gè)過程我們(微信團(tuán)隊(duì))是并發(fā)來做的,”Justin說。同時(shí),整個(gè)開發(fā)過程中充滿了由需求變動(dòng)驅(qū)動(dòng)的“微循環(huán)”。
在每一個(gè)“微循環(huán)”的起點(diǎn)——需求提出環(huán)節(jié),產(chǎn)品經(jīng)理、交互團(tuán)隊(duì)和技術(shù)團(tuán)隊(duì)的同事會(huì)一起,對(duì)平時(shí)收集到的用戶需求和意見進(jìn)行討論。微信客戶端UI組組長Kink認(rèn)為,“如果只是產(chǎn)品經(jīng)理閉門想產(chǎn)品,其實(shí)是不大好的;可能產(chǎn)品經(jīng)理提出的需求在交互設(shè)計(jì)層面并不是最終需求,只是一個(gè)表面現(xiàn)象,用戶需求需要更深層的挖掘;而從開發(fā)的角度看可能有簡潔的方式來達(dá)到目的,但表現(xiàn)為不同的形式。
“通過三個(gè)團(tuán)隊(duì)的成員共同討論確定下來的產(chǎn)品方向,他認(rèn)為往往‘更靠譜’而且降低了項(xiàng)目夭折的可能性。接下來,由于交互團(tuán)隊(duì)、技術(shù)團(tuán)隊(duì)都參與到需求的生產(chǎn)環(huán)節(jié)中,對(duì)產(chǎn)品的大致形態(tài)比較清楚,交互、技術(shù)這兩個(gè)團(tuán)隊(duì)的工作就可以和產(chǎn)品團(tuán)隊(duì)的工作并行開展。Kink說:“大家都明白產(chǎn)品是什么樣的,就可以同步開始了,交互可以做交互方案,視覺可以選定方向,開發(fā)同事可以做代碼設(shè)計(jì)。等交互方案出來,視覺設(shè)計(jì)師可以馬上根據(jù)交互方案實(shí)現(xiàn),開發(fā)同事一看到交互方案就可以開始寫代碼了?!?/p>
在項(xiàng)目推進(jìn)的過程中仍會(huì)發(fā)現(xiàn)各種問題,這時(shí)三個(gè)團(tuán)隊(duì)的負(fù)責(zé)人會(huì)再次碰頭對(duì)問題進(jìn)行討論,如果問題不大,這種小規(guī)模的討論就可以當(dāng)時(shí)解決;如果發(fā)現(xiàn)有比較嚴(yán)重的問題,團(tuán)隊(duì)成員會(huì)花更多的時(shí)間討論當(dāng)初的設(shè)計(jì)是否存在缺陷,這種討論Allen、Harvey也會(huì)參與進(jìn)來。如果確定問題在于原本的需求設(shè)計(jì)不合理,那么新一輪的“微循環(huán)”又會(huì)啟動(dòng)。
整個(gè)微信團(tuán)隊(duì)都在南方通信大廈的10樓,這使得團(tuán)隊(duì)成員之間的面對(duì)面交流十分方便?!懊鎸?duì)面交流”既是敏捷開發(fā)倡導(dǎo)的原則,也是團(tuán)隊(duì)從郵箱時(shí)代積累的經(jīng)驗(yàn)。Kink認(rèn)為:“無障礙溝通有助于敏捷的實(shí)現(xiàn),大家不管什么時(shí)候什么地方碰到面就聊:這邊有什么困難,那個(gè)需求的時(shí)間點(diǎn),設(shè)計(jì)上有什么能改善的……很多問題是在茶水間里一次三五分鐘的討論中解決的?!盠ake對(duì)此的評(píng)價(jià)是:
1小時(shí)說的話,打出來要10小時(shí),而且面對(duì)面溝通可以快速反應(yīng),有什么問題大家直接就可以討論了。如果有面對(duì)面溝通的條件盡量用這種方式,但不是那種冗長的會(huì)議形式。在座位旁邊兩三個(gè)人五到十分鐘的交流,然后快速散開,就一個(gè)問題迅速進(jìn)行討論,得出結(jié)論,散開,這是我們的工作生活,這個(gè)是必須的。
在敏捷開發(fā)中,需求的快速變動(dòng)要求開發(fā)團(tuán)隊(duì)不斷修改甚至是重寫代碼,這給開發(fā)團(tuán)隊(duì)帶來了巨大的困難和壓力。為了預(yù)防和緩解這個(gè)問題,微信團(tuán)隊(duì)在基本技術(shù)架構(gòu)中確立了“大系統(tǒng)小做”、“讓一切可擴(kuò)展”、“必須有基礎(chǔ)組件”等幾個(gè)原則。技術(shù)團(tuán)隊(duì)認(rèn)為這樣的技術(shù)構(gòu)架能保證“產(chǎn)品層面的改動(dòng)對(duì)技術(shù)層的影響不會(huì)太大”,為技術(shù)團(tuán)隊(duì)適應(yīng)敏捷提供基本能力。Justin回顧朋友圈的開發(fā)過程時(shí)說:
比如朋友圈這個(gè)產(chǎn)品經(jīng)歷了很多次變動(dòng),出了好幾十個(gè)版本,但是有東西是不變的,就是數(shù)據(jù)模型是不變的。所以我們?cè)诋a(chǎn)品設(shè)計(jì)和細(xì)節(jié)還沒出來的時(shí)候,我們從后臺(tái)到協(xié)議設(shè)計(jì)到本地存儲(chǔ)的整個(gè)數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)都已經(jīng)做好了,界面的框架也可以先做,等設(shè)計(jì)最終確定的時(shí)候,我們技術(shù)這邊已經(jīng)進(jìn)入ready的階段。這是我們和別人不同的地方。
技術(shù)團(tuán)隊(duì)
敏捷開發(fā)離不開技術(shù)團(tuán)隊(duì)的支持。對(duì)于產(chǎn)品團(tuán)隊(duì)提出的方案,技術(shù)團(tuán)隊(duì)很少以“技術(shù)上實(shí)現(xiàn)不了”為理由拒絕,Harvey把這個(gè)視為技術(shù)團(tuán)隊(duì)的“技術(shù)信仰”。從用戶使用體驗(yàn)的角度思考問題,而不是從技術(shù)實(shí)現(xiàn)難易程度和開發(fā)量的角度思考,這是微信技術(shù)團(tuán)隊(duì)的特點(diǎn)。Justin認(rèn)為,Allen對(duì)于技術(shù)團(tuán)隊(duì)的高要求是催生這種氛圍一個(gè)原因:
在我們這個(gè)團(tuán)隊(duì)中,從Allen的要求來說就是“沒有技術(shù)實(shí)現(xiàn)不了的”。他基本上是這么認(rèn)為的,比如你和他說這樣不行,他會(huì)堅(jiān)持第二次第三次,最后很可能就可以了,那么后來團(tuán)隊(duì)就養(yǎng)成習(xí)慣了,技術(shù)團(tuán)隊(duì)不會(huì)輕易對(duì)一個(gè)功能能否實(shí)現(xiàn)做判斷。
有不少用戶對(duì)微信的評(píng)價(jià)都是“快速流暢”,“微信上傳速度很快,沒有等待的感覺?!薄拔⑿诺姆摵芰鲿?,手指向上拉動(dòng)就可以很快的翻到前面的對(duì)話?!辈贿^為了實(shí)現(xiàn)這種快速流暢的用戶體驗(yàn)微信技術(shù)團(tuán)隊(duì)做了很多努力,以翻頁這個(gè)操作為例,Lake介紹說:
翻頁也有不同形式,做粗糙的話可能要等1秒鐘,會(huì)停頓一下,這是不好的。我們希望雖然翻的時(shí)候有一屏一屏的概念,但是只有一瞬而過的loading過程,但翻的速度快到讓你感受不到分頁的存在,知道但是不需要等待——這都是很微妙的東西,這就是細(xì)節(jié)。但為了實(shí)現(xiàn)這一點(diǎn)很難,因?yàn)橐粋€(gè)會(huì)話有幾千條消息的時(shí)候,必然會(huì)影響速度。cpu需要計(jì)算,技術(shù)人員需要對(duì)技術(shù)有深入理解,要用什么樣的技術(shù)保證功能的實(shí)現(xiàn),而且翻頁的動(dòng)作每天都會(huì)發(fā)生,是一個(gè)非常重要的體驗(yàn)。無論如何要保證。
Allen認(rèn)為,這種挑戰(zhàn)可以帶給技術(shù)團(tuán)隊(duì)更大的成就感和更快的成長:
我更多知道他們需要的榮耀感是什么。對(duì)于一個(gè)技術(shù)人員來說,他有事情可以作出來,并且做得很好,遠(yuǎn)遠(yuǎn)比他沒有任何事情可做,然后每天平平淡淡的混一天日子,其實(shí)他并不希望混日子,他希望做出一個(gè)龐大的系統(tǒng),并且是很好的系統(tǒng),通過產(chǎn)品來驗(yàn)證他。
我們這里好多技術(shù)人員其實(shí)骨干是畢業(yè)生,他們進(jìn)來以后,我們發(fā)現(xiàn)他們成長最快,成就感也最大,并且他們應(yīng)該會(huì)很感謝說有機(jī)會(huì)參與到微信這樣一個(gè)項(xiàng)目里面。
對(duì)一個(gè)技術(shù)人員來說,做一個(gè)后臺(tái)系統(tǒng),做一個(gè)前端的開發(fā),能夠在短短一年多里面從零搭建一個(gè)系統(tǒng),服務(wù)一億用戶,這是非常大跨越了,或者說成就感也好,對(duì)自己的鍛煉也好。
流程管理
微信發(fā)展初期,團(tuán)隊(duì)的流程管理和文檔管理都處于不嚴(yán)謹(jǐn)?shù)臓顟B(tài),“常常是為了快速,三個(gè)人站在那里討論,但沒有落實(shí)成文檔,三個(gè)人自己都知道,是靠三個(gè)人的記憶去做。”Kink回憶說。隨著微信形態(tài)和功能的復(fù)雜化,團(tuán)隊(duì)成員發(fā)現(xiàn)團(tuán)隊(duì)項(xiàng)目進(jìn)度管理的問題逐步暴露了出來,“當(dāng)我們一次討論10個(gè)點(diǎn)的時(shí)候,就會(huì)忘記1個(gè)點(diǎn);討論到四、五十個(gè)點(diǎn)的時(shí)候,就會(huì)忘記十幾個(gè)點(diǎn)。這時(shí)候我們就發(fā)覺又要保持敏捷,又要在敏捷之后去用文檔或各種方式來保持信息不流失?!睘榱私鉀Q這個(gè)問題,各個(gè)團(tuán)隊(duì)都逐漸建立起一些需求管理和進(jìn)度控制的流程,包括將不同團(tuán)隊(duì)的需求點(diǎn)明確為需求清單,同時(shí)在不同團(tuán)隊(duì)間安排專人負(fù)責(zé)項(xiàng)目接口,確認(rèn)和監(jiān)督每個(gè)需求點(diǎn)的落實(shí)情況。
對(duì)于敏捷開發(fā)可能帶來的“混亂”,Allen認(rèn)為:
可能這是我們這里研發(fā)上的一個(gè)不同點(diǎn),就是看起來一些步驟挺亂的,但是這種“挺亂”的狀態(tài)我認(rèn)為又是必要的,不亂就太慢了……挺亂但不要真的亂掉,這可能是我們需要每一級(jí)的管理干部在心理上做到有序,形式上可以亂一點(diǎn)。
【聲明】本案例是由鄭小平和許家馨在楊斌教授的指導(dǎo)下編寫的,僅用于課堂討論。本案例中的情況描述不反映編者的觀點(diǎn),也不作為正式文件、基本數(shù)據(jù)來源以及管理活動(dòng)是否有效的證明。案例版權(quán)歸騰訊公司所有。轉(zhuǎn)載請(qǐng)注明以上聲明。
via:搜狐IT
解構(gòu)微信系列文章
《解構(gòu)微信(一):郵件中誕生與開發(fā)的逆境》
《解構(gòu)微信(二):揭秘微信團(tuán)隊(duì)》
《解構(gòu)微信(三):揭秘微信的“敏捷”開發(fā)與流程管理》
《解構(gòu)微信(四):不靠QQ,品牌和推廣要推翻重來》
- 目前還沒評(píng)論,等你發(fā)揮!