一個軟體工程師加入一個項目管理實踐和軟體工程實踐不佳的公司或團隊是什麼體驗？

01-29

特別是對那些曾在相對更成熟的軟體管理實踐和軟體工程實踐的團隊里工作過的工程師

按慣例，謝邀。

基本上，我的體會是，從一個具有成熟工程實踐和工具體系的公司進到一個這兩方面的都不佳的公司，第一感覺基本上會是非常不舒服：原先習慣的高效的工作流程沒了，原先用慣的工具不見了，尤其是，在你看來，你周圍的人都在用非常「土」和低效的方式工作。

如果只是回答「體驗如何」，我想上面的答案就足夠了。

不過呢，鑒於工程師在跳槽的時候都可能遇到這樣的情況（特別是，當工程師為了尋求發展，從知名互聯網企業跳槽到處於相對早期的公司時），因此，關於這個問題，我想延伸開來說幾句。

我一直認為，「是否追求效率」是非常明顯的優秀的工程師和不那麼優秀的工程師之間的差距。優秀的工程師無法容忍用低效的方式工作，因此落到這個環境中的優秀的工程師，要麼直接離開這個環境，要麼想辦法改造這個環境。改造這個環境可不是個輕鬆活，一方面，這種低效的背後一般都有非常頑固的習慣和觀念，另一方面，這種低效往往也表明了團隊中的大部分工程師並不那麼在意效率。要改變這種狀況，除了要持續積極地用自己的行為影響其他人外，還需要有足夠的position power去在制度上改變不少東西（績效方式，換一種方式對待業務壓力等等）。整個過程絕對充滿了挑戰，不過呢，如果真的被你干成了這件事情，成就感和經驗也會讓你受益匪淺。

會學會罵人垃圾

一開始，你會手足無措。真的，一下子就不知道要怎麼做才好了，恨不得什麼都自己做算了的節奏。

然後。。。事實上，我就是這麼幹了，什麼都自己來，完全不指望和依靠任何人。這段時間主要是靠積累撐過去的，我很明白，必須在耗完積累前，讓團隊把做事的套路學起來。如果不能做到這一點，你就死定了。

最後，我很幸運地撐過去了。於是乎又不安分了。。。。

面對這樣的問題，我覺得不見得有那麼多優秀的開發人員跳槽後都加入了「不佳」的團隊，每一個團隊都是要有一定磨合的，我們眼中或者管理層眼中的效率：這個東西3個月內做完。看吧，命令很明確，有的公司下了命令，執行力很強，有的公司被逼無奈只能拖一拖，甚至有的公司只是告訴你三個月做完，剩下的你看著辦，沒人去督促你。

這裡嚴重反映了一個問題，當你自認為優秀的跳槽走了，發現新的團隊不如以前，只不過是你沒融入，以前解決問題都是熟悉的思維在交流，現在要和陌生的思維去碰撞，沒錯就是碰撞。

這時候你覺得累，難受，因為你可能沒有發言權、決定權，只是在聽、認同、採納或反感。

這不是一個優秀程序員所考慮的事情，該考慮的是如何快速融入，如何將好的制度傳播

很多回答都是說改變環境很難。

但是為什麼我覺得，在咱們這個行業裡面，好的東西，是會被採納認同的，這裡無關感情，因為效率高，省時省力賺錢快，對誰都有好處。我們不像銷售行業勾心鬥角、不像設計行業琢磨怎麼跟甲方墨跡，我們只需要提高我們的執行力，這種事情，是個正常的程序員都不會反駁。改變環境的難點只是一個：每個公司都要有每個公司獨特的運營模式，存在即是合理，這套規則已經存在這麼久，你為什麼要改變它？你不先適應、習慣，妄想上來就改變？你當你是神仙？

所以管好自己，寫好自己的代碼，考慮如果傳播你從別的公司帶來的好的習慣、思想，這是不是你剛剛加入團隊時該想的，該考慮這些問題的時候，注意方式方法再去實現，事實證明：不難！

見過太多團隊衝突的情況了，有衝突都是認知層面的差距造成，如果站在對方的角度考慮問題就好多了。就像今天我和一個開發人員提出要修改一些問題，他的反應比較激動一樣。但從公司整體層面的利益考慮來看，這些都是有必要修改的，不然項目無法及時回款。從開發層面我覺得需要考慮的是，面對一個問題是不是還有其他比較簡單的辦法來解決或者規避，大家相互溝通來解決，而不是很容易就出現應激反應。不管怎麼說搞清楚做每一件事的目的是最重要的，這樣才會有方向感和成就感，同時也會更有判斷力，這樣才不會局限在問題裡面，也不會說別人叫你做啥就做啥。

默默地和客戶說廢話，聽項目經理扯淡，還要無腦的碼字。

沒在成熟的團隊工作過，簡單說一說自己的實際體驗，晚點細說。

接手別人的項目，從windows移植到macosx。

最大的問題是效率極低。

沒有文檔，缺少注釋，即使代碼風格較好理解起來也比較費時。

更大的問題是，由於管理不完善，項目中夾雜大量爛代碼，僅為了實現功能，完全不考慮魯棒性可讀性可維護性及其他各種性，導致後續開發極難進行。

晚上回來舉栗子。

個人覺得日本外包做的最好，但。。。。你覺得呢。。

不好的團隊，基本天天生氣的，日本外包的特點是不會讓你生氣，但規範很成熟很死，基本上沒得發揮。

所以魚和熊掌，不好一起拿，國內大團隊作的好的不多。超過20人就是機械管理辦法範疇了。

如果搞不好，把自己能氣死