突然想起一句話，人生若只如初見，找伴侶如此，在公司幹活也是一樣。

當你剛加盟一家初創公司的時候，總是豪情萬丈，自信滿滿，但是問題總是出現的那麼突然，沒有一點點防備，創業公司甚至沒有大公司的蜜月期，你就會面臨很多問題。

一、專案管理問題

創業團隊為了追求小快靈的模式，很多時候犧牲了專案本身的科學管理部分，例如專案計劃倒排、任意變更需求、隨意封閉開發加班加點，甚至壓縮測試工期等等。

當然，架構師並不是來抱怨問題的，而是如何更好的解決它，我覺得作為一個合格的架構師，基本素養就是敢 SAY NO。很多問題都是因為畏懼權威，過度承諾導致的。

另外，也需要尊重科學，重視專案里程碑，杜絕人月神話這類事情的發生。

我覺得，不管加班也好，砍需求也好，一定要遵守一個原則，就是不能傷害客戶的利益，很多時候我們一味追求糙快猛的工作方式，看起來做了很多事情，其實結果卻是漏洞百出，應付不過來，最終傷害的還是客戶，倒黴的還是你自己！

推薦大家都好好讀讀 Bob 大叔的《程式設計師的職業修養》這本書，特別是前面幾章。在這裡介紹下 Bob 大叔。Robert C. Martin，世界級軟體開發大師，設計模式和敏捷開發先驅，敏捷聯盟首任主席，C++ Report 前主編，被後輩程式設計師尊稱為 “Bob 大叔”。20 世紀 70年 代初成為職業程式設計師，後創辦 Object Mentor 公司並任總裁。Martin 還是一名多產的作家，至今已發表數百篇文章、論文和部落格，除本書外，還著有《程式碼整潔之道》、《敏捷軟體開發：原則、模式和實踐》、《UML：Java 程式設計師指南》等。他最近創辦了 cleancoders.com 網站，專為軟體開發人員提供教育視訊。

二、深入業務程式碼的問題

由於創業公司發展迅速，所以往往會忽略程式碼構建的科學性，甚至犧牲和忽略設計的過程，完全需求片段導向，系統可以說是功能點的不停疊加，到最後就算是經驗豐富的超級救火隊員都沒法解救了。

這時候，很多人就會說，這還不簡單嗎？趕緊重構啊，拆分模組啊。說實話，畫個幾個框，搞幾個箭頭標註一下資料流向這誰都會，但是具體業務如何建模？

任何網際網路的業務平臺無非逃不過：會員，賬戶，訂單，支付，營銷，計費等幾大模組。

但是重構不是說畫幾個框框搞定的，而是在不脫離你業務顯示情況下的合理設計，例如做營銷，你不能只是簡單構建一個營銷的規則引擎就完事了，也不是做一個抽獎或者優惠券的系統就是把營銷的事情做完了，而是需要去分析：

• 從上帝視角（系統整體視角）你的營銷系統擺在什麼樣的位置。

• 從整體上走通營銷的規則和流程。

• 套用目前和未來一段時間內有可能會出現的需求，是否可以在這套模型下可以走通的。

• 設計營銷系統本身，站在營銷系統的視角進行建模。

• 在設計完營銷系統核心部分後，安排開發工程師進入營銷系統的細節功能點開發，以及周邊系統的接入。

再例如會員系統，有些有主子賬號的概念，這樣又會影響訂單系統是否需要體現主子賬號的關係，甚至又得影響營銷，我買一送一這樣的活動如何搞，賬單如何體現等等？

所以，建模和重構沒那麼簡單，也不是畫幾個框框就能解決你的問題的，你得深入業務，圍繞業務，並且建模絕對不是技術人員的職責，而是運營，產品，市場，技術等大家都需要達成一致甚至深入理解的。

推薦大家閱讀下，Eric Evans 寫的《領域驅動設計：軟體核心複雜性應對之道》一書

三、產品需求問題

你會發現產品經理有時候也不能很好的從產品的整體角度去產品，僅僅只是把業務方的需求過濾和理解了一遍就交給了開發，這樣，你就會遇到很多自相矛盾的業務邏輯，甚至影響到使用者體驗。那麼，這個時候你會怎麼辦呢？是選擇做鴕鳥把頭埋到沙子嗎？還是選擇幫助產品經理一起來分析呢？

很多時候，產品經理會抱怨，自己只是個傳聲筒，老闆找他，運營找他，市場找他，那麼多事情，根本沒法系統性的去梳理產品需求，結果導致需求總是零星的提給開發，結果上線之後漏洞百出。最後背黑鍋的不但是產品經理本人，還有開發和測試，客戶會說，這是什麼垃圾技術開發的。另外，老闆不瞭解情況，也會說，花那麼多錢，養一個技術團隊，結果開發出了什麼鬼？

