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