3 項目管理

3.1 20%時間

Google允許員工花費20%的時間去做他們選擇的任何項目，而無需經(jīng)過他們主管或其他人的允許。這對獲得工程師的信任極其重要，有如下幾點原因。第一，它允許任何有好想法的人，即使他的想法在其他人看來目前并不是有價值，可以有足夠的時間去開發(fā)一個原型、示例或者演示去展示他們想法的價值。第二，他提供了管理上的透明性，否則員工會隱藏這類活動，在其他沒有正式政策允許20%時間的公司，員工有時會從事“地下工作“項目而不會讓主管知道。如果工程師對這些項目持開放態(tài)度，這樣會好很多，即使他們的主管并不認(rèn)同該項目的價值，也可在日常狀態(tài)更新時描述他們在這些項目上做的工作。在全公司范圍內(nèi)有正式的這樣一個政策和文化，使得這成為可能。第三，允許工程師在更加有趣的工作上花費一小部分時間，可以使工程師保持主動和興奮，避免他們變的疲憊不堪，特別是員工感覺被迫花費100%的時間在繁瑣的工作任務(wù)上的疲憊。擁有高效生產(chǎn)力、熱愛工作、充滿動力的工程師和疲憊不堪的工程師之間的差距遠(yuǎn)遠(yuǎn)大于20%。第四，它鼓勵創(chuàng)新文化，看到其他工程師在20%時間做好玩的實驗項目會鼓勵每個人都這么去做。

3.2 目標(biāo)和關(guān)鍵結(jié)果(OKRs)

Google要求個人和團(tuán)隊都要明確文檔化他們的目標(biāo)和評估達(dá)成這些目標(biāo)的進(jìn)度。團(tuán)隊設(shè)定季度和年度目標(biāo)，并給出可量化的關(guān)鍵結(jié)果以顯示目標(biāo)進(jìn)度。這在全公司各個層面上展開，直至整個公司的目標(biāo)。個人和小團(tuán)隊的目標(biāo)要和他們所屬大團(tuán)隊或整個公司的更高層次的目標(biāo)一致。在每個季度末，會記錄每個可量化關(guān)鍵結(jié)果的進(jìn)度，每個目標(biāo)都會給出一個0.0（零進(jìn)度）到1.0（100%完成）的打分。OKR和OKR的打分通常是全公司可見的（特別敏感如高度機(jī)密的項目是少數(shù)例外），但是打分并不是用于員工的個人績效評定。
OKR應(yīng)該設(shè)定較高的目標(biāo)，理想的目標(biāo)是總體平均完成度在65%，這意味著鼓勵團(tuán)隊設(shè)定比他們可能完成工作量多大概50%的目標(biāo)。如果一個團(tuán)隊的得分比0.65高很多，鼓勵他們在接下來的一個季度中設(shè)立更高的OKRs（相反的，如果得分比0.65低很多，則鼓勵他們在下個季度設(shè)立相對保守的OKRs）。
OKRs提供了溝通公司各個部分工作的關(guān)鍵機(jī)制，并通過溝通激勵、鼓勵員工創(chuàng)造好的績效。即使OKRs并不影響績效評估或報酬，當(dāng)工程師知道自己的團(tuán)隊有OKR打分的會議，也會自然驅(qū)動他把該分提高。定義關(guān)鍵結(jié)果的目標(biāo)和可量化性有助于確保員工做真正對目標(biāo)有可量化影響的工作。

3.3 項目批準(zhǔn)

雖然Google有完善的發(fā)行批準(zhǔn)過程，但是卻沒有一個完善的項目立項或取消的過程。盡管我已經(jīng)在Google工作了十年，目前也成為了一名管理者，但是我仍然不完全理解項目決策是根據(jù)什么做決定。部分原因是全公司也沒有一個統(tǒng)一的規(guī)范。各個職級的管理者對他們團(tuán)隊要做的項目負(fù)責(zé)，并根據(jù)他們的判斷進(jìn)行他們認(rèn)為合適的項目。在一些情況下，這意味著許多決定都是自底向上建立的，因為工程師被充分給予了在他們的團(tuán)隊內(nèi)自由選擇項目的自由。在另一些情況下，決定是自頂向下建立的，由管理層或者管理者決策進(jìn)行哪些項目，給哪些額外的資源，哪些項目要被取消。

3.4 組織重組