我想，在創業公司產品技術部工作，最難的就是產品經理和架構師，架構師需要從產品的角度去審視，去把住命脈，因為這已經是最後一道工序了，不繫統性的梳理，那麼進入開發就會導致前面的悲劇。

產品經理也得好好思考，雖然前期會很累，確實事情很多，但是累一次總比你無窮無盡受虐最後導致團隊和老闆還有客戶信心喪盡的好。

另外，難道產品設計真的很難嗎？除了整個業務模式的玩法你跟別人不一樣外，整個產品的形態，其實大多數同類的廠商設計的都是可以互相對標的，比如抽獎怎麼玩，你大可以對標一下京東，天貓等產品的玩法，然後結合你自己的特色進行改善。其實我的意思不是叫你去抄襲，而是你要去梳理思路，形成體系化的結構，當你不知道自己怎麼弄的時候，可以去借鑑別人，就像讀書，讀的多了自然就會明白些。我想，大多數重運營的 APP，其實還都是相似的。

四、組織協調問題

大公司的好處就是各司其職，只要有合理的制度和流程，只要你按照規範操作，傻子都能把任務完成（當然這不是說大公司的員工都是傻子。我這裡是說流程和規範的重要性，當然傻子雖然能完成工作，但卻不能成為大牛，同樣，大牛不管在大公司還是小公司，他一樣能成為大牛）。但是，在創業公司卻不是這樣，流程和制度的缺失，導致你會覺得什麼都很亂，什麼都會有問題，但是你得反過來思考一下，假如什麼都好了，還需要你幹什麼？另外，你加盟創業團隊的初心是什麼呢？為什麼開頭我要說，人生若只如初見呢？

其實，亂就是體現你的價值，把你的經驗和優勢發揮出來，梳理清楚流程，該自動化就自動化，不合理的就及早提出改善。其實，管理管理，管理的不僅僅是你的員工，也不只是你自己，你還得需要如何向上管理你的老闆，如何跨部門管理其他同事等等。擁有一顆大心臟吧，為什麼麥迪成為不了科比這樣的人呢？

當然，我覺得在協調合作的時候，千萬不能把自己的成就感建立在別人的痛苦之上，一個創業團隊，大家為什麼跟你合作，為什麼大家要在這個公司，都是和你一樣心存夢想，奉獻自己，不是隻有你一個人是最偉大的。是人總會犯錯，你要理解別人，嚴於律己，寬以待人。我覺得華為價值觀裡有一條非常好，贏則舉杯相慶，敗則拼死相救。而不是你贏了還黑隊友，你敗了在責怪隊友。時刻心存感恩，感恩你的同事，感恩你的下屬，感恩你的夥伴。只有這樣，你的事業才有可能長久，否則就算事業成功了，你失去了一群幫助過你的人，你覺得這真的是你想要的嗎？

五、技術選型約束問題

很多創業專案為了圖快和省事，在開發過程中甚至沒想清楚為什麼，就隨意從網上下載別人的程式碼和元件，然後寫出來的程式碼五花八門，比如一個 web 工程，有 VO、DO、DAO、DTO、AO、BO、POJO…這麼多的概念不把開發給搞成腦殘才怪呢。

再比如 JSON 輸出，有手工拼裝的，有 fastjson 的，有 Jackson 的，總之市面上有什麼同類技術，就會在你的程式碼裡一一出現。

當然，我這裡不是講你要選擇什麼技術，選擇什麼框架，選擇什麼軟體，而是想說，這種規範和約束性的工作，越早做越好，否則後面重構代價非常大。比如說我們之前的 action 居然都是 servlet 手工輸入的，連自動注入都沒法做，後面新人進來就說，你們公司怎麼那麼垃圾等等，為了解決這個問題，我跟一個哥們合作，光光遷移 1000 多個 servlet，並且完成測試，就花了 2 個禮拜，另外，主幹程式碼人家還得提交，後面還得釋出前增量 merge 一次。代價非常大。

架構，還是需要持續的控制，持續的優化，而不只是等到重構的那個點，否則你會很累，團隊會很累，老闆也不滿意，他們會覺得，不是剛剛重構過嗎？為什麼你們的系統又不行了？為什麼又要停下來讓業務需求停止呢？

當然，這個事情不是技術驅動那麼簡單就可以完善的，還是需要得到你的老闆，產品業務方的理解和支援才行。其實架構不是牙膏，擠擠也不一定會有，技術和業務好比公司前進的兩條腿，缺一條都不行。其實再怎麼業務導向的公司，技術其實還是很重要的，比如很多重運營的公司，假如沒有牛逼的運營支援系統來提高運營生產效率的話，人力成本是很龐大的。而且都是完成手工點選裝備的低價值工作，還看不到運營的效果是什麼樣子的。

架構，其實有時候還是和權利有那麼點關係的，你既要讓架構師幹活，而且要出規範，讓系統工作的更好，卻不給架構師明確的權利和約束的職責，有些事情屁股決定腦袋，業務，需求，老闆，隨時都可以否決你的建議，屁股決定腦袋，很多時候真的是一條鐵律。

