題:
我如何在軟件公司中鼓勵守時文化?
Jacob G
2012-04-12 22:34:49 UTC
view on stackexchange narkive permalink

作為新公司的新技術負責人,可以採用哪些其他策略來改變開發團隊的文化,以便人們在我要求的時間露面?

TLDR :我的團隊沒有按時出現。我試圖強迫他們,但它不起作用。

背景數據:

  1. 小型公司,有30名員工,我團隊的5名成員。
  2. 以前的領導者仍然是常規開發人員。
  3. 我來之前的文化是非正式的,沒有固定的界限或核心時間。這種文化沒有受到公司領導者的挑戰。因此,團隊中的大多數人會在10:30到11:00之間出現。
  4. 其他部門由於工作性質的原因,將開始時間設置為8或9。
  5. ol>

    這種差異和不可預測性引起了我之間的諸多焦慮。部門和其他部門。因此,我讓團隊坐下來,並指定了“不遲於” 9:30的時間。我解釋了我的推理,並解釋了這種方案的好處和當前方案的負面影響。這是一場漫長而有爭議的對話,團隊中5個人中有3個人非常不滿意。

    不用說,人們沒有按時出現(而且9:35不按時出現)。

    我已將每天的站立會議安排為9:30,作為額外的激勵因素。知道轉換開始時間(上下班等)需要一點時間,所以我最初將等待開始會議,直到每個人都出現為止,但是現在我只是以以下方式開始會議(並且通常是結束會議):無論誰在場。

    基於個人和小組的對話所產生的結果與原始對話的結果相同(即,他們看不到價值,想想)我拿走了這份工作的津貼,等等...)

    我得到了高級管理團隊的全力支持和支持,並有權使用我認為合適的任何設備來對此進行照顧。

    我目前的下一步是將某人送回家做他們請假。太過分了嗎?我是否忽略了其他可以幫助我解決此問題的策略?

    根據Jarrod答案中的問題進行編輯

    技術線索的最新情況?在此問題發生時,在這家公司住了6個月。

    您為什麼要強加非技術性的管理政策?這在我的職位範圍內,由執行管理層定義。

    您的管理憑據是什麼? 10年的技術主管經驗。沒有任何管理方面的正規教育或證書。

    您以前有什麼人事管理經驗?我已經擔任技術主管10年了。我負責招聘/解僱/面試/審查/領導/建立一些不同的技術團隊。

    您是否以技術方式贏得了團隊的尊重?

    您在管理上贏得了團隊的尊敬嗎?團隊對我的技術和管理能力進行了採訪。對於我喜歡如何運行技術團隊以及如何運行項目,我很清楚明了(很明顯,這只是一個起點,文化和人員最終會影響我的工作地點。)從管理的角度來看,團隊對此感到非常滿意。

    以前的技術負責人是否下台了?是的。

    以前的技術負責人被降職嗎?不。這是他的要求。

    以前的技術領先者有效嗎?。但是,隨著公司和代碼庫的發展,他的風格失效了。

    現有團隊中的大多數人是否與以前的技術負責人有更私人的關係?是的。

    以前的技術領先者是否仍然有效?否。

    然後,[以前的無拘無束的非正式文化]必須具有一直在工作嗎?曾經有一段時間,當時該公司還是一家初創公司。它已經遠遠超出了啟動階段,並且已經發展壯大,並且由於這種增長,其有效性已不如從前。尤其是在其他部門引入了更多的形式性和可預測性之後。

    團隊是否如承諾的那樣成功交付了有用的產品?。但是,隨著公司和產品的增長,質量和交貨時間大大縮短。

    聽起來您甚至沒有考慮或基於團隊的負面反饋而與您的團隊或外部團隊探討某種折衷方案。是嗎?當然可以,我不是菜鳥。事實是,我尊重一個事實,即公司的其他部門由於其職責的性質而無法靈活地工作。團隊不願意在彈性工作時間上做出讓步,在許多情況下,其他部門也無法做出讓步。我還專門與其他部門一起解決了負面反饋,並實施了一些措施來使事情變得更好。這項變更的最大好處之一就是提高了可預測性和變更感知。

    最終更新

    原來的5名乘務員已被替換。首先是先前的團隊領導。我們看不到如何進行開發項目,他也不能接受對他先前所下內容所做的更改,因此我們共同同意分道揚.。第二個人對這項工作失去了興趣,犯了兩個大錯誤,我們也共同同意分道揚。

    作為一個整體,該團隊現在已經足夠早出現,以確保為公司的其他部門提供足夠的覆蓋範圍。最終有效的是任務授權和同伴壓力。另外,已經進行的其他更改導致幾乎所有部門間的焦慮都得到了解決。每個人仍然可以按照自己的步調,在一家令人興奮的公司中從事令人敬畏的項目,大部分都是他們自己選擇的,儘管該地區的就業市場荒謬,他們都非常滿意。

    我被提拔為一個高管職位,新的“問題團隊”已經移到我下面(除了仍然保持對開發團隊的控制和不斷發展。)我現在正在努力幫助他們表現更好,並成為同事的更好的隊友。我沒有這個新團隊的守時問題...他們的問題是準確性和溝通能力。

