分享
团队管理中如何做好任务分配，平衡团队战斗能力，带动后进者？
项目管理很难，现在的我越来越体会到这一点。团队中有的人能力很不错，在有任务到达时，自己身先士卒，整体探索一番，然后找自己可以接受的内容自顾自地搞起来，基本上不给其他成员机会。这会导致团队整体开发内容不平衡，后进者很难找到成就感因为好做的被拿走了，这会打击一部分稍微弱一点的团队成员的自信心，导致团队整体攻击能力可能倒退的情况。一人独大，简单任务繁多，对团队来说有很大的技术开发风险。所以我想求助大神，这种情况是顺其自然还是想一些策略对这种情况做一些处理？补充一下：我说的平衡战斗能力，不是压制强者，而是，怎样带动后进者进步，提升整体的团队战斗能力。团队中，总归会有一些后进者，这些人，渴望为团队做出贡献，也渴望被认可，如果作为团队的管理者认为这样的人是可以培养的，那么就给一些简单的内容做做。
回复 ( 10 )
团队是为了解决问题而存在的，如果这个人一个人就能解决所有的问题，其他人建议直接开除换新血，或者调岗，或者就去扫地打菜吧。
团队管理者要干的不是什么平衡战斗力，而是最大的发挥战斗力，如果某些人的战斗力特别强，就让他们充分的发挥，而不是去搞什么平衡。
一般来说在一个team这样的小单位里面，根本不需要玩什么权术搞什么平衡，如果team leader不能hold住所有人就会滚蛋（一个team才多少人？）。只有在team之上的管理层次里面才会需要玩平衡，免得公司只有那么一两个team把持命脉。
这就是为什么team leader一般都是技术大牛，而manager一般不是的原因。
如果你是team leader，那么你很危险，因为你hold不住团队。如果你是manager，那么你也很危险，因为你根本不应该来问。
这个问题普遍存在在各种团队中，题主貌似已经抓到了问题的本质，在于如何带动后进成员，而不是简单和被动的因材分工，因为成员如果没有进步，始终是治标不治本的。
我觉得任何一位团队Leader都要很清楚本团队的最关建技能是什么，不要空谈综合素质，要定位到相对具体的能力范畴。然后要研究用什么样的学习资源和方法能够尽快带动后进成员提成。比如一个研发团队，后进成员的弱点大多集中在代码的规范性上。与此类似，BD部门的成员可能对产业的熟悉度是一个常见制约项，销售成员可能落后于结构化的产品演示能力。
当识别出核心的能力落差位置后，Leader需要设计和尝试各种方法来针对性提升，所谓的coaching for capability。大多数行业和企业都可能在短时间内帮助员工提升这些能力，是因为我们今天能够拥有的学习资源比过去要丰富和有效的多，但这依然依赖leader专注的发想和大胆的尝试。
我可以提示一些常见的能力提升途径：
1）如果能力因为规范性无法落实，那么可以集中精力来撰写流程要求和检查清单。比如像开放的销售岗位，有经验的销售人员当然可以依靠本能和直觉做到不错的绩效，但后进者始终会有，他们在处理各种具体情况时的机动能力可能不足，所以比如“客户常问的10个问题”、“客户拜访感谢邮件撰写模版”就非常有用。等他们的能力提上来以后，再推动大家的灵活创造力不迟。所谓的先会稳健地走，才会飞快地跑。
2）客户思维建立。无论什么岗位，只要多带他们去拜访客户，都能够从思维模式的角度对成员有巨大的提升。哪怕是代码不规范的程序员，在拜访客户的过程中都有可能触动他。因为他可能意识到客户的满意度和自己工作的方法密切相关。你会神奇地发现，当员工真正面对客户后，大多数都有观念和态度上的一些变化。这也是成本最低的能力提升途径，只不过大多数团队都只是说，而没有真正去做。
3）标杆研究。无论你的产品和服务有多好，总有比你做得更好的产品和服务，至少是他们中的局部优势。对世界范围内的同行进行反向工程是最快的学习过程。这个没有什么好回避的，整个人类的进步都建立在创新成果的交叉使用上。落后成员为什么提升慢，有一个原因是没有找到尺度，他不知道自己的工作距离合格和优秀到底有多少距离，如果我们只看内部，这个尺度感是很难建立起来的。如果一个人非常有经验，他可能在多家公司都做过这个事情，自然会建立这个尺度，然后再找到超越的方法，但对后进员工来说，我们必须帮助他们建立这个尺度感。当代码结构混乱的程序员看到10家相关产品的源代码时，他可能立即能够找到学习上升的通路。我们公司的初级产品设计人员都要求对先进产品进行描摹，比照好的产品一笔一笔画出来，帮助建立秩序感，感受到别人好到底是因为什么好，好在哪里，做到这么好有多么难？
4）邀请外部专家。这个很好理解了，有的时候我们有先进成员，但他们不一定是很好的导师，或者不一定是最好。所以，适当花一些成本邀请非竞争同行的专家来做专门的指导，对企业来说还是很划算的。
这些活都不一定每项立即生效，在具体的方法执行上，必然要经历几轮的试错，但如果你着眼于帮助员工提升能力，必然应该有更加充分的耐心，因为，这是企业能力资产，能够下蛋的母鸡。
一个 Leader 最重要的事情是关注团队的产出：
从描述来看，题主你如果采取你所谓的平衡，那么结果非常明显：
1. 能做事的人得不到推崇，搞不好也没有加薪或升迁机会。
2. 不能做事的人无所谓，反正组织无底限容忍。
最后你的团队也就剩下一堆不做事又借口一堆的“后进”。
如果你描述中的“后进”真的“渴望”有贡献，那么他自己就会像你说的强者一样，自己鼓捣起来，而不是等人手把手的带。
任务一般可以分解成3个维度：重要性，紧急性，困难度；
“重要”的，通常应由leader直接负责（要做出重视的姿态让领导看到）；
“紧急”的，谁比较闲或者谁手上的需求可以推后的，就他了；
“困难”的，由能力强的来负责。
除了重要任务，上级领导或者需求方一般不会在意谁去处理，只要能按时、保质完成即可。
任务不是自助餐，不是扔在那让人自己去选。本来就是作为主管的你该做的事。
先上观点：不要把一群人等于成一个团队。
打个比方，一辆汽车是一个整体。分开的发动机，车轮，油箱等等一堆东西，只能说是零配件仓库。这两者之间有什么不同，关键是整车确定了发动机、车轮、油箱在整车中的作用。要想把一群人变成一个团队，要理顺一下几点：
负责人必须能确定事情的方向和框架
现在有一种陋习（至少我认为是陋习）：认为什么都不用懂，只需要会搞关系，就是好的负责人，负责人就是负责：安抚，撕逼，妥协，搞腐败。但是团队的运作不可能因为“安抚，撕逼，妥协，搞腐败”变成一个好的团队。那样团队会陷入质量灾难，进度灾难，成本灾难。“善战者无赫赫之功”这才是好的团队负责人。
“人（人员）机（工具）料（材料）法（方法）环（环境）”只是事情发展过程中的需要的材料，都不是团队最重要的东西，重要的是整合“人机料法环”形成整体的框架，形成框架以后，通过反复的迭代，自然会降低对“人才，工具”等的过分依赖，有句话说的好，”再好的产品，也有一部分出之于专科生的手“
负责人必须严密的监控框架的运行和迭代，如果有人实在和框架不和，无法调和，必须让其离开，当然必须考虑框架的迭代工作，要明白框架的进步与成熟是需要时间的。
负责人必须明确事情的方向，方向不明确会让团队的成果没有成效，会打击团队的积极性，对团队产生极大的负面影响。所以这方面的经验必须要积累，逐渐学会通过多方沟通，内部沟通，增加判断的准确性。
框架内部必须是模块化，标准化的流水
标准化可以认为是大工业时代以来最伟大的发明之一，但是随着知识经济的到来，大家都认为：GB ISO等等这些就是标准化，或者认为脑力劳动没有办法标准化。导致大家没有提高重视。
标准化的工作，负责人必须亲自参与，仔细考察一下几个方面：
模块化，也就是多个标准化的组合，这是团队成员不断进步后必然的结果，不至于大家都特别靠谱了，还用很微小的标准化来评估其进度。负责人可以采用不同种类，不同大小的模块化来确定员工的等级和薪酬标准。
必须要有明确的问题反馈机制
大部分的人都信奉：师傅领进门，修行靠自身。以此来摆脱培训的责任。
让初学者在前进的过程中反复的摸索，待其成熟，这个过程是：沉重的，高代价的。因为即使大家都是按照标准化在工作，但是初学者可能不能很好的了解标准化制定者的考虑，有很多的有意或者无意的违反规定，或者在执行过程中没有考虑到规定中的细节问题。
这都是人之常情，负责人不能因成员一出了错误就责骂，认为是其不认真（恰巧这是很多负责人的做法，认为交代已经很清楚了，为什么还是出错）。
实际上，出错是有物理基础的，所有的思维方式，都是大脑神经元的再连接，但是神经元的再连接是需要时间的，并且需要大量的反馈信息，来维持神经元的建立。所以错误是有很大价值的。要重视错误，收集错误。这个收集的工作的每个成员都必须做的，负责人必须能拿到大家的汇总清单。
汇总清单可以作为以后改进标准化的依据，可以作为成果检查的注意事项，可以作为人员培训的案例等等。这样可以加速团队的成熟与进步。
必须建立以人为本的管理思维
必须明白人与人之间的差别
从上面的差别来看，人与人的差别还是很大的。很多人管理的时候，总是用最好的作为标准，其实这是最大的错误，这不是以人为本的方式，因为最好的永远是少部分，我们设立标准，流程，模块，反馈机制，激励机制的时候都是要按照最差（能够接受）的作为标准（即使你的团队里面都是牛人，也能分个三六九出来）。
上面都是从人员的层次差别上来区分的，也有大量的思维习惯不一样（不分前后），这种差别，需要管理者，认真的体会，特别是对小的团队，有的时候真的只能委屈一部分人，因为没有那么的岗位去匹配所有团队，所以在平时，一定要重视成员的思维习惯，尽量把其才能嫁接到其工作岗位中来，这一点我还没有很成功的经验，只是作为一个方向。
发现这个问题如果要拓展开，说清楚需要太多的文章了。而且题主也主要关注的是团队人员的问题。其实，大部分团队人员的问题，都不是问题的源头，都要从最基础的东西分析，才能解决，比方说的，汇总错误；确定标准；建立模块；流程管理；反馈机制；标准计量；对外策略等等。
我想，你应该处于一个类似瓶颈的时期了，现在不要急于改变他人，而是从自己身上出发。PMP的课程，时代光华的课程，等等，用能够提供或满足的资源，尽可能的提高自己。
有可能是我们根本没找到根本原因。比如给职责的时候是否有对应的权利分配？考核权在哪里？交付件是否清晰？交付件是文档PPT、excel？还是结果？或者流程？他需要的认可是何种形式？要知道，很多时候，感觉没意思的员工，是付出得不到正视，没有比较肯定的话语。有种讲法是你每天必须表扬十个人，过一个月你再看看。
最后，建立所有人的成就感，这个确实很难，慢慢做。
以上，纯属个人浅见。
推荐小秘软件
终于碰到这个问题：有空写一些本公司的任务分配
其实很简单, 找出团队开发中的瓶颈环节. 从而大幅提高生产力. 例如 web 开发主要就是前端切图后和后端数据接口匹配时经常要再次调整. 那么就让能力强的人想想如何解决这些实际的瓶颈问题. 这时候如果这个人能力强到是全栈就可以快速把后端实现一遍. 或者找个 mock 数据的 server, 用 webpack dev server mock 一下, 前端就可以真正开发了.不需要返工了.
所以找出团队的开发瓶颈, 然后teader 或能力强的处理这些瓶颈.