全面发展 —— 职业生涯高光时刻

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

接上一篇,这篇文章介绍,我一个人历时半年多时间,开发的那个运营数据平台。

先回答一下,上一篇文章提到的几个顾虑点:

Q:你的本职岗位工作怎么办?占用自己的时间?

这个问题不大,直属领导对我的工作还是默许的,原本也只要求我用一半的精力来做运营的工作,所以,这个项目的开发还是有时间保障的。

况且,自己想干的事情,也就无所谓工作时间还是业余时间了。中间有段时间,为了提高开发效率,我甚至把家里的 Mac mini 搬到公司去了。

Q:万一你做不出来,怎么办?这不是闹笑话吗;

最开始,我是基于财务经理的痛点需求着手的,起初只是实现财务数据信息化的功能,并没有一开始就规划得很大很全,所以,整个项目的开发,都在能力范围之内。

对于不熟悉的技术点,都是现学现卖,这种状态下,效率出奇的高。

Q:万一你做出来了,领导不认可怎么办,觉得你浪费了人工;

这确实是个问题,也的确发生了,不同的是,领导认可我的人,但不认可我做的事,这件事,也让我有了一些思考,后面会专门再谈到。

Q:这不是你的本质工作,你做了这部分工作,产品部门的人怎么想?开发部门的人怎么想?

这个就有意思了,我做一半的时候,「正规军」终于开始启动了,然而,最后的结果是,他们的项目还没上线,就被砍掉了,我写的现在还在服务器上跑着呢(写这篇文章的时候,我还专门去看了一眼,一切照旧)。

当时觉得所在的运营中心有点苦逼,而留下来的彩蛋

至于别人怎么想的问题,是我想多了,大家其乐融融,开发过程中,还互相交流借鉴了下。

也许在别人眼里,工作仅仅是工作而已,你愿意干,你干呗,你干了,省我心了,何乐而不为。

开始之前

入手去做这个事情,其实非常简单而自然,没有太多的曲折。

就像之前做的几个信息系统一样,了解用户痛点,挖掘需求,产品设计,开发,测试,上线部署。

而这一次工作的开展,似乎更加的顺畅,原因有二:

一,直属领导是默许的,希望我去做一些改善工作,况且她给了我一半的自由时间,我不必陷入琐碎的运营工作,而无法自拔;

二,财务经理在跟我抱怨的期间,也渐渐跟我熟悉了起来,对于用户需求,我可能是最熟悉的了,比之前的产品经理,要了解得更多,更深入,况且,我自己本身也是半个用户,因为我有一半的时间,也在做项目运营的工作;

在那段时间里,我非常强烈的感受到自己工作的价值,我甚至妄想过,我一个人,正在做着价值上百万的项目,最后这个软件可以成为公司不可或缺的一部分。

产品规划

对了,这根本不是公司正规流程下的项目,正规流程的那个项目,还停留在审批流里呢。

这是我一个人在做的项目,可以没有所谓的项目管理,但是,产品的规划还是要有的。

这里产品规划首先要明确其定位,以及要做的范围,最后,根据规划的功能点,排优先级。

优先级非常重要,既要保证开发有条不紊,还要尽快出效果,因为,即便是支持你去做这个项目的同事和领导,也等不你太长的时间,

这里又不得不提到,最开始做产品的基本原则:一定要基于足够明确的场景,满足一类用户的某个痛点需求,以最快的速度上线,然后迭代。

放到这个项目来看,场景、用户、需求都足够的明确,那就是,财务经理收集汇总运营数据的困难。

痛点需求

目前的工作流程是,运营经理每结束一个运营项目,就将该运营项目所产生的成本费用明细,以 Excel 的形式 ,通过 email 发送给财务经理。

当时,我们每个月大概有十来个项目,分散在不同的运营经理身上,每个运营经理在月底之前,就会通过上述方式,将费用明细发给财务经理。

财务经理每个月整理月报的时候,都会在邮箱中收到十几份不同项目的费用明细表,然后汇总,整理出财务月报(成本,收入,利润等报表)。

等等等等,事情没有这么简单。