也許是另一種動機,例如“甜甜圈” *僅*適用於那些準時或早點出現的人。每天做可能會很昂貴,所以也許每週只做一次,但不要告訴他們*哪一天...;)我從來沒有嘗試過,所以這就是為什麼我發表評論的原因比答案。
這個問題缺少重要的一件事:***為什麼***要進行此更改?工作沒有及時完成嗎?如安德魯(Andrew)在回答中指出的那樣,是否存在需要解決的實際問題(這是解決問題的正確方法嗎?可能是另一個問題的主題……),它決定了知識的任意“不遲於”開始時間已經擁有彈性工作時間文化的員工將變得不受歡迎,如果沒有更多的背景信息,很難提出激勵因素/方法...
@voretaq7:我認為“這種差異和不可預測性導致我的部門與其他部門之間產生了很多焦慮”,這意味著其他部門需要與OP的部門聯繫。當一個小組在上午9點進來並且依靠其他直到11點左右才露面的小組時,就會引起問題。
@FrustratedWithFormsDesigner可能不錯,但是如果開發人員在晚上8點將作品放到設計師的辦公桌上,明天早晨9點至11點之間進行測試,我認為沒有問題。我更喜歡協調而不是任意規則。我也試圖不做任何假設,但“焦慮”可能也很容易成為“銷售人員哭泣,因為他們也想遲到,如果沒有人也不能!”
您是否願意執行“校鈴”規則的另一面?每個人都停止他們正在做的事情,並且一次確定要離開,無論還有多少工作可能被撤消?
@JimInTexas,它更像是“核心時間”規則。您必須在9:30-4:00之間在辦公室裡……您可以選擇早晚擺動。
-1
@HLGEM不過,這取決於投訴的性質:有時,作為經理的正確做法是告訴其他部門“這就是我的團隊的工作方式,並且對公司有效。堅韌的岩石。” -在Jacob的情況下,儘管他的開發人員似乎因態度問題而被寵壞了[請參見聊天中的討論](http://chat.stackexchange.com/transcript/message/4208458#4208458)和以下一些評論。 ..
-1
@KeithThompson:部門之間的交互是頻繁的,並且經常是由於協作的需要。我們是一個小型公司,一個小型開發團隊,我們需要在SDLC中戴上帽子,支持我們的生產環境,並幫助其他部門滿足他們的可交付成果。公司中的許多人都有時間敏感的東西要交付,通常沒有足夠的交付時間來花幾天時間進行協調。我會盡我所能進行干預,但是我不能自己承擔一切,需要團隊中的其他成員隨時待命。
*不用說,人們沒有按時出現(並且9:35也不按時出現)。聽起來好像您需要小兵;在當前機組人員離職時尋找那些人格類型。
你說的那一刻(和9:35都不准時)立即給我的印像是你是一個嚴厲的老闆,我不太可能聽你說的話。幾乎每個地方的程序員都始終具有工作時間的靈活性,並且大多數時候人們都習慣於例行工作,當他們來時,他們不太可能是不可預測的。人們之所以這樣做,主要是因為最適合自己的方法,反過來又使他們更有生產力。
@JarrodRoberson和tsoverflow-顯然,你們歡迎您提出意見,但我認為您有點誇張。我既不是“專橫”也不是“虛假”,但我希望人們能準時出席會議並準備參加。
聽起來好像問題仍然出在您而不是團隊的其他成員身上。您在這裡有獨裁的語氣,我只能想像您是如何成為那些您應該“領導”的人的。我的感覺是,這是您第一次還是第二次擔任這個職位,您認為他們應該像您說的那樣做,因為您要負責。有好有壞的文化;您需要適應它並通過內部示例進行更改。您是來這裡尋求幫助的,但不想听任何人的意見。這確實應該是*我如何才能使員工順從我的意願?*
百吉餅,甜甜圈,咖啡等早餐散佈,上午9:30打包
我不知道你們的想法,但是爭論五分鐘並不是花時間陪伴團隊的真正有效或無益的方式。
@Spoike-可能只有5分鐘,但還很晚。如果他們甚至不能在TIME 9/10出現,那麼作者如何信任他們?
@Ramhound:每當我有人遲到開會時,我都“不在乎”。我最後要和準時的人聊天(討論日子,生活,其他事情……您知道的……對他們的了解會更好),然後在每個人都來了之後開始真正的工作。信任是您通過與他人互動而獲得的東西。懲罰(雖然在好萊塢大片中看起來不錯)不是您如何建立對他們的信任。
@Spoike我會說,習慣性地*在開會*之前要遲到,這表明沒有尊重別人應該解決的時間。該公司不應該讓五個人閒逛,不停地閒聊,等待每個人的到來。*一些*的閒聊是有價值的,等等,但是這種文化是一種會議活動直到幾經開始才開始的。排定的開始時間之後的分鐘數表示時間沒有得到重視和尊重。
@tsOverflow:如果站立會議的時間是9:30,那麼您只需要安排9:25的到站時間即可,如果出現問題,可以遲到5分鐘。
@MatthieuM :: OP決定首先讓每個人早上9:30來,然後他故意將會議安排在上午9:30來迫使每個人都早點來。像這樣有計劃地儘早安排會議與當時實際上召開會議而沒有使人在某個特定時間參加會議的根本意圖之間存在差異。
@JohnMcG:作為新經理加入,在不讓任何人承擔任何任務的情況下破壞事物是件大事,這是您不聽的標誌,也是不尊重的標誌。這樣的變化需要時間,甚至數年。在*要求*尊重之前,嘗試開始尊重他人。從編輯:他的團隊不願意犧牲彈性時間,我想這是因為他們對彈性時間既有興趣,並且可能簽約了這種工作。無論出於何種原因,處理經理和管理期望……或解僱團隊……都是您作為經理的工作,但這是一個糟糕的解決方案。
@JacobG:從voretaq7鏈接的聊天討論中,您的情況似乎可以概括為“我必須領導一個損壞的prima donnas部門,他們做得不好,與其他部門的關係不好,遲到了” -在這種情況下,“來晚了”是*您的問題最少*。您也許可以利用它來發揮自己的優勢,但是-如果您可以同意高級管理層放寬守時以換取其他方面的改進,那麼*並且*將此作為您團隊的交換條件,* *全面改進。
@Spoike-聽起來您將很難使用。在主管看來,您似乎並不認為“遲到”是一個問題。老實說,老主管採取什麼政策都沒關係。如果他們不喜歡上述更改,歡迎他們離開,新主管可以將他們替換為準時的人員。
-1
我仍然感到困惑,為什麼早上失去一兩個小時的窗口對與其他部門的協調如此災難性。如果您的開發人員每天花費超過一個小時的時間來做這種事情,那麼這對我來說是一個嚴肅的管理(不一定是OP的要求)或文化問題的指標。如果開發人員只是表面上的東西,那麼他們可能都是混蛋。也有可能有人每天開會數小時,以不斷更新他們甚至直到5點以後其他所有人都無法完成的所有工作的進度。我去過那裡/見過開發人員薪水的巨大浪費。
*我得到了高級管理團隊的全力支持和支持,並有權使用我認為合適的任何設備來處理此問題。*-您認為這將有助於您樹立守時文化嗎?祝你好運,老兄
@JimG。這僅僅是潛在的相關信息,有人可能會使用這些信息來製定生產性解決方案,以“鼓勵”而不是“施加”守時文化。隨時加入社區,並提供自己的高效解決方案。
問題是矛盾。
程序員的工作強度與其他部門的一名工作人員無法比擬,因此不能一視同仁。例如,如果您的工作是審查幾個簡歷或打個電話,那麼您當然必須在上午9點到下午5點之間去。我的意思是,有些工作沒有挑戰性的工作,但您整天都需要工作,而有些工作則有最後期限和大量工作要做,無論您何時進入工作崗位。早上。
*“我已將每天的站立會議安排為9:30,作為額外的激勵因素……” *-您稱其為*“激勵因素” *?我的天啊..
您是否有任何理由要強調自己是決定團隊事情的人?
OP聽起來像一個獨裁者。 “為什麼要強加非技術性的管理政策?這在我的職位範圍內,由執行管理層定義。”跳閘多少?
“我們以便宜的價格僱用了很多人,以換取超靈活的工作時間。現在,他們想改變我們的誘餌了。”如果您想“準時”將(核心)工作時間納入合同。
我是該站點的新手,我只想在這裡留下便條:作為一名開發人員,我想知道OP在他問這個問題時曾為哪個公司工作,所以我從未將簡歷發送給他們。
通讀問題,評論和聊天,我不清楚“取消津貼”的動機是在“我們需要部門之間協調”和“其他部門嫉妒我們的津貼”之間。可能是顯而易見的,但是如果您的開發人員認為第一個原因只是第二個原因,那麼您得到的反應是完全可以預測的:在您這樣做時,為什麼不降低他們的薪水以與其他部門保持一致呢?如果確實是“協調”問題,是否每天都有問題?如果沒有,必須有其他可能的解決方案
我想知道其他部門為什麼會有“焦慮”。您能詳細說明一下嗎?
-1
如果*他們[…]認為我正在拿走這份工作的津貼*是因為您在。它也可能是有道理的,必要的,不合理的,獨裁的,但這是無論如何。
那麼早起的原因是其他部門嫉妒嗎?也許您需要首先了解為什麼9-5成為標準,以及在遠程辦公時代它不再適用於大多數軟件開發人員的許多原因...
十七 答案:
#1
+155
Nicole
2012-04-13 00:42:13 UTC
view on stackexchange narkive permalink

最佳激勵因素是信任。團隊團結對於實現目標至關重要。規則文化是不信任的產物,執行規則的棍子和產品只會進一步削弱團隊的信任。

與其關注時間和非正式文化,不如去探究內在價值。

  • 9:30(或任意時間)真的重要嗎? 還是,是您的團隊需要確保他們不會因缺席而不會妨礙其他團隊的工作嗎?

  • 5分鐘會有所作為嗎? ? 或者最重要的是讓所有成員都參加日常站立嗎?

  • 非正式性是一個問題嗎? 還是是靈活性會帶來好處嗎?

我會深入探討這個問題的核心,那就是您的團隊沒有接受這個想法。查看斷開連接的位置,但避免創建規則區域性。將他們送回家遲到(在小學時會發現這種紀律手段)會使您的團隊相信您將它們視為無法信任的孩子。

+1-我認為這是表達問題和解決方案的最簡潔方法。無論您設置什麼規則,都需要幫助完成工作,這就是員工應該採用的方法。
我喜歡這個答案,我也同意。我相信我確實試圖讓他們理解潛在的問題,以及如何通過“核心時間”政策來幫助他們。一位開發人員以出色的表現做出了回應(即,我很特別,擰其他部門),而其他開發人員只專注於失去津貼。我不認為他們將自己視為大團隊的一員,而是大團隊的超級巨星。我不想“送他們回家”,這就是為什麼我問一些替代策略的原因,因為我不知道該怎麼辦。
@JacobG您知道,第二個開發人員_does_有一點要說-能夠在上午10:30到11:00之間進來**是**,即使您不贊成使用(例如,例如,煙霧破滅)。如果不提供某種形式的賠償,則不應刪除它。
+1完全同意。我要補充一點,也許可以通過考慮在核心時間安排“隱蔽性”,而不是在核心時間讓每個人都在現場來緩解問題。有些開發人員可以自願參加較早的活動,而另一些則可以稍後留宿嗎?
我同意動機因素,但不同意規則文化是一件壞事。
當人們有不良習慣時,對他們的放棄給予獎勵/補償是不好的。我寧願獎勵並補償結果。
有些好處,但我不同意你的前提。信任而不是不信任可以促進規則文化。檢察官的問題是他的報告對他的信任度不足以履行他對它們的要求。他們不這樣做可能是正確的。因此,寧願**最佳激勵因素是自我利益。**
這不是關於“信任”的問題,而是關於“尊重”的問題,有人直接經理支持他們的意見,尊重他們並確保聽到自己的聲音。閱讀關於我的回答的評論,不相信開發團隊應該對此事發表意見,這是獨裁的方法,而不是孤立的管理方法。
當團隊負責人或生產線經理與聰明,有創造力的人一起工作時,最重要的技能是傾聽。只要團隊富有成效和效力,就不要妨礙他們。在這種情況下,壓力來自團隊外部-我認為我的角色是*保護*團隊免受這種“組織性降雨”的影響,因此傾向於最終在管理上為他們而戰,而不是反過來。如果團隊高效高效,那就不要惹它。如果計時破壞了團隊的凝聚力,那麼請確保在您的回顧中提高了團隊凝聚力,這是團隊需要解決的問題。
+1用於關注核心問題並避免建立規則文化。將靈活性作為好處的觀點也很不錯。
#2
+124
jmort253
2012-04-13 11:26:15 UTC
view on stackexchange narkive permalink

建立守時文化可能需要花費時間,並且可能是您必須妥協的事情。由於您要與聰明的知識型員工打交道,因此,如果他們可以讓他們加入計劃,您會更加成功。與其關注時間,不如關注調度問題所產生的問題。

將此問題作為對團隊的挑戰,看看他們提出了什麼。答案可以設置時間表,也可以解決問題。可能是星期一,星期三,星期五是上午9點的日子,而星期二和星期四是節假日。儘管該計劃可能並不完美,也可能不會完全符合您的設想,但在某個中間位置找到既可以使開發團隊感到高興又可以解決實際問題的中間立場,可以防止您的員工變得苦澀並把您視為敵人。

請記住,您並不是在處理一個製造過程,每個人都必須在哨聲響起的上午9:30出現,這樣他們才可以開始進行令人費解的組裝任務。不斷重複一些小的塑料小部件,直到口哨聲再次響起,並且頭腦麻木的工作人員前往當地酒吧歡度歡樂時光。

我的團隊沒有按時出現。我試圖強迫他們,但它不起作用。

強迫聰明人永遠都行不通。您需要記住,您正在與高學歷,聰明,有創造力的人打交道,他們善於解決複雜,抽象和獨特的問題。這些人,至少是真正的好人,永遠不會盲目遵循命令。這可以追溯到至少在一開始將問題交到他們手中。如果他們什麼都不做,那麼您將想使用自己的解決方案。

您提到您是新的團隊負責人。進入這樣的新職位充滿挑戰和壓力,因為您不確定如何贏得團隊的尊重以及如何成為一個好的領導者。這是有經驗的,沒有經驗的新團隊通常會嘗試“強迫”或強迫人們以自己的方式做事,這很常見。這不是領導。

開發人員和其他知識工作者不需要經理;相反,他們需要一個領導者。偉大的領導者會激勵他人去做偉大的事情,這是您帶領團隊走向卓越而不是讓自己陷入絕望的機會。解決方案將不是解決方案告訴,對他們來說,這尤其是

有關靈感,請參閱Seth Godin的採訪領導與管理之間的差異。我強烈建議以領導身份的任何人和所有人觀看這次簡短的採訪。

“讓他們想出一個計劃”也是我的第一反應。但是,從評論和聊天的角度來看,在這種特殊情況下似乎不太可能...
@Benjol-問題的語氣使我認為這不僅僅是眼神。感覺也是Theory X樣式管理,這在管理開發人員時無效。我們只是在聽故事的一面,而事實總是在中間。
見我的回答:)
最重要的一點是:_迫使聰明的人永遠行不通_。您不能像對待孩子一樣對待您的聰明才智的團隊成員,並希望他們不要抱怨,反擊並為此而怨恨您(舉例來說;我不受任何此類影響的直接影響,但我仍然很難避免在OP如何管理其團隊方面犯下個人罪行)。技術員工通常與經理一樣聰明(如果不是這樣的話),所以與他們打交道的唯一有效方法是與同事同等,而不是像您所說的那樣隨心所欲的底層員工。
我沒有受過良好的教育,仍然反對人們浪費我的彈性時間。
#3
+64
Andrew
2012-04-12 23:19:20 UTC
view on stackexchange narkive permalink

