关注公众号回复1
获取一线、总监、高管《管理秘籍》
注意：笔者能力有限，更了解互联网企业，文章内容如有不当，请您多多指教。
前些日子，群里有粉丝在问组织架构相关问题：
研发型企业如何从职能式架构调整为强项目制的架构？有没有操作案例可以参考，特别有几个实操的问题请教下：
组织架构调整后的人员如何妥善安置，比如有些部门负责人没了，只有项目负责人了，是不是只能让某些管理层走人； 如果项目结束，有些项目成员流向其他项目，还有些项目成员找不到项目归宿，是不是也只能让他们走人？ 如果转成项目制，项目成员都向项目负责人汇报，那么研发职能的平台能力提升等工作，是不是就只能割舍掉了？
这是在做组织架构设计过程中会碰到的非常典型的问题，其中有个分析做了不错的回答：
这个问题我以亲身经历回答下：
这种转型首先是一把手工程，老板要愿意改变，一定是自上而下进行的。老板有这个意愿可能是公司遇到了大的机遇或者挑战，不得不改。例如我们公司当时处于冲刺IPO的阶段，需要做出变革； 得有一个强有力的人来牵头推动，并且能得到老板的认可。例如我们空降了一个比较有影响力的CTO； 具体执行层面，就是成立了PMO团队，对集团的项目进行梳理整合，按项目制推进日常的评审、立项、执行、复盘等；
该粉丝的回答是实操的经历，是关于组织架构正确的理解，但没有能够回答第一个粉丝的问题。
关于什么是组织架构，为什么每隔一段时间就要变更架构，每次组织架构变革又有什么需要注意的点？
要回答这些问题，还是要追根溯源，回归公司的本质。
组织架构的本质
一、公司存在的意义
前面的文章我们探讨过，公司存在的逻辑是聚集一批人去完成一个产品（项目），去解决一个社会问题。
管理的存在的意义是让这件事以效率最高的方式的发生。
站在管理角度来说：一个正确的人去完成一个任务，逻辑上效率是最高的，因为没有任何内耗。
但由于任务变复杂了，必须更多的人参与，人多效率就变低，所有的管理问题都必须回归此图：
二、公司所有问题的根源
公司是一个复杂的系统，问题根源主要在两点：目标复杂度和团队规模。
目标难度与组织规模是公司场景下所有问题的根源。
因为目标难度提高，所以需要精英人物加入去解决专业瓶颈问题，而精英的特点是一定是独立思考能力较强，意思是这批人天生不好管。
最终的结果依旧要回到组织规模增大、人才种类变多，于是企业的最终问题就出现了：
因精英人群理念不合导致的实现路径之争； 人员合作竞争过程导致的问题，如派系斗争、资源争夺、员工冲突等； 人员规模上来导致的信息问题，如沟通误解、信息失真、信息过载等； 因人才种类导致的评价失效问题，这里有两个点：第一是专业人才难以评价；第二是就算有客观评价，可能会因派系斗争或者信息失真导致评价失效；
三、大公司佐证
而以上问题非常常见，比如1998年9月20日， IBM顾问向任正非阐述了对华为管理问题的十大诊断：
一、缺乏准确、前瞻的客户需求关注，反复做无用功，浪费资源，造成高成本； 二、没有跨部门的结构化流程，各部门都有自己的流程，但部门流程之间是靠人工衔接，运作过程被割裂； 三、组织上存在本位主义，部门墙高耸，各自为政，造成内耗； 四、专业技能不足，作业不规范； 五、依赖个人英雄，而且这些英雄难以复制； 六、项目计划无效且实施混乱，无变更控制，版本泛滥
其实华为的问题总结下来也就两个事：
规模扩张引起的管理掌控力下降、跨部门协作难度指数级上升； 专业瓶颈导致的难度；
四、组织架构的目的
综上，两个因素制约了团队发展：
专业壁垒导致的瓶颈：没办法拿到员工的真实评价； 规模大了导致的失控：信息传递因客观原因出问题了；
其实只要能客观的评价每个人，那么派系问题可以得到很好的缓解。
而组织架构的出现只有一个目标：最求最高人效比，全局最优。
而执行力三要素分别是：能力、信息、意愿，意愿对应着公司的奖励机制，也就是员工的上升通道建设，而上升通道的本质又会回到员工在公司客观评价问题。
因为员工能力是可面试的，但能力高并不等于产出高，如何在负责的系统里面客观的评价员工，特别是专业向员工，这会变得很重要。
因为，没有客观评价，奖励就到不了正确的地方，那只能引起进一步雪崩。
所以组织架构，他真实要解决的问题是两个：
第一是公司信息传递问题； 第二是公司体系员工的客观评价问题；
因为所有的公司动作，全部会围绕着组织架构产生，接下来我们一一拆解。
信息问题
我们之前说过：公司80%的管理问题都是信息问题。
在今年受邀咨询的10多加企业里面，我整理了一些特点：
100人以内团队一般都较有活力，希望获得管理相关培训，他们寻求咨询的目的很清晰：提升团队管理认知、项目管理能力，把事做好； 150人以上团队便各种问题频发了，常见的是因部门墙而导致的沟通问题，他们的诉求反而会围绕机制、文化建设展开；
我很明显的感受就是100这个数字，因为有几家CEO以及高管都在交流过程中不停强调：我们曾经如何如何高效、互相如何如何亲密，也不知为什么突然就效率低了，而效率低的界限多在100-150人之间有明显感受。
沟通路径问题
在一个群体中，沟通路径的数量等于𝑛(𝑛−1)/2n(n−1)/2（n为群体人数）。
沟通复杂度随人数的增加呈非线性增长，导致信息“杂音”显著增多，如表格所示：
可以看出，从50人到100人沟通链路增加了4倍之多，而做好50人与200人的信息管理，其难度差距极大：
信息失真
人数较少时，单向信息更容易传递清晰；但人数增多后，由于多重路径叠加，产生以下问题：
信息失真：中间传递环节多，导致信息在传递过程中的扭曲。 信息过载：核心成员收到的信息量超过其处理能力。 噪声干扰：过多的冗余信息使得核心内容被掩盖。
所有的结果，都导致群体沟通效率下降，变相影响决策难度，决策跟不上，效率自然跟不上，如图所示：
而且，信息在传递过程中具有向下扩散和向上压缩的特点。
扩散模型
信息是有价值的，特别是从“金主”嘴里说出、并且需要你去传递的时候，其价值巨大！举个例子：
之前CEO发布了一个指令，指令本身是比较简单的。
但作为传递者的产品负责人，开始在这道“圣旨”上开始加料，将自己一直想做而没有资源的产品模块加了进去；
技术负责人接到圣旨后，进一步将一些“技术改造”加了进去；
于是，原本一个简单的指令，因为一次次“有意”的加工，而与最初的指令有了较大的差异。
所以，战略信息在至上而下传播的过程中会因为利益问题而导致变形，目标变形肯定会导致执行变形，其结果最可能是意想之外的浪费。
另一方面，抛开主观意识，信息也会存在客观的耗损，因为老板的战略描述很粗，需要进一步的细节描述，举个例子：老板张口就是道生一，一生二的战略，方向倒是清晰，但你要如何去三生万物呢？
所以，各个Leader需要对战略进行进一步描述，任务的细化，很难有统一的标准，只有做出来才知道合不合适。
综上，向下沟通是一种“扩散模型”，也是信息有效性逐步降低的原因。
压缩模型
公司到达一定规模，信息会呈现爆炸状态，管理层根本没办法从纷繁复杂的信息堆里面挑选出有效的信息。
作为CEO，接收的是最终的压缩信息，信息压缩意味着“信息修饰”。
从信息流转角度，CEO是发布指令的人，他需要的是对指令信息的反馈，理想情况下他只想看到两个有效信息：进度与风险。
但真实场景是：很多人不愿意暴露风险，因为暴露风险意味着批评，所以大家都喜欢将问题进行一定优化表达，也就是把问题“捂着”。
而老板们一般又很忙，需要处理大量回执，所以很难去“一一校验”。
于是项目负责人就暂时蒙混过关，直到问题最终爆发时，大家再互相甩锅扯皮...
信息对组织架构的启示
信息不仅是战略的载体，也是执行的载体，其流动直接影响战略的有效性、任务实现的成本。
人的认知是有限的，当组织超越了一定的规模，信息在上下级之间必然会发生扭曲和耗损。
向上沟通时，信息逐级浓缩，往往带有美化和隐瞒；而向下沟通时，信息则不断扩散，加上各自的利益与理解，变得面目全非。
最终信息失真，进而影响决策和执行。
站在这个角度，我们在设计组织架构的时候层级应该越少越好，传递越少失真越少。
评价问题
其实专业不一致带来的误解与冲突，其本质也是一种信息差，难以评价是公司管理困难的第二个根源性问题，这里回到那个经典案例：
某天，线上有个BUG，前端可以解决，于是后端认为是前端的问题；后端也可以解决，于是前端认为是后端的问题。
两个同学一步不让，10分钟代码的事，扯了一个小时，两人相持不下，开始上升问题。
双方Leader介入，并开始为自己的组员据理力争，于是10分钟的事情4个人拉扯了一天...
上述案例在每个公司都经常发生，导致这个问题的根源是：对专业员工任务的难以评价。
就比如这个BUG，到底是前端的BUG，还是后端的BUG是非常难以界定的，他就像平衡木的两端，坐哪边都不对。
而且BUG涉及惩罚，所有人都很敏感，这种问题就只能管理看情况处理，用机制、文化去规避。
实际工作中，可评价部分的工作占60%，还有40%是偏灰色，不好评价的部分，如何处理这40%不好评价就是管理最大的价值。
其次，所有的专业类工种，一方面会有很多基建需求，另一方面他们会有一个上升阶梯，所以站在评价、建设、培养的角度，这里面弯弯绕绕很多，外行很难看明白。
所以在组织架构上，专业类一般会被聚焦在一起，方便资源最大化。
至此，我们可以得出企业组织架构的目的与需要解决的问题了：
目的：人效最高； 问题：信息效率以及公正评价；
到这里，我们再一起来解析几个经典组织架构，大家会变得很清晰。
三种常见组织架构
一、职能线
在这个架构下，项目多由上游部门发起，产品、技术承接，最后交互运营。
这个架构的优势很清晰：
各个部门会十分重视自己的基础建设； 团队上升通道清晰，凝聚力较强； 各种培训体系会比较健全，员工专业能力方面可以得到保证； 部门内人员调配比较灵活；
总结下来就一句：这是更关注长期建设的组织结构，适合做基建，提升员工能力，适合50人左右的团队。
比如技术部门50人以内，就特别适合这个架构。
二、项目线
随着团队人数增多，公司达到500人、部门达到100人的时候，上述架构的问题会逐渐暴露，以技术部门为例：
因为部门人数过百，技术老大开始无力关注所有项目； 部门依旧更关注专业技能提升，多数情况项目虽然能得到及时的完成，但是整体部门表现出对业务不太关注的态度，进一步因项目认知不足而产生一系列考虑不充分而需要返工的浪费问题； 部门内的技术基建项目与业务项目难以很好的区分，公司会认为技术部门过多关注技术基建，而且技术也说不清楚技术基建的价值； 项目多了后，不太吃香的项目（脏活累活、技术含金量低）开始被嫌弃，可能得不到很好的支持，而技术部门嘴特别硬，上下游矛盾加大； ......
整体来说就是，技术建设依旧好，但是业务项目推动不足，这会导致上游部门极其不满。
在这个基础上，公司会引导组织结构往项目型发展：
这个架构的优点非常清晰：
项目所需资源得到了绝对的满足，项目推进速度会有基础保障； 项目积累包括项目管理方法论、项目文档等都得到了很大加强；
相对着，缺点也非常清晰：
项目经理领地意识很强，宁愿团队空转也不会释放资源给其他项目组，他们会最大限度的保证自己的项目成功； 多数项目是临时性项目，一旦项目结束，项目经理倒是可以带新的项目，但员工就不好处理了； 又因为项目经理不会关注基建，他们会将员工当干电池使用，项目可能是成功了，但团队梯队却坏掉了； 长此以往，员工首先在专业性上没有期待，其次会担心基本的生存情况，这种既没有生存权又没有发展权的状态，难以持久； 最后，项目经理更关注个人成功，项目间的资源共享或信息传递会有很大问题；
总结下来就一句：更专注眼前，拿到目标，忽视长期。
并且项目经理很难对所有工种进行专业上的评价和帮助，真实执行起来项目风险还是不小；多数员工会感受到自己是执行项目的机器，项目组氛围会很差。
所以，这种人效低、杀鸡取卵的架构，公司见势不妙又会在这个基础上提出矩阵架构。
三、矩阵线
这个架构的优点很清晰：
既兼顾了公司基建，又兼顾了项目目标； 当遇到专业性问题的时候，项目组员可以直接求助专业线Leader；
但缺点也很清晰：项目组员有两个Leader，这会让其迷糊。
而且这个架构最大的问题是如何考核，这里表面是考核问题，其本质是职能线Leader与项目线Leader的资源与权利之争。
在这个基础下，我们再来讨论粉丝的问题。
粉丝的架构问题
粉丝公司规模在200人以内，当前是产研为主，其中专业线主要为技术部约
当前团队使用矩阵式管理，体现出来的问题是：
管理内耗，比如项目成员的双线汇报，导致问题的解决周期拉长、推诿等问题； 项目优先级的判断和资源冲突； 部门壁垒，协作成本高，部门山头主义，追求局部最优； 组织效能较低； 项目负责人权威不高，去横向推动项目的时候，因为不懂技术，会受到部门负责人的挑战和质疑；
结合最开始的一些问题：
组织架构调整后的人员如何妥善安置，比如有些部门负责人没了，只有项目负责人了，是不是只能让某些管理层走人； 如果项目结束，有些项目成员流向其他项目，还有些项目成员找不到项目归宿，是不是也只能让他们走人？ 如果转成项目制，项目成员都向项目负责人汇报，那么研发职能的平台能力提升等工作，是不是就只能割舍掉了？
整个梳理结束，我直观感觉是：组织架构没问题，这个公司有问题，没用好...
如前所述，矩阵架构一定会引起专业线Leader与项目线Leader的评价权之争。
而粉丝公司体现出来的问题是：以为自己是矩阵架构，但因为专业线Leader过于强势而本质其实是专业线架构。
而他们的解法是从直接从矩阵架构转向项目架构，从某个角度来说这是正确的决定。
但长期来说，肯定不能这么玩，其实他们可以有更好的策略：将职能线Leader转为项目Leader，他们强势让他们去带项目就好了。
其实，粉丝案例因为公司不大，还未体现太多信息传递问题，他们主要问题都是围绕着评价问题展开：
专业线Leader认为自己没有得到工作评价，所以他们抵触心理很重； 项目线Leader认为自己没有评价项目组员的权限，所以他们感到无力；
但他们的解法肯定是错的，他解法的结果会导致两个结果：
项目线Leader爽了； 专业线所有员工大概都会不爽；
所以，更好的策略是让项目线Leader回归项目表现评价权，专业线Leader回归专业表现评价权即可。
粉丝公司的问题其实是没有形成达成一致的评价体系。
接下来是一个简单的方案建议：
方案雏形
在理想的情况下，每个员工的人效都可以根据项目计算出来，并且每个标准化任务可以进一步做SOP去降本增效：
首先将项目进行分级，可以分为S、A、B、C、D； 对不同的项目进行定价； 最终每个人完成了相关项目，根据评级获得积分；
最终个人的ROI = 做项目赚的钱 ➗ （自己的人力成本+费用）
具体来说，简单步骤如下：
1. 建立内部采买流程，增强资源透明度
各部门通过内部采买机制，业务方按项目或任务付费（虚拟货币），实现需求方与执行方的公平交易。
业务方根据任务重要性出价，有助于聚焦高优先级项目，削减低产出任务，清晰反映各部门的实际价值。
2. 定价机制与反馈体系相结合
为解决定价难题，在内部项目初期制定估价，并通过实际交付数据进行调整。
以数据驱动定价反馈，逐步优化各类任务的成本和定价，建立真实有效的项目数据库，减少估价偏差，确保各部门贡献更贴近实际市场价值。
3. 引入合理考核，平衡短期收益与长期投入
为避免急功近利和短期效益倾斜，可将基础设施、技术创新等长期项目设置分级标签，确保资源合理倾斜和投入。
平衡短期业务需求与长期成长，为战略性投入提供支持。
4. 加强对中高层干部的间接贡献保护
在分账机制中加入对中高层管理者间接贡献的保障，使其专注环境维护、团队支持和风险控制，避免管理层无用化风险。
5. 监督机制确保采买制的公平性
引入财务或第三方监督角色，定期审查采买流程，确保定价合理，减少内部垄断和资源偏差，优化整体管理效能。
至于完整的解决方案，可私聊交流
一些注意事项
如前所述，组织架构既要解决公司信息流动问题又要解决员工合理评价问题。评价来源于两点：
第一点非常简单，就是最基础的专业能力，上级对下级进行专业的指导与评价； 第二点比较复杂，是上级理解公司战略的进一步任务分解，然后对下级任务执行情况的纠偏与评价。这里的评价权更类似于一种解释权；
由于信息传递的扩散与压缩特性，所以架构层级越少越好；
另一方面，评价权的底层是公司资源使用的权利，也就是公司核心权利的基本。所以大家都想要，只不过不同层级的诉求不一样：
公司高层要的是战略解读的权威性，希望更多人能够理解并跟随，所以对他们的核心要求是掌握最新行业信息，不断的提出战略、确定资源； 公司中层要求会多一些，一个是战略目标解释的权限，他们对上下级信息截断会有特别诉求，这虽然这会导致信息差，但从信息分级的角度又是合理的；另一个还是会涉及对下级专业、管理的指导与评价； 公司一线管理的要求主要围绕专业性和项目执行力展开，因为他们要指导评价一线员工，切实的完成战略分解而来的一个个任务；
下图是不同层级会关注的一些工作内容：
一、组织架构要谨慎
基于此，组织架构的设计要非常谨慎，因为他是公司信息通路以及评价体系的重塑，其本质是公司的权利、资源再划分，他一定要符合权责利模型。
在组织架构设计的时候，上级要权威、中级要授权、下级要自由、员工要活力；
在这个基础上又要避免，上级战略闭塞、一意孤行；中级玩权弄术、玩忽职守；下级各自为政、局部最优；
这本身就是一个平衡问题，很难有完美的架构。
二、组织架构要稳定
之前我们聊空降问题其实涉及到了类似问题：
只要公司决定要设计新的组织架构，那么在一定时间内一定要完成新组织架构的确定！
确定后一定要走正式途径宣发，不要遮遮掩掩，遮掩反而会引起人心浮动。
组织结构确立是为了下面的同学工作好开展，知道自己新的Leader是谁，知道接下来负责的业务是什么，下面同学知道这些就能安心；
Leader知道自己的职责和公司层面的背书才好push下面的同学做事，没有组织架构的做事是很没保障，很难展开工作。
三、组织架构常换常新
公司一年会产生很多项目，里面不少都是战略尝试，所以真正有效的项目是很少的。
一线经理对此会最先觉察，但他们获得的更多是感受，感受是模糊的，他们一方面没办法决策，另一方面，屁股决定脑袋，当前任务是他们“安身立命”的基础，他们也不愿意主动放弃；
中层干部会进一步觉察，由于认知与信息量的全面性，他们会看得更系统。但他们只有上报建议的权限，并没有关掉项目的权限，
高层管理会在一个时间点统一判断公司的项目情况，测算每个项目的UE模型，然后选择做什么、不做什么，这个决策的结果就是组织架构的调整。
组织架构调整对于资源盘活是非常有效的做法，因为他其实是给一些深陷泥淖项目员工的一种松绑。
结语
在AI时代，评价和信息问题都可以被AI搞定，在这个基础下组织架构可能会有所不同，在我理想中的架构可能是这样的：
管理层不停收集外部信息，结合公司情况做任务分发； 而得益于AI与信息通道的结合，战略信息被无损的下放下来了； AI进一步对诊疗进行了合适的切割，并且知道这个任务最适合的员工是谁； 员工对任务的执行，每天信息被AI收集，如果有问题，会接受【专家组】的指导； 最后任务完成，PMO团队开始进行项目复盘，并且对员工进行即时奖惩；
这种模式是公司对内外部信息十分了解下的分工，他没有了部门的概念，员工靠任务赚取积分。
但是这套体系是非常复杂的，特别是公司内外部信息的打通，这里不多说，感兴趣的同学可以下来咨询：
