這篇部落格我想談一談有關於專案組內的事情。
從我剛剛進入專案組開始說起，當時的我，算是有些心高氣傲，剛剛接觸專案**之後，發現這部分**有很多設計得不好的地方，這裡也不好，那裡也不好，於是就提出來了很多的建議，對於這些建議，組長給出了一部分的解釋，但是更多的卻是沒有給出解釋，我嘗試著週日加班將這部分**整理了一通，給專案組的老成員看，他們推說沒有時間，有空了看，最後不了了之。
接下來，我在專案組裡混得也不怎麼樣，總之感覺自己和大家始終有一層隔閡，感覺自己是他們當中的異類，而他們的很多做法其實我是看不慣，也不理解的。
後來這個專案組被解散了，我來到了乙個新的專案組，公司的拳頭產品，乙個延續了十幾年的老遊戲，做後端開發，接觸了一些人和一些事，漸漸地領悟了一些專案組內的道理。
大學裡一直嚮往的是網際網路行業有話直說，實事求是，辦公室政治少，看著其他的行業，各種潛規則，各種人情世故，自問情商不高的我，覺得網際網路行業無比地適合我，於是義無反顧地成為了乙個程式設計師。
但是實際上，程式設計師也不僅僅是乙個與機器打交道的事業，俗話說，有人的地方就有江湖，只要是需要與人相處，需要合作，就一定有人情世故，只是不同的圈子，這種人情文化不同罷了。對於網際網路這個圈子，講究實效，講究業績，搞政治這一套會拖累效率，造成業績不佳，那些搞政治，搞人情的專案組被市場逐漸淘汰，剩下來的專案組大多數都有著一套比較不會拖累效率的人際關係格式。
但這並不代表網際網路行業就沒有人際關係格式。
就彷彿是我見到了乙個素不相識的陌生人，我看到他拎著一袋水果，直接就掏出一把水果刀上去，他肯定會以為我要傷害他，畢竟兩個人素不相識，他不會以為我是要幫他削蘋果，我幫他削了蘋果，削得很好，他和我講，他喜歡帶皮吃，我給他講，帶皮吃不健康，上面有農藥殘留，但是這個陌生人會領情嗎？就算我講的是對的，我能獲得他的感激嗎？亦或是會獲得別的什麼印象？
同樣地，去陌生人家裡做客，我認為自己廚藝精湛，將對方家裡的魚做成了一道酸菜魚，然後對方告訴我，他本來打算吃生魚片的，我開始教育他，生魚片不好，吃了會得寄生蟲，酸菜魚健康美味，我說的都很有道理，但是又道理有用嗎？對的就有用嗎？對方會感激我為他指出生魚片不健康嗎？
實際上在專案組裡也是這樣的，比較外向的新人進入之後往往會這裡不順眼，那裡看不慣，林林總總意見很多，就和我當初一樣，這些意見大部分其實是很中肯的，是對的，但是這並不意味著別人會待見我，我將**按照自己的想法改掉，他們也不會感激我優化了**，相反，很多時候他們不會接受我這樣的改動。
然而，這種事情就真的不應該做嗎？
當然應該做，但是中間有乙個區別，那就是有沒有獲得別人的尊重和認可。
從事網際網路並不意味著人人都是中心，專案組內總歸是有個地位劃分的，畢竟人與人之間的信任建立需要時間，需要契機，tcp還得三次握手呢！何況是人！在別人尊重，認可自己之前，提出過多的意見並不能快速地拔高自己的地位，效果適得其反。
作為乙個在專案組內沒有任何人脈基礎的新人，首先就是得了解專案的方方面面，而且要平等地看待自己的同事和上司，一般在網際網路行業，尤其是技術崗，組長一定是組內最有能力的人，起碼是最有能力的人之一，我能看到的問題，組長一定能get到，他不去理會，不去改，一定是有其道理的。
那麼遇到建議怎麼辦？當然不能假裝忘掉，遇到想要提出的建議，可以記錄在乙個小本本上面，逐漸積累，這些東西不應該是你搬石砸腳的累贅，而應該是中後期拔高尊敬值的墊腳石。
回到上面的例子，加入是兩個熟人，其中乙個拎著一袋水果走過來，另乙個拿出水果刀，結果就是兩人開開心心地吃果子，順便聊聊路上遇到的那個強行削皮的怪人，就算其中乙個人喜歡帶皮吃，在好友的指點建議下（帶皮吃不好），他也能理解好友的一片苦心，會提出感謝，反而增進友誼，之所以不會出現看到水果刀就以為要傷害他，原因就是兩人之間有了尊（ji）敬（qing）。
又比如是夫妻之間，妻子把丈夫用來切生魚片的魚煮了，丈夫回來看到了，也不會責怪妻子，兩人一起吃酸菜魚，其（gou）樂（liang）融融，妻子順便給他講生魚片的不利之處，丈夫也能明白妻子的一片苦心，因為他們之間也有尊敬，或者說是信任
換到專案組也是一樣，乙個剛剛進來的毛頭小子開始大刀闊斧地修改**，他根本沒考慮過開發成本，測試成本，像是乙個愣頭青一樣執拗地秉持著自己的觀點抬槓，這樣誰都不會喜歡的，專案組裡，意識形態的統一是很重要的，我們公司有兩款拳頭產品，一款主程經常換，經常空降乙個主程過來組織工作，另一款主程幾乎不變，就算變動了，也是脈脈傳承，不會出現空降，每一任組長都是從組內一點點爬上來的，顯然後面乙個專案組更加穩定，**各方面更好，當乙個新人進來之後，想要動搖原本早已約定俗成的意識形態，必然會感覺全世界都在針對自己。
按照大專案的規矩，已經完成了的大模組，只有在徹底維護這個模組的時候才考慮重構，不然保持可用就行了，就像我做的遊戲，戰鬥系統我早就看不慣了，但是已經用了十年了，無數的玩法依賴它，我改了之後，可能要測試一年，兩年，甚至更久都還會有相容上的報錯，而每乙個報錯導致的後果，都是所有人都無法承擔的大事故，於是我們秉持的觀點就是，有更優秀的**組織結構，可以用在新的模組上，舊的模組盡量不要去改。
如同一開頭講的，網際網路並不是乙個存粹愣頭青憑藉著熱血和能力就能闖出一片天的地方，當然這兩者很重要，但是程式開發畢竟是團隊協作，涉及到團隊，就必然會和個人有衝突，這個時候的讓步，取捨，溝通，就成為了很深的學問，網際網路相比其他圈子的文化，優點在於，提出顛覆性的觀點，所需要的尊敬成本沒有那麼高，能力和資歷的佔比比較合理。
只要是存在於這個世界上的事業，必然與人打交道，需要與人打交道的，就必然沒有絕對的只看能力，只看能力的事業，或許只存在於夢裡吧。
一些專案管理心得
最近負責的市政數字報建專案快結束了，記下一些心得 對於中小型專案，最好不要使用常規的軟體工程方法進行開發。建議前期採用迭代開發，後期採用測試驅動開發。專案一開始，就要搭好以下文件的框架，隨專案進行中，不斷修改 補充和完善。1 需求規格說明書 甲方負責。詳細記錄整個專案的需求。特別是專案過程中，一些需...
關於專案的一些心得
1.分析需求很重要。在最近做的專案中，關於需求這一點，基本上不容易一次就找好，總是需要不斷的反覆看業務去分析才能知道需求。2.三層架構模式 介面層 user inte ce layer 業務邏輯層 business logic layer 資料訪問層 data access layer 區分層次的目...
近期專案的一些心得
1.關於不同部門協作 1 要配合對方的工作，大家建立好合作的基礎。2 盡量將一些其他部門能夠主導的工作交給對應部門，通過產品進度來推進。比如配55寸屏黑屏問題，這個我們可以自己來負責追，但是硬體追會更好，因為硬體直接會參與採購，能夠更好的主導該問題。3 盡量不要將一些與對方厲害關係不大而對自己關係很...