第91章 转型调整
作者:八月的狮子座   IT女经理的职场回忆录最新章节     
    “鹰总,来来,请坐。今天想和你聊下我们部门组织里面的一些变动。”和我要好的综合组组长说公司里面有几个领导和我同姓,为了区分,她转而叫我的名字。她是院长的得力干将,是我们部门的“大喇叭”,因此很快地这个称呼就传开了,没多久大家都改过来了。
    “今年我们公司根据战略业务发展需要,确定我们部门要从项目型交付向以产品交付转型。因此,为更好地落实中心战略和对我们部门的绩效考核要求,我们部门的业务发展规划和组织架构也要做出调整。”他看着我一口气地说道。
    这个事情同事i和我透露过一些,我自己也听到不少从中心会议传来的一些小道消息。我点点头表示理解,但是心里还是猜不到这种转型和我有什么关系呢。
    “按照孙总的建议,我们打算把部门分成产品组织、项目组织和公共研发组织三大部分。顾名思义,产品组织主要开发有竞争力的行业产品,项目组织则基于产品交付项目,公共研发组织就是负责打造核心技术底座,打造公共组件以支撑产品和项目组织。”
    嗯,中规中矩的组织架构。基本上外界有一定规模的软件公司都是这么干的。我心里默默地想着,点点头表示认同。
    “s总说做产品需要持续的投入,需要不断地积累经验和做迭代升级。因此我们现在这种开发组织模式不再适合了,他建议每个产品要固定下人员以支撑产品发展。固定人员这一点我记得你以前也提过。”
    “是的,不过那时候你说经营压力太大,没办法固定人员。”我心里想,职位高说的话就是不一样。
    “是的,我们部门的人均产能不高,离领导们的期望差了不少。”
    “那现在调整,把人员固定在产品线,人够用吗?”我心里想,以前单独做项目人都不够用,现在这样的调整方案,人更加不够呀。
    “人肯定是不够的。但是产品体系还没完全确定下来,暂时先不招人。不过我们部门有个初步的方案,需要把你下面的部分研发人员分去产品组,剩下的人做公共支撑平台。”他把显示器扭到我这边,给我看新的架构图。
    部门调整方案将部门分成三大块,项目交付部、产品部和软件平台部。项目和产品板块分别由两位副院长负责。产品部则把部门这两年做过的项目分成了三大产品线,有交通行业特有的产品线a,近几年新贵的产品线b还有和部门引以为傲的老牌产品线c。相应地,项目部也分成模型类项目组,集成类项目组和软件类项目组。软件平台组由我负责,包括中台组、用户体验组(ui升级版,s总改了个外界流行的名词)和测试运维组。定位为向产品线输出中台支撑能力。
    另外还新增加pmo(项目管理委员会)这个虚拟组织,每月定期召开项目的决策会议,以全面把控部门的项目质量。加上综合服务组,让人不禁感叹“麻雀虽小五脏俱全”。
    “这是我和xx(另一个副院长)根据开发人员之前做过的项目情况,先定了个初稿。”他指了指产品线里面分配的那些开发人员。“你看看有没有什么问题?”他又指了指我将要负责的软件平台部,“你结合平台部的人员一起也看看。”
    我快速地扫了一下,心算着:调整后,原本三十人的软件研发部拆分出三分之一的人去了产品部。
    “我仔细看看,不过我觉得也要尊重下开发人员的意愿。”
    “对的,你也可以和他们聊聊。有调整明天中午前告诉我。我打算明天下午和s总汇报。”
    中午,我找同事i约着一起外出吃饭,想顺便问问他们部门那边的情况。
    “你部门也要调整吗?”不像我后面才升职,他从入职起,他的部门主任都会带着他出席那些和公司高层的会议,因此他对我们部门的调整也有所了解。
    “没你们那么大。我们以前就很少做项目,这次也只是根据公司发展战略,梳理了下部门的产品而已,没有太大的变化。”他看起来对这次调整挺云淡风轻的。
    “你怎么看现在的那些产品?听说s总带着各位部门老大们开了很多次会议才定下来的。”
    “也就这样吧。这些产品都是来自以前的项目积累,以前都有些雏形了。只不过他站的高些,能通盘拉通,加上他以前一直都是做产品的,经验丰富,大家愿意听他的。”
    “好吧。不过我有点奇怪怎么突然要做产品了?从公司开始做软件项目满打满算也才一年半吧,软件项目大大小小加起来也才十个左右。而且这样一搞,本来开发的人就少,还要分成三份。”
    “只做项目不做产品,成本太高。而且只做项目不但不能持续产生价值,还也很难开拓市场。现在智慧城市,智慧交通相关的业务需求很大,很多公司都争着进入这个赛道。我们公司专注做交通行业领域,而且还有那么大的野心,要业绩增长,要上市,要占领市场,没有产品怎么演示,怎么展示实力,怎么接更多项目?”
    “可是其实客户都喜欢要为他量身定制的项目,而不是千篇一律的产品。你看我们在上家公司的产品,客户买了产品后做二开都要很长时间。”
    “但是你想过没有,在宣传和投标的时候如果没有产品,客户怎么会选择你?中标后如果没有产品,怎么可能快速地交付给客户?”
    “可是我们目前这些资源怎么可能做出有竞争力的产品?那三个业务系统也就算了,我们中台组的那个中台产品被领导寄予厚望的,身兼数据、算法、架构还有ue这些中台功能呢。”
    “心有点大了,能把数据中台做好就不错了。不过这只是规划呢,后面做不做再说吧。”
    “哎,这个中台不容易整呀。你看那些大厂都是摸爬滚打好几年,而且投入的都是大佬,才做出来的成果。我们部门就没几个资深点的开发人员。”
    “我们部门也没比你们好到哪里去。我上次开会的时候也提出了这个问题。不过他们的精力现在还只是放在产品体系梳理和归属部门上,还没到讨论怎么实现上。所以被无视了。看看后面他们有什么招。”
    又过了一周,产品体系和每个产品线的规划终于都确定下来了,转型重组的事情也跟着官宣了。由于这次变化比较大,院长特意开了个部门会议对调整方案做了说明。但是普通员工哪里能体会到背后的原因,表现地很茫然,有些人甚至都不清楚“产品和项目有什么区别”。
    不过那接下来的一年里,由于各种原因,每隔几个月组织架构都有或大或小的调整。因此后来大家都麻木了。反正怎么调整,他们的工作并没有本质上的变化。而且调整来调整去,也没有见着有多大的改进和收益,所以不少同事吐槽部门的这些调整都是“换汤不换药”。