破解互联网企业的“规模化魔咒”

"一个周二的午后,我和团队在会议室里讨论一个招聘管理系统的客户刚刚提出的需求,他们在人员编制管理功能上遇到问题。在我们分别讨论了外企业遇到此类情况下的不同解决方案之后,却没有发现可以借鉴的经验,但产品经理小东眼前一亮,提出了如下解决方案:即通过与招聘系统打通的核心人力系统来控制编制(出现人员流失,编制就会自动发生变化),同时用同一个职位下不同招聘计划的方式来显示新增的招聘数量需求,这个方案终得到了客户的高度认可,研发团队随即着手在一周之内就将新功能交付上线。"

 

这是一个如今在北森每天都会发生的工作场景:产品经理在获得客户需求的时间迅速找到相关的技术人员进行小规模探讨,即使不用我出席,也没有复杂的评审,只要参与讨论的几个人觉得解决方案可行就可以动手开发,然后快速交付客户,并在客户使用过程中再持续优化,我们称之为敏捷开发、快速迭代。

 

但是,同样的问题,在几年前的北森却是另一番景象:由于单个产品功能不断完善,加之产品线不断延伸,我们的研发团队迅速扩张,原有灵活的小组织单元一跃成为了多层级的复杂结构。按照传统的模式,一套软件的研发,需要很长时间来整理需求、设计、再评审、排期、开发和上线,这一套流程通常需要一两年,至少也要半年。即使是一个小功能的上线,研发人员也要准备极其详细的产品介绍和功能演示,然后要经过技术、产品、客户服务和战略层的高负责人非常细致地论证和评审。于是作为CEO,我每天的日程都排满了各种各样的评审会。这样的评审会一开就是好几天,后常是各种争吵,让人心烦意乱。糟糕的是,由于参与评审的我们时间都花在了内部,并不清楚一线客户的实际需求,终选中方案交付给客户的时候也未见得是优的解决方案。而当行政权力代替了技术权力,大家都把心思放在“对付”我了,反而没有人真正对客户负责,不用为结果负责,也就没有心思创新了,公司陷入了一个恶性循环。

 

我相信很多经历过公司从初创期向快速成长期迈进的创业者都有过类似的困惑:如何能够在企业迅速扩展的过程中,用合理的组织形式来避免小公司过早患上大企业病,保持公司对市场和客户的快速反应,让内部员工花多的心思关注客户和寻求创新呢?   

 

2002年我和高中同学王朝晖创立了北森测评, 2010年,随着业务延伸到了人才管理SaaS领域,北森的发展也逐渐进入了快车道。的“北森云计算”已经是一家近千人规模的企业级互联网公司。北森一直在外部市场牵引的“规模化”过程中,不断权衡着“灵活性”与“规范性”的抉择,所幸也逐渐摸索出了一些经验。我们发现组织内部不同职能规模化的本质是有差别的,因此在他们对于规范性和灵活性的需求程度也是不同的,于是也就衍生了实现规模化的不同路径。

 

完整内容请下载PDF文件




下载
咨询 帮助