觀點丨一口吃不成胖子，對待產品你應該要這麼做

一款優秀的產品，從開發到上線，都離不開嚴謹的項目分工和配合。

全文共1287字，消化約7分鐘。

相信沒人能反駁這個理論，不然做出來的只是一堆垃圾，這樣既錯過了一個切入市場的絕佳時機，也損失了好幾百萬的金錢成本。管理是門學問，尤其軟體開發的項目管理，涉及到多個工種的協作配合，產品經理、UI/UE設計師、架構師、前端開發、後端開發、測試、運維。可以說每個工種各司其職，產出的成果資料也要環環相扣，這樣才能體現產品優勢，並突出亮點。

但就算這樣，仍然會出現問題。人有惰性，做得越多，可能越喜歡投機取巧，從而發生偷工減料的問題，前邊出問題，後邊就會出事故。大部分委託方對這些東西不甚了解，項目團隊不在跟前，做事方式搞不清楚，全程不可控的狀態，客戶心裡沒底。

那麼如何能避免沉重的代價呢？

答案：一套項目流程+一個靠譜的項目經理。

正規的軟體項目外包流程大致分為以下7步：

· 收集用戶需求，製作功能列表，達成功能共識

· 項目立項

· 原型設計，交互設計，UI設計

· 技術方案設計

· 技術研發

· 技術測試

· 項目完成，項目交付

雙方達成共識的功能列表，有兩個很重要的作用。第一，基本圈定了需求的範圍，對要做的產品有了更明確的描述；第二，因為需求清晰，就可以評估需要投入多少研發生產資源，有多少風險及如何應對等。當然，客戶最關心的報價也會更加精準。如果此時雙方達成一致，簽訂合同，就可以啟動項目，組隊開幹了。

項目啟動後，各家公司因為人員配置的級別，項目管理的經驗，過往項目的技術沉澱都不盡相同，會產生項目在運作中的諸多區別，例如。

在PRD文檔輸出過程中：

?A：就做主流程，反正驗收時不會被發現。

B：先出主流程圖和描述，再把分支流程，異常處理情況寫清楚，和客戶郵件反饋一下。

在UI設計中：

A：讓用戶確認一下主色調，剩下你別管了，沒問題的。

B：讓用戶確認一下主色調，出3版設計稿，給客戶發郵件，讓客戶選出滿意的一版。

在技術方案設定中：

A：類似的都寫過，先寫吧，有問題再調。

B：一定要出代碼方案設計，項目組和供應商團隊進行二次評審，

在技術研發中：

A：今天心情不好，少干點吧，長城又不是一天建成的。

B：核定的任務量，項目經理把控著，每周的工作進度，要給客戶發郵件反饋，保證工期；項目實施中，走一遍單元測試，看看每個環節是否有問題。

在項目測試中：

A：公司所有人，沒事的都來點一下這個軟體，遇到bug說一聲就好。

B：開發過程中，開發人員已經做了單元測試與冒煙測試，當下正常用測試用例（測試還包括功能測試、性能測試、壓力測試等等）。

在項目交付中：

A：把域名，伺服器賬號密碼給我，我幫你配置好。

B：這是PRD文檔、UI原圖、源碼、測試用例和其它相關交付物，協助客戶上線程序後，仍會有一年的售後服務。

以上只是簡單舉了兩個不同外包團隊在服務客戶過程中的常見狀況，很多細節問題往往是客戶從來沒聽說過的。

舉幾個實際的例子，例如官網開發，大多數客戶只看得到這個網站有什麼內容，以及長什麼樣子。而專業的外包團隊會看到諸如這樣的問題：網站需不需要做手機端適配呢？適配多少個機型？要知道，PC端UI和移動端UI是兩版；再例如移動端app，大家都知道，iOS怕審核Android渠道多，各種形式的應用商店，發包工作不勝其煩。但是這些東西，只有做過的人才知道。

看起來這好像是一篇介紹項目管理的文章，實際上，我們是想告訴你，軟體開發的品質來源於對細節的把控，這需要的不僅僅是技術，更是一場耐心的考驗。

對軟體開發來說，有時候，用60分的努力，如果運氣好的話，可以產出一個80分的產品，但是對於嚴格進行項目把控的外包團隊來說，用80分的努力，不依靠運氣就能保證每個項目的底線都在60分以上。

如有問題，歡迎在官方微信公眾號留言，微信公眾號搜索「外包大師」點擊關注即可。

http://www.waibaodashi.com/?from=dashi_gh (二維碼自動識別)