軟體工程也是軟體專案，如果只是當做乙個專案，那麼專案有專案的管理方式和特點，這個有pmp等課程，也是幫助專案負責人（專案經理）如何更好的把我專案，來控制專案的質量，進度，費用等。
從專案的特點而言，既然認定為專案，那麼在很大程度上是需要乙個team，一些人一起共同完成，其中的原因是乙個人無法掌握這麼多的知識，必須通過協作來達到專案的目標，當時這個專案的目標也是參與的各個人的共同目標。同乙個組織，同乙個夢想。
軟體開發的過程一直在進化，從原來的額瀑布的方式，到敏捷等等。當我們最開始學習軟體專案開發過程管理的時候，我記得比較重要的是說需求的確認要比**的編寫重要很多，而且在專案管理的過程中時間佔比也重很多。
那麼這裡的需求和一般的專案需求的差別是什麼？
土建專案和我們軟體專案的管理的實施的差別在**？
軟體專案開發常見的問題。
1.開發維護成本越來越高
2.開發周期過長
3.系統開發跟不上需求的變化
4.需求變更很頻繁
傳統的軟體專案需求管理人員在網際網路時代是產品經理的角度。當然產品經理的角度更多是在2c的產品設計中，要重視使用者的使用體驗，如使用者使用不爽，那麼軟體產品沒有人使用，公司就沒有任何價值。但這種使用除了功能的需求，還有其他角度的需求，體驗爽不爽是乙個非常綜合性的問題。
傳統企業的軟體開發，是內部的，內部流程的確認，結合功能的開發。體驗不是非常重要，管理流程是否確定是重中之重。
按照開發流程
確定需求->概要設計->詳細設計->開發->測試->使用者確認->上線
上述是乙個比較典型的流程。
在這個確認需求的環節，好的需求管理人員需要進一步分析和了解使用者的需求是什麼，為什麼這個需求，到底可能存在哪些變化，好的需求管理人員能很好的把握業務部門的需求，對於新的需求盡可能不做開發，或者不改變系統框架的條件下達成目標，也讓我們的軟體產品穩定，，降低我們的軟體開發成本等。
那麼軟體是什麼？如果從工具的角度而言，這個工具和別的工具什麼差別？
我們用鋤頭來鋤地，我們用電吹風來吹頭髮，這些都是工具。工具是用來解決問題，都存在這個東西的內在實現和使用者使用兩個視角。
工具的存在是為了解決特定的問題，這個問題需要有一定的邊界，這個邊界決定了這個工具設計的邊界。我們需求人員在對於無結構化的業務部門提出的需求，需要進行分析和建模。這個是形式上比較理性的過程。業務流程，表單等等。
軟體其實解決的資訊流，這個東西比較抽象，也是無形的，你有乙個吹風機，但一般的人可能不會想能否來乙個自動吹頭髮的東西，我不用自己去擺弄這個吹風機工具，我頭髮就立刻幹了，或者我的吹風機能夠自動的來給我吹頭髮，各種角度。因為在使用者的心中對於吹風機的功能有乙個大概的範圍，這個範圍決定了這個產品能做什麼，不能做什麼。
由於資訊的概念很廣，好像什麼都可以做，那麼使用者的需求可能比較天馬行空。
軟體專案在需求分析階段，就是對於使用者的需求進行假設和建模，領域模型理論，是認為每個特定的領域都有自己的業務模型，通過和業務專家溝通，完成不同領域的特定模型，幫助需求人員和業務部門加快確定業務需求，保證軟體質量。
上述的描述問題的另外乙個思路是，從系統的角度是多層次的，那麼我們是否可以多層級，多角度的解決問題問題。我們的世界比較基礎的是原子，但我們不需要原子的概念來看這個世界，使用者的檢視也是多角度的，我們需要在不同的層次來看是系統，也需要掌握系統不同層次的規律，從而讓系統柔性調整達到我們的目的。
剛才說道吹風機的事情，說明我們對於使用者的使用期望的控制，如何控制使用者的期望，那麼可以降低我們產品亂七八糟的需求。
如果從公司的層面來看，最高的企業願景是乙個非常抽象的東西，這個東西的實現可能在不同的時代是不同的東西。比如快遞公司，我們的目標更快的交付物品。但是馬車時代，汽車時代，飛機時代，這些具體物流工具是不一樣的，不同的交通工具，需要內部對應的部門的組織架構，業務流程，人員崗位也有不同變化。企業目標的實現=組織流程架構+技術+人。
在很大程度上這個也是從管理的角度對於企業實際業務操作的抽象，這個抽象是為了讓我們能夠更高的層次來看企業，把控企業的風險和利益。
軟體專案在很大程度上是讓機器支援這個流程。
業務部門和需求管理需要因為企業願景的抽象性到具體實現的差異性中間的相關因素，導致這種變化成本是很高的。
軟體專案的最終產品的乙個特性是剛性。你不能所以的修改功能，和在系統內完成事項的剛性。如果在顯示生活中要求10點上交資料，也許你11點也能提交。但是軟體系統是不允許的，這種剛性也是他的乙個特點，這個是內在的特型，或者說是他比較基層的特型。
自然世界的運作規律是客觀存在，人不可修改。物理規律，化學規律，你不能更改，但在更高的層面上你可以通過其他的方式方法達到目的。
過去的軟體產品在很大程度上是提出需求，建模開發，這個開發是**開發，週期成本都比較長。
目前的一些saas的產品，是可配置的，字段，表單，流程都可以配置，這個是乙個高層次的抽象和使用，可以快速交付給使用者使用。當然這個也有別的問題。
但通過上述的乙個組合方式，且你可以理解這個是多層第的方式滿足業務部門管理的需求，可能取長補短的額方式來完成企業，部門的戰略達成。
**的重構，是為了適應企業業務新的模型，和原來**架構的補足為了滿足業務的更大的容量。
企業和部門組織架構的重構（這裡我希望用重構這個詞）是為了讓企業的內部流程滿足外部的需求。
豐富的行業背景知道哪些是真需求，哪些可以變通，哪些需要真的調整系統的實現滿足。
系統的結構3-5年的調整可能是乙個好的方式，不要指望系統這個模型一直用下去，這個並非是乙個好事情。
動態的調整，合理的成本，且思考這種動態變化反應的外部世界變化的方向，應該是公司，業務部門，需求管理人員深入思考的。
當我們在談進製的時候，我們在談什麼
關於進製，前幾天一朋友詢問二進位制和十六進製制的區別。遂在此總結一下關於進製的相關知識，回憶一下計算機的基礎內容，也幫朋友更好的理解一下。進製是一種記數方式，亦稱進製計數法或位值計數法。利用這種記數法，可以使用有限種數字符號來表示所有的數值。一種進製中可以使用的數字符號的數目稱為這種進製的基數或底數...
當我們學OC的時候，我們在學什麼
實現部分 成員變數 屬性 init，self，super 擴充套件 件 import 引入標頭檔案，與c語言類似 ns assume nonnull begin ns assume nonnull beginns assume nonnull end。在這兩個巨集之間的 所有簡單指標物件都被假定為n...
Linux容器 當我們談容器的時候,我們在談什麼
docker在當下很火,那麼,當我們談docker,談容器的時候,我們在談什麼?或者說,你對docker,對容器了解嗎?容器,到底是怎麼一回事兒?這篇文章著重來講一下linux容器,為什麼強調linux容器,而不是docker,是因為docker是基於虛擬化技術來實現的,但是這篇文章涉及到linux...