根據我的經驗,知識型員工不喜歡受制於他們沒有目的的政策。您確實陳述了一個目標,但是您管理的員工似乎認為這不是一個好目標。此外,您可能還沒有考慮過其他選擇,並且鑑於聽起來像是“從天而降”的問題,您的員工可能沒有想到它們,不願意提出建議,或者覺得他們只是

如果您執行該政策的唯一原因是由於與其他部門人員的緊張關係,管理這種緊張關係以使您的員工能夠最有效地工作是您的工作。不過,我認為這不是唯一的原因。例如,如果需要開發人員解決在8:00或9:00或其他時間發生的緊急生產問題該怎麼辦?但是,開發人員需要 all 來解決該問題的可能性很小。如果您有一個輪換(除非有人自願)的“提前”時間表,那麼每個開發人員都要輪流在8:00(或9:00等)到那裡去怎麼辦?該解決方案似乎更有可能同時滿足業務需求和員工的需求。每個人都“分擔痛苦”(或對不介意的人造成痛苦)。人們大多數時候會進入工作崗位,因為他們覺得自己的工作效率最高。這只是一種可能性,但它可能會與您的員工展開討論,以解決實際問題並滿足每個人的利益。

如果您選擇走更紀律的道路,而“開始時間”問題對於開發人員而言確實很重要,那麼您將失去其他工作中的好人。您的員工可能會感到工作沒有安全感(如果某天真正發生緊急情況使某人遲到會怎樣?)。此外,這可以看作是管理方向錯誤(從您的員工的角度來看),因為他們以前在其他人的幫助下工作過。

這當然取決於您,但是,我敦促您退後一步,更加努力地從員工的角度來看情況。當然,您有工作要做,但是我認為有比您提出的方案更好地滿足每個人利益的解決方案。

