程序員加班延遲

① 程序員要經常加班嗎 有沒有雙休，如果加班大概到晚上幾點下班求業內人士解答

每個地方的都不一樣 我就是雙休的 加班大多數是自己能力不足導致的，加班一般沒有強制規定 任務沒完成就接著做咯 實在不行第二天早點來趕著做

② 程序員晚上加班太晚，第二天遲到被技術大佬批評，怒懟奮斗逼文化

最近接觸到了一個詞叫奮斗逼，什麼是奮斗逼呢？指的是自我感動（包括但不限於自我催眠，自我欺騙）的方向錯誤而不自知的在白白瞎奮斗著的傻子。也就是奮斗逼的定義。他們的內心想法千千萬，但也簡單，概括起來就是三句話:為自己感動，替聰明人瞎擔心，覺得資本家也會為他的奮斗感激並將這份感激轉化為利益並無論何時各種狀況都不拋棄他，視他為己出。

在某平台上看到一程序員發帖稱：程序員打起來了！技術老大在群里批評遲到的同學，遲到同學反擊罵公司奮斗逼文化，然後就被群情激憤的「奮斗者」的口水淹沒了，遲到同學氣不過就跟他們打起來了......我覺得這事還得賴遲到同學，你自己不想加班就說別人加班是奮斗逼，這不是比奮斗逼還可惡嗎？

奮斗的人值得尊敬，但奮斗逼應該唾棄。這群人通過貶踩其餘同事同僚的，通過996、打小報告、當喉舌的方式爬的更高,賺的更多。這個需求明明就是約定這周做完的，奮斗逼非要今天連夜提前做完，不但做完了還要和領導說我做完了我很優秀，然後達到了升職加薪的目的。資本利用這些人當作表率，那其他人看到原來加班提前做需求就能升職加薪受到關注啊，那我們都加班吧。996就是被這幫逼發明的，他們很多人還充當喉舌，充當壓迫其他人的工具。我就是看不起這些人，看不起這些破壞社會規則，禍害其他勞動者的人。

奮斗沒有錯，但是在上班時間能完成的活兒，故意拖到晚上10點，11點，讓別人覺得你很努力，這種行為我是不贊成的，到了下班的點，有人願意繼續奮斗，有人願意生活，誰也不要看不起誰，選擇不同而已，不要以奮斗為名，去安排他人的生活，也不要以自由為名，看不起努力奮斗的人。

google 20年前以20%自由時間為驕傲，而如今20%的定義已經改為在100%本職工作之外的額外部分。我們大可以搖頭說，今日的谷歌不是當年的谷歌了，可本來，就沒有一成不變的規則，保持不變的公司只會被環境給「進化」掉。FB聽起來夠高大上、夠極客，對嗎？一樣會有人告訴你，不同團隊的微觀氣氛差異很大。有些團隊工作按時下班，有些團隊每日每夜，這個和當時的任務挑戰、TL風格都有關。我反倒覺得這樣的公司很有前途。

其實在我看來這件事，改程序員遲到可以依照公司規定處理，或者酌情處理，畢竟每個人都會因為各種事情遲到，至於該公司的文確實不敢苟同，一個公司重視的不是產出而是加班時間，這本身就是謬誤，其次奮斗本身是對的，且我也尊重和佩服那些奮斗的人，但是不能因此去要求別人，這不是公司硬性的規定，你也不應該也無權用自己的標准去要求別人做到你的標准。你們是怎麼認為的呢，也有過類似的經歷嗎？

③ 做程序員每天正常工作時間是多少小時如果要加班一般加班到多少點

程序員也要看公司的情況，有的公司程序員很少加班有的很多。
加班的情況也是比較常見的，單說我身邊的c++，java，ios，前端，
加班最多的就是c++和java，ios，有的時候加班到第二天早上，有的加班到10點左右。
機呼每一個程序員都加過班，不加班的真的很少。
有的公司提供休息的房間，也會有一些加班補貼。
有的時候公司升級軟體啊什麼的都會是在夜深人靜的情況下升級或者測試。

④ 程序員都要加班的嗎

