2018年部门管理的一点总结

文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

1.背景

        在一个公司除了沉淀技术,对于其组织架构和管理的学习也是格外有趣。在目前公司六年,也经常想公司是如何做到现在这个规模,如何每年维护好700多个项目运作,所以对公司职能部门的划分,工作模式甚至会议模式都有一些留意。

        职能部门的划分我想现在多数公司都已经是按照矩阵模式在管理,用职能部门明晰该部门的产品方向和责任,用横向的项目经理来组织各职能部门中的职能人员,再由项目经理办公室(PMO)来进行各项目的统筹管理:

 

        而我的总结并不是想描述公司大层面上的管理架构和职能划分,我想聊的是一个刚任职部门经理,组织部门工作这一年来的一些心得和体会,以期在新的一年可以让团队走的更稳。以下我将从预算、汇报、管理、团建四个方面来总结我这一年的感触。当然今年也参与了不少招聘工作,既有各高校的校招宣讲,也有社招面试等,甚至自己还注册了一个boss直聘,感触颇深,这里不做细谈。

2.预算

           春节后的第一项工作就是部门预算,由于我是研发部门的,需要预算的内容比各营销部门简单很多很多。研发体系目前尚没有业绩承诺书,虽然公司在进行研发体系的“供给侧”改革,但是研发体系又是最难量化的。做底层产品的研发,如何和市场项目份额挂钩?做项目支持的研发,天天吭哧吭哧填项目,如果今年产品业绩不行,难道就全部打折扣?研发的收入只有工资,其他收入太少,IT市场又对研发人员青睐有加,扣了工资人走了呢?并且,项目型公司的业绩决定性因素,市场和营销的影响可能更大。如此种种,研发体系的预算基本是比较好划分,也相对符合最后年终花销的。总结为以下几块:

        a.由公司统筹,确定今年部门的人员编制情况,以下所有花费以该编制人数为基础预算。

        b.本年工资花费(调薪前、调薪后合并),包含公司部分所花费的五险一金总量。

        c.本年年终奖计划(以最大额度算)。

        d.本年封闭开发补助费用。

        e.本年午餐补助和计划加班晚餐补助、交通补助费用。

        f.本年部门办公耗费,包括电话费用、计划差旅费用等。

        g.本年部门团建费用。

3.汇报

        每一次汇报,都是一次传播自己想法的机会,不管是对内,还是对外,无论是对同事,还是对领导。

        公司大的汇报有两场,一场是年中汇报,另一场是全年汇报,另外每个月基本都有大大小小的专题汇报。有的是面向技术总监,有的则是直接面向公司董事长。作为部门经理,让领导理解你的工作,支持你的工作,汇报真的是一个十分重要的途径。所以每次的汇报准备都需花费一定精力,从文字到图片等等。有很多人可能觉得汇报是浪费时间、形式主义,但我觉得,汇报即可以让自己对工作内容有全新的感触,也可以通过与领导的交流提升自己的格局。汇报本身不是错误,而是看如何参与如何使用,我们是私企,不是国企。

        对于部门内部,则只组织一场年终的全员正式参与的汇报,要求是必须用PPT,必须有彩排。生活需要仪式感,工作也是。就业务支持的角度,我们欣赏肯干的,更欣赏干了还能表达好的。对于研发产品角度,技术水平依然还是第一决定因素,但是又何妨不锦上添花,分享自己的作品?

4.管理

        目前部门的管理分为了两个维度,项目管理和产品管理,同样,部门内部人员也基本以此来有侧重点划分。

4.1项目管理

        项目由于其经常是阶段性和零碎性的,而且涉及到多研发部门合作、多职能部门合作。公司采用项目管理平台来进行项目从发起、时间节点、指派流转、各阶段描述、反馈、完成、评价这样的闭合流程。这套流程运作了十年以上(我来公司之前既有,变化的只是系统,管理流程基本没变),可见这套流程是十分符合多项目同时管理的。管理人员既可以直观了解到各项目的进展,又可以通过指派人员直接将责任归结到具体人上,同时通过反馈机制和评价机制来进行研发的水平考核。

        说缺点,也有,最明显的就是项目发起得有控制,其放大了发起人的权利,而最前端的项目发起人往往都是没太多经验的项目实施工程人员,进而弱化了研发的话语权,并且容易出现研发资源争抢问题。目前公司采用接口人制,以及工程人员量化考核制,便是对这个权利的制衡。

