創(chuàng)業(yè)公司，而且老大就在身邊，所以很多項(xiàng)目多多少少都接觸了，有些項(xiàng)目還完全參與其中，所以我想此時(shí)以時(shí)間為維度更適合去總結(jié)，而不再是以項(xiàng)目為維度。
下面都是我自己實(shí)際工作中遇到的問題和解決方法，很大概率不適用于各位看客，所以各位也可以當(dāng)我說的都是錯(cuò)的。
需求模塊確定要做之前。
也就是什么都沒有的時(shí)候，決定下一步要做什么功能。
決策點(diǎn)只有一個(gè)：業(yè)務(wù)需要。
根據(jù)一個(gè)電商通用的公式，去細(xì)化內(nèi)部屬于我們自己的數(shù)據(jù)，找出我們整個(gè)業(yè)務(wù)最底層的任何一個(gè)數(shù)據(jù)。然后制定戰(zhàn)略決定下一步應(yīng)該重點(diǎn)提升哪個(gè)或者哪幾個(gè)數(shù)據(jù)。然后針對(duì)這幾個(gè)數(shù)據(jù)點(diǎn)，去腦暴出一切可以提升的點(diǎn)，然后在里面挑出現(xiàn)階段要做的。下一步就是傾盡一切去干，去組織項(xiàng)目組全線壓上。這是就會(huì)分出各個(gè)不同部門需要負(fù)責(zé)的模塊，產(chǎn)品要解決的需求模塊就出來了。
確定了要做的需求模塊之后。
根據(jù)要做的需求模塊，進(jìn)行產(chǎn)品功能的草擬。腦暴需求中所有要涉及的需求點(diǎn)，對(duì)應(yīng)的去加入功能點(diǎn)。以流程圖捋順?biāo)悸罚@個(gè)是框架很重要，思路不對(duì)做的一切都是錯(cuò)的。
確定了業(yè)務(wù)流程之后。
思路確認(rèn)了以后去設(shè)計(jì)原型，考慮相關(guān)信息，此時(shí)決不可閉門造車，要去向相關(guān)的負(fù)責(zé)人請(qǐng)教，比如給bd設(shè)計(jì)的功能，那一定要請(qǐng)教現(xiàn)有的bd工作流程與細(xì)節(jié)，才能更好的適應(yīng)他們的工作，而不能我說啥就是啥，讓天下人都來適應(yīng)我。
還有就是我始終覺得憑空想象是不可能想全面所有的東西的，所以我會(huì)先做一個(gè)初版原型大體框架，再去帶入業(yè)務(wù)流程，去確認(rèn)細(xì)節(jié)的功能。此時(shí)原型和文檔更配哦，一個(gè)好的文檔模板或者文檔思路能幫自己發(fā)現(xiàn)很多原型中的坑！然后反反復(fù)復(fù)的評(píng)審，一點(diǎn)一點(diǎn)修正原型和文檔，直到確認(rèn)了所有現(xiàn)有的信息以后，拿去給設(shè)計(jì)和開發(fā)。這一步應(yīng)該是最考察功力的時(shí)候了，因?yàn)樵秃臀臋n中所有的問題都會(huì)成為pm前路上的坑，只有跌的鼻青臉腫以后才能慢慢的減少存在的坑。
確定了開發(fā)的原型和文檔之后。
先說一句，我相當(dāng)于是電商后臺(tái)的pm，所以原型就是設(shè)計(jì)稿，不需要設(shè)計(jì)師出設(shè)計(jì)稿（我們公司是這樣的）。不要覺得此時(shí)萬事大吉了。
這個(gè)時(shí)間我說的最多一句話是：xx和xx（前端和后端開發(fā)兄弟的名字），幫忙改一下這里哈。
這個(gè)時(shí)間我聽到最多一句話是：xx（我的名字），來一下，有幾個(gè)問題和你確認(rèn)一下。
當(dāng)然這個(gè)時(shí)間段也是成長(zhǎng)最快的時(shí)間段，因?yàn)榇藭r(shí)的一切問題都是自己當(dāng)初沒有考慮到的情況。把所有問題一一記錄下來，思考一下當(dāng)時(shí)為什么沒有考慮到這一點(diǎn)，思考一下如何才能考慮到這一點(diǎn)，當(dāng)下次做的時(shí)候也這么思考一下，拓寬自己的思維方向，就是成長(zhǎng)。
因?yàn)槭墙o自己的總結(jié)，所以把當(dāng)前最大的這個(gè)任務(wù)我遇到的坑總結(jié)一下，希望能給沒做過的人一點(diǎn)建議，也希望做過的大牛也給我提一些意見。首先介紹一下我現(xiàn)在的任務(wù)是做spu和sku的管理系統(tǒng)，我想所有做電商的都會(huì)知道spu和sku吧，不知道的去百度一下吧。
總結(jié)我的問題：
設(shè)置字段名稱時(shí)，一定要記得給所有人同步，不一定要多形象，但是所有人一定要一致，否則必然出岔子。
由于要展示給使用人員，所以先把所有的字段分一下類，一類的字段集中放在一個(gè)部分，不能散亂，不然使用的時(shí)候必然砸電腦。
能用邏輯得出的字段盡量用邏輯得出；可有可無的字段全部刪去，只留必須存在的字段；減少使用人員操作量。
要考慮使用人員所有使用的場(chǎng)景，比如添加spu或者sku時(shí)需要添加的字段，和管理spusku時(shí)查看的字段不一定完全一樣。添加時(shí)要完全，字段要盡量多；查看時(shí)要精簡(jiǎn)，字段要盡量少；操作時(shí)要簡(jiǎn)單，自動(dòng)顯示>選擇>填寫，選擇時(shí)盡量把最常用的選項(xiàng)默認(rèn)選中。
注意區(qū)分好所有的字段選填還是必填（我開始就懶了，全部限制必填，結(jié)果打臉太狠），一定要給定字段限制。
我得承認(rèn)這個(gè)項(xiàng)目中是我第一次聽到“狀態(tài)機(jī)”這個(gè)東西，狀態(tài)機(jī)很重要，涉及到所有的狀態(tài)機(jī)制，所以必須在原型制作前就想好，否則是大坑！！！不同狀態(tài)的spu和不同狀態(tài)的sku差距可能很大，每一個(gè)都需要去認(rèn)真考慮。
邏輯操作問題。邏輯操作我分為兩種：人為操作產(chǎn)生的邏輯，后臺(tái)內(nèi)部設(shè)定的邏輯。人為操作就是比如我把一個(gè)sku下線，則它就不載客戶端展示了。這個(gè)在設(shè)計(jì)原型的時(shí)候很容易想到。但是后臺(tái)內(nèi)部設(shè)定的邏輯就不那么容易注意到了，這也是會(huì)涉及狀態(tài)機(jī)的東西。比如sku到達(dá)某個(gè)時(shí)間點(diǎn)的時(shí)候就自動(dòng)從上線狀態(tài)跳轉(zhuǎn)到下線狀態(tài)；比如sku在從上線狀態(tài)跳轉(zhuǎn)到下線狀態(tài)時(shí)，若是滿足某個(gè)條件，則此sku又帶上了另外一種狀態(tài)。
一個(gè)實(shí)際問題，需要自己注意的。為了方便添加多個(gè)sku，所以在sku列表中給sku加了一個(gè)復(fù)制功能。其中要注意：a.不同狀態(tài)的sku是否都需要復(fù)制功能，需要思考使用場(chǎng)景。b.復(fù)制的話會(huì)產(chǎn)生兩個(gè)一模一樣的sku，這是不允許的，那么怎么能避免呢？現(xiàn)在用的是點(diǎn)擊復(fù)制以后跳轉(zhuǎn)到sku編輯頁面，頁面信息和被復(fù)制的sku一模一樣，操作人員修改其中一些信息就可以保存，然后校驗(yàn)一下，如果所有信息都和被復(fù)制的一樣則報(bào)錯(cuò)。
在設(shè)計(jì)功能的時(shí)候，如果時(shí)間和資源緊張的話，就盡量先簡(jiǎn)單來，能夠滿足現(xiàn)有需求即可。不要考慮太多的情況，只從現(xiàn)有實(shí)際情況出發(fā)，滿足現(xiàn)有的所有情況，至于其它可能存在的情況，等情況發(fā)生了以后再去迭代功能就好了。
我們團(tuán)隊(duì)，目前來說提升工作效率的需求總是排在最后的。但是當(dāng)業(yè)務(wù)重心向某一塊偏移的時(shí)候，那塊業(yè)務(wù)中提升工作效率的需求也要對(duì)應(yīng)的提升到相對(duì)最高優(yōu)先級(jí)。這個(gè)是我目前知道的，不由人為干預(yù)的提高需求優(yōu)先級(jí)的唯一情況。如果各位有什么其他情況，也希望能告訴我，感謝。
說在最后：
說是4個(gè)月的總結(jié)，但是寫完以后發(fā)現(xiàn)寫成了現(xiàn)在正在做的這個(gè)項(xiàng)目總結(jié)。不過這也算是4個(gè)月的一部分吧。
我個(gè)人覺得做產(chǎn)品就是經(jīng)驗(yàn)的積累：遇到了一個(gè)問題，這次沒解決好，下次就換個(gè)方法解決，直到找到最好的解決方法，然后再遇到類似問題就可以一直沿用這套方法了。而我上面寫到的一整個(gè)流程，就是我現(xiàn)在做產(chǎn)品的方法了。
如果各位有什么建議，希望可以多多和各位交流。感謝

網(wǎng)站沒有備案號(hào)-域名及賬戶問題
php 如何修改 checkbox
請(qǐng)幫忙加急審核資料信息已經(jīng)改好謝謝
美國主機(jī)怎么選擇？ GoDaddy和BlueHost對(duì)比評(píng)測(cè)
阿里云服務(wù)器掛網(wǎng)頁游戲
阿里云服務(wù)器放二個(gè)網(wǎng)站可以嗎安全嗎
盯盤和云服務(wù)器區(qū)別
遠(yuǎn)程不能打開-云服務(wù)器問題