題:
公司如何實施像Google這樣的“ 20%時間”計劃?
Reinstate Monica - Goodbye SE
2012-04-13 02:03:46 UTC
view on stackexchange narkive permalink

我已經閱讀到 Google的20%規則是關於鼓勵娛樂和創新。

我的公司如何實施和管理這樣的程序?

對該問題的一個好的答案還應該涵蓋以下子問題:

  • 在20%的時間裡邊界是什麼?
  • 會發生什麼如果我必須工作40個小時才能按時完成項目?
    那我是否希望再增加10個小時的“有趣”工作?
    我下周可以只呆16個小時嗎?如果錯過一周,我會失去20%的時間嗎?
密切相關:[今天在工作日放假](http://www.codinghorror.com/blog/2012/08/today-is-goof-off-at-work-day.html),有關以下內容的博客文章Jeff Atwood的20%的時間。
實際上,谷歌正在遠離20%。如果您閱讀了他們的官方演講,他們不會再談論它了,而且它也不像以前那樣受到鼓舞。
也許這就是為什麼它們不像以前那樣具有創新性的原因?
七 答案:
#1
+38
Hrafn
2012-04-21 03:28:37 UTC
view on stackexchange narkive permalink

我可以根據我的公司如何實施和我們如何掙扎來提供一些信息。

在我的公司中,我們將其作為招聘工具和保持工程師技能的一種方式來實施尖銳。還有一些可能有趣的原因,保持利用率過高,以更好地促進上下文切換。該答案在20%的時間內也有一些很好的指導原則,還有一些其他參考文獻進一步支持了他的觀點。

我們並沒有根據此處提到的觀點做些什麼,但是我確實值得反思一下,如果您想在公司中實現自己20%的時間。

我們有一些關於人們20%的時間可以用來做什麼的基本準則。它應該通常對公司(包括對我們正在嘗試建立的文化)或您自己的專業發展有所貢獻。因此,花時間學習一種新的編程語言真是棒極了,而花時間學習吉他卻不是。

我們還會定期進行演示,如果您花時間,還需要就自己的工作做一個演示。這樣可以使20%的時間保持生產力。我們發現有20%的時間特別適合以下情況:

  • 原型設計想法或使用我們尚未準備投入生產的技術。
  • 保持精湛的技能。
  • 招聘優秀人才。
  • 為工程師提供了構建有效概念證明並獲得產品級支持的機會。

在分配方面,我們嘗試了幾種不同的方法。

每週時間

這裡的想法是每週1天專門用於輔助項目。從本質上講,“如果您每週分配20%到星期五”的方法。我們首先嘗試了此實現,但遇到了一些直接的問題:

  • 許多有趣的挑戰不利於一天的工作。
  • 要花很長時間才能使自己熟悉自己的工作。
  • 如果在任何給定任務上跑得甚至都落後,您就不會接受……這通常意味著您從未花費20%的時間。過渡是有問題的,因為坦率地說,如果您使用該級別的時間表對其進行跟踪,則出了點問題。
  • 從計劃的角度來看,這不是很可預測的,因為雖然星期五很常見,但是星期五並不普遍,而且您也不知道是誰來吃,或者他們是否真的會吃。
  • 它確實對計劃有所幫助,因為它有助於防止人們將他們的個人速度設置得過高(如果將其自動設置為20%的緩衝區)。
  • 在大多數情況下,它從未使用過。
  • li>

五分之一的迭代次數

我們花了很長時間進行了兩週的迭代。因此,該想法的下一個實現是,您將在每五個副項目中花費一個迭代。這工作得相當好–大大優於以前的版本。一些注意事項:

  • 從產品的角度來看,這使事情非常可預測。您確切地知道您會損失幾週的時間,並可以據此安排工作。
  • 另一方面,安排衝突很常見,因為團隊會在下周安排發布,並且需要進行模擬部署或最後一刻測試完成。因此,他們經常會發現自己的日程安排不正確,並且由於需要他們在部署或代碼方面的專業知識,因此很容易破壞別人的20%的時間。
  • 它並沒有真正幫助您提高利用率問題。
  • 沒有完全同步迭代的團隊(我們都沒有做到)無法真正有效地在更大或更有趣的項目上協同工作。

五週之內

然後,我們開始轉向看板系統,並開始考慮數周而不是迭代,因此我們在五分之一的迭代中轉換為五分之一的一周。

  • 與部署的衝突(頻率)更常見,但通常產生的影響較小,因為阻止一個星期比阻止兩個星期更容易。
  • 由於每個人都每週工作,因此與其他團隊同步變得更加容易。

除此之外,它非常類似於五分之一的迭代。

每季度的時間段

這是我們正在嘗試的當前系統。這裡的想法是,您在看板板上為自己設置任務,並分配給該季度的時間分配給他們。時間不會在每個季度之間滾動,但是您可以將其全部放在前面,也可以全部放在結尾,也可以按照自己的意願分成小塊。這樣一來,個人和團隊就可以根據發佈時間表確定最適合他們的方法,並根據他們的時間表,嘗試執行的操作等,花費不超過一周的時間增量。

這解決了我們之前遇到的許多問題,但是它的缺點是必須對時間進行更嚴格的管理,並且很難精確地預測時間。另一方面,它可以處於較低的中斷級別。

#2
+21
jcmeloni
2012-04-21 20:28:06 UTC
view on stackexchange narkive permalink

我在與執行“ 20%的時間”(即使只是“ 10%的時間”)類似的組織中工作過,我將在我剛加入的公司中實施這種事情。

如何問題的答案是“仔細”。這並不是一個傻瓜式的回答,而是對一個我們不知道貴公司細節的廣泛問題的真實回答。 “小心”是指:

  • 在上級的支持下,或者至少是對所發生的事情的默契地保持一致
  • (不要實施該程序,然後執行
  • 通過對嘗試的人提供支持(不要貶低工作產品,並慶祝輸出結果)
  • ,並了解在開始時您可能會看到正式分配人員的項目的直接收益(或產出)較少

這導致您實際上沒有問到這個問題,這是為什麼在第一個案例中這樣做地方?了解其背後的“為什麼”將使您對子問題的以下這些回答更有意義。

那20%的時間的邊界是什麼?

無論您想要什麼,都可以通過某種方式增強公司的產品或其資源(例如您)。

如果我必須工作40個小時才能按時完成項目會怎樣? (等等)

如果您沒有時間花額外的錢,那就不要。

如果您查看的第一行您鏈接到《紐約時報》的文章,其中說:“鼓勵工程師鼓勵花20%的時間從事與公司相關的個人感興趣的事情。”強調我的。

鼓勵。不強求。 “ 20%的時間”與“強制性樂趣”或“超出實際任務的額外工作”無關。這是自願的,與在工作場所發現和鼓勵動機有關。

值得注意的是,這不是Google發明的-便條紙是在1970年代初出現的,因為 3M員工用他的“ 15%的時間”來實現夢想。 >

Daniel Pink, 驅動力:激勵我們的真相的作者自己的生活),精通(希望在重要的事情上變得更好)和“ 20%的時間”或 Atlassian的聯邦快遞日的許多示例,這是為期1.5天的活動,旨在培養創造力,抓癢,獲得基本想法的牽引力,並(最終)獲得樂趣,以讓他們更快樂,更有動力並與員工互動為核心的願望是,理解到在其他80%的投資中,投資將獲得更好的回報時間,如果這些是對您有用的東西

回到最初的問題“公司如何做到這一點”?我返回“認真”的答案,但還會添加“ with gusto!”

這是一個很好的答案!
#3
+8
Jim In Texas
2012-04-16 21:09:05 UTC
view on stackexchange narkive permalink

我在一家自稱為“以結果為導向的工作場所”(有時也稱為“ 以結果為導向的環境”)的公司工作。

ROW團隊拒絕了工廠的僱傭模式支付給經理和工頭的費用,讓他們在無法信任的孩子等羊的工廠車間騎牛。

[此外:在美國,國防承包商被政府合同要求迫於泰勒主義。這可能是造成常見的巨大成本超支和頻繁錯過交貨日期的原因。]

工廠模型工作環境有時在 Fredrick W Taylor之後被稱為“ Taylorism”。

採用泰勒(Taylor)類型結構的軟件團隊無法實現Google的20%概念,僅時間跟踪將非常昂貴且分散注意力。既然20%的項目中有很多(大概是大多數)都不會帶來短期利潤,那麼泰勒風格的公司就不會繼續進行長期試驗。

我從沒在Google工作過,但我懷疑他們是ROW類型的組織。我懷疑Google開發人員與他們的團隊負責人一起制定了預期結果的時間表,該時間表將開發人員的20%的項目考慮在內。我懷疑只要開發人員按照商定的(或未實施的)計劃或多或少地交付結果,就不必擔心有人花了多長時間吃午餐,或者他們上週在9%的時間上完成了20%的項目

乍得-我編輯了原始問題以進行推測,因為否則只有Google管理層可以回答。我希望這似乎是明智的猜測,因為我的組織雖然沒有正式的20%的政策,卻允許員工有很大的個人自由去試驗和學習公司的時間。
乍得很好,但是按照書面記載,除了Google經理以外,其他任何人都無法回答這個問題。問題的措詞應允許非Google員工以某種方式回答。這意味著無論我們是否喜歡這個詞,答案都將涉及“推測”。
“顯然如何”在“計劃如何有效實施”時,不應以“不,你不能那樣做”來回答。
我很高興您提到泰勒主義。 YouTube上有一個很棒的紀錄片,我會在今天晚上嘗試找到。
#4
+3
HLGEM
2012-04-16 23:54:40 UTC
view on stackexchange narkive permalink

我將嘗試回答以下問題:

或者軟件開發組織如何實施類似的“ 20%項目”概念,從而使管理層,客戶和員工。

在我看來,在工作場所實施此類工作需要克服幾個障礙。您必須意識到,這是一項業務決策,因此必須可以按業務術語出售給高級管理人員。

首先,開發人員的薪水目前是如何支付的?如果像我工作的地方那樣,大部分開發人員時間都花在了針對客戶的特定項目上,那麼花在非計費工作上的時間中有20%將會是很難的。支付這些薪水的錢必須來自某個地方,而任何有關此提議的提議都必須指明從何處來。我看到三個基本選擇:公司從當前利潤中收取費用,公司提高向客戶收取的小時費率以支付費用,或者公司將更改給客戶的小時數提高20%(可能會或可能不會是合法的)。如果您不執行客戶可計費的工作,那麼第一選擇就是您的唯一選擇。如果這樣做,那麼第二種方法(如果這是很大的話)可能是可行的,並且提高利率時不太可能會失去客戶。在我看來,第三個選擇似乎並不切實可行,除非我知道這是合法的,否則我不會建議這樣做。

無論如何出售提案,您都必須證明他們會從中獲得收益。與製藥公司的R&D類似。這是巨大的風險和巨大的成本,並可能帶來巨大的回報。但是如何確定它是否有回報呢?好了,這是您必須跟踪個人項目的地方。因此,如果您提出這樣的建議,請確保為要跟踪實施並跟踪成本節省或新利潤的個人項目設計一個系統。

您將不得不量化業務方面的潛在收益。討論吸引最優秀人才的能力,由於更高的員工保留率而降低的成本以及上述潛在利潤。

接下來,您必須顯示如何使用小時以及如何調整項目計劃以允許時間。這意味著最後期限將被淘汰,這也不是一件容易的事。我建議在每週一次的惡習中最多收取20%的小時數是最合理的。是的,如果您當月不這樣做,您將失去它,除非在特殊情況下,管理層一次決定一個。您還可以考慮在主要項目之間的休息時間中安排部分或全部時間。告訴外部客戶在6月1日之前沒有人可以工作,並且該項目將花費40個工作日,比告訴他們將在5月15日開始並花費48個工作日要容易一些。其中一些必須考慮您當前的業務方式。大多處於維護模式的團隊不會這麼容易定義停機時間,但是對於較短的項目,每週查找工作時間可能更容易。

您還必須解決,我們購買更多人或將截止日期移出,以佔額外的20%。

#5
+2
mhoran_psprep
2012-04-16 17:11:41 UTC
view on stackexchange narkive permalink

有這項政策的公司可以最好地回答這個問題,但是我曾與一些嘗試過但未能使用它的組織合作。

  • 在40小時內每週工作8個小時,不是用來消磨時間,而是有效地消磨時間。在一個組織中,這20%所需的文檔數量意味著4個小時的時間都浪費在文書工作上。

  • 一個小組希望員工每週投入60個小時,因此沒人知道應該工作48個小時還是進行12個小時的實驗。或60個小時的工作,然後在一周結束時進行實驗。

公司或員工要跟踪小時數以便可以用來平分工作量的想法聽起來像是一場管理噩夢。這也意味著員工知道管理層正在跟踪時間,並由管理層決定哪些項目值得進行。

如果聽起來不那麼有趣,或者與其他項目相比壓力較小項目,我對此不會感興趣。

我以某種方式懷疑Google是否真的浪費了20%的時間來完成文書工作。哪家公司需要這樣水平的文檔,為什麼需要它?
閱讀過有關Google政策的文章的小組是必需的,但他們實際上是微觀經理。
微管理!= Google。我不會把這當作違反20%規則的標誌,只是不稱職的公司。
如果公司的目標是通過最大限度地減少勞動力成本來實現季度利潤最大化,那麼管理層或員工當然將無法理解20%的``偏離'';另一方面,如果公司製定了旨在吸引員工的工作環境的政策,世界上最好的員工,以便實現其行業的長期世界統治地位,那麼20%的“優惠”似乎是不小的代價。
@JimInTexas我要說的是,這要復雜得多,工作時間為100%並不意味著生產時間為100%。谷歌的“ Goof off”項目有時也變成了真正的產品(Google Play當前的設計是“ Goof Off”時期)。我認為這裡的很多人都無法理解Google的政策以及實際發生的情況。
-1,因為您要說明的是一家無能的公司將如何做到這一點,而不是如何正確實施。
出於與Rarity相同的原因,我必須將此設為-1。
#6
+1
Thaddeus Howze
2012-04-20 03:29:53 UTC
view on stackexchange narkive permalink

在此之前的所有想法使安排時間變得比需要的要復雜得多。 20%是每週的一天。這樣,在“正常”項目上花費了四天的時間。每週四天的一天用於“其他”更具啟發性的工作。嘗試此過程以獲取大小。

  1. 這種想法聽起來已經賣給了高層人士。如果是這樣,則沒有任何工作可做。
  2. 如果要實施該項目,請以每週一日的20%的價格執行。
  3. 在第五天期間(連續4個星期五,第5個星期五)展示作品。
  4. 第六個星期五,選擇最出色的項目。將其添加到優化隊列中。
  5. 接下來的四個星期五圍繞項目開發工作,確定項目是否具有真正的價值。
  6. 如果這樣,請將其作為主要任務添加到主要工作計劃中。設計並開發一個Alpha版本。
  7. 演示Alpha,並確定是否要進一步。保留其他值得考慮的其他項目的清單。
  8. 如果選擇了該項目進行進一步的開發,請將其添加到開發隊列中。請等待一個月,以使項目穩定,沖洗並重複執行
  9. 您應該每年至少可以執行四次。
  10. “失敗”是指除前8個項目之外的項目以後隨時可以再次查看和修改。
  11. ol>
#7
+1
Scott Stevens
2013-01-11 05:47:31 UTC
view on stackexchange narkive permalink

我同意其他評論,即應該非常謹慎地這樣做。我認為您也許應該爭取以下方面:

1)平衡的目標。您希望您的員工從事可能使您的公司受益的項目,但是,您不一定希望對他們這次決定採取的控制方式過多。如果您告訴他們可以進行哪些工作,他們會認為與添加其他項目沒有什麼不同。