程序員不一定都要加班。Java語言是整個體系的基礎，按照不同的用途，在以下方面應用廣泛： 1、企業級應用開發 這里是JAVA的天地，大到全國聯網的系統，小到中小企業的應用解決方案，JAVA都佔有極為重要的地位 。 2、網站開發 當然就是JSP+Servlet+JavaBean，一直以來都相當流行 。 3、移動領域 典型的應用是手機游戲（國內主要是這方面），這里是J2ME的天地，其實應用范圍是很廣的，只是國內開發不夠 。 至於需要不需要加班需要根據項目而定，不同公司和不同項目是不同的。

⑤ 程序員為什麼加班多,是什麼原因導致的

導致程序員加班的原因很多，主要由以下幾方面吧：

1.需求不清晰。需求人員或者項目經理、產品經理沒有吧需求梳理分析清楚，等開發到一半甚至開發完了，才意識到需求錯了，需要重新做，眼看項目或產品都快交付了，只能讓程序員加班了。

2.管理問題。企業文化，就是加班，本來沒啥活，但領導就覺得員工加班他心裡踏實，所以那不管你是不是程序員，一律加班。

3.自身問題。效率低，解決問題能力不行，分配的工作任務無法在規定時間內完成，那隻能加班，自行解決了。

4.工作任務緊急。突然要開發一個新功能，客戶要求時間緊迫。不加班，無法完成。

5.工作量大。日常工作量就是大，一個人干兩三個人的工作，干不完，加班還干不完呢，加班成常態了。

從甲方角度看，我就想要什麼產品3個月上線，這是戰略和領導決策決定的，不能拖太長時間。

甲方以這個要求去找乙方，乙方銷售為了完成業績，他滿口答應。

售前一般不會反對銷售。

合同一旦簽署完畢，銷售業績就認為算完成一大半，後續介入內部流程就可能減少。

這時候認為，按時交付的責任應該在研發方面。

開發和產品團隊此時可能還需要進行需求分析，系統設計，提交文檔，正規一些的測試部門還要審核文檔。

然後這些事都走玩，開始開發任務。開發人員每天一個日報，每周一個周報，幾乎天天開會討論。

白天都在討論問題，只有晚上其他部門都走了，無人打擾時，研發才可能專心敲代碼。

沒讓專業的人做專業的事情， 是工作開展的大忌，在工業上，早已證明了一切，在工廠生產中，工人流水化作業，一個人只專注一件事情，會越做越熟練，越做越快，越做效率越高。

在軟體開發分工越來越明確的今天，讓後端人員搶前端人員的飯碗，去寫網頁、樣式，效率能高嗎？讓後端人員去搶DBA的飯碗，去做資料庫優化，效率能高嗎？

不專業的人做不專業的事情，可能和公司的發展歷程、組織架構、人員規劃有關；也可能和任務安排有關。

公司發展初期，養不起很多專業的人，可能更需要「全棧」工程師，啥都一把捉；公司發展的過渡期，有點錢了，也意識到了要讓專人做專業的事情，但是人員還沒招齊，那沒辦法，你也得兼職著做各種各樣的事情。如果公司有錢了，發展也成熟了，不是屬於以上兩種階段，在IT組織中，連前端、後端、測試、架構、DBA、網路、伺服器運維、技術支持、安全、產品，這些職能都沒區分好的話，就會對工作效率有影響。IT一線工作人員，每個坑位，都需要一顆專業的螺絲釘。

開發人員不注重代碼質量，導致後期返工，導致效率低

有 時候，快即是慢，對於經驗不足或者習慣不好的開發人員，開發前期，被迫或者自己沒意識到，為了追求進度，邏輯沒考慮周全，沒做好自測，代碼能跑起來就算完 成任務了，表面上任務完成得很快。但是在項目後期，測試階段，問題大規模爆發，甚至要返工，由於測試後期，離自己寫代碼的時候，可能隔了一段時間，有的東 西自己都忘了，再回過頭去重新「熟悉」，效率能不低嗎？更為嚴重的後果是讓項目進度不可控。因此，就算進度再緊張，也頂住壓力，必須要做最基本的測試，再進入下一個任務點。

