微信團隊如此強大,張小龍是用什么方法管理的?
作者 DS
8億用戶的微信是中國歷史上最成功的互聯網產品,沒有之一。 除了張小龍帶領的微信團隊在產品上極度尊重用戶的需求,保持克制和優雅的產品理念。 最重要的就是微信團隊在成立初期就堅定的使用「敏捷」方法,時刻關注組織的「敏捷」性。
「敏捷」到底是什么? 先從字面上理解,顧名思義,「敏捷」一詞包含了兩層含義: 一是「靈活」——檢查調整,游刃有余; 二是「快速」——天下武功,唯快不破。 什么意思?
這其實就是「敏捷」的原理,既滿足產品開發過程中需求的動態變化,又能通過短迭代管理監控項目的實時效果。 究其本質而言,敏捷管理方法很簡單:就是“檢查與調整”循環。 每過一小段時間就停一停手頭的工作,檢查已經取得了哪些成果,看看這些成果是不是自己期待的,想想有沒有更好的方法。 這一點看似容易,做起來并非易事,需要企業愿意改變固有方式,接受敏捷管理方法。 為什么優秀的公司都在做「敏捷」? 優秀的公司或者說團隊,之所以迫切需要「敏捷」這種新的工作方式。像是微信、京東、華為、通用電氣、Twitter 會一致采用「敏捷」。 原因就在于當前不少公司的開發項目都會延期超支,而且最后交付的成果還不能用。這明顯是工作方法不得當。 很多項目堅持采用「瀑布法」,堅持每件事都要事先規劃好,甚至還堅持要求在長達數年的項目執行期之內不能做出任何改變,這是非常荒謬的。 一個組織由小變大的過程中通常會出現一些問題,比如: 執行力下降;發布頻率降低;不尊重用戶體驗;片面追求KPI;制造虛榮指標來獲取公司資源;團隊滿意度降低;團隊的能力和創造力受到限; 這一系列大公司病,早期通常被公司管理者忽視而造成極其惡劣的后果。 一些公司的高管更重視營銷,商務合作,文化洗腦而忽視用戶和團隊管理,等到積重難返,后悔不已,但是很難改變,優秀人才流失,企業增長乏力,進入惡性循環。 「敏捷」方法充分考慮到了可能出現的不確定性因素,同時具有鮮明的創造性。
這幾句話看起來像是口號,但貫徹得到實踐當中后,確實帶來了和在傳統瀑布模型下開發軟件截然不同的局面。 它的結構是圍繞著學習過程建立的,這樣一來,團隊既可以評估已經取得的成果,同樣重要的是,也可以評估取得這些成果的方法。 這種架構能夠為團隊提供更加高效的工作方式,幫助他們更好地自我組織,提高工作速度,改進工作質量。 這時,只有兩個選擇:要么改變,要么解散。 如何實施「敏捷」? 無論你們的員工多優秀,作為領導者,你們都必須確保在員工的能力范圍之內,努力改善產品的質量和一致性。 因此,第一步就是管理層必須讓員工知道,你們非常熱衷于改善產品的質量和一致性,對產品的質量具有深刻的責任感。 如果只說不做,那么一切改善都不會出現。行動是最重要的。 1. 聚焦團隊,實現高水平業績: 2. 進行周期性項目管理 沖刺后必須展示成果,讓每個人知悉一切,再做下一個沖刺循環。
3. 把快樂轉化為更高的績效 在每個「沖刺」階段結束時,讓每位員工找出一個有待改善的地方,在下一階段予以解決,使團隊成員擁有成就感。 員工是否快樂,是預測公司未來業績的指標,工作原本可以讓人愉悅。 4. 80%的價值來自20%的功能 你需要擬定待辦事項清單,確定優先順序,在戰略上著眼于全局,策略上迅速行動。 進行「觀察—導向—決定—行動循環」。 以上觀點來自,《敏捷宣言》的起草人之一、「Scrum 之父」的 Jeff Sutherland。 工作原本也可以不讓人垂頭喪氣,可以以非常流暢、令人愉悅的方式進行,最大限度的發揮自由和創造力,獲得高收益的成果。 「敏捷」在 IT 技術部門的延伸是? 眾所周知,「敏捷」延伸到IT部門后,產生了一個從「開發」到「運維」的跨領域問題,就是這兩年很熱門的「DevOps」 DevOps 的「一個中心,兩個基本點」——以業務敏捷為中心,構造適應快速發布軟件的工具(Tools)和文化(Culture)。
在玩偶實驗室的「開發運維報告說明」中,為了更好地理解企業在采用開發運維各階段的情況和習慣,我們用基準問題測試了 4039 家 IT 企業。 第一點出人意料的是,在敏捷性性指標(agility metric)和可靠性指標(reliability metric)方面,運用開發運維的高績效公司遠遠勝過表現平平的同行:
換言之,他們更為敏捷。他們的部署代碼的頻率快 30 倍,從「代碼提交」到「成功投產運行」的速度快了 8000 倍。 表現突出企業的交付期以分鐘或小時計算,而表現較差企業的交付期以周、月甚至季度計算,如此發展,這些表現差的企業終究會被淘汰。 當一個團隊在進行「敏捷」變革時,也在顛覆IT人現有的傳統認知,如何讓自己和團隊更加高效? 該文章在 2018/5/8 23:09:13 編輯過 |
關鍵字查詢
相關文章
正在查詢... |