2)正常工作時間。如果正確執行了20%的規則,您的員工將在下班時間進行工作。但是,我不需要它。這與“平衡目標”相吻合。如果您告訴員工您希望他們在當前時間之外的20%的時間內從事什麼工作,他們將會看到花哨的行話,並被視為強迫加班。但顯然,他們的正常工作職責是優先的。您將必須努力工作,以確保限制他們的正常工作,以免侵擾他們20%的時間而不是實際的時間。我還要補充一點,如果在仍然有很多工作要做的情況下,如果您遇到員工僅加入工會40的麻煩,那麼您很有可能遇到士氣問題。開心的員工會花點時間完成工作。

3)認可。您需要認識到員工所做的工作。確保您認識到成功,努力和創新。並非他們擁有的每一個想法都是本壘打。但是您需要鼓勵參與。他們需要看到您重視他們的想法和貢獻。

4)樂趣。您希望您的員工對此感到開心。通過這種方式,他們可以發散知識力量,與通常可能不會互動的其他部門和小組交談,發現他們不知道的問題或想法。這不僅是軟件工程師的練習,也是商務人士的練習。通常,軟件端和業務端之間缺乏通信。軟件人員正在構建業務不需要的解決方案,並且業務需求不知道每天都有針對他們所面臨問題的軟件解決方案。

5)反饋。給雙方一個相互交流的機會,他們頭腦中的齒輪就會開始磨碎。通常,您的里程可能會有所不同。我認為最終對您來說最重要的資源是您自己的員工。不要只是從堆棧在線徵求反饋。徵求員工的意見。他們將很高興您提出要求,並希望有機會找到一種可以與他們一起工作的方式。最終,我認為20%的規則是一種提高士氣,產生想法並扁平化組織的機器。我認為這有助於消除許多企業文化所困擾的官僚主義。如果您的公司面臨挑戰,那麼就有可能有人可以解決這些挑戰。他們可能不是您期望的人。傾聽您的員工,找到適合您的方法。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...