如果某人有正當理由遲到,我不會懲罰他們。因為他們整夜都在玩《魔獸世界》,所以一周睡三覺是不合法的。我們有一個更願意在7:30露面的人。最大的問題是,如果開發人員X正在與Designer Y一起進行項目,而Designer Y的工作時間是8點,他將等到下午1點或更晚才得到他可能需要的東西。當調用它時,開發人員不會看到它的問題。我們是一家小公司,應該都屬於同一團隊。說真的,9:30還不是很早。我真的不講理嗎?
-1
“您會失去其他工作中的好人”-這是整個問題的核心,@Jacob。如果工作還沒有完成,那麼您會遇到更深層次的問題;您的開發人員和設計師需要更好地協調。如果工作已經完成,那麼不要浪費時間浪費開發人員的時間,例如設置特定的開始時間。
+1輸給其他雇主。如果我要離開一個值得信賴的環境來保持自己的日程安排並完成工作,而又回到了一個拖欠時間的打孔環境中,那我將把自己的履歷蒙上灰塵。
@ErikDietrich:因此,如果您沒有以令人滿意的方式完成工作,而老闆說:“您知道,您的工作沒有及時完成,因此,某某在抱怨您在此期間工作不足。他們設定好的時間表,所以讓我們最晚在9:30之前按照一致的時間表開始。”你還會繼續簡歷嗎?
@JacobG如果我來自彈性工作時間環境,現在“滿意”的一部分是“準時”,那麼絕對可以(我想,您的團隊也會如此)。彈性工作時間不是整夜玩電子遊戲的遊戲玩家的問題,而是關於信任的文化。如果是我的團隊,我相信他們會充分了解自己的個性和所喜歡的工作時間,以完成工作。取消彈性工作時間意味著取消信任,並發送消息(因為它們是懶惰且無能的),因此需要對其進行(微型)管理。即使是事實,他們也不會喜歡。
同意@AdamRackis關於“如果最大的問題是,如果Dev X正在與Designer Y一起進行項目,而Designer Y在8點,他正在等待[...]我將投票給Designer Y應該提前計劃並說一天結束時:“嘿,我明天早上要去做這個工作,您能確保明天早些時候來幫助我,還是在離開之前完成它?”讓他們一起工作還需要更少的時間。
“因為他們整夜都在玩《魔獸世界》,所以每週睡三遍是不合法的。” “睡過頭”是什麼意思?我們還在這裡讀小學嗎?八小時就是八小時,無論是從上午6點開始還是從上午10點開始。如果您需要有人出席會議等,那麼讓他們選擇可以在某些核心時間參加會議,例如上午10點至下午3點。管他呢。但是,工作是否完成與他們是否在一定時間進來正交。 **您是否嘗試過與開發人員討論該問題並要求*他們*提出解決方案?**
@Kyralessa-如果您的老闆說在9:30上班,那麼您最好在9:30上班,否則您來晚了。我不敢相信有多少人對此作者的問題有疑問,更不用說告訴他他不是一個合理的領導者,我被教導每天每天準時出現。
@Ramhound問題在於以前的文化是9:35尚未到來的文化,OP希望轉而成為一種文化,大概是針對那些具有不易替換且具有一定程度自由度的人才的人我想他會喊“你遲到了”,但這可能導致某些人離開並降低士氣,這聽起來像是他在努力避免。
-1
@Ramhound在以前沒有一個時間的情況下設置一個任意的開始時間,並希望每個人都圍繞它調整整個人生時間表是不合理的。因此,在沒有必要的情況下設置硬啟動時間也是不合理的。顯然,開發人員認為沒有必要,因此對他們而言似乎不合理。另外,考慮到他們在公司的工作時間比經理長得多,而且所有人似乎都同意,他們也許是正確的。
#4
+50
Erik Reppen
2012-05-06 00:55:38 UTC
view on stackexchange narkive permalink

您問題的準確答案是解僱並替換沒有收到消息的人,然後解僱其他沒有收到消息的人。

我不希望這會有所幫助您的職業生涯或公司的發展目標,但您已經確定這是問題所在,而且似乎無法說服您。

更富建設性的是,我建議您考慮以下因素:

  • 您的開發人員有彈性的時間。現在您想拿走它

這在某些書面政策中是否具有官方利益並不重要。這是事實上的政策,也是既定文化的一部分。人們在這些時間附近已經確定了生活和時間表。對於像我這樣的開發人員來說,他們更喜歡躲避高峰時間,並且在冬天遇到了令人討厭的SAD案例,但是無法想到更接近我想要居住的赤道的任何開發人員友好的地方,

  • 您提到的這種“焦慮”的本質是什麼?是a)主要是嫉妒還是b)合法的部門間溝通問題,例如安排會議/常規溝通的難度。

a)開發人員無需與客戶或其他企業進行交互。以我的經驗,公司結構越僵硬,開發人員就越平庸。儘管很多開發工作都是零花錢,但它也是一個創造性的問題解決過程,需要人們發揮出最大的才能。這也是一個不可預測的截止日期驅動的過程,有時會導致非常非常晚的時間。這樣做的副作用是,開發人員通常會獲得“創造性”待遇。在一家擁有30名員工的公司中,不難堅持要讓成年人成為員工,因為他們需要在場時表現出最大才能,並且最終可能會在一年中花費比9-5人更多的時間。通常在下午4:55收拾東西每天。

b)在30人的公司中,您召開的會議不應太多,這會成為問題。不計算衝刺會議或其他每兩個月進行一次的計劃會議之類的事情,每天將您的開發人員束縛在會議中的時間超過30分鐘是一種荒謬的,完全無能的金錢浪費。一般通訊也是如此。 30個人意味著您走向另一個人並與他交談。在彈性時間場景中,合理的是設置一個所有人都在辦公室的時間跨度。我想不出一個充分的理由將工作時間跨度超過一天的3-4個小時,以及為什麼它不應該盡可能地接近一天的中段時間。

  • 為什麼要早上站起來?

為什麼為什麼第一個想法管理會從混亂,敏捷等方面廢除……始終是您沒有站起來的建議?在編程中,需要一段時間才能使您完全了解特定問題上要處理的所有細節和問題。當您首先進行單口站立時,您的開發人員將不會全神貫注。站立對於溝通和提高效率至關重要,不是您要做的第一件事就是“擺脫干擾”。

  • 您的開發人員是否無法完成工作?

如果沒有,為什麼要搞一件好事?與公司的其他問題進行溝通並不是他們的工作。是你的。在理智的管理結構中,您的責任是對直屬經理和所管理的人員負責,而不是出於實際原因必須在更典型的時間到場的其他部門的酸葡萄。

我回答了這個問題。然後是一個很長的隨訪/附錄。
#5
+46
user718
2012-07-12 12:30:04 UTC
view on stackexchange narkive permalink

問題的審查:缺少許多上下文和信息

