作為一個(gè)還未畢業(yè)的人很慶幸自己又能夠經(jīng)歷了一款產(chǎn)品從0到1的過程。雖然說創(chuàng)業(yè)公司在產(chǎn)品開發(fā)的過程中各方面沒大公司那么規(guī)范，但所碰到的各種問題都是自己切身體會到的。自己碰到的問題印象就比較深刻，從而使自己更容易反省以免下次不會再次犯錯(cuò)。下面是我這次經(jīng)歷這款產(chǎn)品的過程中總結(jié)的一點(diǎn)經(jīng)驗(yàn)，也是自己踩過的坑，希望能給和我一樣入行不久的產(chǎn)品新人以及打算從事產(chǎn)品的朋友一些借鑒。

1、有變化及時(shí)傳達(dá)溝通

產(chǎn)品在開發(fā)的過程中很難避免不會有修改的地方，有的時(shí)候可能是界面元素?cái)[放位置的變動，有的時(shí)候可能是操作流程上的細(xì)小改變，有的時(shí)候可能是整個(gè)需求的變更。

有變化第一要修改的肯定是原型圖。改好之后需要和設(shè)計(jì)以及開發(fā)人員溝通說明有改變。剛開始的時(shí)候，有的時(shí)候比較忙修改了需求忘記跟設(shè)計(jì)師和技術(shù)說。等到階段性檢查產(chǎn)品的時(shí)候發(fā)現(xiàn)和原型不一樣，領(lǐng)導(dǎo)問到技術(shù)的時(shí)候，技術(shù)人員一臉蒙蔽說，我不知道啊，修改需求沒跟我說啊。然后我羞愧的忙著道歉說自己忘了，感覺技術(shù)人員有分分鐘想砍死我的沖動，因?yàn)樗麄冇忠匦滦薷拇a，之前的努力白費(fèi)。

任何產(chǎn)品在做的過程中多多少少都會修改需求，需求有變化很正常，重要的是改了需求之后要告知相關(guān)設(shè)計(jì)師和技術(shù)人員。如果是創(chuàng)業(yè)公司，改好之后可以立馬口頭通知，如果是大公司，那可能還需要召集技術(shù)，設(shè)計(jì)，運(yùn)營等負(fù)責(zé)人進(jìn)行小的會議。只有這樣才不會打擊技術(shù)人員的士氣，保證項(xiàng)目的開發(fā)周期，才能和程序猿哥哥友好的合作下去。

2、使用Axure畫原型圖時(shí)要善用模板

我想每個(gè)產(chǎn)品新人可能都曾遇到這樣的痛苦——當(dāng)修改產(chǎn)品原型的時(shí)候，往往牽一發(fā)而動全身，一處修改，其他很多地方都需要修改。

公司做的是C端產(chǎn)品，功能模塊比較少， 完整的邏輯走下來也用了差不多60個(gè)頁面，剛開始的時(shí)候每個(gè)頁面單獨(dú)去畫，有相同的最多復(fù)制一下，完全沒有使用母版的思想。而到后面要修改某部分的時(shí)候，凡是和這部分相關(guān)聯(lián)的頁面都要一個(gè)一個(gè)去找去修改，這樣不僅浪費(fèi)時(shí)間，而且很痛苦，還有可能漏掉一些沒修改到。

所以在設(shè)計(jì)原型的時(shí)候，類似導(dǎo)航條這樣在多個(gè)頁面需要相同展示的部分，一定要使用母版，這樣不僅效率高還不容易出錯(cuò)。

3、設(shè)計(jì)產(chǎn)品各種情況需要考慮周全

我們在制作產(chǎn)品原型圖的時(shí)候考慮的常常是正常頁面和操作流程，往往遺漏掉異常情況下的頁面。比如沒有數(shù)據(jù)的空頁面怎么顯示，斷網(wǎng)情況下是冒泡提示還是整個(gè)頁面作為提示頁，登陸頁面忘記安全考慮，沒有添加驗(yàn)證碼等等。

作為產(chǎn)品經(jīng)理如果各種特殊情況都考慮不到，還要等技術(shù)開始的時(shí)候發(fā)現(xiàn)再跟你反饋，真的會讓他們鄙視。所以原型設(shè)計(jì)好之后一定要多想想還有沒有特殊情況是自己還沒考慮到的。

4、項(xiàng)目啟動前一定要有產(chǎn)品第一個(gè)版本的規(guī)劃

