在創(chuàng)業(yè)公司，做一個(gè)APP（MVP）需要經(jīng)歷的流程來看PM在整個(gè)項(xiàng)目中的角色
需求調(diào)研——原型設(shè)計(jì)——UI設(shè)計(jì)——技術(shù)開發(fā)——測試迭代——提交應(yīng)用市場
一、需求調(diào)研
在創(chuàng)業(yè)公司，一般是創(chuàng)始人會(huì)把控確定業(yè)務(wù)方向，PM負(fù)責(zé)相關(guān)需求的搜集、競品分析、數(shù)據(jù)分析、用戶訪談等工作。通過這些信息，來驗(yàn)證業(yè)務(wù)方向是否可行。
二、原型設(shè)計(jì)
PM在完成需求調(diào)研后，就開始進(jìn)行產(chǎn)品原型設(shè)計(jì)工作了，這個(gè)階段，需要PM產(chǎn)出產(chǎn)品原型設(shè)計(jì)，與產(chǎn)品團(tuán)隊(duì)、創(chuàng)始人、設(shè)計(jì)師、技術(shù)負(fù)責(zé)人進(jìn)行原型評(píng)估、修改工作，使大家的意見達(dá)成一致。之所以拉上技術(shù)負(fù)責(zé)人，是確保我們設(shè)計(jì)出來的產(chǎn)品在技術(shù)上是可行的（不要等到開發(fā)的時(shí)候，技術(shù)同事告訴你，這個(gè)不好實(shí)現(xiàn)，那就傻X了），以及評(píng)估出開發(fā)的工作周期大概在一個(gè)什么范圍。
對于一個(gè)MVP（最小化可行產(chǎn)品），PM一定要很好的控制功能的優(yōu)先級(jí)，即第一個(gè)版本，只做核心功能，只需要滿足用戶的核心需求就可以了。
原型設(shè)計(jì)，我們一般會(huì)進(jìn)行2-3次評(píng)估，最終確認(rèn)原型圖，強(qiáng)烈建議通過工具來產(chǎn)出高保真原型。
三、UI設(shè)計(jì)
在產(chǎn)品原型確定以后，就進(jìn)入U(xiǎn)I設(shè)計(jì)階段了。在設(shè)計(jì)師開始設(shè)計(jì)之前，PM一定要向設(shè)計(jì)師傳達(dá)整個(gè)產(chǎn)品想要表達(dá)的東西、使用對象、使用場景等元素，確保設(shè)計(jì)出來的視覺圖與產(chǎn)品所想要傳達(dá)給用戶的東西一致。（如果可以，設(shè)計(jì)師最好是在原型設(shè)計(jì)的時(shí)候就參與進(jìn)來，這樣可以更好的理解產(chǎn)品）
設(shè)計(jì)圖我們會(huì)進(jìn)行2-3次的評(píng)估，確認(rèn)最終的設(shè)計(jì)稿。整個(gè)周期一般控制在1.5周/人左右。
四、技術(shù)開發(fā)
1.需求講解
UI設(shè)計(jì)圖確認(rèn)以后，第一步就是給研發(fā)的小伙伴講解需求了。
1）會(huì)前準(zhǔn)備：在需求會(huì)議之前，最好是把原型設(shè)計(jì)和UI設(shè)計(jì)圖發(fā)給所有參與項(xiàng)目的成員。讓他們提前了解會(huì)議APP的所有功能和設(shè)計(jì)，這樣，如果大家有疑問的話，可以提前記錄下來，在會(huì)議期間提出來。
## 在講解需求的過程中，大部分同事的注意力是不集中的，就算有問題，可能也一時(shí)發(fā)現(xiàn)不了，這樣就自然而然就遺留到開發(fā)過程中了...。問題雖然不可避免，但可以控制數(shù)量，早發(fā)現(xiàn)的成本肯定小于晚發(fā)現(xiàn)的成本。
2）需求講解：首先需要讓大家了解到我們?yōu)槭裁匆鲞@個(gè)APP，它的價(jià)值是什么。其次，再給大家詳細(xì)的講解功能，有需要特別注意的地方，比如說你想做一個(gè)比較特殊的交互、文本自動(dòng)填充等等，講到這些時(shí)，重點(diǎn)強(qiáng)調(diào)一下。最后，看看大家有沒有什么問題。
##總的來說，這是一個(gè)比較枯燥的過程?？刂坪脮?huì)議的節(jié)奏、時(shí)間、以及講解方式就變得尤為重要了，如何能讓大家不覺得無聊，而且了解需求，這就要看你如何來主導(dǎo)這場會(huì)議啦~
3）周期評(píng)估：需求講解完后，拉上各位開發(fā)負(fù)責(zé)人（iOS、Android、服務(wù)端、CMS），評(píng)估開發(fā)周期。
##一定一定要評(píng)估，這樣，讓大家在心里達(dá)成一致的時(shí)間概念，更合理的安排每天的工作量。
2.開發(fā)過程
在這個(gè)過程中，PM可不要以為就沒啥自己的事情了。在這個(gè)過程中，你依然是整個(gè)產(chǎn)品的主導(dǎo)。開發(fā)前期，建議你最好每2~3天就去向開發(fā)的同事了解一下目前的開發(fā)進(jìn)度，吃飯的時(shí)候，休息的時(shí)候都可以了，每周開一次10分鐘左右的小會(huì)，大家一起碰一下項(xiàng)目的整體進(jìn)度，有沒有遇到什么問題，進(jìn)度是不是與計(jì)劃的差不多等等。PM一定得及時(shí)掌握開發(fā)進(jìn)度，確保項(xiàng)目在按照計(jì)劃進(jìn)行，出現(xiàn)問題時(shí)，以便做出及時(shí)調(diào)整。
整個(gè)周期一般控制在2~3周，還是要看產(chǎn)品的功能來決定。一般分配是服務(wù)端1人、每個(gè)客戶端2人、運(yùn)營管理平臺(tái)1人。
五、測試迭代
這個(gè)過程可快可慢，主要還是看PM來如何把控了。我們公司是沒有設(shè)置專門的測試崗位的，所以測試的工作也被PM承包了...
如果想要加快這個(gè)過程的進(jìn)度，那么就得辛苦PM/測試組同事了。這個(gè)階段，一般會(huì)要求每天發(fā)布一個(gè)新的測試包（解決當(dāng)天的bug），PM/測試組同事會(huì)在晚上進(jìn)行測試，把發(fā)現(xiàn)的問題交給開發(fā)的同事第二天進(jìn)行修改。bug基本快要解決完的時(shí)候，讓負(fù)責(zé)UI設(shè)計(jì)的同事檢查所有的地方是否是按照UI來進(jìn)行實(shí)現(xiàn)的，把需要還原的地方給開發(fā)的同事指出來進(jìn)行修改。
這樣下來，基本一周的時(shí)間，就可以發(fā)布正式版本了。我也見過這個(gè)過程很漫長的，比如說，發(fā)一個(gè)測試包，PM/測試組測試一天，然后開發(fā)修改一天，依次循環(huán)...這樣的協(xié)作方式無形中就把整個(gè)進(jìn)度拉長了一半了。
六、提交應(yīng)用市場
是不是測試版本沒問題了，就等于開發(fā)的同事給你的正式版本也就一定沒有問題呢。當(dāng)然不是，為了保險(xiǎn)起見，一定要在提交應(yīng)用市場之前，把正式版本也過一遍。
好啦，先寫到這里了，下一篇我們一起討論：哪些點(diǎn)會(huì)導(dǎo)致我們的項(xiàng)目延期？