作為新公司中的新技術負責人,可以採用哪些其他策略來改變開發的文化團隊,以便人們在我要求的時間出現?

  1. 技術主管有何新意?
  2. 您為什麼要強加非技術管理政策?
  3. 您的管理證書是什麼?
  4. 您以前有什麼人事管理經驗?
  5. 您以技術方式贏得了團隊的尊重嗎?
  6. 您以管理方式贏得了團隊的尊重嗎?
  7. ol>

    TLDR:我的團隊沒有按時出現。我試圖強迫他們,但它不起作用。

    除非我們明確為什麼,您需要改變文化,否則無法提供解決方案劇烈地我們還不知道您試圖強迫他們做什麼,還是不能告訴您為什麼無效。 我們可以猜測,但這只是推測。

    您為什麼要負責解決可能是非技術人員管理的任務?將其交給主管經理的上級,讓他們處理。好警察vs壞警察。

    背景數據:

    小型公司,有30名員工,我的團隊中有5名成員。以前的領導仍然是常規開發人員。

    1. 先前的技術線索是否已降低?
    2. 先前的技術線索是否已降級?
    3. 先前的技術線索是否有效?
    4. 現有團隊中的大多數人是否與以前的技術負責人有更私人的關係?
    5. 先前的技術負責人是否仍在有效負責
    6. ol>

      在我到達之前的文化是一種非正式的活動,沒有固定的界限或核心時間。 這種文化沒有受到公司領導者的挑戰。

      1. 那它一定一直在工作嗎?
      2. 團隊能否如期成功交付有用的產品?
      3. ol>

        由於以下原因,團隊中的大多數人會在10:30到11:00之間出現這個。由於其他部門的工作性質,它們將開始時間設置為8或9。這種差異和不可預測性導致我的部門與其他部門之間產生了很大的焦慮。

        具體來說,這裡沒有足夠的細節甚至無法開始對此問題的解答。任何答案都將是完全的猜測。

        因此,我讓團隊坐下來,指定了“不遲於” 9:30的時間。我解釋了我的推理,並解釋了這種方案的好處和當前方案的負面影響。這是一場漫長而充滿爭議的對話,團隊中5個人中的3個人非常不滿意。

        如何為我們提供您的好處負面因素如果沒有他們,我們將無法判斷您的交流方式有多合理或有多有效。聽起來您甚至都沒有根據自己的負面反饋考慮或與您的團隊或外部團隊探討某種折衷方案。是嗎?

        不用說,人們沒有按時出現(並且9:35不能按時出現。)

        這沒有。聽起來像是一種非常積極或有效的態度。

        我已經安排了每天9:30的站立會議作為額外的激勵因素。知道轉換開始時間(上下班等)需要一點時間,所以我最初會等待開始會議,直到所有人都出現為止,但是現在我只是開始會議(並且經常結束會議)。 似乎也沒有什麼不同,並且這使團隊的凝聚力降低了。

        採取的單方面行動使團隊的凝聚力降低。考慮一下 it

        基於個人和小組的對話所產生的結果與原始對話相同(即他們看不到價值,以為我是

        我們聽到並可以推斷出他們不接受的內容,您聽到了嗎?

        我得到了高級管理團隊的全力支持和支持,並有權使用我認為合適的任何設備來對此進行照顧。

        天主教徒教會在宗教裁判所期間擁有同樣的權力,看看結果如何!

        我當前的下一步是派人回家,讓他們休假。太過分了嗎?我是否忽略了可以幫助我解決此問題的替代策略?

        升級似乎也不是可行的替代方法。不帶薪水將他們送回家是很侮辱的,對公司的傷害要比對僱員的傷害更大。它會讓您看起來更加獨裁和專橫。像孩子一樣對待他們只會使他們表現得更像孩子。


        您當前方法的預期結果

        1. 您將失去整個團隊的所有尊重,它們將變得越來越無能為力,隨著生產力的停頓,您將被越來越無能為力。
        2. 您因政策變更和人事管理技能的失敗將使您被上級視為無能。
        3. 由於辦公室之間的溝通,您將失去團隊中其他人的尊重。還將破壞與他們未來的任何技術領導機會。
        4. 您肯定會在整個鏈條上下損害您在公司中的聲譽。
        5. 更好的員工會大聲辭職首先。
        6. 甚至更好的員工也會悄悄辭職。
        7. 邊緣合格的員工可能會辭職,也可能不會因您施加的痛苦而辭職。
        8. 不合格的員工會像堅持滴答答答並忍受您施加的任何條件。
        9. 公司最終會虧損,並被離職的員工在外部贏得不良聲譽。
        10. 知覺就是一切!永遠不要忘記!
        11. ol>

          一些建議的方法

          1. 作為他們的經理,您應該努力使他們與高層管理決策隔離開來。您應該為他們的聲音而戰。您應該幫助他們集體形成回應,並通過他們的回應予以支持並予以支持。
          2. 這是非技術性決定,而純粹是公司管理決定。您為什麼要處理它及其實現?對此有上等的待遇。
          3. 別像獨裁者或暴君那樣行事。可能不等於正確。
          4. 帶一些人的技能,進行軟技能訓練。
          5. 移動得更慢。這樣的事情不會在一夜之間改變。
          6. 如果他們與團隊融洽相處,您需要得到以前的技術指導。
          7. 還有其他折衷辦法,如何關於不介意早點做的人,其他人也不必這樣做嗎?
          8. 起立時間的移動是任意的,每個人都認為這是不切實際的
          9. 讓您必須處理的外部團隊參與討論,並幫助您出售政策變更。
          10. 退後一步,與他們達成協議,成為好警察。讓您的上級制定法律。這是管理問題,不是技術問題。您是技術主管,不是經理,對嗎?
          11. 讓外部團隊成員和您的團隊成員在需要見面的時候進行鍛煉。預定的日期和時間將是一個很好的折衷方案。開發人員不希望被外部團隊不斷打擾,而似乎只是想按他們的要求跳到會議上。
          12. ol>

            最終想法:

            我的技術和非技術的管理風格均基於《道德經》中的吳偉校長

            可以通過以下方式來理解吳偉原則:軟木漂浮在水中。擊球越厲害,它產生的力就越大:產生的力越強,反彈的力就越大。在不消耗能量的情況下,軟木塞很容易使您疲憊。您做得越少,完成某件事的可能性就越大。

            間接透明領導力

            起初,人們充其量很少注意到領導者。接下來他們崇拜並稱讚他,然後害怕他,最後鄙視他。因此,失去信心會滋生失去的信心。當工作完成並獲得最終結果時,每個人都會說:我們自然而然地做到了。

            將與您的員工一起投訴的外部部門人員放在一個房間裡,讓他們他們會在內部為您提供一個可以接受的解決方案,您不在房間裡。願意接受任何結果。那麼解決方案就是他們的解決方案,他們擁有它,您會從他們那裡得到一些急需的尊重,因為他們可以讓他們解決問題。這是非指令方法。

+1,這些都是非常好的方法。就個人而言,我喜歡授權團隊解決問題的方法。當成年人像……成年人一樣被對待時,他們的能力令人驚訝。瑪莎需要與約翰會面,因此他們計劃和協調在一起,而沒有那麼卑鄙的老闆來扮演獨裁者。
我已對問題進行了編輯,以回答您的某些特定問題。
-1
@JacobG您從* stick *方法開始,因此無法恢復*胡蘿蔔*的數量。優秀領導者的標誌是要知道他們什麼時候不具備資格,不能有效地尋求幫助,我個人認為這是您保存面子並將這場戰鬥推向他人的那一刻。即使您贏得了這場戰鬥,您和團隊也會在心理上輸掉了這場戰爭,即使您和團隊也將相互輸掉。您可能解決此問題的“唯一”方法是讓外部部門的負責人與您的團隊一起,並讓他們在沒有您參加會議室的情況下*提出解決方案。
@JarrodRoberson-我不確定我理解你的區別。我負責控制技術方向,也負責他們的審核。我批准PTO,並提供功能。我做這兩種事情已經十年了。此外,從技術上講,還沒有“堅持”的方法。通過與整個團隊進行2個小時以上的討論,制定了這項政策。它沒有獨斷呈現,也沒有任何後果。此後,高管們與團隊加強了溝通,基本上進行了2小時以上的討論。
@JacobG *“經過2個小時的討論才到位” *是矛盾的。 *“到位” *表示由某人決定並應用的“單方面”決定。在過去的22年多的時間裡,我工作過的大多數地方都意識到,技術領導和管理應該分開。在我擔任過技術領導的大多數大型公司(我的意思是每年數十億美元)中,這是一個非常完善的組織結構。將這兩種責任混為一談是衝突的秘訣。有2個小時2個小時以上的“討論”應該告訴您政策不好,方法也更糟。
@JarrodRoberson我認為我們正在互相討論。 1)該公司規模太小,無法聘請非技術開發經理。 2)這個問題實際上歸結為“如何影響文化變革”,而不管變革的細節如何。事實是,負責人意識到文化轉變的必要性,並得出了有關轉變的結論。每個人都同意這種轉變是正確的。希望與開發團隊進行討論會導致他們得出相同的結論。那沒有發生,這是慘敗的結果。
+1這是一個很好的答案...儘管我更喜歡一個結構化的環境,但這是一個具有實用建議的實際答案。
@JacobG:“每個人都同意這種轉變是正確的。”但是您說過,五分之三的開發人員強烈反對這一變更。這是否意味著開發人員不會“參與”這一轉變?還是您說的是,討論之後,所有開發人員都同意必須進行此更改?
@MarkBannister-對不起,造成混亂。我的意思是,確定需要進行文化轉變的每個負責人都同意,這是適當的舉動。
您一直在說* @JacobG *是您與他們討論的*,您不是沒有告訴他們現在的情況,顯然有兩個多小時的爭論。這不是關於政策轉變的“討論”。 **真正的討論**是*我們收到了其他部門的以下投訴,這些團隊的一個想法是開始時間更早,你們還有什麼其他想法可以讓我們回到其他團隊去解決。他們實際遇到的問題?*。由於似乎並沒有讓所有人都早早加入團隊的100%實際上是問題所在。
@JarrodRoberson:我仍然不太清楚。領導層認識到系統的,文化的問題,並通過廣泛的討論制定了解決方案。守時部分是該解決方案的要素之一。與開發團隊的討論是為了引導他們採用相同的邏輯,使領導者得出結論,並期望團隊得出相同的結論。之所以沒有發生,是因為團隊不同意要解決的問題。他們選擇將重點放在這個特定問題之上。
-1
@JarrodRoberson我真的不知道為什麼我們不在這裡連接。如果5個部門抱怨1個(真實/有效),而1個認為5個只是嫉妒/次等/應該克服,那麼試圖說服他們為什麼這種改變對每個人都更好似乎公平。就像我說過的那樣,高級mgmt要求我進行更改,我試圖帶領團隊理解高級mgmt所遵循的邏輯,並且回答是,確實沒有問題。我是否應該回到mgmt並說“抱歉,開發團隊認為客戶服務是一堆嬰兒,應該克服嗎?”
@JacobG我的意思是,您對開發團隊的態度很差。如果您堅持採用這種方法(聽起來像您這樣做),那麼**您將繼續失敗**,而您的主管將看到您失敗了。我確實認為您應該代表您的團隊退縮,*經理工作的很大一部分*是使他們的團隊與這種情況隔離。您至少應該給開發團隊一個制定替代解決方案的機會。我已經提出了許多“成功”的方法來達成相互妥協。我不認為整個**團隊都需要隨時待命。
@JacobG不再花太多時間為您的失敗方法辯護,並為其他部門的觀點辯護,並開始就**如何支持您的團隊並讓他們的聲音被接受的所有好的建議!**如果您認為他們不應該這樣做一個聲音,好吧,我不想加入那個團隊。看到我對答案將會發生的預測。
閱讀此討論後,我發現真正的問題是高層人士正在確定與他們無關的細節。每一層都應關注其下一層的不足結果。您的法庭應該如何。在這一點上,開發人員幾乎使所有人失望,這向我表明,他們都已受夠了,根本不擔心要找到新工作。如果他們想那樣玩,最好評估一下替換大部分開發團隊的難度。
#6
+28
Tim
2012-04-27 00:55:45 UTC
view on stackexchange narkive permalink

