开头的一些废话
当老板找我谈话，说想让我带前端团队的时候，说实话，我第一反应是“完了”。
以前自己写代码，好坏都是自己的事，代码烂了，加班补上就行。但带团队，感觉完全是另一码事。我得对好几个人、好几个项目负责，想想都头大。
这篇文章，也不是什么“管理指南”，算是我这两年当个小组长，自己瞎琢磨总结出来的一些土方法吧。主要是写给自己看的，理理思路，要是有地方能帮到你就更好了。写得挺乱的，大家随便看看。
技术选型，真的好难
说起技术选行，真是一把辛酸泪。刚开始那会儿，我也是个技术爱好者，看到啥新东西都想往项目里用。今天Svelte好酷，明天SolidJS性能爆炸，天天都想重构。结果就是，项目没搞好，团队成员被我折腾得够呛。
后来被现实毒打了几次，才慢慢明白，当了Leader，技术选型就不能光凭自己的喜好了。我现在基本就看几点：
1.团队里的人会用吗？ 这是最现实的问题。一个技术再牛，团队成员上手成本太高，项目周期又紧，那绝对是灾难。比如我们团队一直用Vue，那我肯定优先考虑Vue生态里的东西，比如从 antd-vue 换成 element-plus，这种迁移成本就很小。硬要上React，那我得先掂量掂量，有没有时间搞培训，大家愿不愿意学，项目等不等得起。
2.这玩意儿“靠谱”吗？ 靠谱的意思是，社区生态怎么样。我一般就去GitHub看看，Star多不多，issue有没有人回，最近还在更新吗。一个冷门的技术，可能文档都找不到几篇，遇到问题，谷歌都搜不到，那真是叫天天不应。我宁愿用一个稍微“土”一点，但有成千上万开发者验证过的技术，也不想去当那个吃螃蟹然后被夹到手的人。
3.和我们的业务搭不搭？ 这点其实也挺重要的。比如我们是做内部后台管理系统，那开发效率就是第一位的，Vite + ElementPlus/Antd 就很香。但如果要做一个C端产品，对性能和SEO要求很高，那可能就得考虑上Nuxt或Next.js了。不能说哪个技术好哪个不好，就是看合不合适。
反正一句话，技术选型就是“在能解决问题的前提下，怎么省事怎么来”。
关于排期，我的一些“玄学”
排期这事儿，真是玄学。产品经理一过来问“这个啥时候能好”，我心里就咯噔一下。说快了，到时候做不完，天天被催，团队也跟着加班。说慢了，又显得我们团队效率低。
我现在基本是这么操作的：
首先，绝对不能我一个人说了算。需求下来，我第一件事就是拉上要负责这块开发的同学，一起把需求拆成特别细的小任务。比如“做一个用户列表页面”，就要拆成“列表页面UI开发”、“列表接口联调”、“分页功能”、“搜索功能”等等。
拆得越细，后面的评估就越准。
然后，最关键的一步，让做事的同学自己估时间。我不会去压他，比如“这个功能两天必须搞定”。因为只有他自己知道这里面有多少坑。他估3天，那就按3天算。这是对一线开发同学的尊重，也能让他更有责任感。
最后，把所有小任务的时间加起来，得出一个总时间。然后，我会在这个总时间的基础上，再乘以一个1.2或者1.3的系数。为啥要这样？因为总有意外嘛。今天这个同学请个假，明天那个接口后端没写好，或者突然冒出来一个意想不到的bug。这个多出来的时间，就是我们的“缓冲区”，用来应对这些破事儿的。
把这个最终的时间给到产品经理，这就是我们的承诺。虽然前期沟通麻烦点，但总比后面天天被追着屁股后面跑要好。
新人跳板机会>>>技术大厂https://jsj.top/f/o38ijj，前端-后端-测试，待遇还可以，有需要试试。
带新人，有点像养花
团队来了新人，最忌讳的就是直接丢一个项目文档让他自己看。我刚工作时就遇到过这种，一个人对着一堆过期的文档，两眼一抹黑，连个问题都不知道该问谁，那种无助感现在还记得。
所以我们团队现在带新人，会更“婆妈”一点。
1、第一周，不求他写代码，只求他能把环境跑起来，然后提交一次代码。 我会给他安排一个“导师”，一般是团队里的老员工。然后给他派一个超级简单的任务，比如改个错别字、调一下样式。目的就是让他熟悉一下从拉代码、开发、提交、到发布的全流程。只要他成功发布了一次，他心里的石头就落地一半了。
2、多搞Code Review。 新人写的代码，我和他的导师基本都会看。但看的目的不是为了批评他，而是借着他的代码，告诉他我们团队的编码规范是什么样的，为什么要这么写。比如一个变量命名，一个组件的拆分，在CR里说，比给他一本厚厚的规范文档要有效得多。
3、多聊天，吃饭。 技术上的事儿都好说，主要是要让他感觉自己是这个团队的一份子。所以我会有意无意地多找新人聊聊天，问问他最近有没有啥困难，中午吃饭也叫上他。团队氛围好了，他才能更快地融入进来。
也就这些了，拉拉杂杂说了一堆，都是些不成体系的个人经验。带团队这事儿，我也是在摸索中，肯定有很多不足。大家有不同想法可以在评论区留言。 thank you |
楼主
标题置顶
标题高亮
