工作过程中,专业技能没有那么的重要,最重要的是解决问题的能力。
从八月份开始接触onesdk,到现在快俩个月的时间。从零了解到现在熟悉了基本的流程和业务,学习的时间有些慢了。在这个过程中,也认识到自己的好多问题。
onesdk分为三个模块:客户端、打包工具、官网(前台、后台)。第一月,我的关注点只在打包工具和官网的前台展现上,具体的实现以及整个产品的认识(产品整体方向和三个模块联系)都没有去深入了解。以至于作为onesdk的产品经理,对整体产品都不了解。第二个月,leader在产品会议里面拎出我来:你对产品的整体规划一点都不了解,具体每个模块的进度也是未知。其实事实的确是:就算是单纯的前台界面也没有做的很好,前期和team沟通严重不足。
后面这几周的时间,我尝试去梳理整体的业务流程。产品的整体规划,产品时间节点,去和技术沟通具体的实现细节以及一些不明确的需求,每周尽量去确认相应模块的时间节点和任务状态。
list一下最近的处理方法,这样解决问题还是比较高效的:
1、专注产品,关注产品的目标。
2、完成产品规划表,列出产品任务(待处理事项)优先级清单以及相关配合部门
3、发现问题,找到关键节点,积极主动解决
4、找到问题相关责任人,具体落实问题细节和交付物
5、在交付时间内落实交付产品及质量
6、调整已完成清单列表,重新梳理优先级列表
7、及时根据产品运营和后期规划的变化调整产品计划表
过程中遇到的问题及我犯的几个错误:
技术类问题:由于是一个技术类工具,前期参加产品技术会议的时候,我对具体的细节处于不知状态。框架实现,具体参数,细化功能...后面和技术沟通了之后,才明白具体前台展现如何。解决:及时和技术沟通,不懂实现无妨,但是要明确前台展现,以及和其他模块可能的关联关系。
需求类问题:工具类产品大体的需求方都是技术研发类需求,作为产品的我筛选需求的较少,主要集中于页面的呈现和流程的优化。但是产品的流程优化方法,不一定适应于技术的实际操作,好些矛盾。解决:提供几个选择,供技术选择。
UI类问题:前期是借鉴其他产品,所以功能和UI相似的概率比较高。在网站和工具的设计过程中,第一版本是参考其他,整体团队的反馈都说太相似;后面UI从新做调整,也跳不出相似的框架来;以至于UI要求我换人从新设计(我也无奈了,和UI沟通的时候:发现自己有时候仅列出一个框架,所有的形式都要UI去构想,但是这样的做法,仅适用于部分UI人员;大部分的UI都只会去按照原型做东西,基本不会有太多自己的想法)。解决:现有团队,尽量细化原型细节点。
运营沟通问题:1、前期基本上没有和运营沟通,后期涉及推广的时候,也是leader的提醒下,我才去主动和运营沟通产品细节,这一块,太失职了。2、作为产品,在整个产品过程中,没有做到主动去主导整个产品的过程。运营介入了之后,从命名到产品规划,从外界看,都是运营在主导(其实作为一个技术工具类产品,运营只是产品的辅导)。3、运营其实对产品的了解不足(因为当前产品较多,运营对各个产品的区别都不是很了解),这个是整个产品部门的缺失,对整体产品的划分不明确。解决:产品应该主动整个产品,list出产品线内容、让运营明确不同产品推广规划和集合点。
和leader的沟通问题:前期对于页面策划和设计图,我都是具体完成了,才去汇报沟通;其实几次的汇报下来,效率极低而且修改很多。解决:原型或者UI有初期的效果之后即可确认或者评审,在边做的过程中边调整。后期的汇报的沟通的过程中,大体的工作及时汇报;每周都做产品的汇报。
关于产品的问题:作为产品,我的大部分时间都在:项目进度跟进和现有产品完善,对于产品下一版本的规划想法很少。而且一直以来,对新产品的敏锐度、对行业发展的嗅觉、如何商业化这些思考的都不够。解决:及时根据需求的反馈,做好下一个版本的迭代规划和计划;多关注一些行业内容,切实到每周做一项相关行业分析报告。