背景：技术小牛人要升级带团队，这确实有些为难偏技术的同学了，俗话说，隔行如隔山，突然跳出自己的圈子，从单兵作战改为团队攻坚，确实不是一朝一夕可达。于是，针对具体问题，做简单答疑。
注：团队管理没有标准答案，因人而异，风格可以百家争鸣百花齐放，但是，最终的效果都是一样的，做到1+1>2。
问题1：业务目标不确定但是有截止时间如何解决？
这是明显以时间倒推的项目。难度可以是5星。重点是考察组织能力，项目管理，排兵布阵能力。
1.目标统一！
将多个资源方的目标对齐，让所有涉及该业务的参与者感知到项目的重要性和急迫性，并可落实在每一方的KPI上。
只要大家目标统一，后面的路就能走了。
小贴士：这个过程是痛苦的，全看个人的组织协调能力，多找业务方，产品等相关人员聊，晓之以理动之以情。必要时从上自下推进。
- 目标明确！
给出至少阶段性目标，且该目标必须是明确的，可考核的，可落地实施的。如果产品只有大致的需求，但落地不清楚，那就技术侧给一个可执行方案，倒逼产品接受，最终达到业务目标。
有一点要明确，不能蒙着眼睛干活！
除非~~~该业务是一个从0到1，且该业务大致的产品形态是确定的，相应的技术架构非常清晰（如SPA，或者SSR项目，是否需要登录，菜单和权限等等），那么，技术侧可先行。
- 排兵布阵
一个两周需要上线的项目，加的开发越多就干得越快吗？
我们做技术的都知道，不可能！
这时就考察用人技术，和项目管理能力。
1）选什么样的人？
如果是强业务背景的项目，自然是挑该项目的日常维护者更优；如果该项目功能比较独立，那可选择的余地就大多了。
一定要挑技术强的开发吗？不一定。每个同学都有擅长的地方，要针对具体项目，挑最合适的人。
2）选多少人合适？
在于你如何拆解这个项目。模块化，组件式开发，多页面开发，甚至分为MVC模式开发也可以。总之，先拆解好项目，再决定参与者人数。
3）如何协同？
这也是基于上一步的。项目拆解的好，那么并行开发的可执行度越好，且功能解耦度也更高。
4）项目管理！
这就要跨出前端团队了。如何高效的组织产品，测试，云端，和我们一起火力攻坚，每个环节都能无缝衔接。手段很多，从甘特图，到看板，日会，结对编程等。Project manager是一门学科，这里就不展开了。
当然，这个过程也是非常艰难。与人打交道的事情，总是少不了摩擦，沟通，和语言技巧，心理揣摩。
问题2： 如何磨合团队成员
这个问题比较泛泛，往大了说，可以讲到团队建设，往小了说，可以是团队配合。再具体点，也可以涉及到团队培养。
总之，都是“人的艺术”。
首先，你要了解团队的每一个，不仅仅是工作能力，优势劣势，再深入些，走进每个人的内心。他们更喜欢做什么样的工作？偏业务，偏技术？他们的性格，是外向活泼，善于沟通协作的？还是内敛言简，单打独斗的？
很多时候，一块业务会有多人负责，那么一定会有一个最小粒度的小团队（比如两个人），那么，怎么去组织这样的小团队呢？从技术和业务侧来看，每个人个有偏重，然后团队总实力是平衡的；再从性格上看，混搭是一种方式，志同道合也是一种方式，没有绝对的正确或错误，可以都尝试一下，看最终怎样的搭配可以产出最大值。
再说“磨合”~~~人多了，想法自然多，当遇到分歧时，确实有可能争论不休。我一直觉得，只要不升级到“吵架”，争论是一种很好的思维碰撞，可以开拓个人的局限性。但是，争论的主线不能歪，TL需要把控整体节奏，在过程中，将每个人的思维都调动起来，尽量让每个人有发言和倾听的机会，只有类似头脑风暴的讨论，才能让每个人看到小伙伴最真实的一面，也可以看到对方的实力和能力。
我们做技术的，一般都对技术有着天生的虔诚，技术好的同学，自然有天然的影响力和话语权。只要多开展几次分享，几次技术方案评审，大家心中必然有一杆秤。
如此一来，“氛围”就营造出来了。
后续，就是各个击破了。小摩擦，偶尔的拌嘴，没关系，可以私下当个和事佬，找相关的同学聊聊天，安抚或者侧面调节。如果搭档过程中出了问题，双方推诿时，TL还是需要以中立方评判，大棒加甜枣，先扬后抑。这里，需要“学会如何说话”。
网友评论