如何接手一个团队（一）

正如同“幸福大都相似，不幸各有不同”一样，运转良好的项目基本上怎么接手问题都不大，然而运转不顺的项目却可能有千百万种不同的形态和原因让你感觉棘手。今天就主要来讨论运转不顺的团队，我们应当怎么来“维修”。既然运转不顺的项目各有不同，文章里的方法属于普适性的方法，作为抛砖引玉供读者参考。如同敏捷开发一样，请大家理解其中的“剑意”而尽量少的关注“剑招”。

1

首先，对于一片完全未知的大陆（团队），除去旁敲侧击的从外部理解之外，我们最终都得深入其中才能清楚其中的机理，进而执行有的放矢的策略。因此，我们需要解决信息“流入”的问题，我称之为“构建信息渠道”。你可以脑补用吸管扎入装满水的塑料袋里的场景，我们要做的就是让水（信息）不断地从塑料袋（团队）里流出来，为我们所用。信息作为我们的“数据”，我们可以在此之上进行多维度的数据分析，逐步剖析出团队现存的问题，进而逐渐明确我们的切入方案。

2

至于如何构建信息渠道又是另外一门学问，宽泛一点说就是与团队成员建立良好并且紧密的联系。这个情景类似入侵野外某物种的领地，若想在其中与物种和谐共处，耐心是必不可少的。过硬的前期接触容易引起激烈的抵触，沦为所有人的敌人。此时，我们应该做的是采用分治的办法。首先找到现存的关键矛盾，然后逐步简化矛盾，将几个人或几个问题相互捆绑，10个人当5个人治理，抓不住的问题可以再拆分，找到其中最好接触的几个点（人）形成抓手，使团队内部相互作用，我们应该做的是“导流”，而不是“对抗”。

3

信息到手了，我们开始着手分析组织其中的问题。从全局来看，IT互联网项目团队的运转完全可以类比成一部机器，机器应该有输入、动力装置、生产模块、输出四大部分。从行业来看，输入一般指的是“场景”，一个场景作为输入，由运营人员和产品经理双轮驱动对场景进行解读解析形成“需求”，运营人员和产品经理作为需求方会不断push下一步的生产模块运转，两者共同驱动开发人员（生产模块）不断产出符合场景需要的功能代码，最终功能代码再闭环回到场景中，用于解决实际问题。与此同时，解决了前序问题又会产生新的问题，形成多个闭环环环相扣的链状结构。只有明确了机器（团队）的构造后，我们才能准确的定位问题并制定针对性的解决方案。

项目管理也好或是敏捷开发也好，都有许多不同的具象化表现形式，如看板、站会等。这些“剑招”是前人在优秀的“剑意”的基础上提炼出来的、可供迅速复制的、普遍有效的方法。然而剑招该如何使用才是关键问题，在最合适的时候使用最合适的剑招，唯有掌握其背后的“剑意”才是用好“剑招”的关键。

想知道更多细节吗？

请期待下期“如何接手一个团队”~