一個項目的運轉應該是井然有序而非雜論無章，細節決定于很多東西，比如UI中的字體顏色，RGB值可能只是一個R的參數相差1，肉眼很難識別，而如果用到專業工具測試，那么就會暴露無遺，保證整個項目整體色調的一致是在項目開始啟動時就應該全局考慮的事情!

首先項目從需求調研到合同簽訂，接著UI設計好界面給到開發，我們拿到界面的***件事并不就是要開始繪制界面，繪制到哪里就是哪里這樣就失去了對項目的把控能力，首先要做的是先看需求文檔和RP，將整個流程串流起來，這并不是浪費時間的事情，而是重中之重的事情，只有熟悉了整個項目的商業模式，流程運轉，才能在后續占有主動權，而不是跟著項目或者UI設計的鼻子走，如果有時間使用思維導圖整理一份對需求的理解也是很有必要的，讓自己知道整個項目在做什么，而不是為了開發而開發。

對需求理解透后我們開始做的***件事仍然不是搭建界面，而是思考工程的整體規劃，我們不談架構那么大的思路，規劃什么呢?

• ***：整體工程設計模式，MVC，MVVM，MVP，Rout...
• 第二：整體工程模塊劃分：基礎層,網絡層，硬件層，公用層，管理層，邏輯層，資源層，配置層...
• 第三：思考整個項目會用到哪些第三方庫，***使用cocopods導入
• 第四：考慮整個項目界面有哪些是可以公用的，有哪些View是可以在很多位置使用的，哪些控件是需要封裝的，哪些是要做動畫處理的等等。
• 第五：歸納出整個項目使用的顏色，一般不會超過五種，使用宏文件管理好顏色配置文件，同時在Xode常用顏色管理面板設置好項目常用顏色值，后續使用XIB直接使用設置好的顏色，這樣不會造成顏色混亂， iOS11在Assets.xcassets里面新增了一個顏色管理很方便使用，并且可以實現全局變換顏色，同時歸納出常用的字體大小等等...
• 第六：搭建好項目基礎框架并建立好代碼管理倉庫
• 第七：和后臺確認接口字段，如果后臺規范，則可以直接根據后臺給的接口文檔進行先行開發，繪制UI和邏輯同步進行!

如何管理好一個或多個項目?

• ***：切片原則，將項目功能不斷的進行分解和細化，制定計劃進度表。
• 第二：主流程先行原則，也就是一個項目中最核心的功能，這里所說的最核心實則是客戶最關心的功能，該功能使用頻次高，大部分的業務流轉都在此功能中。
• 第三： 以靜制動原則，做項目需求變更是在所難免的，頻繁的需求變更直接反應出項目人員對需求的把控能力及規劃能力，面對需求的變更先靜下來分析該需求是否合理，能否有更好的解決方案，如果變更了該需求從上流到下流會需要多少時間周轉，風險在哪里等。
• 第四： 保留原則，對于項目的一個周期循環，要有實時的文檔記錄，需求的變更要簽訂變更合同，而不是說變就變，***面目全非反倒無可追溯，很多程序員并不是不想做好一個產品，而是懷著一顆打磨產品的心卻被變更的需求折磨的體無完膚，甚至出現程序員在代碼注釋中罵客戶罵公司的行為，實則為無泄可發而為之。
• 第五: 控制源頭原則，所謂水往下流，從商務部--項目部--設計部--開發部--測試部環環相扣，源頭始于需求，牽一發而動全身，不動是不可能的，一個完整的項目不可能不動，動要有原則，有限制的動，需求是一個無底洞，必須限制范圍。
• 第六: 溝通為主，無論哪一個環節都需要多協調溝通，因為需求在傳遞的過程中很可能會變味，就好比一句話傳遞10個人后意思會與原來的有所差異甚至偏離原意，嚴格來說溝通是最重要的一環!

需求有輕重，項目有大小，每個項目的背后都有一個孕育的商業模式，無論是原創還是模仿，都可從中汲取經驗，學習到一種思維亦或一個行業的思維，所以不為做項目而做項目，為做項目而不單局限于某種項目。就如編程語言一樣，不要去討論PHP是不是世界上***的語言，還是人生苦短，我用Python。有了編程的思維，不同的編程語言只是語法不一樣而已，局限于某種語言是對自己思維的限定，它們之所以存在必然有各自的優勢，亦或解決某些特定的問題，而取長補短實為上上之策!