编辑导语：如今随着互联网行业的发展，各种电商平台逐渐深入人们的生活，并且如今微信的小程序也是不少电商平台选择的渠道之一；本文主要讲述以产品经理的角度全统筹的方式去推进一个项目从0到1的建设，我们一起来了解一下。
说阿强少爷骚气，他就是骚气，经过那10秒钟的思考后，他已经决定了要搞一个全新的微信小程序商城了，还要和原来APP端、公众号端的商城分开运营，重新组建运营团队，和他老姐分道扬镳。
就这么个命题，作为产品经理的你，且兼任着阿强少爷的智囊，这个事情要怎么搞哇？
一、理解并满足老板的目的我觉得这个事情太简单了，凡是在大是大非面前，听工资的，总没错。
阿强少爷的目的已经很明确了，就两个点：微信小程序商城、重建运营运营团队。
1. 低层次的思想电商商城的产品，这些年来，我都已经做到吐了，单纯是交互稿，我都攒了八九十斤了。
那么简简单单的，拿个库存交互出来改一改，就那么回事了；再搞个和强少的评审会，让大家都看看我精美的交互稿子！
放在之前，这个事情我应该就是这样给他liao了，产品经理不就是满足客户的期待就好了吗？我也一样，只要管好强少他想看到的效果就好了；至于开发实现和运营计划，有技术呆呆们和运营憨憨们。我只是个做产品的！
真是一个可耻的低级产品人的思维。
2. 产品实施三大定律搞产品这个东西，始终要遵循三大定律：高质量、高效率、可执行。
- 高质量，体现在项目的执行过程，包括需求的调研、解决方案的评估、开发过程及上线验收。
- 高效率，体现在响应业务市场需求要快，以运营、市场需要为第一任务。
- 可执行，执行过程不要出现天马行空的不确定性，最好是在搞事情之前就尽可能把不确定性给过滤掉，比如说五彩斑斓的黑和根据手机壳颜色变换手机主题之类的。
商城这样的产品，已经不是技术难点的问题了，但是从0到1，开发周期却是少不了：
- 商城主流程：浏览商品、搜索商品、注册登陆、加入购物车、下单、支付、订单审核、发货、售后、客服等。
- 营销流程：满减、多件优惠、优惠券、会员积分等。
进行产品规划时，概念要大，业务要全。这个是没有错的。可是掂量下，会发现，却是违背了“高效率”的原则。所以为什么项目都要讲究分期迭代的方式。
是不是可以先把商城主流程和营销板块分成两个大版本？
答案是可以的。可却满足不了业务的需要！是啊，从产品研发的角度出发，做到明年都可以，但如果脱离了市场，等到一年后产品上线了，是不是团队都已经解散了！
且这个纯商城的业务场景和其他结合型的产品业务场景不一样。纯商城的，目的就是卖东西，用户感受到足够多优惠就买了，要不然用户放着京东天猫不去，到这里作甚！
结合型的产品，商城仅仅只是其中的一个附属功能，其主业务流不在于商城，这种，个人觉得是可以把商城主流程先作为一期，优惠作二期即可，比如像小红书这类的产品，主要呈现还是内容流……
实况：公司的商城系统本来就已经存在，只是需要增加一个微信小程序端口，购物流程和优惠功能都是运作良久的；通过调研，因为之前做产品规划的时候，并没有考虑到分端运营的场景，所以后台的订单管理、营销功能配置是没有做栏目区分的，就是不支持分团队的场景。
4. 我的解决方案在这个方案上，我考虑的是两个点：
- 高效率，就是要快速落地；
- 产品独立，不能把这个项目和产品卖身给到原来的项目团队（之前的商城产品做的可烂可烂了，我可不想在烂尾楼上面去建高楼）。
所以在前期，我还是给我的商城规划了两期：
第一期：主流程开发+原商城可用资源直接利用。
让原来的商城团队去对他们之前已经做好的商城架构做改造，可行，但不提倡，起码要经过慎重的评估，毕竟项目运作了那么久，改这些玩意是会影响商城的正常业务的：
第二期：独立干。
逐步断掉原来的次要对接，特别是优惠促销这块。商品的对接可以保留，毕竟公司的商品建档维护、采购等，都是统一的，不好再另外搞团队去重新去干这些东西，除非新商城卖的东西要和之前的商城完全不一样，且也是全新领域的供应链咯。
上面第一期的对接有个难点，在于优惠促销的对接。
不过如果有看过我前一篇文章关于优惠券的介绍的话，这个就不是事了：
促销优惠是需要优惠到人的，以优惠券举例，系统投放的优惠券就是需要投放到人的；所以要求，新商城的用户领取时，需要使用新商城用户的ID，在旧商城系统里面进行一次用户注册，这样才能够做到优惠券投放到人。
至于ID，使用手机号应该不是问题，毕竟微信小程序是可以通过授权获取到手机号的。
在优惠券的核销环节，这里抛出一个细节问题：是用户先支付后核销优惠券，还是先核销优惠券再让用户进行支付？可以结合用户多终端操作同时下单的场景来思考优惠券核销的逻辑，然后加上一个“锁”的理念来解决这个问题。
画这个流程图，不是为了证明我多牛逼，而是方便后续推进项目、产品评审、和技术呆呆聊天时，有比较有力的工具而已。
二、项目执行分解1. 大项分解根据强少的目标和我做的方案，除了要自建团队外，项目的第三方参与者也是不少的，主要是原商城的开发团队和仓储系统WMS的开发团队。
很重要，找出这些相关方，是开展项目的第一步。
当前计划表只是把大项进行了罗列，具体的每个相关方，还需要有个明细的任务分解计划表的；比如自己团队的商城开发计划表、原商城开发团队的开发计划表和仓储开发团队的开发计划表，都是需要细化的。
2. 细项分解：给出详细的任务清单来相对来讲，自己人，一般都是好说话的，关键就是这里面的第三方，同体系的还好，不同体系的，或者根本就是第三方公司的，巨难搞咯！
举例一个口头禅：我都不知道你们的需求是什么？
是的，就算你把业务给他们描述的多详细，只要一个“不知道需求是什么”，全是白搞！所以，做产品经理的你，还需要有一项技能，就是知道怎么给第三方提需求，前提是，你要非常清楚你自己想要什么！这项技能便是：系统交互逻辑。
以上面的优惠券板块做举例：
时序图是系统交互极其有力的工具，考验着一个人对于多系统交互间的逻辑能力；上面仅仅只是正流程的思绪，异常处理的流程没有表达到，可以自行补充。
如果自己不会画或者还没有能力画的话，可以求个技术帮忙解决下。这样的思路出来后，接下来，对于每个版块的功能，需要到对方开发哪些接口的，自然就出来了。
具体的接口需求，根据场景，再做类似的具体细化，详细的需求就出来了。到这里了，应该不会有这么笨的第三方开发了吧？
不过也不怕，我们可以更加详细一些，就是类似微信公众号开放平台一样，写成指导文档，包括接口的使用场景、接口字段，再把交互时序图贴上去。
没有毛病，腾讯那些文档也是他们的产品经理结合开发的呆呆们一起写的，应该向这些产品人看齐：
给这些第三方来一个奶妈式服务——服务到家了。
为了达到我的目的，让这些人越清晰我们的诉求，推进会越是效率。
3. 和自家人做细分理解项目对接所需要哪些接口，只是更加方便我们推进产品建设的效率而已。
当然，如果身边有个技术帮你去做完这些事情的话，自然是更好，但是我们要理解沟通80/20的定律，直接沟通一定是最效率的，也是最能体现一个人的专业性的。
但是和自家人（自己团队的技术）做事情，就不要管的那么多了，比如开发过程的任务分解，让技术经理搞就好了。如果你也能够分解，也是可以狗管耗子的，做出来的分解清单，给技术做下参考也行。
三、恰当的手段做事情1. 官方的作用尽量以客观的方式去描述一个结论。在彼此都不清楚事情面前，或者你清楚，别人不清楚却不相信你的时候，过多的争执只会增加解决问题的成本。
比如：小程序分享的时候，能不能做到分享个性化的界面给到用户。
我们不需要马上给出结论，直接去找个小程序试一下就知道了；但是还是不知道能不能做到个性化界面。你可以选择问比你牛的人，比如说某个技术。
但是，绝对没有去微信平台去找官方文档来说明更加有说服力：
上面第一个图，告诉我们，小程序分享，没有自定义图片的时候，会自动截取页面部分作为默认分享页面。第二个图告诉我们，通过这个接口，可以带上分享的自定义图片。
结论就出来了，小程序分享是可以做到分享自定义图片的。说做不到的那个技术，我相信他没有什么需要和你反驳的。
2. 奶妈式服务上面也讲到了奶妈式服务，这种做事方式是很花个人的精力和时间的。所以不是需要对所有的人都需要提供这样的服务的。唯有遇到那种天塌下来他都不着急的人的时候，全世界就只有你着急，帮你做事情的人却毛线反应没有。
这种情况下，尽量多为他做些活，因为你着急啊。你催他他还是不着急啊。用爱感动对方罗。
- 比如给对方画下流程图、时序图，帮助对方理解系统交互逻辑。
- 比如帮对方找BUG，一个找了半天甚至几天都没有重现的BUG。
遇到故意找茬的人，情商零下的那种，再纠缠下去就没有意义了。利用外力是必要的；但是有想着，跟这个玩意的合作有可能还很长久，所以要委婉的去处理这个事情。
四、小结经过一轮的操作，项目开始到规划到安排到落地，完全已经安排下来了。和强少多吐槽下做事情的难处，申请个项目总指挥的角色，有权利做事情就方便很多了。
产品经理的定义，本身就不只是在需求。所以高规格要求自己，是产品人从事产品岗的先决条件。
从需求的调研，到方案设计、产品设计、评审、开发过程，每个细节都在自己的控制范围内；做出来的产品，才更加像是自己生产的儿子一样。
毕竟，放养式开发，敢打赌最后的模型是自己想要的结果吗？或者说，你设计的这个产品，你为之付出了多少？你敢说这个就是你做的产品？
五、最后所有的细节都已经出来了，拉个项目小组群，把时间点都评估好，把任务都上系统，所有的事情公开、透明，接下来就是等升职加薪了。
留个问题：我的商城，不要独立搞服务器，寄生到原来的商城里面去行不行？让原来的商城对其架构稍微改造下，支持多团队运营就好了哇？
本文由 @产品经理龙汪汪 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议