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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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