有時當(dāng)管理層決定要取消一個大的項目時，這時在該項目工作的許多工程師要在新的團(tuán)隊尋找新的項目。同樣，有時要進(jìn)行資源“整合”，即將分散多個地區(qū)的的項目整合在幾個少數(shù)地區(qū)，這時為促成整合，其他地區(qū)的工程師也要改變團(tuán)隊和項目。在這種的情況下，通常讓工程師在他們地區(qū)可選范圍內(nèi)自由選擇團(tuán)隊和角色，或者在“整合”的情況下，他們也可以選擇更換辦公地點從而繼續(xù)留在原來的團(tuán)隊。
除此之外，其他形式的公司重組，例如合并或分解團(tuán)隊，改變匯報線等，在Google都很常見，盡管我不知道Google和其他的大公司相比算不算多。在一個技術(shù)驅(qū)動的大公司，一定程度上的頻繁重組是必要的，可以避免因技術(shù)和需求改變時導(dǎo)致的組織低效。

3.5 年度的Hack 周

另一種在google被激勵的文化是“黑客馬拉松”活動。在許多的google的辦公室中，軟件工程師每周花時間以這種例行的黑客活動來工作于創(chuàng)新型的項目上。在啟動會后，人們各抒己見，形成小的團(tuán)隊，在新的想法的基礎(chǔ)上構(gòu)建一個demo或原型，在周末結(jié)束時展示他們的demo給觀眾和評委，評委給出小小的獎勵給最佳的項目。 最大的獎勵，其實是認(rèn)可度、認(rèn)同感-一種可以從成功的黑客馬拉松項目孵化成真正的真實項目的希望。
盡管所有的工程師被允許或被引導(dǎo)可以參加這樣的“黑客馬拉松”活動，但許多工程師發(fā)現(xiàn)把他們?nèi)諒?fù)一日的工作從中剝離出來還是有困難的，所以參與率通常是相當(dāng)?shù)牡?#xff08;在5%-20%），盡管許多人有意愿參加了啟動會或最終的展示會并且也被好的靈感所激勵。

4 人員管理

4.1 角色

如下文所述，Google區(qū)分了工程師和管理者的職業(yè)發(fā)展階梯，將技術(shù)主管從管理者中區(qū)分開來，將研究并入工程師，并通過產(chǎn)品經(jīng)理、項目經(jīng)理和網(wǎng)站可靠性工程師（site reliability engineers, SREs)支持工程師的工作。目前看來，至少其中的一些實踐對于維持Google已經(jīng)發(fā)展的創(chuàng)新文化至關(guān)重要。
Google工程師僅有少數(shù)的角色。在每個角色內(nèi)，都有職業(yè)進(jìn)一步發(fā)展的機(jī)會，其通過一系列的等級和晉升機(jī)會（有相應(yīng)的報酬如薪金等的提高）以認(rèn)可下一級別的表現(xiàn)。
主要的角色有：
工程師主管
這是這個列表中唯一的管理者角色。其他的角色的個人如軟件工程師可能也管理人，但是工程師主管一定管理人。工程師主管通常在早期也是軟件工程師，并是全面的技術(shù)專家，有卓越的個人技能。
技術(shù)主管和管理者有一個主要區(qū)別。
工程師主管并不一定要領(lǐng)導(dǎo)項目。項目通過技術(shù)主管領(lǐng)導(dǎo)，其可以是一名工程師主管，但更常見的是軟件工程師。項目的技術(shù)主管有該項目的技術(shù)決策的發(fā)言權(quán)。

