==========2017.7.4更===============

真正在底層工作的人員 跟站在高層的人看到的東西都是兩個東西。

真正的從底層走到高層才能看的更精準  。

同樣的  從底層走到高層的人  也沒有一直處在高層的遠見與見識。

我信奉公司處於什麼階段用什麼樣的人，沒必要一開始就弄高精尖的人和事，畢竟成本不一定是你能承受的了的。

==============================================

現在的網際網路經濟可以說是日新月異，從P2P到O2O，網際網路金融，網際網路保險，還有最近大火的共享經濟，可以說是百花齊放。。。

然後其中的隱患也是相當的巨大。

==============================================

所謂的網際網路思維，敏捷開發與快速迭代來適應瞬息萬變的市場需求，

很多適合市場部制定一個需求，就要求研發部門在很短的時間內上線運營。。。

我相信慢工出細活，所謂的敏捷開發，快速迭代所帶來的後果，一定是前人挖坑後人埋，從一開始的架構上沒有考慮系統的擴充套件性就迅速的投入開發，上線運營，

一旦當專案正式運營，再想重構專案的成本是非常巨大的，很少有人會去真正的重構，只是在現有的架子上 修修改改。。縫縫補補。。

當專案臃腫到一定的地步的時候。。。。也就是瓶頸所在了。

再說重構，沒有一個對業務瞭如指掌的人帶領這個專案，重構是很難進行下去的。

日益增長的業務需求，到後期達到一個量級不進行合理的拆分。。我想。。。後果可想而知吧。

敏捷開發，快速迭代沒什麼不對，但是在動手開發前一定要合理的規劃業務，當業務達到一個量級的時候合理的拆分，必要的時候該重構就重構，畢竟誰都不會一開始就把所有的東西考慮全面。

還有最重要的就是人員迭代。。。leader要考慮到團隊中的人員是不是在你把控的範圍裡，一但脫離了把控我想主動權就在他的手裡了。而去同一模組的業務要保證最少兩個人去負責，整個團隊的人員配置也要在飽和的狀態下多出來2-3人，做技術的大家都知道，離職是很正常的事情，不要因為一兩個人的離職而導致專案的延誤甚至崩盤。

整體專案的技術應用也要自己的規劃，不要把所有的新的技術都應用在專案裡，沒有完整的生態環境代表的就是少量的文件跟一堆沒有踩過的地雷。再者對於團隊的新人來說，學習成本跟技術能力都是提高了很多。。

如今的技術現狀已經完全滿足了開發的必要條件。不要一味的去追求高大上的東西。。。畢竟專案執行要以穩定為主。