題:
我應該向同齡人透露生產力竅門,還是讓他們自己聽以提高生產力?
SOUser5588
2019-09-28 20:11:31 UTC
view on stackexchange narkive permalink

我正在擔任軟件工程師,並與其中一個產品的團隊合作。

在工作期間,我開發了一些生產力工具和技巧,可以使一些重複性任務自動化並顯著提高生產力。

p>

現在我很困惑,是應該將這些內容透露給同齡人還是應該保密,以顯示出比別人更高的生產率?

我沒有什麼要透露的問題,但是這將是短期的認可,但是如果我將其保密,那麼我可以不斷取得良好的成績-比其他人更好。

您在世界哪個地區?習俗有所不同。
可能重複[與工作中的同事共享知識有什麼問題?](https://workplace.stackexchange.com/questions/42255/what-is-wrong-with-sharing-knowledge-with-colleagues-at-work)
相關/重複的文章:[我應該通過保持自己的全部技能來在公司中保持不可替代的地位嗎?](https://workplace.stackexchange.com/q/18249)[我應該幫助他人還是將自己的知識保存給自己?](https://workplace.stackexchange.com/q/56142)
@Harper印度地區
十二 答案:
Kate Gregory
2019-09-28 20:18:30 UTC
view on stackexchange narkive permalink

如果您公開公開它(也就是說,每個人都知道您已經培訓了同行),您不僅會提高工作效率,而且整個團隊也會提高工作效率,管理層也會知道原因。通過提高團隊和公司的利益,您將被視為做出重要貢獻的人。您更有可能獲得晉升(例如​​,成為團隊領導)或獲得棘手且重要的項目。您的慷慨將帶來積極的結果。

如果您只告訴一個或兩個喜歡的人,管理層可能會注意到團隊內部的生產力差異,但他們的猜測可能對您不利。他們可能會認為您中的某些人只是在從事更輕鬆的工作,或者隱藏您的錯誤並讓其他人處理它們,或者其他可能對您將來的晉升不利的事情。更重要的是,與您沒有共通之處的人可能會發現正在發生的事情並開始不喜歡您,或者在需要時拒絕幫助您。

如果您不告訴任何人而您只是您團隊中最好的程序員,您可能會感到很重要和成功,但成就卻遠遠不及預期。真正的10x程序員可以通過幫助其他人,通過提升整個團隊而變得更好而達到這一水平。

還需要考慮另一件事:也許您的同輩可以分享一些技巧和自動化知識,以提高您的技能並速度甚至比他們還要高。

我的建議:去找老闆說:“我已經自動化了一些事情,並使用我們的工具開發了一些技能,這些技能使我比團隊中的其他成員快很多。我想分享這些。我可以安排午餐並學習並邀請人們學習我的技巧並分享自己的技巧嗎?”這表明您在乎,您很慷慨,您會主動。

評論不作進一步討論;此對話已[移至聊天](https://chat.stackexchange.com/rooms/99292/discussion-on-answer-by-kate-gregory-should-i-reveal-productivity-tricks-to-peer)。
這嚴重依賴於管理層思考和認識共享的方式,但並未解決該(樂觀)假設。
simplemind
2019-09-28 20:44:23 UTC
view on stackexchange narkive permalink

我幾乎同意凱特·格雷戈里(Kate Gregory)的答案中給出的所有要點,但會提出兩個小的更改:

首先,我不會說“讓我比其他人快很多” (即使是真的)。我會“大幅度提高我的生產力”。

第二,我不是“午餐和學習”(即使算作工作時間)的最大擁護者,因為許多人喜歡談論那些並非在午餐期間進行與工作相關的更改。因此,我只建議在工作時間召開例會。

但是,這只是挑剔,我認為Kate Gregory的回答是合理的建議。如果您的某些同事沒有您預期的那樣熱情,您會感到失望:有些人不喜歡他們正常工作流程的變化,或者他們還有其他原因不使用建議的工具。因此,請向他們提供建議並給予支持,但不要強迫他們使用您的方法。

我同意這個答案的觀點,並且會補充說,通常沒有魔術的子彈(除非現有的工作流程很愚蠢)
如果您確實想說服人們您的方法更好,那麼您將需要數據來備份它。人們對此做出回應。
-1
-1
@Derek哦,我同意,我的意思主要是,這裡有一個不容忽視的情感方面。人們開始喜歡他們的工具。當人們考慮進行較大的基礎架構更改時(例如,將源代碼控制從TFSVC更改為Git),這對於不得不加入人員的人來說是一個更大的問題。
@Derek我同意Voo。例如,我***討厭***自動完成(在一定程度上)。它確實使編寫代碼快得多,並且在這方面客觀上更好(自動關閉HTML標籤,關閉字符串,打開和格式化括號)。但是我不喜歡使用它,只是為了停止自己關閉字符串/標籤而be頭。如果從現在開始強制執行自動補全功能,我將非常不滿意。
@Derek,和一些人只想手動執行所有操作,因為他們不信任自動化,即使他們從事自動化業務。我已經從我編寫的幾個腳本/實用程序中退縮了,這些腳本/實用程序可以使事情更快,更準確/更可靠,這僅僅是因為它們是手動“總是完成”的。此外,自動完成功能也已到位。如果在放置結束標籤/支架/等方面變得更好,那麼它將變得更加有用。
@computercarguy我不特別喜歡自動化,因為我從事自動化行業,可以看到它實際上是多麼脆弱和有限!我作為IT專家的工作基本上是在現有軟件無法處理的異常情況下介入並修復問題。
@ivan_pozdeev,如果您不信任與之打交道的事物,那麼如何讓任何人信任它?聽起來您的工作類型錯誤,因為您不相信自己的工作。我相信我的工作將一直有效,直到無法控制的事情來改變它,然後我改變為適應新事物所做的事情。在任何事物中,這都是生活的事實。此外,自動測試結果和代碼也非常有用。您是否擔心院子裡有人會開車闖車而留下車轍?不用擔心的那種不受控制的變化。
user106441
2019-09-30 18:14:18 UTC
view on stackexchange narkive permalink

在分享之前,我會三思而後行。

  1. 眾所周知,很多人都在使用這些技巧。
  2. 您的經理通常會欣賞聰明的事情嗎?
  3. 您的經理是否有可能與您分享自己的創新功績?
  4. ol>

    很多從事Stackexchange工作的人都在獎勵創新,自動化和團隊合作的地方工作,但是並非每個工作場所都是這樣。您之所以在此發布,是因為您懷疑共享是否會帶來好處。

    共享巧妙的創新真的很爛,只是讓您的老闆感到愚蠢並為此受到懲罰。

很好,我曾多次看到(並從可靠消息來源獲悉)團隊成員想出一些使事情變得更容易的創新,與他人分享並立即由高級人員關閉的情況。通常,我發現這種情況發生在創新“應該”已經由另一個團隊完成但沒有創新的情況下,從而導致“待在自己的車道上”!拒絕建議的人。您可以猜測那個人或任何其他知道此事的人會提出更多的創新機會...
...在一個案例中,這個人特別有韌性,並提出了許多改進/創新建議,但都被拒絕了,不再贅述。您知道什麼,幾年後,當他們縮小規模並外包時,大多數“創新”都是由外部顧問強加的,然後被接受!
哎呀,這些地方真令人窒息。如果您在這樣的地方工作,我建議您有條件的話就找一份新工作。如果您還有其他原因:IME這類地方也很容易裁員,因為他們將軟件開發人員像商品一樣對待(當然是YMMV)。
asgallant
2019-09-30 22:16:19 UTC
view on stackexchange narkive permalink

Kate Gregory給了一個很好的答案,但我想在此基礎上進行擴展,並提出另一個分享理由:同行評審過程。您的工具可能“使某些重複性任務自動化並顯著提高了生產率”,但是如果這些工具有錯誤怎麼辦?如果有充分的理由手動進行操作怎麼辦?

從經驗上來講,我做的事情與你做的很久(很久以前)。我寫了一些工具來自動化工作中最無聊和乏味的部分(數據分析實習的數據輸入部分)。這些工具加快了我的工作效率,使我可以在一個下午處理與手動輸入其他幾個星期相同的工作量。我為自己的工具集感到自豪,並與團隊的其他成員分享了我所做的事情,這是一件好事:存在一個嚴重的錯誤,它擾亂了兩個領域之間的數據,這會使從數據中得出的研究結果完全無效。如果我自己to積工具(並通過擴展使自己看起來像一個富有成效的搖滾明星),那將對數據集造成巨大破壞,並迫使對所有數據進行廣泛的重新檢查和準確性檢查。

共享您的工具,並準備讓別人告訴您您做錯了什麼,或者可以做得更好,或者您的工具不適合您的特定任務。

我還沒有看到任何一個例子,從長遠來看,人類不會比工具引入太多,*更多*的錯誤,特別是對於單調任務。更重要的是:您只需要修復一次即可編寫測試工具來驗證結果,對於人類而言,您只需要接受一個事實,那就是會有不小的錯誤數量(而且反復出現相同的錯誤)。而且,如果需要對數據進行創造性的檢查,則應將其集成到過程中,而不要將嬰兒與洗澡水一起扔掉。
總體而言,@Voo表示同意。我的觀點是,未經檢查和驗證無法產生正確輸出的工具可能會導致更多問題,而不是解決的問題。
啊,那我誤會了你,我絕對同意你的觀點。
gnasher729
2019-09-28 20:42:40 UTC
view on stackexchange narkive permalink

人們會發現。如果一家公司需要放任某人,那將是那些專注於以犧牲他人和公司為代價而善於表現的人。因此,一旦您的經理髮現了,您就會遇到麻煩。

最好公開提高整個團隊的生產力。但是然後您沒有提及您在哪個國家工作,所以可能會有所不同。

這在很大程度上取決於管理風格-他們很好地選擇保留“頂尖績效”而不關心他們是什麼。華爾街經典管理。
否則他們會發現並要求您將別人的工作自動化而遺忘(讓您,專家和才華橫溢的程序員陪伴在身邊)。
這太籠統了:您是否沒有隻尋求獲得知識卻不分享知識的同事?他們可能是經理的伙伴。如果公司遇到困難,它們將不會是那些首先放手的公司。
人們會發現什麼?你有一些使自己有生產力的想法嗎?所以呢?只要您合法且沒有作弊,這有什麼問題?我同意分享知識,但出於某些原因,因為人們會發現您,而且您會被解僱,所以我並不同意。
這在健康的工作場所有效,但有毒的工作場所將擺脫“製造麻煩”的人。這可能是通過不斷提供建議和改進來不斷“抱怨”工作量,工作流程和其他任何事情的人,“好像他們不信任mgmt來最了解”。提供建議可能會在某些地方“破壞”經理的“權威”,所以了解您的辦公文化是回答此問題的關鍵,因為我已經學到了很難的方法。
我認為沒有人會發現“ OP試圖以犧牲他人為代價來使自己看起來不錯”(除非他們發現了這個問題)。他們會認為“ OP很聰明,但是不分享他的知識”。第二個沒有第一個壞,因為沒有假定的惡意。給出了這個問題,OP會(在所討論的主題意義上)具有惡意,因為他意識到自己可以幫助他人,但是看起來並不會更好,因此第一行是正確的,即使很難證明。
Anthony Taylor
2019-09-30 19:30:18 UTC
view on stackexchange narkive permalink

您需要考慮的最大的事情是

  1. 您要發展公司
  2. 您要發展事業嗎?
  3. ol>

    很多答案是,做對公司最有利的事情,而不是對自己最有利的事情。如果您自己掌握這些竅門,並且由於成為公司中生產力最高的開發人員而獲得10,000美元的薪水高漲,或者您與他人共享,則可以為公司節省10,000美元的費用。

    這取決於您的生活觀點,無論哪種方式都可以。

這是一個非常自私的答案,可能導致工作場所充滿毒氣,無法分享。我同意您需要提防自己,但提高同事的生產力可以使您獲得晉升並提高您應得的/需要,以及使您以後獲得更高的薪水,這對您更有利。只有在共享改進對您不利的情況下,將改進保密才是最有效的方法。
@computercarguy確實是一個自私的答案,但是許多工作場所已經有毒,許多人已經自私。我可以想像這樣一種情況:最好讓卡片靠近胸口。在OP等情況下的讀者必須明智地判斷。
@Agent_L,是的,我同意,並在其他答案的評論中也是如此。但是,此答案並不能斷定它是否是針對已經有毒的工作場所而作出的,它只是將建議隨時提出來使用,大概與工作場所有毒還是健康無關。缺乏說明僅在有毒環境中使用此試劑的原因是我評論的原因。
自私自利將立即為您提供幫助,但慷慨地從長遠來看將為您帶來更多收益。畢竟,我們向他人學習並讓我們回饋一些東西。
d-b
2019-10-01 00:38:16 UTC
view on stackexchange narkive permalink

在升職後分享他們。這樣一來,您的團隊就會比其他團隊看上去更好(當然,隨著時間的流逝,知識將會傳播)。

我不同意大多數其他答案。您將因分享您的技巧而獲得讚譽,但第二天將被忘記。

Dominique
2019-10-01 00:46:34 UTC
view on stackexchange narkive permalink

逐步工作如何?這就是我要做的:

我首先向團隊其他成員分享一個或兩個技巧/竅門,然後檢查他們的回應:有人可能會說:“嘿,那是你教給我的一個巧妙技巧。讓我教你一些你不知道的東西:...”。如果您有這樣的同事,請繼續分享您的提示/技巧。但是,如果他們沒有共享任何內容作為響應,那麼您將來也沒有理由共享任何內容。

raubvogel
2019-10-01 09:07:25 UTC
view on stackexchange narkive permalink

恕我直言,您將必須了解您的環境並親耳聆聽。我在一些工作氛圍濃厚的地方工作,這些分享方式使工作變得更好,而其他人則沒有。後面的小組的一個變體將與某人合作,該人會欺騙您,然後去找您的老闆,並說服他進行一些“改進”,以使您的老闆將他作為改進的項目經理。

是的,這是我之前發生的事情。

因此,請考慮您的企業形象,時間安排和團隊動態。並註意您的團隊。如上所述,您可能不會因為惡意而遭到拒絕,而僅僅是因為該團隊過於頑固地嘗試其優化想法。我和一個項目經理一起工作,他認為擁有一個回購協議(甚至是內部回購協議)是巫術(我在凱蒂學校接受教育,開發,更新回購協議,然後從回購協議部署),而不是用副本填充他的 local drive 他的工作。當他超越我時,與他吵架將很快成為事業的終結。您還可以整理技巧(將其通用化,而無需參考您的工作,以便其他人可以使用),然後將其保存在博客中。您仍然會在幫助別人,但也會在幫助自己。

這裡有一個關於分享的爭論:不要成為英雄;不要成為英雄。業務不應該依靠英雄來經營。使自己僅對解決一些問題至關重要,這可能會使您很難晉升。

關於共享,您還應該考慮另一件事:無論您共享什麼知識,都是受時間限制的,就像一旦完成,就轉向新事物。如果願意,請使用工具/技術並進行共享,下週您可能會想到一些新的東西。不要依靠過去的輝煌。教別人,以便您繼續前進。

我知道我的回復不是共享還是不共享的好理由,但這是有目的的:沒有絕對正確的答案。最佳答案應適合您的情況。

mckenzm
2019-10-01 07:54:22 UTC
view on stackexchange narkive permalink

假設您的任務需要12個小時。您花了20個小時來開發自動化,從而將其減少到5分鐘的工作量和4個小時的“監視”時間。有投資回報率要考慮。訓練其他人使用它可能需要2個小時。

總的來說,這意味著共享,但是在可信任的圈子內,例如,在不了解“全局更新”的情況下,不要讓同伴工作。尤其是如果您做錯了什麼(雲,外包,盜版軟件)。

有兩種方法可以解決此問題。如果您的團隊是半自治的(Agile?),則在團隊內部共享該團隊,並編寫一個尋呼機。永遠不會告訴客戶,您會接受維護費用,並繼續向客戶收取12個小時的費用。

如果管理層意識到了這一點,並且您的組織在程序方面仍然保持不變(CMMI 5級?)。然後,您可能會被迫簽署該協議,並在接下來的三個月中將其記錄下來(並使其“合規”)到現在需要10個小時的時間,以及通過各種指標來衡量收益的其他流程需要另一個FTE進行測量和製表。一旦編寫了這份辦公桌手冊,任務就可以簡化為發送到“便利岸”的票證。

哦,當然,如果其他人可以損害您的快捷方式,那麼當怪罪遊戲開始時,那將使您離開哪裡呢?

我想起了一個有趣的故事:能夠對齊並閃爍T型福特上的發電機磁鐵(使其再次堅固)。它節省了絕對的時間,這是今天仍在舊車上使用的一種方法,但是早期仍向客戶收取了預定的費用。

您的客戶可能並不愚蠢。他們可能還希望這些改進是顯而易見的,而且如果競爭對手指責您進行過度維修,那將不是什麼好事。

MonkeyZeus
2019-10-01 21:59:35 UTC
view on stackexchange narkive permalink

揭露是什麼意思?人們是否在問你“你過得好嗎?”?

無論做什麼,都要做強加給別人的生產力把戲,因為這會使人們不想和你一起工作

我個人的工作效率技巧包括使用鍵盤快速導航我的操作系統並執行一些普通的事情,例如切換窗口,關閉事物,打開其他事物,執行複雜的搜索等...

當我解決問題時,每當有另一個程序員站在我旁邊時,他們總是會留下深刻的印象和嫉妒心。但是,他們從不要求我教他們。嘗試複製我所做的事情可能會對他們及其工作效率造成危害,因此,我指出絕不要強加於人,當我看著他們“慢慢地”使用他們的計算機時,我當然也不會插話。

調出您的“技巧”,因為如果您希望團隊以任何程度的統一性採用這些技巧,很有可能需要對這些技巧進行審查或至少對其進行充分的記錄。

Monoandale
2019-09-30 22:54:34 UTC
view on stackexchange narkive permalink

不,您永遠不應該向同行透露您的生產率技巧。但是您應該一點一點地向您的直接報告展示它們。您的能力是一種力量。在組織中釋放權力之前,首先要確保可以與其他權力進行交易。否則,您只會使自己的職位在組織中變弱。真的是代數。

我理解您在說什麼,但也許您應該對答案進行編輯,因為當前的第一句話與第二句話不同,正如您所說的“從不”。順便說一下,我沒有投票。
區別在於“對等”和“直接報告”之間。
我贊成,因為它似乎是可行的。但是,我不確定將來是否會在*我的工作場所*繼續提出建議(這可能不是一般的工作場所解決方案)。


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