您需要做的第一件事是閱讀“ Peopleware”

現在嘗試更改此設置是錯誤的。我是一家公司的經理,我們的工作時間表非常靈活。我們生產力最高的開發人員之一在上午11點進來。他向我報告了一段時間。有人告訴我讓他改變時間。我應了這個要求。硬。我被否決了。

結果:

一個效率低下,興趣不大的開發人員,是一個巨大的團隊貢獻者。他的工作效率大大降低,對團隊也毫無用處。

所有這些都是因為“準時”的一些愚蠢概念。

更多地關註生產力。

您作為經理的工作是消除生產力障礙,而不是使每個人的外觀,感覺和行為相同。

彈性工作時間是一種福利-允許彈性工作時間的雇主可以吸引更多優質的人才。

作為“新技術領先者”,您無法很快改變文化。尤其是在您似乎想要的方向上。您是否做了任何改善團隊角色/工作的事情?

首先要與他們建立信任。如此多的初次經理/主管會犯這樣的錯誤。

找出其他組真正需要的內容。不是“他們必須在9:30在這裡”。真正找出問題所在。然後找到解決問題的方法。

您含糊地提及“在我的部門與其他部門之間引起很多焦慮”-但目前尚不清楚這種焦慮是什麼-他們是否對開發人員得到優先待遇感到不安?真正的根本問題是什麼?

我試圖強迫他們,但它沒有用。

這是有原因的。而且您似乎沒有在聽。採取更大的措施和更大的錘子並不能真正改善這種情況。嘗試使用“胡蘿蔔”方法而不是“堅持”方法。

再次閱讀“ Peopleware”。

您不會在日常會議,派人回家等想法上走得太遠,或者想到他們是您的奴才,就像您說的那樣, “要不然。”

誰告訴你他們需要在9:30上班?其他團體?你的老闆?您?找出真正的問題並解決。他們出現的時間不應該是問題。

