3 項目管理

3.1 20%時間

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

3.2 目標和關鍵結果(OKRs)

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

3.3 項目批準

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

3.4 組織重組

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

3.5 年度的Hack 周

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

4 人員管理

4.1 角色

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

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

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

4.2 設施

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

4.3 培訓

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

4.4 轉崗

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

4.5 績效評定和獎勵

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

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

5 總結

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

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

致謝
特別感謝Alan Donovan的極其詳細和建設性的反饋，感謝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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。