恭喜你升任主管，也对于你愿意认真带领团队，甚至不惜直接上来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