在小公司当产品总监是一种什么样的体验

写下这篇日志时,我已经离职快两个月了。

是的,我也没想到会这样,从去年至今互联网行业动荡会这么大,以及,疫情的影响会这么大。我才换了新工作不到一年,就又要换了。

去年从在线教育行业出来后,我选择了这家公司(以下简称为A公司),属于家政O2O行业。由于对双减政策出台后行业团灭的惨状心有余悸,当时我的想法是,至少国家不会打击家政行业,因为这是一个能促进劳动力就业的行业。另外,和A公司老板面试沟通后,你说是洗脑也好,画大饼也好,反正我相信了这家公司的团队是OK的,业绩是整体往上走的,前途是光明的。

老板最终给了我一个总监职级,这倒是我没预料到的,因为他们当时挂出的产品岗也不是总监岗。老板说,公司发展很好,他想扩大规模,需要这么一个职级的人来帮他搭建产品团队。

于是我就突然成了一名产品总监,只是要加一个定语:小公司的产品总监。

我说的“小公司”是相对而言的。我没在BAT等万人乃至十万人级别的公司待过,不过我也待过几千人(高峰时也快破万)规模的公司。就深圳IT行业而言,几十人规模的公司很多很多。A公司虽然有五六百人的规模,但我刚入职时,产研才个位数,所以我还是将其定位为小公司。

在小公司搬砖就要有一些觉悟和心理预期,对吧,不能直接按照大中型公司的套路来。

话说回来,为啥小公司喜欢从大中型公司挖人,很大程度上,也正是因为从后者出来的人,见多识广,知道如何帮助小公司往上走。所以,一些可以复制的套路,还是可以搬过来用一用的,例如规范化的需求管理流程等等(如引入语雀、TAPD)。

刚入职时,我面临的是这样一个局面:

  • 产研总人数加起来不到10个人
  • 技术栈为PHP,总体技术水平堪忧
  • 技术负责人管理能力欠缺,难以驱动研发成员
  • 测试人员严重不足,完全没有测试用例
  • (基本上)只有一个大而全的后台系统,前后端不分离,耦合严重,性能不行,动不动就挂了
  • 用户端体验很糟糕
  • 业务发展迅猛,业务需求很多,产研承接不过来,业务方颇有怨言
  • 双十一大促即将到来

上面这张图可以总结当时的基本情况,总之,我压力还是很大的。

在和原来的产品小组长聊过几次后,我又花了一两周时间,找各个业务部门的负责人或者一线组长聊天,了解公司业务全貌。

这个聊天的过程,还是挺有意思的,值得展开说说。

首先,面对一个空降的产品总监,业务部门同事还是满怀期望的,他们会和我吐槽很多,也会直接提一些产品需求。不管后续做不做,以及需求是否合理,至少我都要记录下来,表现出足够的重视,以及适当承诺说后续会有改进的。

其次,聊天的这个过程,也是发现公司内部问题所在,以及了解部门之间利益冲突的好时机,所谓旁观者清嘛,毕竟我是新来的,啥都不懂,可以较为客观地评估现状。我发现,供需两个大部门的矛盾还是挺明显的,以及被夹在中间的交付部门,也是一肚子火。

再次,聊天也是快速拉近客情关系的机会。无意中发现这里有不少来自B公司的人,刚好前几年我在B公司也待过,于是一来二去,俨然我也自动具备了“曾在B公司的前同事”身份,亲近感+1。说到这点,我想表达的是,圈子真的很小的,当你在一个城市,一个行业待得足够久,你会发现,换了一家公司工作,很大概率会遇到前同事,或者前同事的前同事。所以说,职场口碑也是很重要的,我也一直信奉做人留一线,事后好相见(哪怕是面对故意搞我的人,我也维持了表面的和平)。

了解完现状后,作为总监,我得给出老板想要的整改方案,短期的,以及中长期的那种。

短期方案:

1、系统压力测试

双十一快来了,系统动不动就挂了,这可不行,我们要对系统性能上限心里有底,至少做一次压测吧。压完后,按照预估的大促流量,提前做好性能优化工作。双十一系统要是挂了,我们就得卷铺盖了。

2、信息安全相关需求优化

这边后台系统做得很粗糙,没有啥安全可言,登录账号、登录有效期、后台水印等,统统给优化一顿。说实话这些工作难度不大,但是效果立竿见影,属于领导喜闻乐见的(信息安全嘛,必须重视对吧)。

中期方案:

1、新的权限系统

我刚到公司,很多人就来问老系统何时能重构?这事儿急不得,重构会占用很多人力;但,也得有个路线图。我的计划是,先全新做一个权限系统(包含内部账号、应用管理、资源配置、角色管理等),作为重构计划的基础:后续所有系统都会使用此系统进行资源配置和权限管理。为啥第一步是先做权限系统?还有一个重要原因,是因为老系统自带的权限配置功能过于反人类,而且一大堆历史问题,导致整个公司只有测试经理一个人知道如何配置权限和角色。

另外,基于统一的授权登录机制,还搞了一个系统门户聚合入口,方便系统拆分后从统一页面找到自己想要访问的子系统。

2、拆分出独立的客服工单系统

权限系统毕竟不是偏业务的系统,平时是产研用得比较多,既然要重构了,总得搞一些业务系统吧。我仔细调研了一遍老系统后,发现里面有个客服工单模块,比较简陋,但客服部门同事的需求并不少,如自动派单之类的,想往上面继续迭代。