工程師主管的責(zé)任是選擇技術(shù)主管，并負(fù)責(zé)他們團(tuán)隊的績效。他們指導(dǎo)和協(xié)助職業(yè)發(fā)展，進(jìn)行績效評估（使用同事反饋），并在一定層面上負(fù)責(zé)薪酬，也在負(fù)責(zé)招聘中的一部分。
工程師主管一般直接管理任意地點的3到30個人，但8～12個更為常見。
軟件工程師（Software Engineer , SWE)
從事軟件工程開發(fā)工作的大多數(shù)人都是這個角色。Google招聘軟件工程師的門檻非常高。僅招聘最一流的軟件工程師，可以使許多在其他公司如瘟疫般的軟件問題，在Google都盡可能的避免或者縮小。
Google區(qū)分工程師和管理者的職業(yè)發(fā)展序列。盡管一個工程師可以從事管理工作或者轉(zhuǎn)崗到一個工程師主管職位，但是對于晉升來講，管理才能不是必須的，即使是在非常高的級別。高級別的工程師職位需要有一定的領(lǐng)導(dǎo)能力，但它可以有多種形式，例如創(chuàng)造了產(chǎn)生了巨大的影響或者被很多其他工程師使用的軟件，對晉升來講就足夠了。這非常重要，因為它意味著，對于擁有卓越技術(shù)能力但缺乏管理欲望和技巧的人仍然可以有很好的職業(yè)發(fā)展，并不一定要求這類人走管理者的發(fā)展道路。這避免了在其他組織中身處于管理職位，卻忽視團(tuán)隊管理，從而失去上升空間的工程師的痛楚。
研究科學(xué)家
該角色的招聘標(biāo)準(zhǔn)非常嚴(yán)格，招聘的門檻極其的高，要求已有一系列的發(fā)表文章記錄以證明其出色的研究能力，并要求寫代碼的能力。許多在學(xué)術(shù)屆非常有才華的人，他們或許有能力符合Google軟件工程師的角色，但不一定符合研究科學(xué)家的角色。在Google，大多數(shù)博士都是軟件工程師而非研究科學(xué)家。研究科學(xué)家通過其研究貢獻(xiàn)包括文章發(fā)表等評定，但除了頭銜之外，Google的軟件工程師和研究科學(xué)家并無太大的區(qū)別。他們都可以做原始的研究并發(fā)表論文，都可以貢獻(xiàn)新的產(chǎn)品想法和新的技術(shù)，都可以寫代碼開發(fā)產(chǎn)品。在Google，研究科學(xué)家和軟件工程師在一起工作，即在相同的團(tuán)隊做相同的產(chǎn)品或者研究。將研究科學(xué)家嵌入到工程師中對在將發(fā)布的產(chǎn)品中融入新研究成果影響巨大。
網(wǎng)站可靠性工程師 (SRE)
系統(tǒng)的運(yùn)維由軟件工程師團(tuán)隊負(fù)責(zé)，而非傳統(tǒng)的系統(tǒng)管理員。但SRE的招聘需求和其他軟件工程師職位略有不同（如果有非常專業(yè)的其他技術(shù)如網(wǎng)絡(luò)或unix系統(tǒng)管理等彌補(bǔ)，軟件工程師相關(guān)的技巧可以稍微降低一些）。SRE角色的性質(zhì)和角色在SRE的書[7]中已經(jīng)很好很仔細(xì)的解釋了，這里我們就不繼續(xù)討論了。
產(chǎn)品經(jīng)理
產(chǎn)品經(jīng)理負(fù)責(zé)產(chǎn)品的管理。作為產(chǎn)品用戶的代理人，他協(xié)調(diào)工程師的工作，宣傳對用戶重要的新產(chǎn)品特性，協(xié)調(diào)與其他團(tuán)隊的溝通，跟蹤bug和協(xié)調(diào)時間，并確保一個高質(zhì)量的產(chǎn)品所需的所有資源一切就緒。產(chǎn)品經(jīng)理通常并不親自寫代碼，但是會和軟件工程師一起工作以確保寫出適合產(chǎn)品的代碼。
項目經(jīng)理/技術(shù)項目經(jīng)理
項目經(jīng)理和產(chǎn)品經(jīng)理的角色大致相同，但并不管理一個產(chǎn)品，而是管理項目、流程和操作（例如數(shù)據(jù)采集）。技術(shù)項目經(jīng)理也類似，但是需要和他們工作相關(guān)的特定的技術(shù)專長，例如處理語音數(shù)據(jù)的語言學(xué)知識。

軟件工程師與產(chǎn)品經(jīng)理和項目經(jīng)理的比例在公司不同團(tuán)隊中各有不同，但一般來講，該比例是比較高的，一般在4:1到30:1之間。

4.2 設(shè)施

Google因其有趣的設(shè)施而出名，如滑滑梯，球球堆和游戲室，它有助于吸引和保留人才。Google一流的咖啡免費向員工開放，這也有相似的功能，并且巧妙的鼓勵員工留在辦公室，饑餓從來不是離開的理由。員工們更常去的地方“微廚房“，可以拿零食和飲料，也有同樣的功能，并且這里還成為一個重要的非正式的交換想法的地點，許多聊天都始于這個地方。健身房、運(yùn)動、和便利的按摩椅幫助員工保持健康快樂，也提高了生產(chǎn)力和保留率。
Google的工位是開放空間的，并且通常是密集的。盡管有爭議，但這鼓勵了溝通（盡管有時以分散個人的注意力為代價），也很經(jīng)濟(jì)。
員工會分配了一個獨立的工位，但是工位重新分配相當(dāng)頻繁（如6～12月，通常是組織擴(kuò)張的結(jié)果），主管會重新安排座位以便利和促進(jìn)溝通，這通常對工位臨近的或相對比較近的人是比較容易的。
Google的設(shè)施中均有擁有一流的視頻會議設(shè)備的會議室，和其他組織的開會僅需點擊接入屏幕上的一個預(yù)先組織好的會議邀請即可。

