离开学校,入职4月的产品汪感想

从零开始学运营,10年运营老司机带路,2天线下集训+1年在线学习,做个优秀的运营人。了解详情

我不知道其它入职到这个时期的PM是怎么样的。但是由于我的老大(聪哥),就坐在我身边,每天经常能看到他在做些什么,自己有时也会默默记下来他在做什么,所以有时就会摸不清看不透自己现在的状态;没有办法去验证自己的能力到底在哪里,无法确定自己是不是真的高估了自己,还是自己真的可以去尝试触碰那些更高的点了。

happiness

创业公司,而且老大就在身边,所以很多项目多多少少都接触了,有些项目还完全参与其中,所以我想此时以时间为维度更适合去总结,而不再是以项目为维度。

下面都是我自己实际工作中遇到的问题和解决方法,很大概率不适用于各位看客,所以各位也可以当我说的都是错的。

需求模块确定要做之前。

也就是什么都没有的时候,决定下一步要做什么功能。

决策点只有一个:业务需要。

根据一个电商通用的公式,去细化内部属于我们自己的数据,找出我们整个业务最底层的任何一个数据。然后制定战略决定下一步应该重点提升哪个或者哪几个数据。然后针对这几个数据点,去脑暴出一切可以提升的点,然后在里面挑出现阶段要做的。下一步就是倾尽一切去干,去组织项目组全线压上。这是就会分出各个不同部门需要负责的模块,产品要解决的需求模块就出来了。

确定了要做的需求模块之后。

根据要做的需求模块,进行产品功能的草拟。脑暴需求中所有要涉及的需求点,对应的去加入功能点。以流程图捋顺思路,这个是框架很重要,思路不对做的一切都是错的。

确定了业务流程之后。

思路确认了以后去设计原型,考虑相关信息,此时决不可闭门造车,要去向相关的负责人请教,比如给BD设计的功能,那一定要请教现有的BD工作流程与细节,才能更好的适应他们的工作,而不能我说啥就是啥,让天下人都来适应我。

还有就是我始终觉得凭空想象是不可能想全面所有的东西的,所以我会先做一个初版原型大体框架,再去带入业务流程,去确认细节的功能。此时原型和文档更配哦,一个好的文档模板或者文档思路能帮自己发现很多原型中的坑!然后反反复复的评审,一点一点修正原型和文档,直到确认了所有现有的信息以后,拿去给设计和开发。这一步应该是最考察功力的时候了,因为原型和文档中所有的问题都会成为PM前路上的坑,只有跌的鼻青脸肿以后才能慢慢的减少存在的坑。

确定了开发的原型和文档之后。

先说一句,我相当于是电商后台的PM,所以原型就是设计稿,不需要设计师出设计稿(我们公司是这样的)。不要觉得此时万事大吉了。

  • 这个时间我说的最多一句话是:XX和XX(前端和后端开发兄弟的名字),帮忙改一下这里哈。
  • 这个时间我听到最多一句话是:XX(我的名字),来一下,有几个问题和你确认一下。

当然这个时间段也是成长最快的时间段,因为此时的一切问题都是自己当初没有考虑到的情况。把所有问题一一记录下来,思考一下当时为什么没有考虑到这一点,思考一下如何才能考虑到这一点,当下次做的时候也这么思考一下,拓宽自己的思维方向,就是成长。

因为是给自己的总结,所以把当前最大的这个任务我遇到的坑总结一下,希望能给没做过的人一点建议,也希望做过的大牛也给我提一些意见。首先介绍一下我现在的任务是做SPU和SKU的管理系统,我想所有做电商的都会知道SPU和SKU吧,不知道的去百度一下吧。

总结我的问题:

  1. 设置字段名称时,一定要记得给所有人同步,不一定要多形象,但是所有人一定要一致,否则必然出岔子。
  2. 由于要展示给使用人员,所以先把所有的字段分一下类,一类的字段集中放在一个部分,不能散乱,不然使用的时候必然砸电脑。
  3. 能用逻辑得出的字段尽量用逻辑得出;可有可无的字段全部删去,只留必须存在的字段;减少使用人员操作量。
  4. 要考虑使用人员所有使用的场景,比如添加SPU或者SKU时需要添加的字段,和管理SPUSKU时查看的字段不一定完全一样。添加时要完全,字段要尽量多;查看时要精简,字段要尽量少;操作时要简单,自动显示>选择>填写,选择时尽量把最常用的选项默认选中。
  5. 注意区分好所有的字段选填还是必填(我开始就懒了,全部限制必填,结果打脸太狠),一定要给定字段限制。
  6. 我得承认这个项目中是我第一次听到“状态机”这个东西,状态机很重要,涉及到所有的状态机制,所以必须在原型制作前就想好,否则是大坑!!!不同状态的SPU和不同状态的SKU差距可能很大,每一个都需要去认真考虑。
  7. 逻辑操作问题。逻辑操作我分为两种:人为操作产生的逻辑,后台内部设定的逻辑。人为操作就是比如我把一个SKU下线,则它就不载客户端展示了。这个在设计原型的时候很容易想到。但是后台内部设定的逻辑就不那么容易注意到了,这也是会涉及状态机的东西。比如SKU到达某个时间点的时候就自动从上线状态跳转到下线状态;比如SKU在从上线状态跳转到下线状态时,若是满足某个条件,则此SKU又带上了另外一种状态。
  8. 一个实际问题,需要自己注意的。为了方便添加多个SKU,所以在SKU列表中给SKU加了一个复制功能。其中要注意:a.不同状态的SKU是否都需要复制功能,需要思考使用场景。b.复制的话会产生两个一模一样的SKU,这是不允许的,那么怎么能避免呢?现在用的是点击复制以后跳转到SKU编辑页面,页面信息和被复制的SKU一模一样,操作人员修改其中一些信息就可以保存,然后校验一下,如果所有信息都和被复制的一样则报错。
  9. 在设计功能的时候,如果时间和资源紧张的话,就尽量先简单来,能够满足现有需求即可。不要考虑太多的情况,只从现有实际情况出发,满足现有的所有情况,至于其它可能存在的情况,等情况发生了以后再去迭代功能就好了。
  10. 我们团队,目前来说提升工作效率的需求总是排在最后的。但是当业务重心向某一块偏移的时候,那块业务中提升工作效率的需求也要对应的提升到相对最高优先级。这个是我目前知道的,不由人为干预的提高需求优先级的唯一情况。如果各位有什么其他情况,也希望能告诉我,感谢。

说在最后:

说是4个月的总结,但是写完以后发现写成了现在正在做的这个项目总结。不过这也算是4个月的一部分吧。

我个人觉得做产品就是经验的积累:遇到了一个问题,这次没解决好,下次就换个方法解决,直到找到最好的解决方法,然后再遇到类似问题就可以一直沿用这套方法了。而我上面写到的一整个流程,就是我现在做产品的方法了。

如果各位有什么建议,希望可以多多和各位交流。感谢

 

本文由 @Nick 原创发布于人人都是产品经理 ,未经许可,禁止转载。

祝给予赞赏的伙伴,2017年发大财!

评论( 1

写下你的想法
  1. 运营狗

    不会是ERP的产品汪吧

    回复

推荐阅读