創(chuàng)業(yè)公司一個(gè)共同的特點(diǎn)就是 “追求快”，開發(fā)流程上可以不用規(guī)范，但一定要快。有些創(chuàng)業(yè)公司在項(xiàng)目啟動前不做充分準(zhǔn)備，而是一邊競品分析，一邊設(shè)計(jì)原型，一邊開發(fā)。運(yùn)營部不斷提出新的需求，老板又不確定功能模塊，不斷變更需求。導(dǎo)致產(chǎn)品、設(shè)計(jì)和開發(fā)都要改，產(chǎn)品甚至快上線了還要變更需求，這讓程序猿真的有種想殺人的沖動。

項(xiàng)目啟動前的準(zhǔn)備就像建房子打地基一樣，地基打穩(wěn)了后面蓋房子才會順暢。

雖然說項(xiàng)目啟動前不能100%確定好產(chǎn)品要是什么樣子。但至少應(yīng)該對第一個(gè)版本規(guī)劃個(gè)百分之七八十，做足競品分析，確定好產(chǎn)品定位，需要做哪些功能點(diǎn)，產(chǎn)品的布局風(fēng)格，主色調(diào)，開發(fā)文檔的規(guī)范等等。  這樣對于后面他人提出的功能業(yè)務(wù)需求就可以暫不考慮，規(guī)劃到第二版本。這樣才能保證產(chǎn)品的開發(fā)周期和各部門人員的士氣。

5、UI設(shè)計(jì)好的界面檢查確認(rèn)之后再給開發(fā)

每個(gè)人都有自己的一套想法，UI常常會按照自己的理解和審美對原型圖進(jìn)行一些修改，比如界面元素位置的變動甚至刪除或增加一些按鈕標(biāo)簽等等，如果產(chǎn)品經(jīng)理不提醒UI設(shè)計(jì)好之后讓他看的話，他很可能設(shè)計(jì)好之后直接扔給技術(shù)人員。我就碰到過好幾次原型圖和效果圖不一樣，導(dǎo)致要么程序員改代碼要么我修改原型然后重新設(shè)計(jì)效果圖。

當(dāng)然這也是我經(jīng)驗(yàn)不足造成工作上的失誤。正確的做法應(yīng)該是自己看過效果圖確定無誤后再讓大家看一下，統(tǒng)一意見后再給技術(shù)開發(fā)，這樣以后如果要改也不會出現(xiàn)誰怨誰的情況，因?yàn)楫?dāng)時(shí)大家統(tǒng)一了意見。

6、對于原型圖的標(biāo)示注解盡量詳細(xì)

有時(shí)產(chǎn)品原型文檔上可能會有一些東西沒寫清楚或者忘記寫。比如APP的錯(cuò)誤提示到底是彈窗提示還是toast冒泡提示，無數(shù)據(jù)的空白頁面如何顯示，是使用同一樣式還是不同的空白頁面采用不同的文案圖像顯示等等。

技術(shù)人員希望看到的是一份簡潔又有詳細(xì)說明的產(chǎn)品文檔，因?yàn)樗麄儾辉敢馑伎?，只要照著設(shè)計(jì)和說明做就可以了。如果碰到原型設(shè)計(jì)和說明上模糊不清。那么技術(shù)人員很可能就按照自己的思路去做或者直接忽略，這樣必然會造成后期產(chǎn)品經(jīng)理和程序員的撕逼，各有各的理。程序員覺得你自己又不寫清楚或者文檔上沒寫啊，產(chǎn)品經(jīng)理又會覺得你怎么那么蠢，一點(diǎn)沒寫清就不知道，你的那種想法靠譜嗎。這樣就會造成溝通和時(shí)間成本上的浪費(fèi)。

7、對于業(yè)務(wù)邏輯要100%清楚

可以說任何一款產(chǎn)品沒有誰比產(chǎn)品經(jīng)理更清楚產(chǎn)品的業(yè)務(wù)流程，細(xì)節(jié)交互和各種功能點(diǎn)了。從小到大我們養(yǎng)成了差不多的習(xí)慣，不管做什么都覺得差不多就行了，沒必要全部弄清楚?？勺霎a(chǎn)品一定不能有 “差不多”的概念，對功能和業(yè)務(wù)流程以及任何細(xì)節(jié)都要100%清楚。程序員跑來問產(chǎn)品經(jīng)理問題的時(shí)候最不愿聽到 “應(yīng)該吧” “可能吧” “大概吧”這樣不確定的詞語。