【管理】IT公司管理团队结构思考
本人有幸参与了一个创业公司从创业初期到初具规模的进程。
在这个过程中，本人一直担任公司二级部门的负责人
部门规模从人员数量这个维度上来看，从7个人扩展到了25个人。
部门内部工作组由3个扩展到了6个组。
这个过程时间是2年不到。
本人加入这个创业公司的时候，是作为一个总架构师的身份加入的，这个身份没有维持多久，大概也就是2-3个月，公司老大沟通，我的工作主要变成做项目管理和人员管理。顺带讨论下方案的可行性。再过了一年左右，工作重点基本上到了人员管理上，技术上也只是对部门内部的重点工作进行跟踪。在这整个过程中，自己觉得是完成了技术人员到管理人员的半个转身。为什么是半个转身呢？我觉得主要有几点
第一点就是感觉自己不做点技术(也就是写点代码)心里很慌，总感觉没有做事，我相信大部分和我一样做管理转身的码农们和我有同样的感受。
第二点纠结的是不知道怎么是管理，容易按照技术人员的思路，就是很直接的去指挥下属，甚至就是说让你慢慢做，不如我自己来的想法去做事情。
【【管理】IT公司管理团队结构思考】第三点纠结的是容易让自己的技术决策作为整个团队的技术决策，这样会导致自己成为整个团队的技术天花板，也让团队的技术大拿们很受伤，毕竟没有两个人的思路是一样的。
到现在为止，本人都没有完全做好这个转身，但是呢，毕竟开始认识到这个问题，也开始专门去思考这个问题，所以自我感觉算得是半个转身。
接下来呢，我想从这将近两年的时间里，分析和总结下几个管理上的关键事件。自己做一个回顾，也与各位看官进行一个分享。
一. 初期采用的是典型的组织结构，上传下达，这个阶段很好理解。
文章图片
图片发自App
经典的IT产品/开发部门结构
其中，产品1人，开发4人，测试2人，加上我自己共8人，这个时候第一代产品还处于研发阶段。每天的工作流程很清晰，那就是产品提供需求，我拉上产品/开发/测试一起讨论可行性，确定技术方案后简单分工就开工了。当时就是处于最原始的作坊式开发模式，每天下午5点构建一次给到测试，测试进行测试。有问题的话很多情况下也是口口相传，虽然搭建了一个BUG管理系统--禅道，但是也未完全严格按照问题控制管理流程来。
这个阶段因为人员少，系统规模不大，基本所有问题整个团队都清楚。所以这个阶段的进度是最快的。大约半年时间就将产品V1.0打造了出来。
这个阶段应该是所有的初创公司的必经阶段(当然有大财团支持的公司不一样，本人见过一个央企背景的合资公司，营业许可还没办下来的情况就招聘了20+从华为出来的工程师，一年时间内就扩展到了100+，基本都是华为背景，这得是多大的财力，我这里指的是：一群人有一个好的idea，凑吧凑吧就开始做产品的初创公司)。这个阶段的团队优缺点都非常的明显：
优点：
沟通成本低，需求和问题基本可以在全团队中流转，一嗓子就可以解决问题，解决速度也非常的快。
决策时间快，由于系统复杂度规模和团队规模小，基本上一个方案，都是由总设计师或者架构师进行决策后即可分工开发
团队氛围简单、融洽，这时候大家的思路和想法都是相对统一的，都在向着同样的目标前进。还有一个重要的原因就是此时产品的进度是很快的，大家的成就感也就相应的大。很多人都是比较怀念这个阶段的团队气氛。
缺点：一般来说，为了业务上线速度，牺牲掉规范性的工作流程，这样会导致几个问题
需求和问题没有跟踪，导致问题反复出现，需求改过多版之后，没有人清楚的记得当时为什么要改成这样，无法有效的进行传递
代码管理和风格属于八仙过海型，各显各的神通，导致代码可维护性差，这一条加上上一条导致产品对开发人员的依赖性巨大。
没有严格的技术论证，团队人员的技术水平决定了第一代产品的技术局限性，当然，如果是大厂大拿出来的，这个技术局限性也会高出很多，但是很多情况下是一些手握资金的人有好的Idea或者好的资源，拉出一个团队就开工，这样的团队不一定有多大的技术前瞻性的。导致业务量上去之后出现各种性能问题
二. 小组管理方式
在上述的简单结构中，可以看到，除了产品是1个人以外，其他的两个组都是大于1个人的，那么，对于这样的小组如何进行管理，在整个管理过程中，本人前后共做过两种安排，在这里都记录下当时的背景、过程及出现的相关问题和后续的解决方案，以便自己做出总结，也共享给各位看官做一个参考。
① 本人当时出于开始规范和做团队扩大的准备的考虑，当时的做法是每个组任命了一个组长，统一安排工作。
对于开发组而言，其中一个人是明显的技术能力和工作经验大于其他几人，于是无悬念的担任这个组长的职位，负责安排Bug/需求的分发和技术指导工作。这个安排在当时过渡的比较顺利。(当然，后面这里也出现了一个问题，我在后续会提到)
对于测试组而言，当时是两个人，其中一个人对工作的计划和事项的安排更符合公司对这个岗位的要求，更有项目管理意识，经验也相对经验丰富(各位可能对于这里有一定的异议，这个评价是否有个人偏向问题，我的答案是有个人偏向问题，但是我觉得这是合理的，在一个初创团队中，必须所有人的工作方式相对一致才能保证项目顺利推进，这个工作方式基本上就是靠团队的负责人来确定，所以没有正确的人，只有合适的人)。
基于上述考虑，于是安排这个人做了测试组的小组长。当时的一个直接后果就是引起另外一个成员的不满，很明显的对这个安排不服气，提出了辞职，经过一系列的挽留工作后无效，再经过一些工作交接，人员招聘等工作后，花了将近1个半月才找到合适的人员将这个空档补上，还没有算上新人员对项目业务的熟悉过程。
这是第一次事件的安排，我先将第二次事件的安排和结果接着记录下来，再综合两种安排来做出我自己的总结。
②大概在半年后，我的部门接手了因业务重新调整而其他部门转过来的一个开发小组，当时这个小组是两个人，由于第一次安排的教训，所以这次没有立刻安排小组长来安排事项，而是所有的和项目相关工作都从我这里统一安排(这里有一点点背景，这时团队已经扩大到了16-17人，本人基本上已经开始大量做人员管理工作)，包括需求点方案设计及分解等。后续又招聘进了一个技能更强的员工进来，也是基于这种考虑，到目前为止，快一年的时间了，都没有设立这样一个岗位，都是由我直接分配工作(部门的其他小组均有小组长)。暂时也没考虑设置这样一个岗位。
综上两种情况，我自己的总结是
第一件事情是考虑好组长小组工作范围，预期发展规模，组长职责
是否需要有组长，也就是这个组长职责是根据业务情况来考虑，比如之前的测试组，经过短时间的动荡之后，小组长将组内工作接起来，扩展到了4个人，保证业务顺利进行。
还有一个关键性的原因，这个是对我个人的经历来说的，本人是开发出身，码农顺利转正为高级码农(设计师)，测试工作不是我熟悉的，因此把专业的事情交给专业的人来做，做的更好，而新的开发小组由自己分配除了游刃有余之外，还可以让自己在做人员管理的大前提下，不至于让自己在技术上变得过于迟钝。
最重要的一点经验教训就是，这个小组长的任命的关键因素不在于人数的多少，而是在于对业务的预测，更重要的是对团队人员的了解，在不了解团队每个成员的情况下，不要轻易做决定
可以尝试先让有潜力的人试着做一些类似的工作，再来确定是否合适。
三. 矩阵式管理
矩阵式管理，现在应该算是一个比较流行的管理概念吧。我自己的理解是相对于第一点里面的直线式管理方式而言的。
在直线式管理方式中，在公司的组织结构中，上层管理人员既为人员管理，也做了事务管理。而在矩阵式管理中，是试图将这两种管理有效的剥离开来。
公司是在产品超过两个交付项目的情况下引入矩阵式的管理方式的。其实引入矩阵式管理是一个选择题中的一个选择。对于B2B的产品，而且这个产品又存在一定的定制化存在的情况下，当初代产品成型开始交付之后，必然面对一个选择题，在人员结构上如何配置的选择题：
每个项目配置一个项目组，单独的开发团队(包括从需求->设计->开发->测试->部署维护)。每个项目的需求单独演进，每个项目互不影响，定制化程度高。但是如果产品需要对需求进行演进的话，需要规划一个大段时间来梳理所有项目的需求，并进行重新设计。
共同的产品开发团队，负责产品的演进；成立单独的交付团队，单独拉出分支来进行演进，有必要进行合并。这个选择针对上一个选项，选择成立单独产品团队来进行演进， 这个团队会收集所有交付团队的需求进行产品演进，而每个交付团队单独对自己的交付项目进行演进和交付。待新一代产品演进发布后，再在每个项目进行替换和交接。这样相对而言比较稳定，但是不一定适合小的创业公司，毕竟这个对人员规模的要求较高。
不区分开发/交付团队，任何项目的需求都在主干上开发，每行代码的变动都需要考虑到所有项目的业务需求。在项目规模小，定制化程度不高的情况下可以推进。但是一旦需求差异大，代码耦合度不够低的情况下，很难对所有业务考虑周全，会导致交付项目之间相互影响，对关键人员业务能力要求极高。
我们在业务扩展到一个以上项目时，需求团队根据业务特殊性，预计项目之间的差异不会很大，做出的选择是第三种。其实在人员规模上也不够支持其他选项。但是这个选择在两个项目持续交付一段时间之后，由于用户习惯等其他原因，导致两边差异越来越大，代码维护和演进越来越困难。我们在人员结构上做了一个调整，想尽量的往第二个选项上去靠拢。
这个调整是在公司的层面成立了项目管理办公室这样一个虚拟组织(PMO: Project Management Office)，这个虚拟组织按照项目职责进行项目线的划分，而公司的不同部门提供人力资源到PMO中，就初步形成了矩阵式管理。更进一步的，因为不想成为上述的第一种模式，不能完全割裂交付项目之间的联系，这样一个办公室也从某种意义上来说做产品 + 项目的需求决策，产品和项目的重大决策都由这个团队讨论得出。
这里说到的初步，是因为pmo的话，主要职责是跟踪需求，项目进度等，从某种意义上来说是和开发/测试的出发角度是不同的，而我们因为人员成本的考虑，主要是几个架构师做的人员复用，有点点既当运动员又当裁判员的感觉。
这里我不想做过多的说明，矩阵式管理业界有各种各样的资料和文献，我只是想从自己经历的过程，和之前部门的直线式管理进行对比来做自己的总结
单从速度上来看，直线式的管理是优于矩阵式管理的，人员管理和事务管理都集中，分配工作比较简单。
同样的，缺点也比较明显，所有的风险都集中于这个做决策的关键人物，一旦对于某个风险点预估不准或者完全没预见到，就会导致项目失败或者发生方向性的错误
对于矩阵式管理而言，就可以很好的控制风险
矩阵式管理的另一个好处就是，当交付项目扩展时，直线式管理的某个中心关键人物会变成瓶颈，因为所有的决策都从这个关键任务作出，不了解具体情况就没法作出决策和选择，而一个人是没有时间和精力去了解每个细节点的，也反过来提高了决策的风险程度。
个人认为，矩阵式管理的缺点也是明显的
风险降低的同时，效率也明显降低。操作不好的一个极端就是事无巨细全部经过PMO决策，导致项目推进缓慢。
决策由集体作出，难于追责，更麻烦的是，关键任务不愿作出决策，降低关键任务的工作成就感。
人员管理碰到挑战，直线式管理下，事务管理和人员管理统一，绩效很方便进行评估和考核。矩阵式管理下，事务和人员管理分开，特别的，作为项目经理的下属(同为PMO成员)进行事务安排时，会发生决策混乱和对管理权威的挑战。
因此，个人认为，这两种形式各有优劣，对于新产品，新项目适用于直线式管理，迅速推进占领市场。一旦进入稳定器，就适用于矩阵式管理来保持产品和项目的稳定。另外，矩阵式管理对人员素质的要求更高，不论是领导层还是执行层。
四. 基层管理人员如何定义？如何定位？管事还是管人？
本文开头提到，本人负责的部门有6个小组，每个小组大约就是3-5个人，由于每个小组的工作性质不一样，个别还跨度较大(行业完全不同)。因此每个小组都有相应的小组长进行统一调配。这些小组长的岗位就为本小节想讨论到的基层管理人员。
这里就面临两个问题：
什么是基层管理人员？
这些基层管理人员是只管事还是要管人？
对于第一个问题，相信每个企业的定义都是不一样的。我这里给的定义就是在某一个工作小组中，专业工作能力较为突出，主动(自己有意愿)或者被动(业务推动)承担了一部分管理工作的员工。
对于第二个问题，首先要明确一点，人和事是不是能分开管。对于这个子问题，我自己的回答是无法完全分开，但是可以有各种方式方法可以做到。
首先，我们可以分析一下，管人和管事到底是管什么东西，管事相对比较好定义，一般来说就是专业任务分解，然后进行跟踪。管人的话就比较复杂了，往大了说什么都可以扯上。个人觉得就是通过一定手段的引导，达到合适的人做合适的事情。这里提到的手段包括但不限于以下几点，绩效引导，岗位职责定义，目标牵引等等，而其中最关键的技能就是沟通。
基于上述理解，我得到的逻辑是，员工到一家企业做事，是要实现自己的目标，不管这个目标是实现人生价值也好，赚到足够的钱也好，都是员工的目标。而企业的管理就是通过上述提到的一些手段来牵引并适当满足员工的目标，达到企业和个人的双赢。因此，在关注事的同时必须关注到人，人和事无法完全分开，事务管理是做人员管理的基础。
一般来说，对于基层员工，都是由于自身的专业能力突出的情况下被赋予一定的管理能力，基于更突出的专业能力，对专业需求有更好的把握能力才能对事情做到相对合理的分配和跟踪。在这个基础上必须给予一定的人事管理权限才能更好的对其他员工进行引导。
五. 所谓公司文化
说到文化这个词，总感觉是一个很大很空的概念。个人对这个概念的理解就是一群人的做事风格，或者说是在做选择题，做决策的一种指导思想。这种风格和思想是在日常工作中慢慢积累的一个过程，是最开始的一群人慢慢扩大影响的过程。那么很多公司的工程师文化也就是指的以工程师的态度和思维方式取做事和做决策。
文化所谓好坏，只有合适和不合适。而且这个必须是一个从上而下的过程，而没法做到从下而上的推广。只有一个企业从上而下的推广某种风格，并且在政策、制度等方面去进行匹配，才能影响到日常工作中的每一个决定，进而深化和推广这种风格和态度。
六. 其他
推荐阅读
- 宽容谁
- 我要做大厨
- 增长黑客的海盗法则
- 画画吗（）
- 2019-02-13——今天谈梦想（）
- 远去的风筝
- 三十年后的广场舞大爷
- 叙述作文
- 20190302|20190302 复盘翻盘
- 学无止境，人生还很长