4.2产品管理

        产品维度上,目前我采用的是tower来进行管理。以月为单位,每月将各产品计划登记上去,以周例会为单位进行产品进度的追踪。不过目前tower对普通用户限制了多个功能,尤其是团队人数限制,考虑更换其他方案。

        产品管理,我觉得是一个比项目管理更难量化的东西,因为产品的KPI如何划分更难。很多产品并不一定有很明确的上线时间,甚至当他发起时和最后完成后的作用可能都在中途不断发生变更。我想说的是,产品管理,更多的需要是产品经理的远见,更考验的是产品经理的水平,而不是研发人员。项目管理可以跟着项目进度进行,跟着合同需求实现,产品呢?只能靠我们产品经理的嗅觉,和其本身应该对技术和细节的执着。

       今年虽然我个人学习了axure,也在关注一些产品设计的专栏,还是觉得自己更像一个研发经理,为人不够“挑剔”。

4.3周例会

        特地提一下周例会制度。很多公司或团队不止有周例会,还有每日头脑风暴。在我看来,周例会是最管用的,频度适中不耽误时间,但是又能很好的把握好各类事情的进展。大家每周将自己做的事情先以文档提供给对应负责人,再汇总给我,例会中,各负责人直接询问其工作日志里没说清楚或自己关心的事情,最后由我来针对上周,和本周我关心的事情进行讨论。这样既可以节约大家的时间,又可以把火力集中到最重要的事情上。

        每日的头脑风暴,我个人并没有太多仪式感来进行,而是每天早上抽一点时间逐个问一下各负责人其手上任务的进展,有必要时再做简单的聚合讨论。

        总结,周例会是个好东西,要文档化、重点化、持久化。

5.团建

        往往大家说这个公司好不好,除了说公司薪酬、工作内容、福利外,同时,团建也是一个很大话题。就我自己部门来讲,以经费计划来算,可以保证一些正常聚餐等,我想这也是很多很多公司可以做到的。

        但是我最想建设的,并不是吃吃喝喝,而是技术氛围。所以我定期指定人,要求他必须做一次培训;我在每周例会,尽量和大家分享技术或产品计划的话题;定期给大家安排作业;甚至要求大家写wiki或博客等等。

        我想建设我们部门内部的文化,虽然我们是项目型公司,但是我们做的是产品,我们可以做很多新的东西,学很多新的知识。

6.不足和规划

        2018年,在部门管理上,我最大缺憾是没有把管理精细化。

        以前我们是一个小团队,现在人多了,覆盖的技术线和产品线都多了,不能如当初各类事情均是我参与、我统筹、我安排。而应该形成一个内部的机制,这个事情,它就是你的,它自然会分派到你那里,而我不要担心你搞不定。

        虽然我并不赞成目前就进行前后端分离的人员架构,毕竟GIS不仅仅是写代码,数据处理、桌面端维护、方案的整体性需要大家都有涉猎,并且前后端分离带来的快速迭代优势在一个百分之60为维护工作的部门没有太多优势,反而会带来人员的编制的扩编,导致任务不饱和。但是我也知道,想让所有人全栈是不现实的,所以,每个人需要有工作的侧重点。我计划将工作划分为:方案制定专家(接口人)、前端对接专家、空间分析专家、轨迹专家、三维核心产品专家、二维核心产品专家、空间存储专家、数据处理专家等这些类别,以这些类别再细分工作。在如此运作一段时间,当大家对各自负责的事情十分了解和胜任后,再内部进行轮岗制度,让大家走向全栈,起码是全面了解产品(视个人意愿)。

        我个人没有太多管理技巧,研发出生,现在是,以后也是。但是又必须管理,我不想套路,只想让团队走的更稳。2019,继续努力。

                                                                     

                       -----欢迎转载,但保留版权,请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

                                                                       如果您觉得本文确实帮助了您,可以微信扫一扫,进行小额的打赏和鼓励,谢谢 ^_^

                                         

posted @ 2019-01-13 13:18  李晓晖  阅读(2157)  评论(1编辑  收藏  举报