还记得前面描述的项目管理的例子吗?每个月收到的邮件数量可远远不止十几份这么简单,至少要 triple(三倍)一下,当然,这个 triple 的过程,少不了各种沟通环节。

等等等等,还没完。

汇总数据也不是简单的复制粘贴那么简单,还需要考虑各种格式样式等问题,别跟我说「你不知道做一个标准格式的模板吗?」这样的话来,要是人与人之间的协作,能够通过一个口头标准就规范了,也就没有那么多约束存在了。

那么多有权威的「国际群」,美国还不是说退就退,一个国家尚且如此,更何况某个个体,你说是不是呢?

类似的,财务经理和运营经理之间的摩擦,更是不在少数,大家碍于在一个部门,平时没有发作而已。

这真的太正常了,也很容易理解,前台运营经理提供的数据问题,最后会全部压在后台财务这边,因为财务要出报表呀。

所以,财务要想办法解决这个问题,除了一遍一遍的强调标准规范,那就是「不合规范,拒不接受。」

有没有一种似曾相识的感觉,你在做报销等财务业务时,是不是也被公司财务的一些制度给「恶心」到,没错,它们如果不「恶心」你,就得「恶心」自己。

所以,抱怨的时候,不妨换个角度,站在对方的角度想一想。

每次写到效率低下的那些问题时,总是滔滔不绝,也许工作这么多年,这是我痛的领悟吧。

开始做了

定位、范围和具体需求了解清楚之后,接下来就可以开始干了。

这类产品的开发,有它的固定流程,通常都是产品(功能架构、信息架构以及数据库设计)、设计(原型、视觉、交互)、开发(前台、后台)、测试(接口、功能)、部署等。

而如果是独立开发的话,中间就会省去了很多的环节,例如:原型设计,甚至是视觉设计等。

下面简单说下,各个环节,我都做了些什么?又省去了什么?

产品

我认为这块是重中之重,为了避免后期的反复修改,这块的工作一定要做全了,可分为三个部分:

第一,功能架构。可以通过脑图工具,把产品功能结构绘制出来,越细致越好,不要担心浪费时间,这里省了时间,开发那就会浪费时间,开发还是你做,何必呢,是吧。同时,即便是前期不做的一些功能,这个阶段也要考虑到,尽量预留出相应的接口和设计,便于后期的扩展。前面产品规划的时候,也谈到了,这里尽量全,然后再排出优先级。

第二,信息架构。这个通常要描述清楚,某一个功能,需要展示或是用到的信息元素,例如,我这个项目,要做项目成本的功能时,就要把项目成本包括的所有成本元素都列出来。这个跟业务的相关性就非常大了。

第三,数据库设计。前面功能架构和信息架构想清楚了,数据库的设计,就是水到渠成的事。这里需要注意的是,表与表之间的连接关系,表结构如果没有设计好,后面开发会很头疼的。

设计

这一步一般由产品设计师来做,再细分一下,就是原型设计师、UI 设计师以及交互设计师。都是一些比较专业的细分领域了,谈到设计师,一般都是要带创新意识的。

在我的认知里,这些岗位都是高大上的存在,而现实情况是,很多公司的设计师都沦为了「美工」,当然这跟大环境也有很大的关系。这个话题以后再说。

对于独立开发来说,这一步基本上就省掉了,省掉的原因有两个:

一是,确实没有能力来做这个事情,如果花时间做了,可能会适得其反;

二是,对于企业内部产品,这不是重点;

所以,我的做法是,找一个第三方的模板套用一下,直接就解决了界面布局、视觉效果以及交互的问题,最终的成品效果还是不错的。

这是我当时使用的模版 AdminLTE.IO,首页如下图所示:

开发

开发虽然是最重要的环节,但是,不是花时间最多的环节。因为几乎都是在使用别人的框架来搭建功能,然后就是数据库的增删改查,你说,我一个产品经理都能做出来,能有多大的难度。

前台开发,由于选用了 AdminLTE 作为模板,开发框架以及技术,基本上就定型了,那就是 jQuery + Bootstrap,虽然有些古董了,但是在这里,并不重要。

后台开发,直接就是用 Node 了,这个我也没得选,因为当时我就会这一种后台开发技术,并且由于前面项目的开发经验,使用 Node 开发是最经济、最效率的方案。

