189 8069 5689
创业公司，而且老大就在身边，所以很多项目多多少少都接触了，有些项目还完全参与其中，所以我想此时以时间为维度更适合去总结，而不再是以项目为维度。
下面都是我自己实际工作中遇到的问题和解决方法，很大概率不适用于各位看客，所以各位也可以当我说的都是错的。
需求模块确定要做之前。
也就是什么都没有的时候，决定下一步要做什么功能。
决策点只有一个：业务需要。
根据一个电商通用的公式，去细化内部属于我们自己的数据，找出我们整个业务最底层的任何一个数据。然后制定战略决定下一步应该重点提升哪个或者哪几个数据。然后针对这几个数据点，去脑暴出一切可以提升的点，然后在里面挑出现阶段要做的。下一步就是倾尽一切去干，去组织项目组全线压上。这是就会分出各个不同部门需要负责的模块，产品要解决的需求模块就出来了。
确定了要做的需求模块之后。
根据要做的需求模块，进行产品功能的草拟。脑暴需求中所有要涉及的需求点，对应的去加入功能点。以流程图捋顺思路，这个是框架很重要，思路不对做的一切都是错的。
确定了业务流程之后。
思路确认了以后去设计原型，考虑相关信息，此时决不可闭门造车，要去向相关的负责人请教，比如给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个月的一部分吧。
我个人觉得做产品就是经验的积累：遇到了一个问题，这次没解决好，下次就换个方法解决，直到找到最好的解决方法，然后再遇到类似问题就可以一直沿用这套方法了。而我上面写到的一整个流程，就是我现在做产品的方法了。
如果各位有什么建议，希望可以多多和各位交流。感谢