六、運維方面的問題

現在很多公司都上了雲，比如阿里雲，騰訊雲，所以，很多同學都會覺得運維省事了，沒什麼挑戰了。但是恰恰相反，這是墨菲定律的反定律，越是你覺得沒問題的地方，越會出現問題。因為人家可以幫助你維護硬體，維護機器，甚至維護中介軟體，資料庫。但是沒法幫助你維護你的業務，也沒法幫你優化效能的瓶頸。

另外，現在有很多第三方的公司和服務，做了很多運維支撐監控，錯誤排查等服務和工具，假如你的業務發展速度飛快，運維跟不上，你也可以先期使用這些服務來快速定位線上問題，等後期業務發展壯大了，再慢慢發展你的運維團隊，招人永遠是個大問題，但是我們不能因為這個問題就面露難色，天助自助者呀！

同時，一定要提倡人人都是運維的理念。試想，你自己寫的程式碼，你居然都不知道哪裡出了問題，線上到底是什麼情況引發的問題，這是多麼可怕的事情呀。

不是說上了雲，你的系統就不出問題高枕無憂了！很多中介軟體，甚至一些基礎元件，因為貼合你的業務，還是你自己開發的，它們的運維成本並不比維護機器更低。

七、最後談談人的問題

其實，前面講的這些最終都可以歸結為人的問題，或者說不管大公司還是小公司，人的問題才是最本質的問題，天下熙熙皆為利來，天下攘攘皆為利往！

首先你得解決內部溝通的問題，如何溝通，如何平等溝通，特別是創業團隊，大家為什麼會選擇加盟你，為什麼又會選擇離開你？這是很科學嚴肅的問題。很多創業團隊就會犯類似錯誤，把人當做工具使，不行就換，再不行繼續招聘。

他們從來不想如何培養內部人員，如何讓內部人員的效能最大化。天助自助者，假如你自己都沒法救你，還指望別人來救你？

其次是招聘的問題，很多公司都缺人，都缺牛人，但是他們缺從來沒有認真科學的理性分析，我為什麼要招人？我要找什麼樣的人。我可以負責人的說，很多公司都是在憑感覺招人，盯著簡歷憑感覺撞大運！

最近遇到好幾個創業公司的 CEO，都說缺人，需要架構師，但是他們自己卻說不清楚招聘進來架構師能解決他們什麼問題，是技術問題？還是業務問題？太可怕了。其實這不僅是對自己不負責，也是對別人不負責。人進來不僅僅是短期能否解決你的問題，還得長期關注別人在你這裡獲得什麼，找到合適的人是雙贏，否則就是雙輸。

你真的得想清楚，你是想要找的這個人能做成什麼事情，還是看重這個人看起來曾經做過什麼事情，這可是有本質的區別的，因為這恰恰決定了你招聘的態度，這是個嚴肅的話題，而不是你撞大運的行為！

另外，很多時候，你第一個招進來的技術負責人會決定後面人員的素質，屁股決定腦袋，牛人跳槽也不希望找個二逼管著自己，就像蔡振華管中國足球，就是個笑話，所以，當你和一個大牛把酒言歡，暢談一番覺得這個人板上釘釘能加盟你的時候，卻在關鍵時刻放你鴿子，你就該反省，為什麼你的團隊沒法讓大牛加盟了。

也許大公司招人只是為了壟斷人才市場，形成人才資源的行業壁壘，但是創業團隊不能這麼幹，否則，遲早你會身敗名裂，找不到任何一個人。

接下來就是人才培養的問題了，一個人進來之後，人家為什麼選擇在你創業的階段加入你？你是否對這個員工具有感恩的心，人家幫你成長了，你是否願意幫助人家呢？每個人都會在一家公司遇到階段性的瓶頸，在這個時候，你是一腳把人踢了，還是樂意抱著感恩的心，來給人家成長的機會呢？因為任何一個人，在一段時間內，總有被榨乾的時候。感恩的心，不只是對別人，也是對你自己！

最後，就是成就感的問題了，假如工作天天都是上面指派，每天都是機械的處理指令，我想，任何有想法的人幹不上幾個月就得離職。當然這個也得看你的團隊是否足夠精英，假如是組建精英團隊的思路，就不會出現這樣的情況，但是假如你的團隊只是區域性精英，你就得考慮如何保證精英人才的成就感問題，而不只是機械的向他們傳遞指令，否則…..

講了那麼多，我是想說，當你豪情萬丈打算加盟一家創業公司的時候，今日長纓在手，何時縛住蒼龍？卻在進入一家創業公司之後，發現這樣那樣的問題，請你耐心，細心，愛心的去解決。而不只是抱怨。

創業不簡單，加盟一家創業公司也不簡單，請你認真對待你的人生和你的家人。並不是每一個人都適合在創業公司工作的！