如何设计多批次收货需求上我的产品方法论

　　本文是一个系列文的上篇，分成上下文是为了方便大家的阅读和理解，本篇是写的关于我自己的产品方法论，也是在做这个需求的时候自己定义并遵守的一个规则和指导思想，内容偏理论，可能太干。
　　此需求也是我近期的工作内容之一，所以具有实战性也很新鲜，希望会对一些2B的产品会有一些启示，也希望有供应链及跨境电商行业的产品大佬一同交流学习。
　　很早之前我就想写两个内容，一个是自己的产品方法论，一个是关于WMS的背后的故事。
　　产品方法论是因为我每次看别人的文章的时候都觉得头头是道，有条不紊，而自己做需求，做一些产品相关的工作的时候总是今天用＂华山派的功夫＂，明天用＂武当的功夫＂，后天＂可能就完全不会功夫了＂……所以我想自己写点东西给自己一些指导，一些约束。
　　WMS的背后的故事是因为我目前主要负责的就是这个模块，我也对这个领域是最熟悉的，当然虽然说最熟悉，但是我依然觉得这一块我做得很一般，还远没有踏入行业的门槛。
　　写这些是为了总结自己的一些产品心得，同样的网络上这方面的资料和信息太匮乏了，如果我的东西能给别人一点帮助，那也是一个莫大的荣幸。
　　结合上述几个理由，我决定说干就干，既写下我的产品方法论，也写下我对WMS这一块的心得感悟。
　　我的产品方法论
　　产品方法论是指我在日常完成一个需求设计的一个过程中所使用的一些步骤和方法，其实这个方法论是我现写的，这也是我在前面提到自己没有严格的约束、规范去指导自己做这些东西的原因之一，因为没有方法论，所以今天想起来了就会用＂华山派的功夫＂，要是没想起来可能就会用＂武当的功夫＂，甚至为了偷懒直接就没有什么功夫。
　　所以会导致每次做不同的需求的时候，会有千奇百怪的差异，有时候会心血来潮写Mindjet分析，有时候会写文档记录，有时候会用Excel表进行跟进和梳理，有时候啥也脑子里过一遍就定了方案……
　　为避免上述问题的持续发生，我决定去制定这些方法论，同时也严格去执行、落实，其中对这些方法论进行必要的迭代升级。下图就是我制定的属于我自己的「产品方法论」，主要是在适用在＂需求分析及设计＂环节。
　　第一步：背景
　　背景这个东西一般我在写需求文档或者写TAPD的时候都会写上去，因为很多时候我们都会忘记为什么要做这个功能，或者时间一久就会忘记当时做这个的理由和原因是什么了，所以写背景，一方面是为了以后翻起旧账的时候可以做参考；另一方面是在需求评审或者分配开发任务的时候，让开发和测试能够认同这个需求，有共同目标和共同的认知。
　　毕竟如果团队成员都不知道为什么要做这个，做这个的意义是什么，那么久而久之需求就会变成一项苦差事，大家就没有奋斗和拼劲了。
　　背景除了上述说到的功效，还能在写背景的过程中对需求进行一个初步评估，结合各种方法论和一些指导，比如我们常听到的：＂用户访谈，调研＂，＂市场调研＂，＂需求析＂，＂SWOT＂，＂5W1H＂等……
　　总之这个环节就是要确定需求是能做的，是有价值的，让大家认同这一点，才能接下来去落实具体的方案。产品做完了这一步，才能进行第二步的工作。
　　第二步：方案制定
　　方案制定是一个大环节，也是「需求设计」环节中最重要的一环，我一般根据产品生命周期会将产品工作流程分为这几个大块：
　　需求的收集与评估；
　　需求的设计与评审；
　　需求的研发与测试；
　　需求的上线与跟进。
　　本文所讲的产品方法论其实是针对「需求的设计与评审」这一环节来写的，其他环节也重要，但是本文重点突出「需求的设计与评审」这一块。
　　一般来说，做一个需求的时候，需求提出者会给出＂问题型需求＂和＂方案型需求＂，那么什么是＂问题型需求＂，什么是＂方案型需求＂？
　　拿WMS中的一个多SKU流水导出的需求来举例，＂问题型需求＂应该是这样提出的：
　　我在导出SKU的流水时候，会发现每次只能导出一个SKU，或者每次只能导出一个货主的全部SKU的流水，我希望有一个功能，能让我自己选择要导出的SKU，这样既不用一次性导出去挑选想要的，也不会用分多个批次导出每个SKU的流水然后拼接到一起。
　　而＂方案型需求＂一般会这样提出：
　　我在导出SKU的流水时候，会发现每次只能导出一个SKU，或者每次只能导出一个货主的全部SKU的流水，我希望你们能做一个功能，让我在界面上勾选我想要的SKU信息，然后进行导出，这样的话我想要哪几个SKU就能导出哪几个SKU，就很方便了。
　　注意看上面的需求描述，其实大体上来说都是在描述一个事，但是＂问题型需求＂侧重的是表达自己遇到的问题，以及自己想要的结果。
　　而＂方案型需求＂则会表达出自己期望的操作方式或者解决手段，往往很多时候，需求提出者并不懂技术，也不懂系统的一些架构，限制等，所以他们提出的这种要求，有时候是能满足的，有时候却不能满足。
　　但是，如果产品经理没有仔细去分辨其中的原因，就会先入为主的被这种＂方案型需求＂代入其中，一直想用需求方描述的方式去解决这个问题，当遇到瓶颈的时候还是会一股脑的想要按照需求描述的去实现，而难以跳出来去寻找其他的方案。
　　其实也许用另外的一种交互或者手段一样能达到这种要求，所以当一个需求提出的时候，我们应该仔细地去分辨，它是＂问题型需求＂还是＂方案型需求＂。当需求是一个＂问题型需求＂的时候，我们会不受约束地去想到多种方案和办法，这样更加有利于迅速和准确地解决问题。
　　方案制定包含很多内容，但是核心点就是：出一个方案，这里的方案可以是初步的，不成熟的，但是一定是要具有可行性的，能被大家认同的。
　　所以我一般会出一些流程图，业务分析介绍图等和开发或者是业务干系人进行初步沟通，看看这种方案从理想化，抽象化的角度是否具有可行性，是否能解决需求方的问题。
　　方案的制定一样的会有很多成熟的方案论，例如＂用例图＂，＂泳道图＂，＂任务拆解＂，＂需求剖析＂，＂对比分析＂，＂用户调研＂，＂数据佐证＂等等……
　　这里一样不展开讲了，此环节的关键目标是：制定出一个初步的需求解决方案，最好是通过了一些业务干系人的认可。
　　第三步：产品结构图
　　产品结构图，产品信息结构图，产品功能结构图，基本上算是逼死产品小白三座大山了。
　　首先是从字面意思就有点绕，都是结构，都长得很像，但是又不像；其次就是网上的解释五花八门，大家各自有各自的认知和理解，谁也不能说服谁；最后是到底用哪个，大家也没有准信，全部都写，都整理出来太麻烦，费时间，不整理出来又怕被人说自己不专业，是个＂野鸡产品＂……
　　于是乎，产品小白们，卒！
　　在这一块我个人的理解是产品结构包含了产品信息结构和产品功能结构，「产品信息结构」就是指为了解决这个需求那我做出来的页面或者功能它有什么信息，例如WMS多批次收货功能中的信息：
　　一共有几个界面，每个界面分别能展示什么信息等；
　　一个有多少字段，字段的限制、规则、解释等；
　　展开与缩起的信息分别有哪些，优先级顺序是怎么样的；
　　功能带来的交互，文案，提示，以及涉及的一些异常机制等；
　　而「产品功能结构」则是突出此需求需要用到什么功能，功能是放在什么位置，起什么作用之类的，继续的拿WMS多批次收货功能来举例，它的功能结构包含有：
　　每个界面的功能，有什么按钮，按钮的作用；
　　每条数据应该有什么状态，不同的状态有什么不同的功能；
　　功能会带来什么作用，产生什么后续的结果；
　　功能引发的一系列联动，例如记录日志、其他系统的联调，多个模块间的联动等；
　　总体来说，你会发现产品信息结构和产品功能结构并不能百分百切割独立，其中还是会有一些重叠的部分和互相作用（信息是功能，功能也是信息）的部分，所以我一般会将这两个东西放在一个Mindjet中，取名就是「产品结构图」，甚至会在里面加上一些特殊的业务说明和一些背景介绍等，因为它们可能既不是功能，也不是结构，但是却构成了产品结构图。
　　我推荐大家不明白的可以去看「人人都是产品经理」中的两篇文章，它们的访问量和阅读量都很高，具有一定的指导意义。
　　此环节主要的作用就是：抽象化需求，形成明确的方案，这种方案是跃然于纸的感觉，大家可能看到了你的产品结构图基本上就能脑补出你做的东西大概是怎么样子了。
　　模块四：原型或文档
　　最后一步是关于原型和文档，这一块也是所有产品最熟悉的环节了，因为基本上的需求都会走到这一步，不管怎么样，原型不画那文档总要写吧。
　　这一块我的方法论反而是比较成熟和稳定的了，一般针对原型来说，我都是低保真中突出重点，因为我们团队没有UI，所以基本上我如果要对UI有什么特殊要求，我就要在低保真的原型中重点突出这个需求，同时也要进行私下的沟通或者验收，以防止开发没有看到或者没有重视这个问题。
　　而原型设计其实就是对上一步的抽象化的方案进行实例化，做过开发或者能理解面向对象的人就很容易get这个意思。需求的设计和梳理其实都是抽象化的，画原型和写文档就把这个需求的方案从抽象化的类变成实例化的对象。
　　类是对象的抽象，而对象是类的具体实例。所以从这一点我们也就可以理解，为什么很多时候产品面试的时候并不会很看重一个人的产品原型绘制的能力呢？
　　因为原型绘制只是一种表达的手段，你的原型画的很好看，很漂亮，这是一个优势，但是如果你不能很好的达成它最原始的目的，那么这个漂亮和好看并没有多少实用性。而它的原始目的就是：实例化前一步的产品结构图，填充它，让开发和测试可以更加清晰明了的知道具体的方案是怎么样的。
　　原型只是一个手段，文档也只是一个手段，如果你能空用嘴巴讲清楚这个需求，其实你也一样是一个优秀的产品，但是嘴巴讲出去的东西没有根据，没有日志，以后要追溯的时候就不那么好使了，这个时候咱就得以笔代嘴，多写点文档。so，对产品的文档能力有一定的要求，其实一点不过分，因为太重要了。
　　最后
　　方法论这个东西就是＂我之蜜糖，彼之砒霜＂的玩意儿，有时候你遇到了相似的问题的时候就会发现这个东西贼好用，但是如果你一直遇不到相似的问题那么就会觉得这个东西写的毫无意义，也毫无水平。所以每个人的方法论都有一定的局限性，希望我的这篇陋文能给你一些启发。
　　如果你有何高见或者斧正之处，请留言指出，谢谢！我们下一篇再见！届时，我会结合本文所讲的产品方法论，PO出我实际工作中出的一些流程图，产品结构图等，以便让大家更加方便和直观，接地气地了解我所说的「产品方法论」到底是什么！