個體組織人員膨脹，出現溝通成本大的問題，導致效率低

溝通成本是人員膨脹後，暴露出來的首要問題。

舉個簡單的栗子，很多公司都有每天晨會習慣，如果一個組有5個人，開晨會匯報工作，平均一個人匯報2分鍾，就需要10分鍾，現在一個組增加到10個人，一人匯報兩分鍾，都要20分鍾才能匯報完。時間就這樣過去。

再舉個栗子，30人天的工作，分給2個人做，可能需要15天，共耗費30人天，但是分給5個人做，6天能完成嗎？

信息在溝通、傳遞的過程中，可能會「失真」，你想的，不一定能100%說出來，你說出來了，別人也不一定能100%理解，而且每個人的理解能力、知識體系都不一樣，理解起來容易產生偏差，產生偏差就容易做錯事情。

因此，如果人員出現膨脹，要以項目為單位，進行合理的項目拆分、人員拆分。同一個「小項目」最好不要超過4個人負責。溝通的時候，推薦使用口頭+書面+復述，減少溝通過程中的信息失真。

上、下屬之間相互不信任，做事有阻礙或者導致重復工作，導致效率低

上 下屬相互信任是一切工作的基礎。如果上級不信任下屬，不敢授權給下屬，凡是都要自己過一遍，而上級往往是一對多的關系，這個時候，工作瓶頸會出現在上級身 上；如果上級不信任下屬，搞一堆監督機制，為了下屬不做錯事情，又讓別人同事過一遍，又要耗費額外的成本，勞民傷財，而下級得不到信任，做事受阻，久而久 之就會畏手畏腳，很難獨當一面，或覺得自己有能力沒地方使，乾脆走人。

上級應該充分信任下級，放心授權讓下級去做事情，但這些都一個前提就是要有一個較好的軟體管理過程，包括開發環境和測試團隊和在完成任務的過程中進行一些輔導和進行重要節點管控和監督。

上級不信任下級，經常碰到，而下級不信任上級也很要命。程序員是很有個性的工種，不好管理，往往特別多想法。就好像車輪子陷入泥潭中，上級說車子往前推，有的人又說，往後拉，各自發力，估計車子永遠都擺脫不了泥潭，還談何效率？

因此，如果有意見，前期可以提，但是解決方案一旦定下來，應該上下一心（即使有意見也埋在心底吧），朝著目標一起去努力。

不同部門之間溝通存在隔閡與障礙

軟體開發過程中，在IT范疇內，不同部門難免有交集，例如開發與運維、開發與測試，不同崗位承擔的責任、掌握的知識體系、考慮問題的角度往往不一樣，導致處理事情受阻。

舉 個栗子，有一次，開發人員為了驗證某個問題，需要運維人員協助重啟某個站點。對於開發人員來說，這個站點，用的人比較少，而重啟也是一瞬間的事情，風險為 基本為0，但是由於運維人員掌握的知識體系不一樣，怕重啟了會造成很大影響，甚至害怕出了問題要自己承擔責任，明明可以瞬間操作解決問題的，又要等到中午 或者半夜三更沒人的時候才敢重啟，效率就是這樣降低了。這個時候，需要運維人員，去學習一下相關知識，或者引入新流程，例如，重啟站點，需要某個專業人士 口頭同意，即可立即執行。

因此，不同部門之間的人，應該互相學習，才能更好地溝通；做事情，盡量做輕量級的流程化、標准化。

上級工作安排不到位

上級工作安排不到位，也會導致工作效率低。有時候會有這種怪現象，可能很多事情沒做，但是下面的人沒事可做；或者有的人很忙，有的人很閑。

軟體開發分工，不像搬磚頭，一人搬一車就行了。軟體開發， 工作量化本身就是一個很難的地方，如果項目經理沒有做項目計劃，沒有做工作點、任務點拆分工作就很難安排到位。特別是剛剛從程序員轉型做項目經理的人，過 程性思維，不會對項目做整體的把握、整體規劃，想到哪裡就做到哪裡，想到什麼就分配什麼工作，最後一團糟，一會把下面的人累死，一會又讓下面的人閑死。

