讨论下专业团队和跨专业混搭团队
发布网友
发布时间：2022-11-01 06:19
共1个回答
热心网友
时间：2023-10-18 18:11
先从团队产出上看。按专业技能相近情况来组织团队在现实中比较常见，这种做法看起来更像是让专业的人干专业的事，直觉上这会更有效率。但是，当对“效率”一词进行更深入思考后，会发现，这种方式确有值得商榷处。如果“效率”指“流水线上某一环节的生产速率”，这种组队法确实会比较有效；但如果“效率”指整个生产线的“整体吞吐效率”，或者放到更高层面，指从产品设想开始到最终用户付款的全流程“有效产出效率”，这种组织方式问题就比较多了：
问题一：按专业组织流水线本质是工业经济时代流水线作业模式的延伸，其特征是标准化、大批量生产。这种模式要求流水线各步骤之间契约关系(工作内容、时间和质量约定等)非常明确，但是，对于知识工作（比如软件开发）来说，步骤之间的边界划分往往没有制造业那么清晰，再加上国内文化风格总体上是走中庸路线，一般不会特别倾向精细控制，于是团队之间边界地带往往变成重灾区，结果理想上应该单向流动的流水线，在实际中，环节之间来回折腾扯皮的情况并不少见。这必然影响整体效率。
问题二：按专业组织团队时，由于团队产出物只是流水线上的中间物，缺少整体感，且不说成就感缺乏问题，更严重的是各团队局部优化可能导致整体阻塞。一个简单案例是，如果最终交付物要先后由A、B两个团队经手才能完成，若A团队一天能完成5个组件，B团队一天能对这5个组件中的3个进行再加工，那么当A、B团队都只强调自己这块的生产最大化时，并不能提升系统对外的交付速率，反而导致每天在A团队处有两个组件堆积，这是不良存货。对于制造业，存货不但导致资金浪费还要额外消耗仓库等资源。对于软件业，看起来因为存储空间成本低廉，可以忽略不计，但是不能交付的特性会增加软件复杂度和后续维护代价，同样成本高昂。这时候，团队只好再借用跨团队级的精益看板等工具辅助，才能再由局部视角切换回整体视角。
问题三：按专业组织团队，因为大家专业相近、思维模式类似，遇到问题时，很难引发大的思维碰撞，也就难以产生创新型解决思路。这恰恰是跨专业组队的优势。而且，随着现在社会生产由稀缺时代往过剩时代过度，生产方式由大批量生产标准化产品的福特式生产模式往小批量生产个性化产品的精益生产模式过度，企业对创新的渴望只增不减，这时候跨专业组队的优势会更加明显。
再从人员成长上看。让专业相近的人聚在一起组队，看起来交流学习会更方便，人的成长也会更快，但这种成长更多体现在初期，一两年以后，随着基本技能的掌握，新人的成长将进入停滞期
一方面，专业团队所涉及领域有限，队员在掌握基础技能后，没多少机会接触到更多东西，缺少新领域锻炼机会。而且同专业组队，大家思维模式共性大于差异性，几年之后，群体思维方式越来越趋同，难以有大的突破，而且由于团队领域范围*，也没有足够动力让团队中每个成员去换个视角去重新审视自己的工作。所以在一些组件团队中，队员头三年成长很快，但三年以后，却难以再有质的提升。
此外，由于专业组队往往是为了完成流水线中的一个环节，除了其上下游相邻环节外，团队中成员缺少和其他团队进行技术交流的必要性。这进一步*了团队和外部交往，团队内敛化严重。反而在跨专业团队中，团队工作本身涉及知识面广，而且由于团队自身并不是按技术中心组织，每个队员找单项技能高手进行深入技术交流的意愿相当强烈。比如一个特性开发团队中有名队员对前端框架技术特别关注，由于本团队其他人不一定是前端技术专家，所以他必须得去加入一些前端技术研究圈子，以便提升自己的前端技术能力。这样一来，这名队员将同时身处两个圈子中，一个是工作团队圈子，一个是技术研究圈子。相反的，如果团队是将前端技术专业人员组织在一起，关注的也只是特性的前端组件开发，队员将只身处一个圈子中。也即，跨专业团队成员和外部的连接更丰富，而这更有利于队员成长。
第三，从人的激励上看，按专业组队时团队之间成绩很难比较。人天生就是有理由的生物，不同专业团队成果的差别，我们会很容易将之归因于专业差异，“不是他们比我们做得好，因为我们的工作内容不同”，“他们的经验也不见得适于我们，毕竟我们专业分工不同”。在按特性跨专业方式组队时，这些理由或多或少不再站得住脚。当不给自己留理由时，团队只好经常反思自己做事的方式，并向其他团队取经，这有利于团队之间良性竞争关系的培养。
总之，如果我们希望鼓励创新，鼓励协作，鼓励团队和外界的连接，以及促进队员成长，最好是按跨专业混搭方式来组织团队。如果确实在某些场合需要按专业方向划分组件团队，建议不要长期设置，或者增加一些辅助措施，比如定期进行人员轮换，以重新激发团队活力 。
