对于刚入职场或者还没入职场的产品助理,在刚开始的时候都会比较迷茫,不知道怎么做,那么我将我近期自己的经验告诉你们,希望对你们有用
熟悉业务与项目
我是一个大学生,刚刚毕业有幸进入一家小公司做了B端的产品助理,其实刚开始我挺忐忑的,因为我大三实习的时候是做前端开发的,虽然有接触过产品经理,可以说算是略微了解他的工作。但是对于他的工作内容是怎么进行的我是朦朦胧胧的。刚进去的时候带我的产品经理给我大概了介绍了一下我们公司项目,然后就给我抛了一堆资料跟系统,让我先熟悉一下公司的业务跟项目。我用了一个星期的时间去了解了我们公司的系统,对于这一周的学习,我对于业务跟项目的了解我也掌握了一些心得。
首先了解业务,我们要知道这个系统是做什么的,有什么用,面向的用户有谁,把这些整理清楚,然后在开始熟悉项目。熟悉项目,可以先把整个项目的大致模块先了解清楚,用脑图将整个系统的功能大致的整理出来,然后去了解系统的数据走向。再去去体验整个系统(要带着不同角色去体验,因为不同角色的权限都是不一样的,要知道哪些角色对应什么权限,他们都是做什么的),你要把整体的角色所对应的业务都去走一遍,因为B端产品的业务跟系统都是比较复杂的,需要用心去了解他。
需求分析
在熟悉了业务跟项目以后,我开始小试牛刀了,我们上司,安排我做了一个视频检测系统,大概的功能就是检测我们公司安装在别的地方的视频能不能用,有没有出现异常,可以让我们及时发现他出现异常并及时修复。
这个时候我们前面做的事情,也就是了解业务跟项目起到了重要作用,因为你如果不了解业务跟项目的话,你就真的不知道这个功能要做成什么样,虽然是叫视频检测系统,但是不是用一个简单的判断他有没有出现异常就可以了,他还包含了很多业务的问题。
我是软件工程专业毕业的嘛,之前在学校因为做了挺多小系统的,所以说对于软件的设计会有一些心得,但是就是因为这些心得,让我把整个功能想的太简单了,经过一版一版的设计,一版一版的驳回,这个时候我才意识到业务的重要性,如果不了解这个功能的业务,那个需求分析是做不好的。以下是我我带你了解整视频检测系统的需求分析。
- 首先要了解这个系统是建立在什么背景下被提出来的?
背景:因为公司目前在学校、供应商、货车等地方安装了一些设备,这些设备有时候会出现问题,但是我们这边不知道他是否出现了问题,需要我们人工手动去排查设备是否有出现事故(抓拍异常,温/湿度异常,轨迹异常),由于需要手动去排查有没有异常,这大大增加了运营人员的维护难度。现在需要一个功能来帮助工作人员来排查这种情况。排查出设备有问题以后,运维人员可以根据上面的信息打电话给安装公司,叫安装公司过去维修。
知道了这个功能的需求跟业务以后,你还要结合整个项目的业务才能更好的去分许他,比如,怎么去检测这个货车里面的设备,什么时候会出现异常,怎么判断他会出现异常,会有哪几种异常等等,还有一点常识是学校会有放假的空白阶段,在这个阶段学校会断电断网,使得学校的监控器出现离线的情况下,那么这个时候我们要去判断他这个设备是异常的嘛?显然不是,如果你不了解业务,不知道学校放假后整个设备没去用它导致他处于离线状态,那么你设计出来的功能显然是不会完整的,所以,需求分析这个阶段是最终要的,你需求理清楚了以后,你在后面的功能设计就可以根据你理清楚的需求去做,思路一下子就出来了。当然,这是基于你理解业务的前提下。
- 当你理解了背景以后,就要思考,他们在没有系统之前是怎么进行这个操作的?
背景出来了,那么你现在要做的就是去了解他们在没有这个功能之前是怎么做这件事的,把流程画出来,画出来以后,最好先问一下运维看看是不是这样使用的,有没有什么漏掉的流程或者是不是这样做的,这很重要!!!!!如果流程错了,那么后面的不用看,基本肯定也是错的。最后我们画出了完整的流程图,然后就可以去思考这个存在什么业务问题,有没有什么好的优化方案。
比如我做的这个发现的问题的其中一点:
想要发现设备有没有问题,需要人工手动点进去查看设备是否正常运转,随着业务的增加,想要去检查所有的设备几乎不现实。看,这就是存在的问题之一,那么就要想办法去解决他了。
- 接下来就是,想象一下你做出了这个功能,那么他们是如何使用这个功能的呢?
使用这个功能的可能只有一个,也可能有多个,B端系统面对的人员会比较复杂一点,所以你这里你就要清楚的知道哪些人对应着什么样的权限,都得写清楚,否则整个系统会乱作一团糟。当你把这些都写完以后,就可以跟你的上头汇报了,他会给你评审,然后给你看看你的需求有没有漏的,没有的话就可以开始进行第二部,功能设计了。
- 总结
学到了这,也该放松放松啦,做个总结吧!
- 首先就是对这个功能进行背景分析,要知道为什么需要它
- 要理解这个业务的流程,画出流程图,考虑它的细节
- 总结出这个业务存在的问题,思考解决他的办法
- 将解决办法融合在一起,想象出功能的使用场景
功能设计
当需求分析做完以后,对于功能设计也就简单多了,因为功能设计本身就是根据你的需求分析来做的。只要一个表头,你就知道大概要怎么做了。
注意事项:
- 首先页面后面要整合好,这个页面的功能要包含在这个页面里面,不要这边放一个,后面放一个,要做到整体性,这样开发看起来才不会那么乱。
- 功能描述细节要写清楚,后面的文档需要根据这些来,如果功能描述都写不清楚,那么开发出来可能会不尽人意,比如开发看懂60%,剩下的40%他就会按照自己的理解来,可能后面开发出来就不是你想要的效果了。
- 功能设计最好坚持高内聚低耦合的原则,这样后面会比较好维护。
我的认知大概也就到这了,后面对于这块理解更深了我在单独发布一版新的功能设计模块嘻嘻。
原型图
其实跟上面的比起来,原型图可能是最好学的了,我们公司用的是墨刀,大概去网上找一下教程,花个一上午你就可以完全掌握了,其实学原型图不需要学那么深,大概能画出界面,简单的交互会就可以了,其他的啥复杂功能完全没必要去学,因为后期制作成本有点高。
原型图画出来以后,可以用批注把各个功能描述清楚,开发在开发的时候大部分都是看原型图来的,要是原型图批注写的好,开发可以省很多时间。
注意:
- 画原型图的时候千万不要随便使用插件,因为整个系统会有些复用组件(这个可以节省开发成本),也要保持界面的一致性,所以这个时候你对公司系统的了解也就起到了作用,需要用到比较特别的主键的时候,你可以去公司系统中截图,然后放到你的原型图里面。
- 字体风格要一致:不要这边字体大小16,那边字体大小18的,这样看起来很有维和感,字体大小样式最好根据系统的来,不要自己自创风格。
评审
最后一步就是评审了,其实我也还没到评审的这一步,但是我姐首先先给我评审了一下,教我怎么介绍这个功能,然后给我指出了很多错误。
首先,你先介绍一下这个项目的背景,然后可以介绍一下这个功能一些不易理解的。比如我这个是判断监控器异常的,但是有包含哪些异常,什么时候报这些异常先讲一下,然后开始讲流程图,记住,流程图要写清楚!!!!
我刚开始画了一个流程图,给大家看一看:
这个是之前我在学校学习的时候,流程图的画法一般就这样了,我还没反应过来,虽然要不可能马上就画的很精细,但是我会努力的,经过姐的点播,我终于画出了比较完整的流程图了。
好了,整篇文章大概就介绍了样了,希望跟我一样还是刚入产品坑的产品助理,跟我一起努力吧!
大神如果看到了,如果我有哪里写的不好或者哪里写错了,感谢指导一下,非常感谢,我会更加努力的。
来自一位刚入门的产品小坑货。