客服工单?好家伙,这是我老本行呀,早在几年前我就做过类似项目,这不轻车熟路嘛。

研发同事,尤其是新入职的,都表示,不要往老系统叠加太复杂的功能,老代码实在是改不动了。

于是,说干就干,我决定从老系统把客服工单模块拆分出来,做成一个相对独立的新系统。

前面提过老系统是基于PHP的且前后端不分离,我要求新系统一定要前后端分离开发,刚好让新招聘进来的研发同事练手。

吭哧吭哧,第一个试水性质的业务系统就这么搞起来了,客服部门同事很满意,总算有自己的专用系统了。。。期间也暴露了不少新团队成员磨合、新旧开发模式转换的问题,不过这是好事,暴露问题才能有针对性地改进,对吧。

长期方案:

1、老系统核心模块重构与解耦

从产品的角度看,A公司这些系统对我而言,唯一有挑战性的就是核心的库存与派单模块了。这块业务经过几年的魔改,已经没法继续维护和扩展了。想动它,也存在困难,类似于,怎么说,开着飞机换引擎?因为你不能直接把业务给停了之后去重构哇,线上业务还是要继续跑的。核心模块与其他模块耦合严重,也不是说拆就能拆。

办法总是有的,就是需要投入足够人力和时间,以及准备好足够完备的重构方案。

2、按服务能力拆分子系统

除了上面重点提到的核心模块,老系统还有其他很多功能要处理。我的总体思路就是把老系统里面的功能分类拆分成多个子系统,大致就是下面这张图的意思,当时为了给领导汇报我简单画的:

虽然我给出了以上总体规划,但在产研人数只有个位数的前提下,你是不可能一边重构老系统,还能兼顾新业务需求的。加人,是一个很自然的结论。

按照公司五百人规模计算,产研比例10%不过分吧?老板也算是展示出对产研发展的重视态度,一直强调让我们做好组织建设,尽快增员。

于是,我招来了几个产品经理;通过个人关系,我也挖来了之前我待过的C公司的一个技术负责人,来A公司当技术总监。高峰的时候,产研总人数有40+。

技术总监来了之后,效果杠杠的,无论是研发风气的改善,还是整体效率的提升,都肉眼可见。

老板对产研干预不多,基本就是放手让我和研发总监自己做的意思,偶尔指导下。

短短几个月时间,我们上线了一系列的新系统,也对老系统打了N个补丁,还对客户端(小程序)用户体验做了一次专项提升,以及实现了数据埋点(以神策为用户端数据采集来源,配合后端系统自有数据搭建了离线数仓)等,支撑了业务的高速发展。春节前连续连两个月,公司销售业绩创了历史新高。

应该说,我们产研仅有的这几十杆枪,在公司架构频繁调整、业务频繁试错和变化、资源极其有限的情况下,有这样的产出,我个人给出的评价是:很不容易。

年底,公司在海边包了酒店,开了好几天的闭门战略会议。大家都很兴奋,为来年定了很高的目标,斗志满满。

当时,一切都挺乐观的。我和研发总监说,按照公司这个发展速度,看来咱们的百人产研规模指日可待呀,将来从这里出去了,也能吹嘘说咱们是管理过百人团队的。

春节前,深圳开始出现散发疫情,我们以为这只是暂时性的困难,很快会过去。

没曾想到,年后深圳疫情到了封城一周的严重程度;以及,上海后来发生的事情,大家也都知道,我就不多说了。持续几个月不断的疫情,给A公司业务造成了沉重的打击,毕竟家政这种服务是重度依赖于线下交付的,你都没法上客户家去,咋开展业务呢。一方面公司无法给客户提供服务,另一方面,疫情之下消费者信心下跌购买力下降,随之而来的客户退款也是持续增加。

疫情只是公司经营恶化的直接原因,根本原因还在于公司的经营策略方向问题,这里我就不展开描述了,后续有空再细说。

总之,原本我们打算618大促冲击一波,再上一个阶梯的,谁知到了五月底业绩还是持续低迷。

A公司开始拖欠社保和薪资了。当时看这个阵势,我预感,A公司已经是无力回天了。

过完端午节,我提了离职,很快就办完手续走人。可能,看到这里,你是不是会觉得,有点轻描淡写,就这么走了?实际上,促使我离职是有多重原因的,限于篇幅,我就不展开了。

七月份,我在家里刷到新闻:A公司宣布资金链断裂,开始清算。不少坚持到那一刻的同事,才意识到真的剧终了。失望,愤怒,后悔?估计各种情绪都有吧。离职讨薪群里,信息不断滚动。和被欠了三个月工资的同事相比,我只被拖欠了一个多月,我是应该表示庆幸呢,还是说其实我应该反思下,为何我没有更早离开?可能还是心存侥幸,觉得不至于发展到如此地步?产品是好的,市场是有需求的,只是公司搞砸了?

闲暇时,回看去年公司周年庆时的照片,那热闹的场景,恍如隔世。

时间过得真快,一年又过去了。刚刚结束的这份工作里,我得到了什么,又失去了什么?确实值得好好总结下。

“在小公司当产品总监是一种什么样的体验”的2个回复

发表评论

邮箱地址不会被公开。 必填项已用*标注