一旦認識到試驗性(其實，現在很多公司都在開始建立自己的研發隊伍，不管技術在行業裡難度如何，都希望有個某方面的突破。可就在管理實驗性專案方面失敗的很多。如果，沒有對常規專案做好管理工作，我個人認為不要再做實驗性專案，失敗的多，成功的少。更何況從中得到成果更是難 )的系統必須被構建（很多技術人員喜歡這樣做，但是構建之時沒有理論上提高，只是有了實踐的經驗，重建未免得到更好的效果，有可能事倍工半 ）和丟棄（拿得起放得下，真是說對。但是，為放棄發生很多爭端，有人不歡而散，有人搞惡作劇... ），具有變更思想的重新設計不可避免，從而直面整個變化現象（如果是乙個專案正在做此工作，應該有心理輔導員、公司領導正確指導，重新認識新的任務。把各種心理轉化成新事物的嚮往 ）是非常有用的。第一步是接受這樣的事實：變化是與生俱來的，不是不合時宜和令人生厭的異常情況。cosgrove很有洞察力地指出，開發人員交付的是使用者滿意程度（換位思考方式特別重要，讓開發人員成為使用者，站在使用者的位置體驗。其實很多地方說到這點，真正做到有幾個呢？尤其是是開發人員對使用者解釋乙個bug、new feature時，經常用技術化的語言表達，已經證明沒有站在使用者的位置上考慮問題了。如果說的話能使用者化，80%應該站在使用者位置上了 ），而不僅僅是實際的產品。使用者的實際需要和使用者感覺會隨著程式的構建、測試和使用而變化。
當然對於硬體產品而言，同樣需要滿足要求，例如新型汽車或者計算機。但物體的客觀存在容納和階段化（量子化）了使用者對變更的要求。軟體產品易於掌握的特性和不可見性，導致它的構建人員面臨永恆（如何對永恆做量子化呢？值得考慮！ ）的需求變更。
我從不建議（如何理解？指的是把使用者的潛意識通過教育『培訓等手段轉化成技術化因素？還是指讓顧客接受技術基礎建設條件的約束？ ）顧客目標和需求的所有變更必須、能夠、或者應該整合到設計中。專案開始時建立的基準，肯定會隨著開發的進行越來越高，甚至開發不出任何產品。
然而，目標上的一些變化無可避免，事先為它們做準備總比假設它們不會出現要好得多。不但目標上的變化不可避免，而且設計策略和技術上的變化也不可避免。拋棄原型概念本身（估計指形散神不散，形式可以多種多樣 ）就是對事實的接受——隨著學習的過程更改設計。
閱讀《人月神話》批註
軟體工程 唯一不變的就是變化
青潤軟體諮詢2群中的對話，總結說來就是，軟體工程面對的專案中唯一不變的就是變化，國際上管理學的規律和原則都是依據抽象出來的相對穩定的內容進行抽取和總結的，而專案中最重要的因素變化是完全被遮蔽的，所以，不要說國外就一定如何如何，國內就一定混亂。軟體工程的終極目的就是要解決這種混亂。飛魚 576 16 ...
應對變化的唯一不變就是提公升自己的核心競爭力
這次疫情絕對算得上是一次黑天鵝事件，也許很多年之後我們回首今年，我們一定會感慨 歷史的程序的改變也許就是這件事情。原來以為撐過2月，3月，我們就會度過難關。是的，沒錯，我們是很快控制住了疫情，但國外卻陷入了更大的疫情當中，這是我們始料不及的。如果不好彩，疫情會持續幾年，當然，希望能快速結束，不然經濟...
IT行業，唯一不變的原則 「變」！
最為乙個程式猿的我，儘管剛出來，但還是對這個行業的變化之快很感概。應該是，也確實是，it行業因為 變 才能跟上和推動整個人類的發展，it行業唯一不變的原則就是 變 尤其是網際網路上的技術，剛盛行沒幾年技術就能很快被更好更新的技術替代了，很多技術都經歷這個淘汰的過程，從大一，到現在，我也是深有些體會。...