数据库,使用的是 MySQL,为什么不用和 Node 更配的 MongoDB 呢?因为我考虑到后期可能要与内部系统对接,选择关系型数据库是必要的。

开发这一块,最花时间的是,前端页面。因为要整合不同的框架,来达到最佳的效果。另外,我似乎有一点视觉强迫症,有一点看着不舒服,一定会调到舒服为止。这可能是我作为产品经理的一个弊端。

测试

这个几乎是直接跳过的。没上线之前,基本上都是边开发,边测试;上线之后,就变成边迭代新功能,边改 Bug,边测试。

嗯,一个人开发就是这么任性,不过从现在还能用的角度来说,稳定性还是不错的,至少这么长时间,还没有崩溃。

部署

这个对我来说,轻车熟路了,整个大学生涯都在鼓捣操作系统,虽说没学到 Linux 多高深的技术,但是,对于 Linux 的使用还是不成问题的。

在 Linux 服务器上,配置必要的运行环境,部署个把项目,就跟装系统差不多的流程,按照操作手册的步骤,一步一步走就行了。

当时,是让产品技术部门的同事,帮我建了一个虚拟机,然后在数据库服务器上,创建了一个数据库,后面的事就交给我了。

运营

企业内部产品也就不存在什么运营了,大抵就是发个邮件,告知一下财务经理和运营经理,xxx 业务可以通过线上的方式来做了,当然,顺便抄送一下领导。

自己部门内推广使用,倒没有多大的问题,况且这个系统是响应直属领导和财务经理的需求而做的。

即便是再傻瓜的系统,依旧会有人不知道咋用,而不停的问你,让你不胜其烦。所以,不管是为了利他还是利己,都非常有必要写一份操作手册。

写用户操作手册,按照我的风格,我定然不会在 Word 上写的,原本我就非常反感线下办公的方式,在这个完全由我控制的系统或项目,我更是不可能使用通过线下的方式来做。

于是,顺手又搭建了一个文档管理系统,当时还写了一个篇文章:为了写操作手册,顺手搭了个文档管理系统

后来这个文档管理系统,也被组织采用了,现在还跑在服务器上。

迭代

在公司里,像这种个人项目,千万不要等到功能完备了,全部测试通过了,再上线。

因为没人愿意等你,最高效的方法就是做完一个功能模块,简单测试过后直接就部署上线。

用户在使用的过程中,自然会发现问题,然后及时修改,再上线,就这样,持续更新迭代,一个人也可以敏捷开发测试。

这样的好处有几点:

一是,开发周期周期明显缩短,能够快速获得反馈,快速出效果,快速解决问题;

二是,用户觉得自己提出的意见,很快得到满足了,更加乐于帮你测试完善;

三是,省去了埋点的工作,埋点是一种常用的数据统计测试的方法,可以借助用户的行为数据,来判断某个特性是否有效。而这里就不需要了,不确定的地方直接空着,由于与用户频繁密切的沟通,你自然会知道用户说关心的点在哪里。

高光时刻

在实现一个又一个的功能,满足用户一个又一个的需求时,我的内心得到了极大的满足,那时的自己,真心的认为在做一件非常有价值的事情。

这样的感觉, 比之前的职级晋升更有成就感,这才是我职业生涯的高光时刻。

不过在外人看来 ,我似乎有点傻,主动放弃管理职级,放弃 IT 部门,跑去做了一名培训运营。当然,如果我只是把自己当作运营的话,那才是真的傻。

只是我并没有,对于换岗位的事情,我还是那句话:

调岗后,好多之前的同事,都比较疑惑,你转行了?那不得从零开始?我回头想了想,好像并没有啊,在互联网时代,对一个学 IT 技术的人说转行了,不是很奇怪吗?现在哪个行业,不需要 IT 技术???

一个岗位并不能说明什么,也不能代表什么,仅仅只是表示你现在在做什么事情,但并不代表你将来能做什么。

恰恰是在做培训运营的这个岗位,让我找到了自己的「高光时刻」,而后又找到了自己的职业目标。

我觉得,这就是有意义的。