⒈POC的概念 POC，是Proof of Concept的縮寫，意思是為觀點提供證據，它是一套建議的電子模型，它可用於論證團隊和客戶的設計，允許評估和確認概念設計方案，POC的評價可能引起規格和設計的調整。POC流程所產生的關於設計的承諾、大家都認可的意見都將記錄在設計的調整文件中，以備查。這樣下去，POC不斷髮展。如果在完成這些任務時需要幫助，可以在Queensland大學找到協助資源。

⒉POC的開發 POC的開發步驟及方法如下：第一步，開發包含所有基本導航特徵（按紐，圖示、選單等）的介面模型，但不是最終的完美形式。第二步，給介面新增少量內容，尤其是在至關重要的媒體中新增一到兩個樣本。例如，如果套裝軟體包非常依賴3D模型，就應該新增一個包含驅動所必須的3D模型樣本。如果軟體包需要顯示資料符號和表格，那麼有關資料符號和表格的樣本也應新增上。

請注意，這個過程應該用於支援論證和驗證設計，而並不是軟體包開發的實際開端。你應該盡力去論證和銷售設計，但也不要太過分，因為設計過程中有時需要作重大的修改，這樣將導致浪費大量的資源。

⒊POC的評價和驗證 評價和驗證過程就是尋求風險承擔者透過POC和備案設計文件的反饋。透過POC評價，風險承擔者可能提出調整規格和設計的要求。有時，由於設計存在的缺陷或不適當的地方，設計團隊就可能只好回到繪圖板。客戶可能決定停止設計或尋找其他團隊，這是因為設計沒有足夠地關注客戶和使用者的需求，或者是因為客戶需求的不穩定性。

有時這種改變是由客戶組織或者專案決策者所引起的。通常，在評價和驗證過程結束時，有關設計的承諾、大家都認可的意見都將記錄在備案的設計文件中，這往往是產品開發的生命週期中一個重要的里程碑。在結束評價和驗證之後，POC就可繼續發展。

⒋最小化的需求 儘管POC是產品開發過程中重要的評估技術，但是你也應該限制在POC開發方面所花費的時間，考慮到早先的設計階段包含的所有因素，構建POC中關鍵元素。應該把充足的精力用於論證和認同設計方面，但也不要過多，這樣即使設計中需要作重大的修改，也不會導致浪費大量的資源。在全面設計開始執行之前，讓客戶對設計認可是必要的。

⒌客戶的角色定位 規格和設計階段，要求產品開發有詳細的設計文件，而且POC常伴隨著產品開發。客戶簽署設計文件中，並反饋POC是重要的專案里程碑。如果在下一階段仍需修改產品設計，就要按照受控的變更控制流程得到認可和批准。

在整個專案過程中處理不同的檢查和停頓時，客戶的一個重要職責是為按期交付而保證已確認的進度表，並同意為防止計劃被耽擱而需再投資的情況出現。

POC 是一種利用本地計算機硬碟驅動器裡的閒置空間來進行挖礦的共識演算法。可以這樣形容：相比POW 不停改變區塊頭的某個數字來猜測正確的雜湊值，POC 把你猜數字的工作量變成了硬碟空間裡的“測繪”（plotting）的工作量。

這POC模式下，每個區塊都會繫結一個專屬的“謎題”，在挖礦還沒開始前，網路就會把破解這個謎題的計算方法（solutions）儲存在你的硬碟空間裡。這些計算方法有的比較快，有的比較慢，如果你的硬盤裡恰好有一個計算方法，是目前最近產生的這個區塊裡的謎題所對應的“最快解”，那麼你就贏得了這個區塊的記賬權——挖礦的獎勵就是你的了。