隨著軟體專案越來越龐大，為了提高開發效率和有效的質量管控，開發過程中的專案管理越來越重要，流程分工也在不斷細化。傳統的軟體開發過程分大致分為如下幾個步驟：
需求提出
可行性分析
需求分析
概要設計
詳細設計
編碼測試
整合交付
產品的最終形態和功能都是第一步的需求所決定，「蝴蝶效應」在開發過程中體現特別明顯，第一步的需求發生了變化，很可能會導致後面所有步驟都重來一遍。傳統的專案管理除了對專案過程的管控，更多的是對需求的管理。傳統的軟體專案開發過程中會盡力避免需求的變更，甚至在需求確定以後會由需求提出方（合作開發）出具正式的需求文件並蓋章確認以示「不再改變「。
傳統的軟體開發流程是乙個工業流程化的模擬過程，最大力度的管理變化，然後進行工序的詳細分拆和實施。整個過程中會有大量的各部門（公司）的溝通會議和流程，時間成本極其龐大，動輒數年的版本計畫也很常見。
隨著網際網路的快速發展，市場環境和使用者喜好都在急速的變化過程中，動輒數年的產品開發周期已經遠遠不能滿足日新月異的市場形勢。網際網路產品，特別是遊戲類產品，開啟了精益開發，小步試錯，快速迭代的開發模式，並非從一開始就需要構建乙個大而全的完整產品，而是最開始只推出最核心的單一功能，通過不斷迭代來完善和調整產品，開發過程中不斷收集使用者反饋，並將有效反饋意見融合進下乙個迭代版本中。
「小步試錯，快速迭代」的前提否定了需求的」聖神性「和」不變性「，預設需求是」錯「的，是會隨時變化的。雖然遊戲產品大多數沒有了嚴格意義上的傳統軟體開發過程中的步驟分工，但是這些步驟所代表的開發內容是存在的，只是因為需要」快速「，各步驟的界限被打破簡化融合到了一起。變化的需求依然會導致後續開發個階段的變化。
軟體產品的需求提出是為了能夠做出乙個產品來滿足目標使用者的痛點或者癢點。而痛點/癢點的發現的方法是多種多樣，可以經過深入的使用者調研，觀察到使用者的需求，提出乙個產品來滿足他們的需要；也可以像賈伯斯這樣，根本不做使用者調查，我給你的就已經是最好的。也可能最開始做出了乙個產品原型方向，然後經過多次迭代修改後得到了乙個受歡迎的產品形態。
具體到遊戲產品，產品的方向更多是公司老闆或者製作人看好某個遊戲細分領域，構造出這個遊戲產品的核心玩法，基於該核心玩法，結合各種輔助系統，最後得到乙個完整的遊戲。
遊戲的具體做法是，產品策劃根據製作人的巨集觀構想，首先設計出核心玩法原型，並和程式緊密配合，實現出第乙個核心玩法demo。專案主要參與人員（特別是老闆，製作人等）體驗並頭腦風暴，可能經過多次的迭代修改後，得到乙個大家都認可的核心玩法demo。核心玩法是遊戲的存在的根基，是能夠滿足玩家對遊戲性，可玩性的要求，或者超出玩家的預期。
為了構建乙個完整的遊戲，需要在核心玩法之外建立各種輔助遊戲系統（如角色，等級，成長，裝備，任務，副本，好友，工會，組隊等等），而遊戲開發過程中最大量的需求，即來自這些輔助功能系統。輔助功能系統大多數都有一定程度的同質化，簡單粗暴的方法都是copy友商的系統規則和設計，好一點的進行一些微創新，極少數的會有原創功能玩法。無論是copy，微創新還是原創，針對開發（程式，美術）來說，都是任務需求。
世界在不斷的發展變化，行業環境在變化，使用者的喜好也在變化，唯一不變的就是」變化「本身。如果將遊戲功能簡單的分成核心玩法和輔助系統兩部分，那麼需求變化也來自這兩部分。
核心玩法變化
核心玩法是遊戲存在的根本，理想情況下核心玩法的變化只應該在demo打磨階段，已經demo確定後，核心玩法就不應當再改變。此時發生的改變的原因是發現核心玩法並不能滿足使用者的需求，或者有了更好的想法。
輔助系統變化
遊戲開發過程中的絕大部分工作量都是集中在輔助系統，大量的輔助系統涉及各種龐雜的邏輯規則，系統互動和設計細節。輔助系統的需求變化主要有一下因素：
有了」更好「的想法：對於同乙個功能，策劃有了新的更好的想法。
之前規則理解有誤：由於文件不細或者溝通理解有偏差，開發和策劃對於規則理解不一致，開發過程或者完成後才發現不對導致的需求「變化」。
來自上層的想法改變：上層是指老闆或投資人等，他們有自己的想法和理解，要加入到遊戲中，導致變化。
來自合作方的變化：遊戲的渠道和運營方通常有更大的話語權，他們「更理解市場和使用者「，他們會加入自己的想法到遊戲中。
來自」新人「的不同想法：專案的新成員，特別是新策劃（新製作人）的加入，會導致需求的大量變化。
來自和程式的妥協：開發過程中，程式發現有些功能規則的實現複雜度很高，價效比很低。和策劃商量後採用了簡化版的替代方案。
美術需求變化：單獨說一下美術變化，產品的第一眼看到的總是介面和美術，而每個人都有自己偏好，沒有什麼絕對的對錯，都能發表自己的意見，總會或多或少導致一些變化。
遊戲開發過程中，頻繁的需求變化，對專案的開發和團隊的管理都是有害無益。需求變化可能導致以下問題：
專案開發周期不可控：需求的變化意味著開發工作量和溝通工作的提公升，必然導致開發周期delay。又要引入變化，還需要強制按原計畫時間完成都是天真的一廂情願。一廂情願的事情累計多了之後，會在團隊中逐漸產生怨氣，從而危害團隊。
損害團隊士氣：古人作戰追求，「一鼓作氣，再而衰，三而竭」。專案開發也是一樣，大家有了相同的任務目標，正興致勃勃，士氣高昂得前進，三番四次的目標修改，會讓團隊對目標產生迷茫和懷疑，會耗盡團隊的士氣，從而降低團隊生產力，甚至導致團隊不穩定。
成員間產生不信任感：專案成功是乙個團隊合作的結果，成員之間的肝膽相照，相互信任，相互扶持和幫助是專案成功的助推劑。而頻繁的需求變化會讓組員之前產生不信任感，覺得對方是在給自己挖坑，「既然還會繼續變化」，那實現當前需求只是浪費時間。成員之間的質疑產生後會很快導致各種矛盾出現，甚至上公升到人員之間的各種衝突。
首先所有團隊成員需要明白，絕對的需求不變是不可能的，唯一不變的僅僅是「變化」本身；所謂的控制變化，是盡量讓需求變化更小，更可控，即使最終變化來臨也使得變化對專案的影響降低到最小。可以從以下方面嘗試解決需求的變化問題：
構建靠譜團隊
所有專案都是由獨立個體組成的團隊開發完成的，構建乙個靠譜團隊是任何事情的前提。我所理解的靠譜團隊，首先有乙個擁有遠見卓識，目標堅定，值得信賴和追隨的老大；其次，下面有一批各種職能分工都能獨當一面，認真負責，坦誠相待，積極上進，相互信任的成員。即使一開始沒有這樣的團隊，也要有目的的一步一步建立起來，並形成一種互信包容，相互扶持的團隊氛圍。
作為團隊管理者，需要挖掘和發揮每個人的優勢，讓他們能夠發揮自己的全部潛能，並不斷提高。在專案中不斷做出自己的貢獻，形成一種成就感和歸屬感，一旦事情從「要我做」變成了「我要做」的狀態後，很多難題都會迎刃而解。「想做一件事情會找到乙個方法，不想做一件事情會找到乙個理由」，我始終相信一般的專案開發中，並會不會遇到不能解決的世界級難題，絕大部分都是能夠很好解決，一旦成員有了自己想去解決問題的心態，解決方法會隨之而來。
在這種心態之下，遇到需求變化並不會導致成員的抵抗，而是會讓他思考你的變化是否是對專案的一種真正價值提公升，並自己深入分析再提出自己的建設性意見，最終在積極討論的氛圍中形成了決議。
統一目標
構建利益共同體
從組織架構和利益分享機制方面，讓需求的提出人和實現人成為利益共同體；一榮俱榮，一毀俱毀，團隊成員都在一條
船上，個人利益就是共同利益。
充分設計和討論
專案開發過程中，很多時候為了」快「，導致系統設計和規則邏輯並未想徹底就已經開工。最終做到一半或者快要完成時發現機制有缺陷，需要重新設計，此時的改動可大可小。開發前的充分設計，徹底理解和吃透產品邏輯規則，有利於減少開發中的不穩定因素。
重要資訊多次確認
人與人在溝通過中，廣泛存在「資訊漏斗」現象。假設a有一件事情需要b去做，資訊漏斗作用過程如下：
a在心裡想了一件事情，假設完整度是100%。
a找到b，把事情描述給b的過程中，因為表達能力或者語言表意缺陷，只能把80%的事情說出來。
b在聽a表達的過程中，由於自己注意力分散或主觀偏見等因素，只能聽到事情的60%。
b在理解自己聽到內容的過程中，因為自己的知識結構，理解偏差等，又會損失掉20分的資訊完整度，得到40%的資訊。
b在執行的過程中，因為執行力或者其他因素導致偏差，又損失掉20，最終只能得到乙個20%的結果。
從以上模擬的「資訊漏斗」可以看出，最初a的乙個100%完整度的事情交代給b執行出來後，只變成了乙個20%的結果，和最初要的東西已經大相徑庭。最終a和b在核對最終結果的時候，會出現無窮的爭執和矛盾。
為了降低「資訊漏斗」帶來的影響，需要每一步都對資訊進行重複確認，確認資訊的丟失降低到最小。同時溝通各方都需要明白「資訊漏斗」的存在，當最終出現偏差的時候才能心平氣和的繼續溝通解決問題，而不是相互指責和推諉。
需求分期
對於優化型的需求，在之前需求已經進入開發階段的情況下，可以考慮放到下乙個迭代週期裡面做優化，而不是打亂當前的版本進度，重新設計和實施。同時也給到產品策劃乙個時間視窗再次沉澱和思考修改的必要性和機制的完整性等細節。
坦誠有效溝通
專案開發的目的是為了共同完成任務，做出乙個大家認可的產品。開發過程中無論是產品本身還是涉及開發成員，都會有大量的溝通需要進行。而溝通要能順利進行且最終富有成效，坦誠是所有前提的前提。只有坦誠溝通，對事不對人，讓被溝通人感覺到得到尊重，才能將溝通有效進行下去。把別人當傻子，浮於表面的客套話，忽悠別人的虛情假意都會最終導致信任的消逝，沒有了信任，專案失去了根基，所有目標和遠景都會變成虛無縹緲的空中樓閣。
前幾部分做好了之後，應該能大幅降低需求變化，即使發生變化也會將影響侷限在小範圍內。但是如果已經出現反覆變化，導致矛盾，有哪些辦法呢？
首先，需要確保成員都理解變化是不可避免的，確保大家對共同目標的認可，都在為達到目標積極的想辦法改進，大家的溝通還在乙個「頻道」上，有了共同的前提，對事不對人，就事論事的討論分析，都有溝通改善的意願是事情能夠改善的大前提。
其次，坦誠溝通是任何有效溝通的基本要素，「正其心，誠其意」，一旦溝通雙方都感覺到了對方的坦誠溝通態度，自己的防備和抵抗情緒就會消減，更容易回歸到事情本身。
再次，溝通時要給與對方足夠的尊重，任何人都有被得到尊重的需求，」你的心理有沒有我「？我們交流的時候，你是否是一種願意解決問題的態勢，這個很重要，中國是人情社會。大部分人對應別人對自己的態度是很在乎的，知道是」你在乎我「的前提下，任何問題都不是問題。
最後，成功能夠掩蓋所有的的問題，即使問題再多，矛盾再大，當專案的結果是乙個巨大的成功，所有問題都會被暫時掩蓋，不過通過成功來掩蓋問題是暫時的，一旦成功沒能延續和複製，問題已經會爆發。
每個人都有自己的解決矛盾的想法和方式，以上是自己的一些思考，不過防範未然才是更好的選擇。
軟體專案開發過程中的需求分析心得
目錄參考 需求分析是軟體計畫階段的重要活動，也是軟體生存週期中的乙個重要環節。該階段是分析系統在功能上需要 實現什麼 而不是考慮如何去 實現 需求分析的目標是把使用者對待開發軟體提出的 要求 或 需要 進行分析與整理，確認後形成描述完整 清晰與規範的文件，確定軟體需要實現哪些功能，完成哪些工作。1 ...
開發過程中錯誤總結
1 18年5月28日 說明是.xml檔案的問題。去上.xml排查，看是不是註解。或者檔案本身書寫有誤。2 linux下 webstorm,ppt,wps不能書寫漢字。在啟動檔案中修改 啟動 sudo sh webstorm.sh export xmodifiers im fcitx export q...
iOS 開發過程中遇到的那些奇葩的坑
1.列印異常 dyld lazy symbol binding failed symbol not found objc unsafeclaimautoreleasedreturnvalue dyld sim dyld fatal error 0x60e000 0 int3 0x60e001 1 n...