若是我是一线技术主管

若是我是一线技术主管，可能曾经是团队综合实力最强的，被时间支配不能再天天写代码，但团队各类挑战依旧在

若是我是一线技术主管，每周也要写周报，每一年也要写绩效，想晋升、加薪、人生巅峰云云

若是我是一线技术主管，团队有5、六我的还好，十几我的的团队的话会但愿有人能够站出来帮我

不抱怨

若是我是一线技术主管，我不会喜欢团队爱抱怨的同窗

1. 我天天也很忙，听一我的抱怨会花时间
2. 一我的抱怨了，天然是有问题的，须要花必定的时间梳理出问题，须要及时给出解决方案，甚至要安抚对方情绪
3. 一个喜欢抱怨的人会影响整个团队的士气

其实大部分开发抱怨的工做内容很类似，无非是本身作的业务是一堆屎，谁谁谁就是不配合我作某事，PD 提了无理的需求

大促中咱们的后端主管说过句很好理解的话，看到大促这么多问题很激动，这很好，问题越多机会才越大，若是都是稳定健壮的系统、完善的流程、合做良好的团队，要大促 PM 干什么呢？

若是是机会的话不少状况下没什么必要抱怨，那真的就是有问题还不能说了吗？

向上管理

偏偏相反，若是我是一线主管，我会迫切但愿团队有问题必定要说，甚至没有问题仅仅有想法也要说，但主要是反馈的方式

高效

若是我是一线主管，我更但愿团队和我交流的方式是让我作选择题、判断题，而不是问答题、思考题

主动

一个十几人的团队主管很难有精力面面俱到，了解全部人天天的细节，给你们找出合适方向和机会，甚至认真读完每一个人的周报都要用一个下午，很难作到你有一个不错想法的时候主管刚好找你聊聊，若是我是一线主管，我更但愿团队同窗主动找我聊

废话这么多，其实看看向上管理的一些理论知识会有豁然开朗的感受，抄一下知乎上很接地气的总结

做为领导他们既要有全局决策的能力，杰出的领导魅力，还要有大量一线数据、客户反馈、团队底层真实信息、行业趋势分析与总结。不少点不是他一我的能搞定的，除去那些工做上的support，有时候领导也会出现信息失察、决策失误的状况，因此向上管理的必要性就出现了。

1. 及时按期总结工做进展、数据、部门问题、行业关键信息，以清晰文档的方式递交上级，并同时附上下阶段计划及问题解决办法
2. 提身而出替上级解决困扰他已久的难题
3. 对于明显有错的重要决策，给出合理分析建议，反馈给领导
4. 以培训、分享、我的交流等不一样方式，“教”领导一些东西

想顺便说一下高质量周报的必要性，不少同窗的周报极其敷衍，就是一周的流水帐，发送出来都是浪费本身和收件人的时间，团队不会有人认真读完全部人的周报，取决于周报的质量

我的习惯粗略浏览组内全部人周报（周报有 highlights 多重要），而后会针对有些人的周报设置规则，必须认真看，遇到不理解的还要过去问，高质量的周报你不主动，主管都会主动

天天忙不完的业务怎么办

还有一种抱怨的声音是：本身天天很辛苦，想拼命忙完业务后作一些技术的东西，造个轮子什么的，但一个需求还没作完，另一个需求就安排过来了

若是我是一线主管，我会把团队面临的问题分一下级

1. 重要&紧急，不能按时完成都是失败
2. 重要不紧急，是个很好的机会
3. 技术想法，很好撬动业务的点
4. 简单分析只是业务需求

团队的人可能也有几种特性

1. 能力强，在某领域是专家
2. 能力通常，有潜力，可是很是有积极性
3. 能力通常，主动性通常

其实不用意义说明就知道大部分主管分配任务的思路

1. 重要&紧急的事情只能交给能力强的认去作，意愿有问题也要说服去作，因人成事，能力强多重要
2. 重要不紧急的事情就能够借事修人，若是作得好这我的之后就有信心了，团队多了一员干将，作很差也有能力强的人给保底，不会形成业务问题
3. 技术想法也能够交给有积极性的人作，那么必然占用一些时间，那么这我的手头上无关痛痒的事情只好交给。。。

实际上按照向上管理的思路，须要主管去分配任务的时候，就已经输了，甚至主管来找你问进度的时候也已经输了

固然每一个合格的主管都须要发现、解决团队人才培养的问题，不可能听任问题发生

什么样的人有积极性

能力强的人很好识别，那什么样的人才是有积极性的，看过一个 AE 快速升 P8 的同窗写的文章，他有个很好的习惯

不管大小难易，永远不知足于作出来指定的事情，必定要给人惊喜

若是我是一线主管，我不会凭空把一件重要的事情就给某我的去作，我会更指望

1. 团队同窗来教育我某件事情很重要，想去尝试
2. 在不少微不足道小事情上作出了惊喜，有理由相信这件更大的事情也可能作出惊喜

我被分配了纯业务事情怎么办

上面也提到了简单分析只是业务需求，简单分析，简单分析，简单分析，在阿里将近五年见了太多事在人为的案例，每一个人身边确定也有很多这样的案例

咱们觉得本身在作业务，不少时候是由于两个误区

这不是技术项目

没有什么所谓的技术项目，全部的技术项目除非显而易见，不然确定脱胎于业务，只有业务一线的同窗才能够抽象出来，作业务需求不是坏事情，拿着完成任务的心态作业务才是最要命的

没目标

全部作的事情都要契合本身的目标，而本身的目标大部分时候应该和团队目标 match，今天让我开发一个前端组件，我要看到的是这个需求反应了我营销体系对某个分类能力的缺失，需求概括到我营销可视化体系完善的目标中，在阿里这种人才辈出的环境中目标不清晰的人和咸鱼没什么区别

怎样才算业务负责人

不少小伙伴已是实际的业务负责人，和3、四个小伙伴一块解决特定业务领域问题，但尴尬的是级别相同，在分配任务的时候会很差意思，以为对方也有本身的"技术项目"要作，我得求他把这个业务需求作一下

这种其实不算真正的业务负责人，若是业务负责人仅仅是分配任务，那么任何人辛苦一些均可以作。业务负责人的核心特质应该有一条是了解业务的发展、引导相关人我的目标

这样能够把业务需求转换成每一个人目标中的一环，和上面提到的本身作事情思路是同样的，无非写代码的那我的不本身。 其实即便主管也不可能命令团队成员去作某事，那样团队迟早散伙

若是我是一线技术主管，我但愿团队的业务负责人时刻在两个方面提醒本身

1. 可衡量
2. 体系化