*主持人注意:註釋中的擴展討論已清除。對於任何進一步的討論,請轉到[chat](http://chat.stackexchange.com/rooms/3060/the-water-cooler)。*
我曾經有一個同事,他12點鐘出現,當他喜歡時就離開了。既不穿涼鞋,也不穿鞋子。作為軟件開發人員,他非常了不起。他是我見過的為數不多的人之一,在這項工作上顯然比我更好。試圖強迫這個傢伙早點開始(a)不會成功,並且(b)是您可能做過的最荒謬的愚蠢的事情。
#7
+20
Kristof Provost
2012-04-13 15:03:29 UTC
view on stackexchange narkive permalink

不管您為什麼這樣做,對於您的團隊成員來說,感覺就像是在帶走額外津貼。對於他們中的某些人來說,這甚至可能是他們為您的公司而不是為您的公司工作的主要原因之一。

可以說服他們接受,但是您需要有充分的論據,並且幾乎肯定會對此產生不滿的不滿。您可能因此而失去好人。

根據您的描述,主要原因可能是其他部門的嫉妒。

簡而言之:除非您認為值得在其中丟掉一部分人,否則不要這樣做。

如果我將嫉妒定性為嫉妒,那不是我的錯。其他部門有面向公眾的工作時間,因此在沒有增加資源的情況下延長工作時間實際上對他們來說是不可能的。
@Chad-第二段中隱含了答案:多付錢
@CurtainDog-除非加薪取決於準時出現,否則我懷疑這將是一個持久的解決方案。如果這是偶然的,那麼我們有點同意。
是否可以編輯此帖子,並擴展如何使另一個團隊享有相同的特權?儘管此職位確實提供了替代方法,但並沒有真正深入探討或解決某些員工可能是必須制定時間表的輪班工人這一事實。
#8
+18
Erik Dietrich
2012-04-23 20:37:03 UTC
view on stackexchange narkive permalink

要改變您的文化,您需要了解為什麼會遇到阻力,然後管理造成阻力的原因。

根據我的經驗,“與其他部門協調”往往是那些職位更高的職位,並沿著項目/人員管理的軌道前進。只對代碼感興趣的一天工作的開發人員往往對此有所抵觸。在結構更複雜的商店中,他們可能根本不這樣做,而在規模較小的商店中,他們可能會更非正式地這樣做。

無論您是否喜歡,您都繼承了彈性工時文化,這對大多數開發人員而言是一項巨大的福利。在您作為領導者的第一個行為中擺脫他們不僅對他們似乎是暴虐的(當您向他們解釋9:30並非很早時,您就是在強加自己在他們看來是任意安排的),但實際上是扣除了很大的津貼。您可能喜歡制定特定的時間表,而不認為這是有意義的津貼,但他們可能認為它無價之寶。考慮到這與告訴他們您要休假一周或將他們的薪水削減百分之幾相提並論。

要更改此設置,可以使用胡蘿蔔或棍子。您正在談論使用棍子,也許是更大的棍子。如果您走這條路,我計劃僱用一些新的開發人員,因為我猜想您的某些團隊將開始在其他公司進行採訪。我本人會走上胡蘿蔔路線,以便明確表示將來的晉升和晉升將由“與其他部門協調”的人來決定,以消除這種津貼。也就是說,領導者/重要人物還處於早期階段,與其他團隊一起工作,承擔責任等。“新手”獲得了彈性津貼,但認真進取的人們準時入職。

如果您創建了這種文化,我懷疑您的一些開發人員將按自己的意願準時加入。出於對進步的興趣和對“重要人物早起”的看法。

#9
+13
aroth
2012-07-12 11:03:25 UTC
view on stackexchange narkive permalink

簡短的答案是您不應該這樣做。您的技術團隊成員很聰明(至少應該很聰明),他們知道讓所有人在任意時間出現在辦公室並沒有明顯的好處;唯一重要的指標是他們的工作是否完成。

如果您的團隊沒有完成他們的工作,那將是一個單獨的問題。但是,如果他們把事情做好了,那麼為什麼只因為其他部門騷擾您而騷擾他們呢?

作為領導者的一部分職責是使您的團隊免受瑣碎的干擾和批評外部資源。如果您對抱怨您團隊成員的其他人的反應是將抱怨傳遞給您的團隊成員和/或僅根據這些抱怨來決定進行更改,那麼您的工作就會失敗。我建議,假設您的團隊實際上已經完成了工作(聽起來很像,因為您沒有抱怨他們的生產力),應對此類批評的更好方法是告訴抱怨者:“是的,我伙計們努力工作,始終如一地取得可觀的成績,那是唯一重要的事情;那麼,為什麼不停止擔心我的團隊如何處理任務並回到自己的工作上呢?”

當然,如果您通過強制性的“您必須在X時離職”政策,則以“您必須在Y時離職”政策作為補充是公平的,並且一項“您不得在正常工作時間之外在家工作”的政策。這是保護員工工作/生活平衡的唯一方法,因為我敢打賭,直到11:00時才出現的許多團隊成員可能熬夜或要在家裡多留點時間。

除了作者聲稱工作還沒有完成之外。
@Ramhound-不,他沒有,至少不在原始帖子中。他在編輯名單中提到最近的表現一直在下降。但是,由於團隊過去一直有彈性的工作時間,因此仍然沒有任何證據表明績效下降與工作時間有關,或者設置一個固定的開始時間會帶來任何改善。從原始職位來看,作者似乎最擔心他從其他部門得到的負面反饋。
聽起來像“毆打將持續到士氣提高為止”。
#10
+13
bethlakshmi
2012-07-12 21:36:53 UTC
view on stackexchange narkive permalink

我不羨慕您-作為經理,對我來說很難。老實說,我相信您會因此而失去人們。我認為您只有一個症狀,就是“啟動->中型文化轉變”,而且並非每個開發人員都會成功進行此更改。我認為您需要準備好職位描述和有關如何打開求職申請的知識,並且我認為您需要強調聘用新人和改善文檔的能力...

對不起,如此嚴峻。但是我認為您不會遇到信任問題,也不會出現可以輕鬆地使人們達成協議的情況。實際上,沒有任何補償可以完美平衡工作的巨大靈活性。

我同意您正在拿走津貼。對於某些人而言,開始時間的靈活性很重要,它表明一種非正式文化對某些人而言可能是強烈的偏愛。據推測,隨著公司的發展,工作量變得更加可靠,工作安全性得到了改善,對產品的尊重也有所增加,您也許能夠提供一些漂亮的庫存計劃,加薪或其他改進措施。如果這都不是真的,那麼您會問自己,是否有成長中的&蓬勃發展的公司或陷入絕望的公司。添加和刪除喜愛的特權。您可以嘗試解釋一下,但是對於某些人來說,這不是一個好的折衷方案,也不是您可以選擇的情況。這是“我的方式或高速公路”,因為它具有組織上的影響,不一定能在團隊中感受到,但在公司的更高層次上得到了經驗和支持。

聽起來像您已經做了正確的事情:

  • 您已清楚地說明了這一點

  • 您已經談到了原因,需要改變

  • 您已經一對一地聘用了(我認為應該繼續這樣做),以便在個案出現時予以解決

  • 您已提供反饋

我認為您可以接受“他真的是真的嗎?”這主要是在向人們證明你是認真的,而這確實需要改變。我個人認為,在我所在地區的辦公室遲到5分鐘不是什麼大不了的事,而且會議間隔短的會議(例如敏捷衝刺中的站立訓練)不應該在開始時就這麼輕率在工作日,公交車連接丟失或交通不暢將是一個經常出現的問題。但這有點地區性-不同地區的交通狀況差異很大。這樣一來,您就可以了解您所在的地區並從個人投訴中了解什麼才是合理的。

其餘的只是想出了一種足以使您變得認真的機制。一天的停薪是一種選擇,它在您的合法權利之內-儘管我想出的任何機制都將通過律師來解決。正式的警告系統也會導致紀律處分。我認為您的人事部門可能會提出建議...

很大程度上取決於工作的承受能力-當您將某人送回家中時,您也會鬆懈當天的工作,這會影響您的費用&時間表。當您擁有一個導致紀律處分(包括解僱)的警告系統時,您可以節省一天的剩餘工作,但有被解僱員工的風險。

我想的是,當您處理懲罰時,您必須準備好受到足以嚴重損害的懲罰,以使人們明白“如果您不這樣做,就沒有工作”。

#11
+10
weronika
2012-04-14 08:21:56 UTC
view on stackexchange narkive permalink

在您的開發人員如何看待此問題與其他部門(或您的上級,或實際上要求此更改的人員)如何看待此問題之間似乎存在脫節。我建議嘗試在必要時分多個階段縮小這一差距。

首先,開發人員是否同意此更改有充分的理由?如果他們不同意,他們是否有很好的反駁或替代建議?如果這樣做,您應該將它們帶到管理層,看看他們是否會放寬對時間的要求-或者他們是否可以解釋為什麼替代方案不起作用以及反議論點不能解決問題,以便您可以回到您的開發人員,並給他們更完整的解釋。只要有必要/富有成效,就可以反復進行。

如果您達到了這樣的地步,即開發人員同意有充分的理由但不願意適應,或者他們不願意認為原因很好,並對整個想法感到不滿,然後將其傳達給管理層。說明您可以強迫開發人員去做想要做的事情,但這會引起怨恨,動機降低,生產力降低甚至員工離職。確保管理層理解這一點,並且仍然同意強制執行開始時間很重要(再次與開發人員進行溝通),否則您可能最終要為變更造成的損失負責,這將使公司蒙受的損失超過獲得的收益。

(個人說明:我一直被告知要在規定的時間進來,因為就員工而言,這沒有充分的理由,而且確實非常無聊。確保人們理解原因,不要以為自己只是隨心所欲地更改政策,或者是因為您不信任他們,這真的很重要。) sub>

#12
+9
Michael Durrant
2012-05-06 19:27:24 UTC
view on stackexchange narkive permalink

我曾經在有這個問題的非營利組織工作。會議總是遲到,遲到10分鐘成為“標準”。

然後,我們得到了一個新的項目經理,負責一個大型關鍵項目(一個固定的時間表)。她召開了第一次會議。人們像往常一樣漫步,遲到了幾分鐘,然後隨便聊天。她坐在椅子上,沉默了幾分鐘,什麼也沒說。最終,聊天消失了,直到寂靜無聲。我們都在等待聽到說話。她讓沉默持續了一段時間。她環顧四周,他們說:“我需要澄清一下。開會按時開始。如果您要遲到5分鐘,請不要再來了,以後再來看我。好吧,現在我們開始這個項目了這個星期[無論如何] ...”。這給人留下了深刻的印象,人們為按時開會而付出了很大的努力。

注意:下面添加了其他答案。

說明遠程完成的工作。

通常,最高製片人遠程會做大部分工作,因此有時像在辦公室一樣花很多時間在遠端。這是考慮和與其他部門溝通的重要點。這種交流應該是微妙的-不要召集會議,只是開始尋找方法來顯示“是的,喬昨晚在x上工作很晚”和“是的,瑪麗在周日確定,她起床直到午夜。 '。

公開談論通勤情況。如果某人在10.30時進來,他們的通勤時間可能是15分鐘;如果他們需要在9或9.30時進來,通勤時間可能是一個小時。如果他們工作了8或9個小時,他們會回家。很多人認為這是他們生命的主要浪費。他們寧願遠程工作一會兒,然後再進來。次,並確保其他部門也知道這一點,只需經常提及即可。

確保使用技術來提供幫助。例如,我實際上是在工作-100%的時間。因此,啟用Skype,顯示我的在線狀態,攝像頭等也可以幫助您。

我之所以反對,是因為經理的想法很棒-她幾乎給了所有人“擺脫會議的免費卡”。
#13
+8
Spoike
2012-07-17 14:04:35 UTC
view on stackexchange narkive permalink

曾經遇到過類似的情況,儘管公認的時間少於OP,但我只能說他的情況:

最實用,最簡單的解決方案...

...將改為嘗試在11點開始會議。不用擔心,您不是在“屈服”。取而代之的是,您像合氣道背後的原理一樣重定向流程。這樣做的重點是使團隊能夠完成重要的事情,因為這是最重要的,因為確實有一個嚴重的問題需要解決:

團隊真的不知道其他部門的情況以及他們真正需要做的事情。

讓您的團隊參加9:30的會議,我可以承認,現在還不早,但這不是解決方案。問題。您嘗試過並失敗了,所以停止堅持這樣做。別再撞牆了。我唯一的提示是始終重視通過任意召開的會議進行的溝通。

由於其他部門從8點開始,因此您可以利用這次較晚的團隊會議來發揮自己的優勢。在8點到11點之間,您有 3小時來幫助您的團隊進行項目管理活動,例如(無特定順序或優先級):

  • 參加會議並收集目標其他部門的要求和要求
  • 弄清昨天以來完成的事情
  • 與其他部門一起管理在工作日需要完成的期望和承諾
  • >
  • 向其他部門傳遞好消息和壞消息
  • 如有任何更新,請與團隊相關的任何計劃
  • 找出需要解決的代碼和軟件體系結構問題今天關注
  • 對不提供任何商業價值的請求說“不”
  • 接受其他公寓的批評,並向您保證問題將得到解決表示歉意。
  • (總有一些問題需要解決)

最後,在會議之前,為團隊簡要概述發生的事情,以使他們了解一些情況。當會議開始於11點,每個人都準備上班時,您將獲得信息和為他們準備的會議協議。您可以將會議的摘要和會議記錄寫成簡訊,並在會議結束後的某個時間以電子郵件的形式發送,以提醒您。

在與團隊會議期間,您需要他們提供兩件事:

  • 詢問需要完成的任務的估計,尤其是那些優先級高的任務。不一定要精確到幾分鐘。這樣,您可以與其他部門一起更清晰地確定承諾和期限。如果他們無法為任務提供任何估計,請他們在白天或下一天解決。
  • 詢問障礙,或者如果他們需要幫助,寫下來,看看這些問題是否可以解決並且得到解決。

過一會兒,您可能會逐漸逐漸開始開會。但是最初違背糧食原則並不是唯一的選擇,只會導致更具感染力的文化(其中唯一的修復方法是更換整個團隊)。 如果您說的是“ primadonnas”,那麼您真正的工作就是將它們翻新為質量卓越的真棒primadonnas。很明顯,您的團隊擁有並想要自治,因此開始利用這種文化來發揮公司目標的優勢。

當您設法通過溝通而不是強迫來組建一個可靠的團隊時,您可以比其他人提前三個小時離開團隊知道他們正在做自己的工作(但是如果胡扯到球迷,仍然可以隨時待命)。 現在可以信任您了。

我認為這是更可靠的建議,也是成功的替代方法。 “經理/團隊負責人”的作用是使團隊遠離噪音和混亂,並消除降低其效率的障礙。這個答案提出了一種做所有這些事情的方法!
#14
+6
pap
2012-04-26 17:26:40 UTC
view on stackexchange narkive permalink

我正在閱讀評論和答案,我不得不承認,我有點發瘋。從什麼時候起有人按時出現“振作”?既然彈性工作時間何時不必關心您的行為對團隊和公司其他成員的影響?

從我在問題和評論中看到的內容來看,他的團隊成員的行為是可證明對公司有害且代價高昂。在嘗試推理和妥協之後,情況並沒有得到改善(順便說一句,9.30並不是很早就實現了,或者說是不合理的)。

向您的團隊說明您沒有彈性時間的問題,但這意味著一定程度的個人責任,以確保您的彈性不會影響他人(在您的團隊或其他團隊中)的工作。由於您的團隊顯然在責任方面不及格,因此我想說,立即生效,直到另行通知,所有彈性時間都必須事先得到您的批准。未經批准或沒有合理辯解(不能接受,鬧鐘不能在早上出現),將導致紀律處分,例如停薪或休假。 p>

非常清楚為什麼會發生這種情況,以及促使您採取這些措施的原因。請指出,這不是您想要要做的事情,而是您被強迫要做的事情。還應該清楚的是,一旦情況改善,就可以取消這些限制性政策。

**刪除評論。**請使用評論來改善答案或要求澄清,而不是用於一般討論。要進行更多討論,請使用[聊天]。
#15
+6
anonymous
2012-04-24 00:35:26 UTC
view on stackexchange narkive permalink

其他人就如何處理這種情況提出了很多好處;但是,歸根結底,如果小組的日程安排干擾了公司中的其他人員,那麼您必須糾正問題並確保一切順利進行。考慮到這一點,您需要找出其他組何時需要對開發人員的可靠訪問,以及該時間表中是否有靈活性的餘地。如果其他團隊在無法預測的情況下需要在辦公室訪問開發人員,則開發人員的核心部分需要確保滿足需求。如果這意味著某些開發人員必須在固定的時間到辦公室,那麼便是如此。

關於將開發人員轉移到某種固定的可用性時間表,最好的選擇是是為了確保盡可能減少“辛苦時間”。例如,如果“核心時間”是從11:00到15:00,那麼您還可以確保不存在星期五的核心時間,而星期五是真正的彈性工作日。由於通常認為星期二,星期三和星期四是一周中生產力最高的日子,因此您可能可以將核心時間應用於這些日子,並允許星期一和星期五也可以是全日制。

在確保遵守小時數方面,如果指示是從上而下並經高層管理人員批准,則開發人員最終必須在工作中遵守該指示。您應該盡力確保逐步實施該協議,並且如果某些開發商在其僱用協議中寫上了彈性工作時間,則應予以解決(例如,通過更改其薪酬和福利,使他們成為祖父等);但是,在某些時候,您將必須確保需要遵守該政策,這也可能需要對員工進行正式紀律。同樣,如果有人選擇離開,可能值得嘗試看看他們是否願意留下補償和福利變化;但是您可能還必須接受失去一些開發人員的經歷。

最終,如果您的工作要求您對團隊進行文化變革以滿足企業的需求,那麼您的選擇將受到一定程度的限制。您可以並且應該採取一切措施來軟化變更,並儘力與其他組織達成妥協,但最終您將需要實施變更並接受隨之而來的任何人員變更。

#16
+2
Karlson
2012-04-12 23:14:29 UTC
view on stackexchange narkive permalink

您仍然可以通過多種途徑來解決此問題,其中之一就是更改部門所扮演的角色,例如:如果您與軟件開發人員一起工作,則可以更改某人或某人的角色。在一周中讓他們為其他部門提供支持,這需要1個或多個9點或更早的時間才能進入,如果不起作用,您可以隨時調用任何從業手冊中通常存在的不服從條款。在美國。就我個人而言,我一直反對使用此子句,它為經理提供了譴責甚至解僱某人的途徑,原因,但在您的情況下,這可能是適當的。因此,請查看員工手冊,並與您的上司進行討論(如果有的話)。

基本思想如下:

  1. 您設置了規則,規定X個小時之前至少有1-2個人或所有人員都在工作。
  2. 如果您的團隊成員沒有有效的藉口不露面或堅持這種做法,您作為經理應譴責他們並可能開除他們。
  3. ol>

    作為經理,我正在做我描述將是不得已,但根據您的描述,您可能已經達到了這一點。您可以在網上找到許多關於可能構成員工從屬的文章,這些只是一些示例:

當然,不幸的結果可能是小組中的上崗率很高,雖然這對您作為經理的反應不佳,但會強制紀律並可能打擊士氣

現在說了所有這些,我確實有一個問題:您真的需要團隊早些時候進來嗎?

回答您的問題-是的。我們有多個部門與我們定期合作。這些部門在8-9之間,在4:30-5:30之間離開。遲到的開始時間和午餐至少意味著-1)下午1點之前沒有開會,以及2)如果有人在等待我們部門的某些東西,則浪費了半天或更長時間。效率極低。
@JacobG的經典後果是“您要熬夜才能完成工作,否則我們會休假”。關於“每個人”都找到一個合理的開始時間9:30:我不是。再說一次,我一直工作到晚上8-9點,有時會再晚一些,而且經常在我回家之後。這些是我最忙碌的時間,如果我被期望在0930銳利的“否則”時進門,我不會把它們放進去-我會成為9比5的人。每個團隊都是獨一無二的,希望您在評估時考慮到這一點。
@Jacob-這是什麼樣的開發團隊?你們只是維護內部X應用程序的另一家公司,還是這些高質量的開發人員編寫了堅實的代碼,這些代碼是您公司的骨幹?如果是後者,他們中的一些人希望能夠在家工作到很晚才能遲到,這似乎不足為奇。我建議您嘗試適應這一點。優質的開發人員很難找到。如果當前工作無法完成,他們總是有其他選擇。
@voretaq7不會採取這種錯誤的方式,但是我發現這很大程度上是一個習慣問題。如果您習慣在晚上11點而不是凌晨3點上床睡覺,並在早上7點而不是9:30上床睡覺,您會發現一段時間後,您最有效率的時間是在午餐前,而晚上9點,開始有點困。人類適應。
-1
-1
@JacobG但是您想念我的意思,為什麼他們要等到當天早上8點才決定告訴開發人員他們需要什麼?
@robertc因為他們不知道直到早上8點才需要東西。 “一個客戶打來電話,正在遇到此問題...”“看來此數據已損壞...”
@JacobG您列出的所有示例都不是開發任務。即使您讓開發人員提供客戶支持(正如您所暗示的那樣),為什麼所有開發人員都需要在一定時間到辦公室來提供支持?當您沒有專門的支持人員時,為什麼要向客戶和其他部門承諾具體的支持時間?
我曾在少數幾個團隊中工作過,這些團隊由於像此處建議的規則而被打破。忠告:人們可能會在幾週前開始進入。但是之後,您將看到他們在比賽中發揮作用。
#17
+2
A quiet hum
2018-06-24 21:22:16 UTC
view on stackexchange narkive permalink

基本上,您必須決定更重要的事情,正確完成工作或在規定的時間在辦公桌旁坐8個小時?



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