編輯導語：如今隨着互聯網行業的發展，各種電商平台逐漸深入人們的生活，並且如今微信的小程序也是不少電商平台選擇的渠道之一；本文主要講述以產品經理的角度全統籌的方式去推進一個項目從0到1的建設，我們一起來了解一下。
説阿強少爺騷氣，他就是騷氣，經過那10秒鐘的思考後，他已經決定了要搞一個全新的微信小程序商城了，還要和原來APP端、公眾號端的商城分開運營，重新組建運營團隊，和他老姐分道揚鑣。
就這麼個命題，作為產品經理的你，且兼任着阿強少爺的智囊，這個事情要怎麼搞哇？
一、理解並滿足老闆的目的我覺得這個事情太簡單了，凡是在大是大非面前，聽工資的，總沒錯。
阿強少爺的目的已經很明確了，就兩個點：微信小程序商城、重建運營運營團隊。
1. 低層次的思想電商商城的產品，這些年來，我都已經做到吐了，單純是交互稿，我都攢了八九十斤了。
那麼簡簡單單的，拿個庫存交互出來改一改，就那麼回事了；再搞個和強少的評審會，讓大家都看看我精美的交互稿子！
放在之前，這個事情我應該就是這樣給他liao了，產品經理不就是滿足客户的期待就好了嗎？我也一樣，只要管好強少他想看到的效果就好了；至於開發實現和運營計劃，有技術呆呆們和運營憨憨們。我只是個做產品的！
真是一個可恥的低級產品人的思維。
2. 產品實施三大定律搞產品這個東西，始終要遵循三大定律：高質量、高效率、可執行。
- 高質量，體現在項目的執行過程，包括需求的調研、解決方案的評估、開發過程及上線驗收。
- 高效率，體現在響應業務市場需求要快，以運營、市場需要為第一任務。
- 可執行，執行過程不要出現天馬行空的不確定性，最好是在搞事情之前就儘可能把不確定性給過濾掉，比如説五彩斑斕的黑和根據手機殼顏色變換手機主題之類的。
商城這樣的產品，已經不是技術難點的問題了，但是從0到1，開發週期卻是少不了：
- 商城主流程：瀏覽商品、搜索商品、註冊登陸、加入購物車、下單、支付、訂單審核、發貨、售後、客服等。
- 營銷流程：滿減、多件優惠、優惠券、會員積分等。
進行產品規劃時，概念要大，業務要全。這個是沒有錯的。可是掂量下，會發現，卻是違背了“高效率”的原則。所以為什麼項目都要講究分期迭代的方式。
是不是可以先把商城主流程和營銷板塊分成兩個大版本？
答案是可以的。可卻滿足不了業務的需要！是啊，從產品研發的角度出發，做到明年都可以，但如果脱離了市場，等到一年後產品上線了，是不是團隊都已經解散了！
且這個純商城的業務場景和其他結合型的產品業務場景不一樣。純商城的，目的就是賣東西，用户感受到足夠多優惠就買了，要不然用户放着京東天貓不去，到這裏作甚！
結合型的產品，商城僅僅只是其中的一個附屬功能，其主業務流不在於商城，這種，個人覺得是可以把商城主流程先作為一期，優惠作二期即可，比如像小紅書這類的產品，主要呈現還是內容流……
實況：公司的商城系統本來就已經存在，只是需要增加一個微信小程序端口，購物流程和優惠功能都是運作良久的；通過調研，因為之前做產品規劃的時候，並沒有考慮到分端運營的場景，所以後台的訂單管理、營銷功能配置是沒有做欄目區分的，就是不支持分團隊的場景。
4. 我的解決方案在這個方案上，我考慮的是兩個點：
- 高效率，就是要快速落地；
- 產品獨立，不能把這個項目和產品賣身給到原來的項目團隊（之前的商城產品做的可爛可爛了，我可不想在爛尾樓上面去建高樓）。
所以在前期，我還是給我的商城規劃了兩期：
第一期：主流程開發+原商城可用資源直接利用。
讓原來的商城團隊去對他們之前已經做好的商城架構做改造，可行，但不提倡，起碼要經過慎重的評估，畢竟項目運作了那麼久，改這些玩意是會影響商城的正常業務的：
第二期：獨立幹。
逐步斷掉原來的次要對接，特別是優惠促銷這塊。商品的對接可以保留，畢竟公司的商品建檔維護、採購等，都是統一的，不好再另外搞團隊去重新去幹這些東西，除非新商城賣的東西要和之前的商城完全不一樣，且也是全新領域的供應鏈咯。
上面第一期的對接有個難點，在於優惠促銷的對接。
不過如果有看過我前一篇文章關於優惠券的介紹的話，這個就不是事了：
促銷優惠是需要優惠到人的，以優惠券舉例，系統投放的優惠券就是需要投放到人的；所以要求，新商城的用户領取時，需要使用新商城用户的ID，在舊商城系統裏面進行一次用户註冊，這樣才能夠做到優惠券投放到人。
至於ID，使用手機號應該不是問題，畢竟微信小程序是可以通過授權獲取到手機號的。
在優惠券的核銷環節，這裏拋出一個細節問題：是用户先支付後核銷優惠券，還是先核銷優惠券再讓用户進行支付？可以結合用户多終端操作同時下單的場景來思考優惠券核銷的邏輯，然後加上一個“鎖”的理念來解決這個問題。
畫這個流程圖，不是為了證明我多牛逼，而是方便後續推進項目、產品評審、和技術呆呆聊天時，有比較有力的工具而已。
二、項目執行分解1. 大項分解根據強少的目標和我做的方案，除了要自建團隊外，項目的第三方參與者也是不少的，主要是原商城的開發團隊和倉儲系統WMS的開發團隊。
很重要，找出這些相關方，是開展項目的第一步。
當前計劃表只是把大項進行了羅列，具體的每個相關方，還需要有個明細的任務分解計劃表的；比如自己團隊的商城開發計劃表、原商城開發團隊的開發計劃表和倉儲開發團隊的開發計劃表，都是需要細化的。
2. 細項分解：給出詳細的任務清單來相對來講，自己人，一般都是好説話的，關鍵就是這裏面的第三方，同體系的還好，不同體系的，或者根本就是第三方公司的，巨難搞咯！
舉例一個口頭禪：我都不知道你們的需求是什麼？
是的，就算你把業務給他們描述的多詳細，只要一個“不知道需求是什麼”，全是白搞！所以，做產品經理的你，還需要有一項技能，就是知道怎麼給第三方提需求，前提是，你要非常清楚你自己想要什麼！這項技能便是：系統交互邏輯。
以上面的優惠券板塊做舉例：
時序圖是系統交互極其有力的工具，考驗着一個人對於多系統交互間的邏輯能力；上面僅僅只是正流程的思緒，異常處理的流程沒有表達到，可以自行補充。
如果自己不會畫或者還沒有能力畫的話，可以求個技術幫忙解決下。這樣的思路出來後，接下來，對於每個版塊的功能，需要到對方開發哪些接口的，自然就出來了。
具體的接口需求，根據場景，再做類似的具體細化，詳細的需求就出來了。到這裏了，應該不會有這麼笨的第三方開發了吧？
不過也不怕，我們可以更加詳細一些，就是類似微信公眾號開放平台一樣，寫成指導文檔，包括接口的使用場景、接口字段，再把交互時序圖貼上去。
沒有毛病，騰訊那些文檔也是他們的產品經理結合開發的呆呆們一起寫的，應該向這些產品人看齊：
給這些第三方來一個奶媽式服務——服務到家了。
為了達到我的目的，讓這些人越清晰我們的訴求，推進會越是效率。
3. 和自家人做細分理解項目對接所需要哪些接口，只是更加方便我們推進產品建設的效率而已。
當然，如果身邊有個技術幫你去做完這些事情的話，自然是更好，但是我們要理解溝通80/20的定律，直接溝通一定是最效率的，也是最能體現一個人的專業性的。
但是和自家人（自己團隊的技術）做事情，就不要管的那麼多了，比如開發過程的任務分解，讓技術經理搞就好了。如果你也能夠分解，也是可以狗管耗子的，做出來的分解清單，給技術做下參考也行。
三、恰當的手段做事情1. 官方的作用儘量以客觀的方式去描述一個結論。在彼此都不清楚事情面前，或者你清楚，別人不清楚卻不相信你的時候，過多的爭執只會增加解決問題的成本。
比如：小程序分享的時候，能不能做到分享個性化的界面給到用户。
我們不需要馬上給出結論，直接去找個小程序試一下就知道了；但是還是不知道能不能做到個性化界面。你可以選擇問比你牛的人，比如説某個技術。
但是，絕對沒有去微信平台去找官方文檔來説明更加有説服力：
上面第一個圖，告訴我們，小程序分享，沒有自定義圖片的時候，會自動截取頁面部分作為默認分享頁面。第二個圖告訴我們，通過這個接口，可以帶上分享的自定義圖片。
結論就出來了，小程序分享是可以做到分享自定義圖片的。説做不到的那個技術，我相信他沒有什麼需要和你反駁的。
2. 奶媽式服務上面也講到了奶媽式服務，這種做事方式是很花個人的精力和時間的。所以不是需要對所有的人都需要提供這樣的服務的。唯有遇到那種天塌下來他都不着急的人的時候，全世界就只有你着急，幫你做事情的人卻毛線反應沒有。
這種情況下，儘量多為他做些活，因為你着急啊。你催他他還是不着急啊。用愛感動對方羅。
- 比如給對方畫下流程圖、時序圖，幫助對方理解系統交互邏輯。
- 比如幫對方找BUG，一個找了半天甚至幾天都沒有重現的BUG。
遇到故意找茬的人，情商零下的那種，再糾纏下去就沒有意義了。利用外力是必要的；但是有想着，跟這個玩意的合作有可能還很長久，所以要委婉的去處理這個事情。
四、小結經過一輪的操作，項目開始到規劃到安排到落地，完全已經安排下來了。和強少多吐槽下做事情的難處，申請個項目總指揮的角色，有權利做事情就方便很多了。
產品經理的定義，本身就不只是在需求。所以高規格要求自己，是產品人從事產品崗的先決條件。
從需求的調研，到方案設計、產品設計、評審、開發過程，每個細節都在自己的控制範圍內；做出來的產品，才更加像是自己生產的兒子一樣。
畢竟，放養式開發，敢打賭最後的模型是自己想要的結果嗎？或者説，你設計的這個產品，你為之付出了多少？你敢説這個就是你做的產品？
五、最後所有的細節都已經出來了，拉個項目小組羣，把時間點都評估好，把任務都上系統，所有的事情公開、透明，接下來就是等升職加薪了。
留個問題：我的商城，不要獨立搞服務器，寄生到原來的商城裏面去行不行？讓原來的商城對其架構稍微改造下，支持多團隊運營就好了哇？
本文由 @產品經理龍汪汪 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議