快速发展的爱宝宝是如何做矩阵式管理的？
矩阵式管理是互联网团队常见的管理形式之一，公司一般会有若干个产品，这些产品也会由若干个项目小组负责，这在管理系统中就形成了一个为完成专门任务而出现的横向系统，这个横向系统与原来的垂直领导系统就组成了一个矩阵，我们一般用职能主管来表示技术领域的垂直负责人，项目主管表示产品领域的横向负责人。说到这里，大家应该对于矩阵式管理都不陌生，接下来，我主要以场景及案例的形式为大家分享一下我们公司爱宝宝在做矩阵式管理中踩过的坑和一些实践建议。
统一视图、数据说话
大家脑海中是否有这样的一个画面：项目主管们在一起开会，纷纷嚷着任务重、项目紧、需要资源，开会就像吵架，要这个人、要那个人、要优先处理某个任务……
而在矩阵式管理中，员工具有明显的多线命令和多任务并行的特征，这对管理团队做决策提出了较高的要求。安排谁、用多少时间、处理什么任务，这就需要一个统一的视图，可以了解每个成员的任务、工时和进度。每个项目小组都要通过项目协同管理工具（Tower、明道、Worktile等）把需求、任务、工时和进度记录在案。
在这里，工时尤为重要。但是程序员对于预估并记录真实工时这件事一般都是有抵触情绪的，所以我们需要从个人成长、工作效率提升的角度与团队成员进行沟通解除他们的担忧。而员工的担忧包括很多方面，例如，领导知道了我的工时会不会把工作量压得满满的、如果任务的用时明显比别人更长，领导会不会批评等。
软件开发基本来说预估小时级别的任务要比预估工作日级别的任务准确得多，我们有同事在入职的时候一个任务预估时间和实际完成时间差几倍，现在经过锻炼基本上做到任务预计时间和完成时间相差无几，项目主管非常喜欢和这样可控性强的成员合作，职能主管根据任务以及预估的工时也可以灵活的和其它项目主管共同安排他的工作以及根据项目进度安排任务的优先级。
这样的话，工作忙不忙？任务急不急？这些都可以全部依靠数据说话，无需项目主管舌战群儒！
拒绝中庸之道
在这里给大家分享两个案例：
案例一 我们有个项目主管在完成一期项目之后，给每个成员的评分是差不多的。在经历过两个项目之后，虽然大部分人都会选择加入这个小组，但是它的产出明显不如其它小组，事后分析这是由于项目主管认为自己对团队的掌控力相对较弱不能采取直接的管理措施，所以还不如采取平均主义，这样你好我好大家好。
这个比较容易理解，因为创业公司早期建立团队不容易，各团队的主管对团队成员的影响力都比较大甚至整个团队都是主管一手建立的。这样在实际运作的过程中，项目负责人的责任往往大于权力，因为参加项目的每个人都来自不同的技术团队，工作带有一定的临时性，而项目负责人对于项目成员的工作好坏没有足够的激励和惩罚手段。这就促使我们在各个技术团队相对稳定后，从公司早期的平衡矩阵方式转向强矩阵方式，赋予项目主管相对大的权利，这包括职能主管更换项目参与成员的要求。
案例二 项目主管之间会努力争取合适的资源，我觉得这在目标管理下也是很正常的事。之前，我们有采用过中庸之道，例如给项目A安排一个资深的移动端人员，同时给项目B安排一个资深的服务器后端人员，当时想的是这样均衡的安排可以避免天天有人和你啰嗦，让你看看是否还可以帮助提升一下整体的能力。但是，结果却大跌眼睛，项目A和项目B的项目主管越来越不满，抱怨开发小组内部配合不默契导致项目延后。我觉得其关键问题在于能力不匹配、沟通不对等，技术人员大部分不是好为人师的，最好的情况是技术成员一说，项目主管就懂。因此，合适的小组成员才是最好的。
拒绝机动部队
矩阵式管理具有较大的机动性，如果用得好，它可以促进专业人员相互帮助、相互激发、相得益彰；如果用得不好，会出现下面这样的情况：
当时，我们临时安排了一位Web技术组的高级程序员加入A组，他的技术能力不错，噼里啪啦码了一堆代码把他认为原来不好的地方都给修改了，但是原作者很不乐意，再加上之前不在一个项目组双方都不熟悉，因此关系比较尴尬。除此之外，在项目上线后机动部队撤回去了，原作者继续迭代，考虑到代码对后续业务的延续性以及自尊心，之前被修改过的那部分代码又被改回去了。这也有可能是这样的，新加入项目的成员知道这是个紧急任务，他在这里属于帮忙，所以同事让干啥就干啥，在项目上线之后就离开这个项目组了。这导致后续业务延续性很差，原来项目组的同事还得重构。
再比如迫于定制项目的压力，一个优先级高的项目对正在进行的其它项目中的人力进行抽调，这就造成其他项目进度延期，同时另外一个项目也是如此，这样就形成了一个恶性循环。古语说一鼓作气，再而衰，三而竭。机动部队的组建（人员抽调）不仅会造成其它项目的延期，而且还会影响团队的士气。如果企图用无止尽的加班来挽救项目的延期，那有多少人愿意这样呢，我觉得个性十足的90后、00后们不会吃这一套，他们有自己的想法和要求。
所以，我们的建议是可以有技术支持组或咨询组，宁可原团队加班加点，实在不行就调整项目周期，但不建议建立机动部队！
狭隘的归属感
你是不是常常遇到这样的场景，一个独立办公的项目组一到午餐时间，各回各家邀上同一个职能部门的哥们或姐们吃饭去了。如果我们和程序猿们聊一聊，你会发现有相当比例的人会从内心认为他属于职能团队，和这个团队的成员更熟悉、更有归属感。
这种狭隘观念在于：他在公司职业生涯的起点在职能部门，在那里使用相同的沟通语言和思考方式，对职能部门有了超越公司的归属感。此外，也有可能是因为他尚未学会和表现出如何发展跨部门沟通并建立人际关系的技能。 而事实表明，那些以公司为归属地，有意识地追求并建立与同事及支持者之间非正式关系网的人往往是矩阵内工作最有效的员工，在多接触点的矩阵网络中，非正式关系网比正式关系网更有价值。
为了突破这种局限的“归属感”，必须持续开展跨部门的活动增进了解，公司可以为项目组提供活动经费增加沟通的机会，让员工狭隘的归属感转为基于公司的归属感，在任何一个项目组都有归属感。这样，很多工作冲突在非正式关系网中就消化了！
需要持续的开展培训
起初我们有个误区，认为矩阵式管理描述起来非常直观而且容易理解，那么推行起来也应该比较容易，一个会议、一封邮件就启动了。然而，事实并非如此，它需要持续的开展培训，职能主管、项目主管和员工通过培训逐步提高谈判能力、掌握项目小组的团建、提升领导力、管理冲突以及学习解决复杂的问题，这些都要结合矩阵式管理来讲解和学习。持续培训的目的是希望在那些能够提高矩阵式管理绩效的关键领域培养正确的意识和合适的能力。
看似顺理成章地选择了矩阵式管理，但其路漫漫，值得我们继续学习~
加入我们