1. 一般如何制定給產品新人的培訓計劃
硬技能的概念
硬技能是相對於軟技能而言的。
軟技能是指不以人的工作內容和工作性質為轉移的基本技能，由一系列個人要素的特質組成，軟技能包括的內容很廣，比如社交技能、語言能力、個人品質等等，是內在的、無法量化的。上一期，根據群友意見，並結合產品新人的特徵，著重從知識管理、時間管理和情緒管理三個方面講述如何培養軟技能。
硬技能是指與個人工作內容深度相關的專業知識和專業技能，硬技能包括專業知識、成果輸出、智力水平等，是可見的、可量化的、可客觀比較的。軟技能類似 「情商」，側重於「做人」，而硬技能類似「智商」，側重於「做事」。
本期討論，從產品經理工作中使用最多的工具出發，按照從需求到方案的過程，講述不同階段的工作技能的培養，主要包括工具的使用、成果的輸出以及注意事項等。
需要特別說明的，本期討論先拋出一個面試題目，作為本次討論的案例分析，以達到理論結合實踐，增強理解。該面試題如下：小明面試一家購物社區網站（類似於蘑菇街），在面試中，要求小明給出一套簡潔又清晰的用戶登錄產品設計方案，如果你是小明，你會怎麼做？
需求管理
一般產品的萌芽都來自於需求，有了需求，才會考慮如何滿足需求，才會考慮設計什麼產品提供什麼功能以滿足這些需求，因此需求是產品的起源。（當然現實工作中，有很多產品都不是來自對需求的分析，而是某些人的一句話，姑且認為這也是他們的需求）
1. 需求管理的概念
需求管理，從狹義上來說，是指需求內容管理，主要是進行需求的條目化管理、需求跟蹤等活動；從廣義上來說，是指需求過程管理，需求過程管理就是推動需求的分析篩選以及開發和上線，遍歷整個需求流程。
需求管理是一個復雜且長期的過程，以需求收集、分析、篩選等工作為核心，解決「有什麼」、「做什麼」、「做哪些」的問題。
「有什麼」需求，意味著需求的收集要全面徹底，包括來自用戶的使用反饋、部門成員的開發運營需求、領導的需求等。
「做什麼」需求，意味著需求的分析要公平透徹，每一種需求力求反饋其真實的想法和訴求。
「做多少」需求，意味著需求的篩選要明確堅決，每一種需求做與不做一目瞭然，堅定不隨意變動，且保證需求均是重要的核心需求。
2. 需求管理工具
需求管理，需要針對不同來源的需求，進行統一管理、分析、跟蹤，單純的靠紙筆或大腦遠遠不夠，需要專門的工具，那麼有哪些工具可以用於需求管理呢？
1) Excel
標准化的辦公軟體，操作簡單，易維護，數據處理方便，共享性好。
列出需求的管理維度，比如需求的來源、描述等，同時附上需求的解決進度控制，如需求的解決方案、負責人、進度、時間等。
2) 腦圖（如MindManager）
形象化的操作，便於同類需求的合並，管理維度不宜太多。
用MM列出所有的需求功能點，然後進行需求的合並整理，確定需求功能點後，用Visio畫出主流程。
3) Google Docs
可協作編輯與網上共享，版本管理，實時在線查看，支持導出與上傳。
在線創建表格文檔或上傳，實時更新並同步，共享給相關人員，使用方法類似Excel。
4) 文檔
需求的列舉管理，簡單方便，適用於數量小、變更少的情況。
具體的需求用文檔詳細寫出來，關鍵的點提取成Story，用Excel管理起來，進行需求的評審討論。
需求管理工具還有很多，目的只有一個，對需求進行全面的管理。工具是次要的，只要使用順手即可，關鍵在於如何分析需求。
3. 需求管理分析
統計與分析需求時，一般考慮哪些維度呢？
1) 來源
需求主要來源於用戶，用戶的反饋建議、問題投訴等，可以通過與用戶溝通、反饋意見平台、微博搜索等渠道獲得用戶的反饋，然後提取成用戶需求。
需求的來源還有市場、運營、開發和領導等，這些需求都來自於公司內部。
2) 需求描述
對需求的詳細描述，遇到什麼問題，想要達到什麼效果等。
3) 隸屬模塊
劃分需求所屬的功能模塊，以便對需求進行模塊化管理，具體模塊內部具體分析，比如登錄/注冊模塊，分享模塊，購物流程模塊等。
4) 處理方案
針對此需求，有什麼可能的處理方案，是增加功能，還是改進流程等
5) 優先順序
對需求的評估，此需求是否緊急需求，優先順序是高是低，意味著何時去解決需求，一般先解決優先順序高的需求。
6) 處理進度
目前此需求是還在討論中，還是已經確定方案，是正在開發，還是已經上線。每一個需求的優先順序無論高低，都需要有一個進度跟蹤，以便做好需求的整體管理。
7) 其他維度
還有其他維度，比如需求採集時間、部門、負責人等，視具體工作而定。
4. 需求管理的案例分析
拿上面說的面試題來分析，需求的一部分來自用戶反饋，比如用戶說，這個登錄太麻煩了，我不想注冊，能不能給我接入微博賬號登錄，於是你收獲一條用戶需求：接入微博等第三方賬號登錄。此需求來源於用戶，隸屬於登錄/注冊模塊，可以通過調用微博等第三方賬號API完成，優先順序中等。接下來就是具體的需求解決了。
1) 登錄的設計
具體要設計登錄功能，首先，列出大的分類，也可以叫做提綱，登錄的功能分析（Why）、登錄的方式（Where）、登錄的流程（What），然後按照每個分類進行思維導圖細化。
登錄的功能分析，此登錄功能根據用戶可以分為兩部分，已有賬號的用戶登錄和沒有賬號的用戶登錄，提供哪些功能讓他們登錄呢，比如提供注冊功能和直接登錄功能等。
登錄的方式分析，直接登錄還是接入第三方賬號登錄，用戶登錄與管理員登錄入口是否一致等。
登錄的流程，什麼時候提供登錄，登錄出錯怎麼辦，驗證和授權的流程等。
2) 需求優先順序的評定
需求優先順序的評定一般在需求評審時確定，確定需求點後，需求評審時，技術、運營等會給出專業的評估，比如實現時間等，砍掉部分需求後，留下來就是需要接下來解決的。
如之前的面試題，蘑菇街的登錄功能的需求處理流程應該是，收集所有的需求->需求評審->確定優先順序排序->提出處理方案->跟進處理進度。
需求管理的工具其實不重要，重要的是收集需求的廣度、需求優先順序評定、需求的處理方案以及推動需求的解決。
你是否通過各個渠道收集到了需求（領導的、用戶的、部門內部的）；你是否分析的清楚哪個需求應該立馬解決，哪個需求可以往後放，哪個需求是虛假需求；需求的具體處理方案是什麼？需求的解決進度管理（類似項目管理）等。
思維導圖
分析清楚需求後，滿足哪些需求就確定了，梳理這些需求，提供哪些功能就需要詳細梳理，於是，通常情況下，就會使用思維導圖，細化需求的滿足。
1. 思維導圖的概念
你所理解的思維導圖是什麼？ 思維導圖可以用來做什麼呢？
先來群友們的想法，思維導圖是用來分塊管理細化思想的；MM是功能點的初步梳理；思維導圖管理的是發散思維，也是為自己梳理需求，功能的約束；是理清自己想法的一種工具。它可以用來理清需求，知道需求怎麼做，怎麼實現；可以用來管理需求，讓需求和流程清晰化；引導思維，梳理需求，進行形式擴散式的梳理。
讓我們來做個拆詞游戲，「思」是想法，你所要實現的效果和目的，「維」是維度，從哪些維度入手，「導」是疏導，是邏輯的貫通與引導，也是導出，「圖」是圖形，以圖形的形式呈現出來。因此，思維導圖可以理解為以圖形化的形式從多個維度展現你所要實現的想法。
2. 思維導圖的工具
理解了思維導圖的概念，那麼我們一般使用什麼工具來繪制思維導圖呢？
繪制思維導圖的工具有很多，比如Mindmanager、mindmapper、FreeMind等，其中使用人數最多的當屬Mindmanager，也是產品經理中使用最普遍的工具。
你就把MM這個軟體，當做一個隨便的玩意就行了。將自己的所有想到的都扔進去，開始寫。寫完了就開始分組，把類似的或者近似的放一起。然後最終的時候就出現了一個思維導圖。一般主要是在會議上快速整理匯總。你就當做是一堆貼紙，每張寫一句話，然後開始到處貼，貼完了開始整理，整理完了，然後開始插在不同的板子上，然後開始連線。
總結來看就是，窮盡寫想法->對想法分組合並->各分組關系判斷排序->根據隸屬和層次關系繪圖。寫想法和分組的過程要遵循MECE原則，即「完全窮盡、相互獨立「原則，各分組之間互不重疊，且所有可能的分組都已列舉出來了。
最方便的思維導圖工具，應該是紙筆了，在紙上按照上面的流程梳理，可塗可改，相當於紙上版的Mindmanager。
3. 思維導圖的案例分析
還是回到蘑菇街的登錄上來，蘑菇街登錄的思維導圖要如何來畫？一個登錄功能，你需要考慮的維度有哪些？
其中一種考慮維度是這樣的：
1)用戶角色（用戶、商戶）；
2)登錄環境（是否注冊，即有無帳號和是否初次登錄）；
3)附加條件（是否需要驗證，如驗證碼，手機簡訊等）；
4)界面設計（首頁登錄還是單獨設計登錄頁面，以及提示信息）；
以上從功能模塊的角度出發，設計一個登錄功能。
另有一種處理角度是這樣的，它從用戶的角度出發，針對不同類型的用戶進行具體的分析。
兩者分析問題的角度不同，但都可以滿足「需求的解決」。登錄這個功能比較小，但是其中要考慮的問題挺多，簡單說幾個，比如輸入模式（中英文輸入狀態）、驗證碼的使用策略、輸入反饋機制等，還有很多很多需要考慮的。產品重在思維，越細越好，無限細化 就越接近完美。
分析問題的角度決定了你的圖形形狀，但是最終目的是需求的解決和功能的實現，理論上，每一個角度都不是錯的。但一定存在一個最優的角度，最簡單明了的分析清楚問題，解決需求和實現功能。
流程圖
思維導圖讓我們理順了如何去滿足需求，應該有哪些功能，但是這些功能點，還只是孤立的點而已，要把他們串起來，應用到具體的用戶使用中，才最好，研究用戶的操作流程，就顯得很有必要。
1. 流程圖的概念
如何理解流程圖呢？如何建立流程圖呢？
還是先來看看群友的理解吧，流程圖就是控制器，是模擬用戶流程的邏輯關系；是指從開始到結束所有的環節之間的邏輯和順序；需求是點，思維導圖將點集結成塊，流程圖把塊連成線；我們應該根據用戶角色的操作過程來建流程圖，包括後台的動作。流程圖就是把每個功能點上操作流程表述清楚，包括前台和後台的連接性，以及用戶和網站的關聯性。比如：用戶登錄時在輸入用戶名的時候就要先判斷是否注冊用戶
流程圖是利用特定的圖形符號和說明，模擬用戶實際操作的場景，建立的圖形，它揭示了整個流程中的邏輯關系嗎，真正的講產品功能串聯了起來。
2. 流程圖的工具
流程圖的工具，一般使用Visio來繪制，Axure也可以。
無論使用什麼工具，都需要遵守流程圖的繪制規范。比如，圓角矩形表示「開始」和「結束」，矩形表示行動方案，菱形表示問題判斷或判定環節，平行四邊形表示輸入/輸出，箭頭表示工作流方向。
流程圖的繪制需要注意的是：
1) 繪制之前，要清楚流程的起始狀態，從何時開始，到何時結束
2) 先把主流程走通，然後在此基礎上，不斷完善附加信息和狀態判斷
3) 一個節點只做一件事，一個節點完結了，再考慮下一節點
4) 流程不能斷掉，所有流程最好形成閉環
5) 所有條件要考慮到，邏輯要嚴謹，考慮各種異常情況的輸出
3. 流程圖的案例分析
如之前的面試題，就拿密碼輸入錯誤這種情況來說，其他暫不考慮。該如何去繪制流程圖呢？
密碼輸入錯誤的流程可以分為三個子流程：
1)訪問-某節點選擇登陸-進入登陸頁-輸入各項-判斷-通過-跳回之前頁面
2)訪問-某節點登陸-進入登陸頁-輸入各項-不通過-用戶名不存在-提示注冊新會員 或者 找回用戶名-跳至郵箱-激活成功-跳回原頁面
3)訪問-某節點登陸-進入登陸頁-輸入各項-不通過-密碼不正確-找回密碼-郵箱激活-重新登陸-跳回原頁面
密碼判斷通過作為主流程，是首先需要想清楚的，在此基礎上，在想密碼判斷出錯的情況，密碼判斷不通過時，提示用戶不存在或密碼錯誤，提供用戶注冊和密碼找回的解決方案。
原型圖
了解了需要實現的功能點，並通過再現用戶使用流程，將功能串起來了，接下來就是通過原型把這些展現出來,因此，產品原型的呈現就是接下來要做的事兒了。
1. 原型圖的概念
如何理解原型圖呢？
還是先來看看群友的想法吧，產品原型可以粗略的描述出網站頁面的構想；原型是界面交互的初稿；產品原型作為產品的素描圖，包含了所有的功能點和邏輯跳轉；產品原型可以理解為產品的一個框架設計。
原型是在梳理清楚產品的主要功能和操作流程後，將產品功能和流程從想法階段到輸出階段的過程，產品原型描述了產品的功能構想和交互邏輯，是產品的低保真形態的呈現。
2. 原型圖的工具
繪制原型圖的工具也有很多，比如Axure，是產品經理使用最普遍的原型設計工具，類似的還有Balsamiq Mockups，騰訊UDC專門開發了UIDesigner，用於iso平台上APP的原型設計。
如果是輕量級的設計，Mockups就夠了。但如果要做一個產品高保真的交互原型，Axure RP應該是產品經理或交互設計師的首選。
原型的類型可以分為三種：圖紙（在紙上畫）、點陣圖（繪圖工具）和可執行文件（互動式），需要包括兩部分內容：線框圖和交互。
原型設計時，需要注意的是：
1) 原型設計前的准備工作至關重要，考慮清楚畫什麼，比用什麼畫和怎麼畫更重要
2) 原型設計中對細節要全面把握，不能有所遺漏，比如將常態、非常態、空態分別表現出來給設計和開發
3) 思想表達清楚，要有必要的文字說明
4) 所有模塊或頁面的關系明確，哪些模塊強化，哪些模塊弱化，分清主次
5) 原型設計的流程一般是先畫草圖，然後用模擬做交互細節
6) 原型設計的工具，PPT、Axure都只是工具而已，重點是呈現你的想法，讓別人明白你的想法
3. 原型圖的案例分析
還是從之前的面試題說起，具體的原型線框圖就不詳細說了，這里只考慮密碼錯誤的情況，應該在交互邏輯上考慮清楚呢？
1） 錯誤提示方式：如何提示用戶密碼錯誤，是文字提示，還是彈層提示，提示文案如何設計，文案的顏色、位置是怎樣的
2） 找回密碼的入口：當用戶密碼輸入錯誤時，是否提供找回密碼，在什麼位置提供入口，如何提示用戶找回密碼
3） 找回密碼的策略：是用郵箱，還是手機，還是密保問題，找回後，如何回到原頁面等
原型設計是產品的原始呈現，需要明白要什麼和不要什麼，真正明白產品設計是做減法，功能越精越好，而不是越多越好。
畫原型，可以用軟體，也可以用紙筆，紙筆比較簡單，就按照你的想法，以什麼形式展現，就畫出來，比如登錄框的設計，兩個輸入框，一個按鈕，看起來很簡單，但是背後的邏輯很多。
產品文檔
產品文檔是產品方案的具體輸出形式，原型圖是產品方案的圖形化呈現，產品文檔則主要說清楚產品方案的邏輯規則和交互細節。
產品文檔主要包括三種：PRD、BRD和MRD，即所謂的產品需求文檔、商業需求文檔和市場需求文檔。產品新人一般能接觸到的就是PRD文檔了。
1. PRD文檔
PRD文檔，是產品項目由「概念化」階段進入到「圖紙化」階段的主要文檔，文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。
PRD文檔結構一般包括6個部分：文檔的版本管理，功能概述，流程圖，核心功能模塊，各功能模塊的細化說明，總結與建議等。針對具體業務，還會有些微的不同，關鍵在於說清楚核心功能邏輯和流程。
版本管理：文檔的每一次修改都需要更新記錄，以便更好的核對管理
功能描述：是產品功能的整體描述，簡要概括
流程圖：產品流程圖，就是前面講到的流程圖
核心功能邏輯：是產品功能的核心邏輯，不可隨便改變
各功能模塊說明：詳細講述各個功能模塊的流程和交互
總結與建議：產品功能設計的總結和建議等
2. BRD文檔和MRD文檔
一般產品新人很少接觸到BRD文檔和MRD文檔，因此，這里只是簡單說下。
MRD文檔是產品項目由「准備」階段進入「實施階段」的文檔。在你的產品獲得老闆支持後，產品進入實施階段，需要寫MRD，需要有細致的市場分析和競爭對手分析，包括可通過哪些功能來實現商業目的，功能需求和非功能需求分哪幾塊，功能的優先順序等。
BRD文檔是基於商業目標或價值所描述的產品需求內容文檔，內容涉及市場分析、銷售策略、盈利預測等，通常用於產品在投入研發前，給領導作為決策評估的重要依據，主要是為了獲得認可，爭取資源。
本期我們討論了產品經理工作中用到的工具，通過從需求到產品方案的形式，在不同階段介紹工具的使用。其實用什麼工具是其次的，只要能表達清楚自己的想法，重點還在思維，你是否想清楚了，細化徹底了。
2. 如何寫網路產品的安裝，調試，驗收與培訓內容
合同應對設備的安裝調試和考核驗收的具體內容、方法和要求、依據的技術標准、時間和地點等問題做出明確規定，一般應在商務條款中列明原則，同時單列附件詳細說明。這部分內容是買方達到合同目的的關鍵步驟，因此買方一般對此條款比較重視，經常會盡最大可能、在最大范圍內要求賣方承擔責任和義務。賣方對買方的合理要求，只要技術水平能夠達到，可以考慮盡量滿足買方的要求，以示簽訂合同和認真執行合同的誠意，但同時一定要注意作好有關的風險防範，將賣方無法控制的和賣方責任之外的風險明確排除在外。
一、現場准備
現場准備是設備安裝調試等一系列工作的前提，也經常是引起項目拖期的主要原因，對此，合同應明確約定現場准備工作的內容、要求、指標及完成的期限，買方應按照合同及賣方提出的標准作好現場准備工作並進行全部土建、公用工程及環境等方面的保障工作；對於買方未能按期或按合同規定的要求完成現場准備工作所造成的遲延、損失及其他後果，賣方不承擔責任，並且買方還要支付因此給賣方帶來的損失和費用。
二、現場代表
在進入設備安裝調試階段之前，買賣雙方應各自指定一名現場代表負責全權處理合同現場執行合同過程中的問題，包括技術問題的協商、雙方爭議的解決、具體事務處理、以及各種現場記錄、人/日工作量表和驗收證書的簽署。
三、技術人員的資格
在成套設備出口合同中，設備的安裝、調試、考核工作由買方負責執行，賣方技術人員只負責進行技術指導，因此買方技術人員的技術素質和語言素質直接關繫到項目能否順利進行；為防止發生有關問題，賣方應要求買方派有經驗、技術水平高、語言能力強的技術人員到場配合，如因買方技術人員配合問題造成項目延期或其他損失，賣方不承擔責任，例如額外消耗的原材料費用、買方技術人員操作失誤造成的設備毀損等，甚至可以要求買方對因此給賣方造成的損失負責賠償，如賣方技術人員因工程延期產生的額外費用等等。
四、設備安裝調試程序及期限
為控制項目進程，合同中一般規定貨物到達現場後一定時間內應開始設備的安裝，即將全部設備就位、裝配、使之具備運轉的條件，安裝完畢後一定時間內應開始試車，即進行單機及設備系統的單獨和聯動空載運轉，空載運轉完成後，即應在一定時間內進行投料試生產。經過一定期限的試運行達到一定的條件後則進入考核驗收階段，驗收成功後，由雙方現場代表或授權代表簽署驗收證書，確認賣方已全部完成合同項下除保修責任以外的所有義務。以上各個階段可以根據項目具體情況規定考核驗收的次數及具體操作的方式，並應明確考核過程中出現失敗的原因和責任及其處理辦法。
在整個設備安裝調試過程中，買方技術人員應詳細研究和掌握安裝和試車的方法、技術要求和注意事項，賣方技術人員給予指導。如果其中涉及賣方的專有技術或其他秘密信息，雙方應按合同中有關保密的規定執行。賣方指導意見的執行及合同設備的安裝工作由買方負責，並且買方有義務將可能影響安裝或安裝指導工作的任何情形及時通知賣方。
在設備安裝調試過程中，雙方現場代表應共同簽署日誌，記錄具體的操作過程、遇到的問題、每一步驟開始的時間和狀態及完成的情況和時間等，雙方之間一旦發生糾紛，日誌將成為記錄合同實際執行情況的重要文件，並且作為分清雙方責任的書面依據。
設備安裝調試過程中各個階段的開始時間和完成期限，對於買方來說直接影響整個項目工期，對於賣方來講也影響其技術服務的責任期限及人員安排等一系列整體規劃問題。因此通常情況下，買賣雙方均願意在合同條款或附件中明確做出有關規定，但期限的約定也給雙方增加了一定程度的違約風險，對此只能根據具體情況確定。但一般情況下，對各個階段的期限約定均應留有一定的餘地，至少應考慮因失敗而重復進行工作的可能性。
五、考核驗收標准
這一問題在前面的檢驗標准中已有所涉及，在此還應進一步明確。考核驗收標准可以有兩種涵義，一是設備本身的性能考核，即通過對單機和設備系統進行單機聯動試車，以及投料試生產考核設備本身的各項性能指標是否能夠達到要求，如設備的能耗、產量等；另一種涵義是合同產品的考核，即通過投料試生產出合同產品，對產品的性能指標進行考核驗收。這後一種考核方式由於很可能摻入很多賣方所不能控制的因素影響考核的結果，對賣方具有較大的風險。賣方如果考慮接受買方對合同產品進行考核的要求，應注意以下兩個方面的問題：
1、對買方提供的各種生產條件、配套設施、原材料、操作人員及其他可能影響合同產品性能的各種因素進行嚴格的限定。
2、賣方提供的技術保證范圍是否包括能夠生產出合格的合同產品，還是只提供實驗室技術或供繼續研究開發的階段性或基礎性技術。
對於具體的性能指標，一方面可以按前面檢驗標准中提到的將本企業或本國標准適當降低作為合同中的驗收標准，以便留有餘地，確保按照約定的技術質量要求生產出合格產品；另一方面也可以在合同中規定驗收的一般標准和最低標准，即超過最低標准即視為考核成功，但賣方可以考慮在考核成功後繼續協助買方盡量改善設備性能，以便達到進一步滿意的狀態，費用由買方承擔。
六、考核驗收時間
合同中應規定考核驗收的時間期限，但考慮到考核驗收時間的拖延可能是由買方的現場准備工作不足等原因引起的，為盡量減少風險，賣方應堅持在合同中做出自動驗收的規定：
1、由於非賣方原因，考核驗收工作遲至最後一批交貨後X個月內仍不能進行，則應視為已通過驗收，由雙方代表簽署驗收證書；
2、由於非賣方原因，最後一批交貨之日起若干個月，性能考核仍不合格，即視為自動驗收，由雙方代表簽署驗收證書。
七、雙方責任劃分
在設備安裝調試尤其是考核驗收過程中，如果發生問題或考核不合格，雙方應分析原因，共商研究對策，找出解決辦法，然後重新進行考核。全部考核的費用，例如有關的修理費、更換費、運保費、原材料費用、人工費用、賣方的技術服務費等，由責任方承擔或按責任比例的大小由雙方各自承擔。合同中應根據具體項目情況規定允許重復進行考核的次數，
如因買方原因，例如水電氣供應不符合合同約定、配套設施不完備、買方技術人員失誤等，造成考核性能指標在規定的期間內不能達到合同規定的標准，應視為通過驗收，由買方簽署驗收證書。在買方簽署驗收證書後，應買方要求，賣方可以考慮在買方承擔所有相關費用的前提下協助買方對設備進行進一步調試。
如果在考核中性能指標未能達到合同要求完全是由於賣方原因造成的，賣方可選擇下述方式之一承擔責任：
1、自負費用繼續調試，直到考核合格為止；
2、按合同中規定的比例和方式承擔違約金，但合同中還必須明確規定，在賣方支付違約金後，即視為驗收合格，雙方簽署驗收證書，賣方在合同項下除保修義務之外的所有義務已全部履行完畢。