恭喜你升任主管，也对於你愿意认真带领团队，甚至不惜直接上来Po文讨论，感到尊敬。 毕竟在这位置要打混装死，也是挺容易的。 因此也分享一些经验； 首先这个位置主要是重建/维护/改善一套软体生产系统，这系统关联的当然有产品、人、 工具。所以所有你执行的内容，背後也是考虑这样的大前提去运作。 换句话说一个好的主管，每一个导入的政策、计画、管理工具等等时，应该都确立出这系 统局部目标，并且应该可以量化执行的结果方便分析跟稽核效果是否预期。 ※ 引述《imasaka1117 (Teddy)》之铭言： : 大家好@@ : 因为小弟去年被升为技术主管(小公司) : 一开始底下只有一个人 : 到现在已经有四个人了 : 因为刚升的时候 : 专案的量还很重 : 所以其实没做什麽主管该做的事 : 顶多只有帮忙看其他人遇到奇怪的Bug或是技术上问题的讨论而已 : 一直到最近老板说要再招募一人减少我的loading : 让我有时间去做主管该做的事 : 刚升主管的时候老板有提点我一些主管该做的事 : 像是 : 1.task review : 我的想法是每周开例会来让大家报告做的事项 : 但又觉得好像没必要，因为PM都会知道RD们做的事情 虽然单纯是执行task review，但根据背後确立的局部目标不同，会直接影响进行方法跟 思考方向。因为你预设了PM知道即可，那麽这好像没必要。 事实上哪些人需要task review 以及频率该多久一次的才是真正命题；从我过去经验是PM 外，技术主管也该知道，每一个工程师也该知道。然後其他越多人知道越好。最後我建议 是每天进行，而且10分钟内搞定。 PM的目的显然是为了方便产品与市场或客户衔接。 而技术主管的目的应该是「产品开发的顺利运作，维持产值的稳定性」。所以review 必 须除了让你知道生产中细节，进而快速排除开发障碍外，还必须量化产能。量化非常重要 ，因为他是发现异常的依据，更是你跟其它部门谈判的工具。千万记得，不是压开发时程 的工具。压开发时程这种事情应该是PM做。然後你来挡。 举个例子来说，一个做完量化开发产值的team，应该可以知道该排入多少的工作量。而当 有突发状况，像要hotfix时，外部串连服务挂掉、突然改版等等时 1. 由於每天都知道各自进程状况，会更容易找到适合的人来负责突发状况，也更容易预 估会减少的开发产值。 2. 由於工程师都知道各自每天的进程，所以也更容易提供你适时的建议。 3. 由於增减的产能都有纪录及量化，也更好有依据去抵挡PM的不适合的压时程问题。PM 一周一次检视很容易忽略掉或错估处理一些突发状况的时程。 其他： 1. 透过每一天自我检视，再加上PM不会无理压时程，让工程师可以专心每一天的工作内 容。因为你知道工程师都要热机的麻。 以上目标都是「产品开发的顺利运作，维持产值的稳定性」 另外有量化数据让你争取资源更容易，比如招聘、添购硬体设备、外部服务或开发套件。 只要有数据，谈判就顺利。实行後也可以有数据分析跟稽核，再来就可以邀功。记得一定 要邀功，你越红才有机会把更多想做的导入。 还有一个重点是，每个开发团队适合的作法不一样，比如也有可能每天对你们没什麽增益 ，但透过量化分析持续修正，适时回想目标，找到你们团队的最佳解，这是技术主管必须 做的。 PS. 该写内容的实在太多，但是真的要都写完太长，最後会导致我直接不发。希望短短的 内容有帮到你。 : 2.公司未来技术方向 : 因为程式人生是需要不断学习的 : 公司也是，不然也会被业界淘汰 : 我是希望可以带着每个RD成长 : 这个倒是没有什麽异议 : 但如果决定了某个方向也是会和RD们讨论 : 看是不是有盲点 : 3.提升RD工作效率 : 这点应该就是会想破头的XD : 因为公司的PM有些是非本科的 : 客户如果发问，他们不懂的话就会pass给RD : 有时候就是一些基本问题，然後RD工作就会被打断 : 所以我是想说给PM教学一些资讯业相关基本知识或术语 : 另外就是观察RD们的IDE操作或是找解答的方式，并给予更好的建议 : 例如滑鼠点两下可以直接反白该单词，而不用滑鼠拖拉之类的 : 当然有时候反而是我看到他们更好的操作是我该学的，也要记下来给大家知道 : 4.统一coding style : 这点主要是防止人员临时请假或是离职，交接时痛苦指数会比较低 : 当然还有如果多人合作时就较不会有违和感 : 以上是目前觉得该做的事@@ : 另外还想问各位是否还有哪些是我没想到且建议的吗? : 先谢谢大家QQ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.163.131.8 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1588430287.A.DFE.html 有空会再继续写下去，希望有更多人来一起分享 没错啊，因为原文看起来是比较贴近技术主管担任scrum master的状况，task managemen t 比较多与scrum master/coach相关，所以本文内容的确很像scrum master经验。而技术 主管还有更多事情要做（尤其我们不知道原po是挂什麽title，上面是不是有CTO还是哪一 级主管）。 这也是为什麽我说该写的其实很多。像规划架构演化方向、建立技术门槛、向上/向下管 理、维运、危机处理&风险管控等等的，每一篇都可能是技术主管该参与或直接主导的。 每一个也都要不小篇幅写。 另外，原po状况应该也可以招聘一些这样角色的人（像是Scrum master、架构师、DevOps 、Security)来专门负责执行上述的议题，但这背後的目标与过程技术主管应该也要知道 。 ※ 编辑: Masakiad (1.163.131.8 台湾), 05/03/2020 13:00:19 ※ 编辑: Masakiad (101.12.51.98 台湾), 05/03/2020 13:26:58