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/

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