⑥ 程序員工作時間長短

程序員按規定是每天8小時上班時間，但運氣好的話，你3小時把一天的活幹完了，也就OK了。但是也必須清楚，作為一個軟體公司，如果接到一個工程的話，就可能不僅僅每天上班8小時了，也是你所說的無償加班至晚上12點，這也是常有的事。

⑦ 程序員一定會熬夜加班嗎

生活中的我們很多時候都會面臨著熬夜加班，這已經成為年輕人中的一種夜生活，很多時候我們都很難向像那樣的生活是不是真的很刺激，我也體驗過夜生活，但是真的太累了，身體還是要緊的，那麼程序員一定會熬夜加班嗎？接下來無我們一起來看看。

對於程序員來說他們的任務量一般是非常大的，很多時候，我們會知道他們是技術人員，而且要工作，工作的大量的內容我們基本上看不懂，我們知道他們一定是會加班的，這點事非常明確地，還有就是生活中的他們可以說因為他們的愛好造就了他們的事業。

總的來說，很多時候，程序員比我們想像的還要辛苦，我們只是看不見他們想要的，但是我們知道他們通過自己的努力，最終變成自己想要的，那種收獲的喜悅是我們都懂得的。

⑧ 為防被程序員「砍」，產品經理需要注意這些場景

互聯網行業中，眾人熱衷於討論「程序員砍產品經理」。雖然，「砍」更多是調侃的意思，一種消遣工作的方式；但是，這不是一個飯後笑話，側面反應了產品經理和程序員間的對立關系。很多時候，產品經理和程序員間就像對手，產品研發過程就像打仗，總要爭個你死我亡。「砍」的本質，是程序員表達對產品經理的不滿，也是一種情緒的宣洩。

在產品研發的過程中，產品經理與程序員對立關系，會嚴重影響項目的推進。一旦產品經理和程序員對立關系公開化，很容易導致團隊人心渙散。這種對立關系，經常滋生出一些極端的事情，罵娘、打架已屢見不鮮。

下文就列舉一些程序員想砍產品經理的場景。這些場景都是我過去和很多程序員朋友交流時，他們遇到的對產品不滿的場景。這些場景，都會以產品經理的溝通話語表現出來。通過這些場景，去解析這種對立關系產生的原因。以及，作為對照，產品經理應該如何規避和處理這種對立關系。

這樣說法是程序員們最不喜歡的，最容易惹毛程序員的。這句話，在程序員們看來就是削減工時、加班的代名詞，他們當然不喜歡。而且他們也非常討厭，一個非技術人員為技術人員做技術難度的定論。簡不簡單，都需要技術人員做了技術評估，才能下結論。

這種言語，會讓程序員們覺得產品經理不靠譜。大家通常都是比較排斥借鑒。借鑒你也得有合理明確的理由。以我某程序員朋友的話來說：微信怎麼做的，你就怎麼做，那你不如去微信做產品算了。

每個產品，在表面的UI下，都有其背後的復雜的業務邏輯。如果產品經理只是叫程序員照著某個產品做，很多時候技術們是很難實現的，因為他們也需要弄懂背後的邏輯和流程。當然，這應該是產品經理的工作。

這就是抬杠。產品經理雖然名字裡面有「經理」二字，但並沒有經理的權利，當然不能命令合作的技術們。這句話，言下之意也是拒絕了商量和討論。而程序員也需要參與感和團隊感。

這就是質疑他人能力，是人都不會喜歡。如果產品經理提出的方案，程序員們沒有理解。那就說明產品經理的解釋說明和文檔，做的不夠優秀，不夠簡潔易懂。讓程序員們理解需求，是產品經理的基本工作內容。

在互聯網產品開發中，修改需求和插入新需求都是挺常見的。對於程序員們來說，這是非常不爽的事情。這種操作通常會打斷程序員的思路，思路被打斷是非常痛苦的。當然，這樣也會影響他們的開發效率。更可怕的是，反復的修改需求，會使他們有種勞動成果不被尊重的感受，同時也會對項目的未來抱有懷疑的態度。反復的更改方案，也說明產品經理設計是未經過嚴密的論證，或對細節的把控是不夠。

