岗位成就 —— 职责之外的探索

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证是一个完整的故事,但不可避免会有些前后关联,毕竟这是一个成长的过程。

我的岗位是企业内部产品经理,在这个岗位的本职工作上,很长一段时间,我都找不到所谓的成就感,而在岗位职责之外,却意外发现了一些惊喜。

企业内部产品经理,所负责的产品通常都是企业内部系统,用户是自己人,通常是主营业务的部门。它们会针对自己的实际业务,对企业内部系统提出需求,我们要做的就是去了解它们的实际业务(需求分析),产出系统功能需求文档(PRD),然后在各个部门之间进行协调,在一定的时间内,完成这个事情(项目管理),满足业务需求(产品交付)。

我最初负责的产品是 ERP 系统生产制造业务模块,大多时候的工作都是业务流程梳理,以及系统的业务运维,而一旦熟悉了这块的业务,整个工作流程就显示比较单一且枯燥了。

大公司的业务细分程度通常比较高,如果自己不去寻求改变,或是有所突破的话,很有可能好几年都在一个岗位上,干着重复劳动的工作,身边有太多这样的例子了。

在第二年的时候,我就渐渐感觉到,对这个行业似乎不是很感兴趣,很难深入到业务的根本,有一段时间,我找不到工作的成就感。

从马斯洛的需求层次模型可以看出,现代社会的我们,更需要的是「成长性需求」。

马斯洛需求层次模型

那时的自己应该处在「尊重需求」这一层,也就是「内在价值肯定,外在成就认可」,而这个岗位的本职工作,很难有所谓的外在成就,而其内在价值我也一直没有找到。所以,那时的自己,想要去做不一样的尝试。

最开始提到的,利用静态博客站点的技术,搭建内部知识库,就是自己对「尊重需求」的探索。

这个尝试产生了一些正面的反馈,直属领导的肯定,应该可以算是这个岗位上的成就吧,即便它并非是主要职责工作。

如果直属领导的肯定,只能勉强算作是岗位工作成就的话,那么下面这个事情,肯定算是岗位的成就了。

当时,我们的研发岗位都是聚焦在显示技术领域,而非 IT 信息化,研发岗位的工作有一项重要的 KPI,那就是专利。

我们并不属于研发序列,我们组织的工作,最初的定位,更多充当的是辅助的角色,辅助主营业务做信息化的转型,提升业务效率。

后来集团对信息化的要求越来越高,信息化组织从辅助的角色,慢慢变成领跑的角色,不再是满足业务需求,而是要带领业务,走信息化的道路。其实,这个观念的转变,我们算是起步较晚的了。

对于一线的员工,其实看不出有什么明显的变化,唯一能感受到的是 KPI 添加了一项,那就是要写专利了。

正好那个时间点,我正在鼓捣静态站点的事情,静态站点的优点是无需开发,快速部署,非常适合单方面的展现类网站。但缺点也很明显,页面无法动态更新内容,例如博客中,文章评论等功能就需要借助第三方来实现。

基于对这个事情的琢磨,顺便就写了一篇专利,顺利通过了公司的审核,后来还获得了国家授权,在我离职后,公司的专利专员还在联系我,说在申请美国的专利,需要我确认一些信息,这个对于我来,绝对是意外的惊喜,并且是「名正言顺」的岗位成就,比我做的那些信息化的项目,更加受领导的关注。

我写的那份专利,应该是我们组织有史以来第一份通过国家授权的专利,后来,基于这个思路,我又写了第二篇专利,依然是围绕静态站点的那些问题,提出的一种一体化解决方案,当然前提肯定是在专利网站上查重排除过的。

这篇专利花了我更多的时间和精力,自认为提出的创新点要比第一篇要好,可是,被自己组织内的「专家组」给拒了,被拒原因不详。

随着我们组织专利提交数量的增多,集团的专利部门应对不过来了,于是,我们组织内部成立了「专家组」来做第一层的筛选工作。

所谓的「专家组」并不是专利领域的「专家」,也许他们自己一篇专利也没有写过,还不一定熟悉专利要求呢,却有权利去评价别人的专利是否符合要求,而且还是匿名反馈,感觉这个就有点「社会」了。

被拒之后,我没有去申诉,也没有再重新提交,因为我不清楚哪方面需要修改,再后来,我调岗了,也就把这个事情淡忘了。

在人生第一份岗位上,把应该做专业的主要职责工作,做得有些业余了,却把业余的工作,做出了点成绩,也是一件奇葩的事情。

但是,我依然觉得这是一件值得的事情,重点不是专业和业余的问题,而是你要尽早知道自己的「专业」和「业余」分别是什么。