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

最后更新于： 2022年8月13日

写下这篇日志时，我已经离职好一阵了。

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

去年从在线教育行业出来后，我选择了这家公司（以下简称为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公司宣布资金链断裂，开始清算。不少坚持到那一刻的同事，才意识到真的剧终了。失望，愤怒，后悔？估计各种情绪都有吧。离职讨薪群里，信息不断滚动。和被欠了三个月工资的同事相比，我只被拖欠了一个多月，我是应该表示庆幸呢，还是说其实我应该反思下，为何我没有更早离开？可能还是心存侥幸，觉得不至于发展到如此地步？产品是好的，市场是有需求的，只是公司搞砸了？

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

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