4.3 培訓(xùn)

Google通過多種方式鼓勵員工教育。
Google新員工（“Nooglers”)有強(qiáng)制的入職培訓(xùn)。
技術(shù)類員工（SWE和研究科學(xué)家）從完成“Codelabs”訓(xùn)練開始：短時間的關(guān)于個人技術(shù)的編碼在線培訓(xùn)課程。
Google提供一系列的在線和線下培訓(xùn)課程。
Google也提供在外部機(jī)構(gòu)學(xué)習(xí)的支持。
除此之外，通常都會為每個"Noogler"分配一個正式的導(dǎo)師(Mentor) 和獨立的伙伴(Buddy)以幫助他們更快的適應(yīng)。非正式的指導(dǎo)也發(fā)生在和主管的例會、團(tuán)隊會議、代碼審查、設(shè)計審查和其他非正式的工作流程中。

4.4 轉(zhuǎn)崗

鼓勵在公司不同的部分之間轉(zhuǎn)崗，這有助于知識和技術(shù)整個公司傳播，提高跨組織溝通。在同一個崗位工作滿12個月后就可以在不同項目和辦公室間轉(zhuǎn)崗。鼓勵軟件工程師做其他組織內(nèi)的臨時性工作，例如SRE (Site Reliability Engineering，書名).中的六個月的“輪崗”(臨時工作）。

4.5 績效評定和獎勵

Google非常鼓勵反饋。工程師可以通過“同事獎金”(peer bonuses）和“勛章”（kudos）給其他人直接的積極評價。所有的員工都可以提名其他人獲取”同事獎金“——100美金的現(xiàn)金獎勵，每年最多兩次，以獎勵其超額完成任務(wù)，僅需要通過網(wǎng)頁填寫并描述原因即可。通常當(dāng)獲得“同事獎金”時，組內(nèi)同事們也會收到通知。員工也可以給其他人“勛章”，即正式聲明表揚(yáng)，以期對他們出色工作的社會認(rèn)可，但是沒有經(jīng)濟(jì)上的回報。“勛章”沒有超額完成工作的限制，也沒授予次數(shù)的限制。

管理者也可以獎勵獎金，包括立即獎金（例如完成了一個項目后）。和多數(shù)其他公司一樣，Google員工每年有績效獎金，根據(jù)他們的績效公平的獎勵。
Google有非常仔細(xì)、詳盡的晉升流程，晉升需要主管推薦或自我推薦、自我評價、同事評價、主管評估，最終由晉升委員會根據(jù)以上信息決策結(jié)果，結(jié)果可以由晉升上訴委員會進(jìn)一步審核。確保優(yōu)秀的員工獲得晉升對保持正確激勵機(jī)制至關(guān)重要。
另一方面，差的績效，根據(jù)主管的反饋處理，必要時制定績效提升計劃，績效提升計劃中設(shè)置了非常明確具體的績效目標(biāo)和如何評估達(dá)到該目標(biāo)的進(jìn)度。如果提升計劃失敗了，因為績效差可能會被終止合同，但實際上，這樣的情況在Google非常罕見。
主管的績效通過反饋調(diào)查評定。要求每個員工一年填寫兩次對他們主管的績效的調(diào)查，結(jié)果會匿名收集并提供給主管。這種形式的向上反饋對提升整個公司的管理質(zhì)量非常重要。

5 總結(jié)

我們已經(jīng)簡要地描述了Google的大多數(shù)核心軟件工程實踐經(jīng)驗。當(dāng)然，Google現(xiàn)在已經(jīng)是一個體量巨大并且多樣化的公司，公司的一些部門可能有不同的實踐經(jīng)驗。但是這里描述的是大多數(shù)團(tuán)隊目前遵循的實踐經(jīng)驗。

有著大量軟件工程的實踐經(jīng)驗，以及眾多與軟件工程實踐無關(guān)Google的制勝之道，想要客觀地定量地證明個人的實踐和提升結(jié)果之間關(guān)系非常困難。盡管如此，這些實踐經(jīng)驗在Google都經(jīng)受住了時間的考驗，經(jīng)受了成千上萬的優(yōu)秀軟件工程師的集體主觀判斷。
對于其他的公司，假如他們所倡導(dǎo)的軟件工程實踐也在本文中有所描述，或許，這有助于說明“這在Google已經(jīng)實踐證明足夠好了”。

致謝
特別感謝Alan Donovan的極其詳細(xì)和建設(shè)性的反饋，感謝Yaroslav Volovich、UrsHo?lzle、Brian Strope、Alexander Gutkin、Alex Gruenstein、Hameed Husaini在本文初稿時給出非常有用的評論意見。

引用
[1] Build in the Cloud: Accessing Source Code, Nathan York, http://google-engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html
[2] Build in the Cloud: How the Build System works, Christian Kemper, http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.htm
[3] Build in the Cloud: Distributing Build Steps, Nathan York http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html
[4] Build in the Cloud: Distributing Build Outputs, Milos Besta, Yevgeniy Miretskiy and Jeff Cox http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html
[5] Testing at the speed and scale of Google, Pooja Gupta, Mark Ivey, and John Penix, Google engineering tools blog, June 2011. http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html
[6] Building Software at Google Scale Tech Talk, Michael Barnathan, Greg Estren, Pepper Lebeck-Jone, Google tech talk.
http://www.youtube.com/watch?v=2qv3fcXW1mg
[7] Site Reliability Engineering, Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, O’Reilly Media, April 2016, ISBN 978-1-4919-2909-4.
https://landing.google.com/sre/book.html
[8] How Google Works,Eric Schmidt, Jonathan Rosenberg.
http://www.howgoogleworks.net
[9] What would Google Do?: Reverse-Engineering the Fastest Growing Company in the History of the World, Jeff Jarvis, Harper Business, 2011. https://books.google.co.uk/books/about/What_Would_Google_Do.html?id=GvkEcAAACAAJ&re dir_esc=y
[10] The Search: How Google and Its Rivals Rewrote the Rules of Business and Transformed Our Culture, John Battelle, 8 September 2005. https://books.google.co.uk/books/about/The_Search.html?id=4MY8PgAACAAJ&redir_esc=y [11] The Google Story, David A. Vise, Pan Books, 2008.
http://www.thegooglestory.com/
[12] Searching for Build Debt: Experiences Managing Technical Debt at Google, J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc, and Sanjay Bhansali.http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37755.pdf
[13] Development at the speed and scale of Google, A. Kumar, December 2010, presentation, QCon.
http: //www.infoq.com/presentations/Development-at-Google
[14] How Google Tests Software, J. A. Whittaker, J. Arbon, and J. Carollo, Addison-Wesley, 2012.
[15] Release Engineering Practices and Pitfalls, H. K. Wright and D. E. Perry, in Proceedings of the 34th International Conference on Software Engineering (ICSE ’12), IEEE, 2012, pp. 1281–1284.
http://www.hyrumwright.org/papers/icse2012.pdf
[16] Large-Scale Automated Refactoring Using ClangMR,H. K. Wright, D. Jasper, M. Klimek, C. Carruth, Z. Wan, in Proceedings of the 29th International Conference on Software Maintenance (ICSM ’13), IEEE, 2013, pp. 548–551.
[17] Why Google Stores Billions of Lines of Code in a Single Repository, Rachel Potvin, presentation.
https://www.youtube.com/watch?v=W71BTkUbdqE
[18] The Motivation for a Monolithic Codebase, Rachel Potvin, Josh Levenberg, to be published in Communications of the ACM, July 2016.
[19] Scaling Mercurial at Facebook, Durham Goode, Siddharth P. Agarwa, Facebook blog post, January 7th, 2014. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
[20] Why We (Still) Believe In Private Offices, David Fullerton, Stack Overflow blog post, January 16th, 2015.https://blog.stackoverflow.com/2015/01/why-we-still-believe-in-private-offices/
[21] Continuous Integration at Google Scale, John Micco, presentation, EclipseCon, 2013.http://eclipsecon.org/2013/sites/eclipsecon.org.2013/files/2013-03-24%20Continuous%20Integr ation%20at%20Google%20Scale.pdf

總結(jié)

以上是生活随笔為你收集整理的Google软件工程（续）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。