程序員都比較討厭反復的催促。當項目的節點確定後，技術們會嚴格遵守節點，產品應該信任他們。當然，時間比較緊湊時，反復催促也會加大程序員們的壓力，使他們變得非常煩躁。在這種時候，催促就是添麻煩。

甩鍋會導致團隊分崩離析，人心不齊。不管任何問題，都是團隊的責任，不要將責任指定給某人。特別是在項目復盤時，如果心態不好同事，這是非常難堪的。所以，我們要盡量以原因和結果為導向，而不是責任為導向。

程序員也是也是團隊的一份子，有權利知道知道需求的背景。同時，了解需求背景也利於程序員們更好的開發程序。

產品經理給程序員們畫餅是最不切實際的，只會引起大家的反感。程序員都是喜歡偏實際的東西，虛的東西只會招致白眼。

任何傳遞給程序員的需求，都是需要有計劃和規范的。如果口頭傳達一個需求，很容易導致開發出的功能與需求不匹配。同時，因為缺乏相關的記錄和文檔，可能會造成需求流失。這對於程序員們來說，可能就是延遲、加班、返工、擔責等等風險。這是團隊合作的大忌，也是項目管理不專業的體現。

以上的這些場景，可能出現一次，程序員們都會順著我們的想法做。但是，這會漸漸改變程序員們的心態，最終會使產品經理與程序員間產生隔閡和矛盾。如果出現這些場景，作為產品經理都需要小心的處理好，以免影響項目的正常推進。當然，最好是不要出現這些場景。作為產品經理，我們的最終目標，都是要保證我們的產品，准時、保質、保量的落地。

產品經理在與程序員們合作時，產品經理需要講究合作共贏、互相體諒。在產品經理的相關工作中，最要避免的就是抬杠。抬杠是一切矛盾的根源。很多時候，產品經理要站在程序員的角度考慮問題。比如，對於產品來說可能就是改改需求，但對於程序員，他們更在意的可能是因為改需求而導致的加班。

產品經理在工作中，經常會追求產品上的極致。追求極致本身是好事，但是切忌過分偏執。我們也需要考慮團隊的現狀和資源，在極致和現實間尋找均衡。畢竟，如果沒有喬布斯的團隊，要像喬布斯一樣做產品，只會拖垮團隊。

在產品開發的過程，改需求、改方案等項目異常，都是不可避免的。這是項目管理的第一部分。如何進行項目異常的處理，考驗的是產品經理的溝通能力和項目管理能力。產品經理需要在保持技術們高效工作的情況下，完成項目異常的處理。

當然，在產品經理工作中，矛盾的根源也並不總是產品經理。有時候，也可能是某些程序員的性格或者對該工作的態度導致的。這時候，產品經理要明確，作為團隊的潤滑劑，有責任推動和協調大家的工作。如果，矛盾不可調和，我們需要盡早提出問題、控制風險，避免「勉強」行事。

有時候，程序員在私下評價一起工作的產品經理時，總是會補加一句「我感覺我也能做產品經理」。這句話的背後，是產品經理沒有讓程序員們感受到產品工作的價值。在這種背景下，產品經理是很難獲取程序員們的注重，也會為很多爭論埋下誘因。那如何感受到我們工作的價值那？其實很簡單，就是保持工作信息的透明。將我們針對需求和產品做的相關工作，體現在我們的溝通或者文檔中。

導致程序員想「砍」產品經理，本質是產品經理工作方式的問題，也有情商的問題。在我的產品經理工作經驗中，我總結下了以下四點，我們需要注意和避免的。這四點，都可以和上文的場景相對應，是最容易慢慢改變程序員的心態的。

⑨ 如何看待程序員經常加班熬夜這個問題

程序員加班熬夜屬於正常現象。這年頭的話，騰訊雲本人就是一加班熬夜的一個團隊。你不想加班，不想熬夜的話，你就不要干。