在APP開(kāi)發(fā)外包公司，產(chǎn)品經(jīng)理和項(xiàng)目經(jīng)理是非常重要的角色，他們決定了項(xiàng)目的交付質(zhì)量以及交付工期。那么，如何才能管理好一個(gè)APP開(kāi)發(fā)項(xiàng)目呢？
       首先，在APP產(chǎn)品管理方面，有以下幾點(diǎn)需要注意的。
       1. 產(chǎn)品在設(shè)計(jì)過(guò)程中不能貪大求全，要有節(jié)奏，注重質(zhì)量大于數(shù)量，這本質(zhì)上來(lái)講是追求極致的用戶體驗(yàn)，有時(shí)候會(huì)因?yàn)闀r(shí)間和資源的限制，技術(shù)實(shí)現(xiàn)上會(huì)打折。
       其實(shí)打折了的功能，如果用戶反饋很差，寧愿砍掉，也要保持產(chǎn)品在一個(gè)高的水平中，千萬(wàn)不能貪大求全，反而傷害了用戶。
       2. 需求來(lái)的時(shí)候，不能因?yàn)闀r(shí)間原因或者客戶催的緊，就立馬開(kāi)始做；應(yīng)該在做之前多問(wèn)幾個(gè)為什么，區(qū)分需求和需要。多跟客戶溝通，尋求合理的解決方案。
       3. 對(duì)于用戶數(shù)據(jù)收集，要保證收集過(guò)程中沒(méi)有臟數(shù)據(jù)，保證數(shù)據(jù)來(lái)源真實(shí)可靠，了解源數(shù)據(jù)和數(shù)據(jù)處理每一步過(guò)程，同時(shí)也要注意數(shù)據(jù)收集渠道多樣性，樣本的局限性。
       4. 需求定版之前不要想當(dāng)然的以為自己了解用戶，什么都替用戶做決定了，大的需求定版之前應(yīng)該進(jìn)行扎實(shí)的用戶調(diào)研，需求優(yōu)先級(jí)也不應(yīng)該誰(shuí)急誰(shuí)優(yōu)先，要根據(jù)產(chǎn)品核心價(jià)值和用戶的訴求定優(yōu)先級(jí)。
       5. 如果有遇到相同的業(yè)務(wù)，有多個(gè)人在對(duì)接，那么最好能夠溝通好需求負(fù)責(zé)人，由需求負(fù)責(zé)人統(tǒng)一對(duì)接需求，不然造成多頭需求，容易產(chǎn)生混亂。
       另一方面，就是開(kāi)發(fā)過(guò)程中的項(xiàng)目管理。
       1. 給技術(shù)除了PRD等文檔之外，還應(yīng)該給功能結(jié)構(gòu)圖和系統(tǒng)流程圖，因?yàn)楣饪碢RD,一大堆文字，換成誰(shuí)都容易看懵，最后開(kāi)發(fā)就會(huì)吐槽產(chǎn)品的PRD寫(xiě)的不好。
       功能結(jié)構(gòu)圖就是新功能的層級(jí)關(guān)系梳理出來(lái)，系統(tǒng)流程圖又分為事件流程圖和狀態(tài)流程圖，事件流程圖是功能點(diǎn)擊的順序和步驟，狀態(tài)流程圖是訂單等狀態(tài)變化的規(guī)則。
       2. PRD除了業(yè)務(wù)邏輯清晰之外，還要求文檔規(guī)范和沒(méi)有遺漏，最理想的情況是需求評(píng)審后，技術(shù)和產(chǎn)品不用溝通了。
為了降低出錯(cuò)率，產(chǎn)品應(yīng)該有一個(gè)自測(cè)表，定義每個(gè)功能都需要寫(xiě)哪些東西，用來(lái)檢查是否都寫(xiě)全、寫(xiě)細(xì)了，目的還是為了讓開(kāi)發(fā)好理解、降低出錯(cuò)率，提高整體研發(fā)效率。
       3. 有時(shí)候在技術(shù)評(píng)審和時(shí)候，產(chǎn)品和技術(shù)互懟比較嚴(yán)重，新聞還出現(xiàn)過(guò)產(chǎn)品和技術(shù)互毆的情況，如果產(chǎn)品和技術(shù)關(guān)系不好，絕對(duì)是整個(gè)公司的悲劇——因?yàn)閮烧哒l(shuí)也離不開(kāi)誰(shuí)。
       對(duì)于產(chǎn)品和技術(shù)來(lái)講，需要在心態(tài)上建立雙贏思維，任何一方不能不顧對(duì)方的立場(chǎng)和處境做事，溝通上應(yīng)該對(duì)事不對(duì)人，為了共同的目標(biāo)，即用戶體驗(yàn)去實(shí)現(xiàn)產(chǎn)品，這是雙方良好溝通的前提。