扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
创业公司,而且老大就在身边,所以很多项目多多少少都接触了,有些项目还完全参与其中,所以我想此时以时间为维度更适合去总结,而不再是以项目为维度。
创新互联专注于宁安网站建设服务及定制,我们拥有丰富的企业做网站经验。 热诚为您提供宁安营销型网站建设,宁安网站制作、宁安网页设计、宁安网站官网定制、小程序开发服务,打造宁安网络公司原创品牌,更为您提供宁安网站排名全网营销落地服务。下面都是我自己实际工作中遇到的问题和解决方法,很大概率不适用于各位看客,所以各位也可以当我说的都是错的。
需求模块确定要做之前。
也就是什么都没有的时候,决定下一步要做什么功能。
决策点只有一个:业务需要。
根据一个电商通用的公式,去细化内部属于我们自己的数据,找出我们整个业务最底层的任何一个数据。然后制定战略决定下一步应该重点提升哪个或者哪几个数据。然后针对这几个数据点,去脑暴出一切可以提升的点,然后在里面挑出现阶段要做的。下一步就是倾尽一切去干,去组织项目组全线压上。这是就会分出各个不同部门需要负责的模块,产品要解决的需求模块就出来了。
确定了要做的需求模块之后。
根据要做的需求模块,进行产品功能的草拟。脑暴需求中所有要涉及的需求点,对应的去加入功能点。以流程图捋顺思路,这个是框架很重要,思路不对做的一切都是错的。
确定了业务流程之后。
思路确认了以后去设计原型,考虑相关信息,此时决不可闭门造车,要去向相关的负责人请教,比如给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个月的一部分吧。
我个人觉得做产品就是经验的积累:遇到了一个问题,这次没解决好,下次就换个方法解决,直到找到最好的解决方法,然后再遇到类似问题就可以一直沿用这套方法了。而我上面写到的一整个流程,就是我现在做产品的方法了。
如果各位有什么建议,希望可以多多和各位交流。感谢
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流