技术管理学习

1. 前言

程序员不单单只有技术的深度，更应该有广度的提升，比如产品思维，项目管理，运营，时间管理，沟通，领导力，.压力管理，冲突管理，目标管理，经济学，博弈论，商业模式，财报入门等等.

看看 程序员，技术主管(Leader)，架构师 有什么区别：

技术管理最重要的两个任务：

• 完成工作目标.
• 培养下属.

在我眼中，我认为技术管理并不是真正的纯管理人员，只是一个懂技术的服务人员与领路人，有时候可以说是你成就了大家，倒不如说大家成就了你，也可以说是大家双赢.

技术管理者需要为团队成员服务，有人需要资源就给协调资源，有人不明白目标就帮助他明确目标并制定其个人目标，
不同的模块间接口无法确认就组织相关人员讨论，xxx任务完成的好就给予明确肯定，
xxx所从事的技术方向迷茫就协助找到发展方向，
有人突然情绪低落效率低下及时发现背后的原因并在必要时提供支持… …(感觉是不是像保姆)

影响力的六大原则也是应该知晓的：互惠原则，承诺一致，社会认同，喜好，权威，稀缺

激励别人无非就两个因素（基础因素与动力因素）：

技术管理者还需要几点，以身作则，勇于承担责任，共情能力，时刻牢记公司，团队，项目目标，情绪控制，不传递负能量，不耻于下问 ，复盘 等等.

团队leader 负责工作罗列:

• 促织线上Carsh的修复
• 组织线上突发BUG
• 排查每日客人投诉的问题
• 解决团队遇到的技术难题
• 组织每周 Code-Review
• 组织每周例会

团队Leader一定要明确两点：

• 不要给自己分配具体的需求开发，会发现，管理工作会消耗掉你大量的时间
• 努力不要使自己成为瓶颈；很耗费时间的事情，及时分配到具体的开发人员。BUG如果都集中到自己手里，那么一定要及时分下去；

那些工作今早分出去给具体的开发人员呢？比如 Android项目的打包，代码混淆，设计 Lib 框架，技术调研，Monkey日志分析；

保持内心强大

• 要学会带领团队成长，不要事必躬亲
• 要多进行思考
• 要学会风险管理
• 要保持内心的强大
• 要学会邀功(要给团队成员邀功哈)

技术管理者的核心能力是什么？

• 技术判断力（某个技术项目“要不要做”，要做的话“能不能实现”，是否适合现在做，还要考虑技术风险，项目管理复杂度，成本等等，远远超出以前写代码的范畴）
• 技术判断力包含

1. 对结果的判断(这个事情做还是不做，用什么样的指标来衡量它的好与坏，比如：开发人员提出要用Flutter对现有App进行重构，你要给出一个判断做还是不做。技术人员想玩一玩新技术，而你作为技术管理者，考虑的是现阶段公司App的关键问题是什么？假设说是App稳定性、开发速度不够快，那么Flutter作为一种新技术框架，能不能解决现有的问题？如果不能，那么现在引入它也许还不是最好的时候，可以安排一两个技术人员做预研，开始关注这项技术。)，
2. 对技术方案的判断(对技术可行性、可维护性、成本收益等方面进行判断，通常在技术方案评审环节给团队进行指导)，
3. 对风险的判断(技术风险、项目执行风险、团队风险等方面。技术管理者利用自己的经验、思考分析、团队讨论等手段，识别出主要的风险，并采取措施进行规避)

• 提升技术判断力，

1. 团队日常技术和产品工作汇报(获取信息反馈，验证技术判断的大好时机，看看自己之前的技术决策产生哪些影响，有无需要调整的地方，也可以学到下属们的思考和经验，及时更新自己的技术和产品认知)；
2. 参与技术方案评审(尽量参加，结合自己的理解和经验给团队反馈，架构判断力也得到提升)；
3. 主持系统顶层设计和规划(担任或主持系统顶层设计规划，业务架构规划，系统各层的划分，子系统之间的数据交互协议，技术框架选型，系统容量规划等等，从技术整体架构把控，再由团队进一步展开更细的规划)；
4. 持续学习新技术(技术管理工作，并不是完全丢弃技术，只是放弃大部分代码工作，新技术的学习不能停止)。
    

CodeReview(代码评审)

每周技术分享 每周一次，每次1个小时，单周(技术Leader)，双周团队成员轮流。Leader 主要偏内核修炼(比如设计模式，架构设计，等等)，团队成员偏实战中的经验和心得体会，具体到代码和项目层面.(比如优化，重构用到的东西等等)；题材可以不限制，当然也可以按照大家掌握的技术点打分，进行有效的技术短板提升；
 

2. 技术提升

每天进步一点或者看一会书，1个月，1年，坚持下来，慢慢就提升了，时间复利就是我们最好的朋友
程序员的主流成长发展路线，是明显的“T”形路线，纵深是技术的深度，横向上，是广度方面的，当然也包括技术专业之外的领域。 

建议看看《认知天性》中说的后刻意练习时代:
1.学习的东西需要进行检索
2.穿插练习，有助长期记忆.
3.反思是检索的一种
结论：平时可以尝试技术分享，讲解给别人听，重构代码，严格要求自己，写DEMO，或者自己写一个小项目等等来检索或者练习 自己学习的设计模式，性能优化，自定义view，动画等等知识点，有问题的再重点去学习，掌握. 后续也可以进行一些总结，反思，优化.

OKR目标管理学习：
平时很忙如何学习，建议做好年计划(列出目标与关键结果)，分解为月计划，再细致分解到周计划，然后每周或者每个月检查成果.

** 产品思维提升**
人人都是产品经理

运营了解

习惯养成指南：

提升的途径有几种方式：

阅读优秀源码，不只是单单阅读，要理解别人为何这么做，要是你做会如何做，最后可以尝试自己写一个类似的检索与练习下.
用指标严格要求自己: 代码风格，内存，CPU，APP大小等等优化，交付时间，BUG率，冒烟测试通过率等等
讲给别人听，就是可以做一些分享，或者平时解决问题，能不能说明白原理，眼睛过的，不代表你真的懂.

业余时间：

• 看看程序设计相关的书，文章和博客(不断的吸取新东西，也可以写一些小DEMO验证)
• 参加一些技术主题论坛或会议
• 写写技术博客（输出是一种提升，也在于 总结和提炼知识）
• 创建自己的业余项目(比如我写的 AndroidTVWidget， android-tv-frame-new，实践所学，获得新的技能或加强旧的经验，完整的经历一次创造)
   

高质量文章编写
首先，如果你写文章的目的是为了给自己看，那怎么写都无所谓，如果，你写的文章是给别人看的，那么感觉应该是这样的：

1. 针对简单概念，你要介绍的全面，理论配合demo，能够让一个不懂的人看了之后懂了
2. 针对有点难度的概念，你要一步一步地详细介绍，让刚入门的小伙伴们能够仿照你的例子做出来
3. 针对底层的东西，比如源码，你要能把大致流程说清楚，并且能够结合源码分析出上层的东西。

这是写一篇好的文章所应该达到的，总之，我们要明白，写出来的文章主要是给别人看的，写的时候要考虑这么一个问题：如何写才能让别人更好地理解，这样，好文章自然就出来了

技术演讲与分享

Who-What&When-Why-How-Future-Recap
Who: 自我介绍，让听众了解自己，建立连接；
What&When: 今天要分享的主题，通过简短介绍吸引听众的注意力、好奇心；
Why: 为什么要做这个架构改造、技术升级，整个项目的背景是什么样的，结合对听众的了解，做特定的介绍；
How: 深入浅出 3~4 个最核心的内容点，当然为了全面性，你可以都罗列出来，但介绍的重点建议控制在 3~4 项；
Future: 让大家了解你未来的计划，你对技术趋势的看法等等；
Recap: 对今天的主题再做一个回顾，让听众加深对核心内容记忆。

技术人员的会议如何高效开
高效会议

怎么提高英语水平呢？

• 使用google，直接英语关键字查询资料，阅读资料
• 需要买的书，有英文版的，就绝不买中文版，刚开始一两年的阅读速度会很慢，后来就好了。
• 学习视频课程时，尽量看国外的公开课，不要开字幕，集中所有的注意力去听，去理解，一两遍不行就多遍。
• 自己做笔记、日记都换成英文来写，不断的迫近英语思维方式。
• 至于说口语，对于绝大多数人来说不怎么重要，等你每天都需要用的时候，再去刻意地练习。

避免能力陷阱

做的越多就越擅长，越擅长就越愿意去做。这就容易被你当前的状态所局限。
这样的一个循环能让我们在这方面获得更多的经验，但却容易陷入能力陷阱，在其他方面无法突破。

学会延时满足
第一个原因：做事从不分你我。做完自己的工作后，对于大部分同事的问题，只要能帮助解决，尽量都去做。所以成长得非常快。 第二个原因是，做事从不设边界。负责技术，但遇到产品上的问题，也可以积极参与方案的讨论。很多人说，这个不是我该做的事情，但做这些事情让我得到了各种锻炼，这对个人之后转型做什么有很大帮助。

哪些事情尽量少做(鸡汤)

当某个事情产生短期快感，建议少做，比如熬夜刷手机，看抖音，玩游戏，深夜撸，睡懒觉。做一些长期坚持收益巨大的，如读书，学习，健身，理财；
痛苦与想回避的地方，越能让我们成长；跨越
永远记住，身体健康是根本；不要以熬夜加班为光荣了，身体真的出问题，后悔莫及；
 

3. 项目管理

如何分配任务，跟踪进度，沟通，等等，是一个刚进入 技术管理者 应该必备的技能.

项目有三大目标：时间、成本和质量

项目几个要点：以目标为导向，以计划为基础，以控制为手段

后来在工作中我每天都尝试着问自己这些问题。
时间：项目计划在什么时候完成？有哪些工作，分别在什么时候完成？是否发生了偏差？如果有偏差，怎么处理？
质量：软件功能完整吗？软件操作方便吗？运行结果正确吗？运行效率够快吗？软件代码符合规范吗？客户用起来满意吗？

按照公司，团队 实际情况，合理应用项目管理手段（比如敏捷，瀑布等等）.
在开发前，建议项目的团队成员需要知道任务的优先级，尤其是多任务并行的时候.
也可以善用清单 对于项目各个环节进行把控检查.

避免被动管理
这里需要避免进入被动管理(消极管理)，任务分配不代表就结束了；
被动管理 就是 一开始不做计划，也没有风险评估和备案，开发过程中也没有定期跟踪任务状态，更没有根据成员的工作状态调整计划，验收的时候出现延期或者各种问题 又或者 导致被动的赶进度加班；被动管理对个人，团队，公司，被害而无一利；
所以 需要 做好计划，风险评估，备案，定期跟踪任务状态，调整计划；

3.1 技术管理者进行项目管理主要解决几个问题

 
建议拿到或者讨论 项目或者需求，第一件需要做的事情就是技术可行性评估.
项目或者需求，我感觉执行应该符合 Smart原则.
各个项目需要分清 轻重缓急.

先不要急着给出承诺以及开发计划，先了解几个方面：

• 背景了解一下，为什么做这个事情，解决什么问题，目的不明确的不接.
• 做哪些东西，具体的需求内容，不知道具体内容的，不接.
• 最傻屌的需求举例：做一个聊天软件，我做你TMD，聊天有那些具体需求内容哈，范围那么大！！！
• 邮件需要发出来(至少你的上级应该知道这件事情)，还要有需求规格文档等等.
• 还要了解他们是否已经需求，设计 评审过，没有评审，尽量不要接.

根据我多年的了解，项目失控往往有几个原因：

需求不到位
问题主要表现几个方面：
(1) 需求/原型/设计图 评审太随意，导致后续改来改去
(2) 产品需求与技术人员脱节

没有指定完整的项目目标
问题主要集中在需求方面：
（1）需求过多，系统过于庞大、复杂；
（2）需求不稳定，用户无法决定他们真正想要解决的问题；
（3）需求模棱两可；
（4）需求不完整。

拙劣的计划和评估
对项目的难度和工作量评估不准确，导致项目的进度永远达不到进度表的要求，并且被无限期地拖延下去。

采用新技术
新技术的采用，有时的确可以极大地提高生产效率，并解决一些棘手的问题，帮助项目最终成功。但同样可能会引出新问题，给项目的失败埋下祸根：
（1）项目组成员对新技术掌握有限，并且迫于项目进度的压力，很少有机会去深入地研究和实践这些技术；
（2）新技术不一定成熟。

缺乏或根本不具备项目管理方法
项目经理不懂管理，没有“章法”。这种情况下项目经理有两种做法，一是想到什么做什么，胡乱出招；二是等事情做，有问题才觉得工作很充实。这两种做法的最终结果都是一样的：项目问题不停冒头，成为了“打地鼠式管理”方式。

团队中缺少资深人员
资深人员通过其丰富的经验（特别是失败的经验），可以给项目组提供成熟的解决方案，帮助项目组识别风险、解决突发事件等，如果缺少资深人员，项目陷入失控的概率就会大大增加。

硬件/软件供应商的低劣表现
将项目中的部分工作或产品外包，是很常见的事情。如果供应商不给力，有时只有干着急的份。特别是国内层层转包的情况，导致真正干活的人费用非常低廉，根本无法保证进度和质量。

质量无法满足要求
质量达不到要求，导致项目失控也是很常见的。功能做了一遍又一遍，每次接近一点，却始终不能达到。如果性能或可靠性存在问题，还有可能给客户造成重大损失，带来更加严重的后果。

项目受控

• 保证目标和计划的可行性
• 采用成熟可行的技术方案
• 密切监控项目状况
• 保证团队和谐，激励员工士气
• 时刻将质量铭记于心

3.1.1 任务分解

任务分解需要搞清楚几件事情：

• 做成什么样子，demo? 提测？发出去的版本？问清楚才能开始做任务分解，因为影响开发的时间以及质量问题.
• 什么时间完成，截止日期，没有具体的截止日期不做. (影响 质量，开发的时间，排期等等，需要根据具体的开发周期商讨磨合)
• 资源是否到位(设计，测试，其它部门，外部 协助等等)，协调资源.

顾名思义，就是将一个项目分解成N个小任务，参考敏捷开发的需求池概念。

开发任务分解(将一个或者多个需求分解成几个开发任务)，定人，定时间(开发周期)。

技术选型(适配分辨率，Rxjava，网络请求库等等)，架构，技术难点，风险 需要暴露出来，包括选用新技术也需要考虑几个方面(学习，招聘，时间，机会成本，风险也需要考虑).

比如，开发一款影视工具，有影视搜索，影视详情等等. 影视详情可以分解出很多小任务或者实际的开发任务(API接口 2天，界面 3天，逻辑代码1天，设计资源 等等)

1. 对于需要使用的新技术，要估算学习和调研的时间。(新技术引入的成本)
2. 我们需要编写什么样的接口？
3. 我们需要创建什么样的架构？
4. 我们需要更新哪些表？
5. 我们需要更新或是编写哪些组件？
6. 根据统计，每个程序员每天的有效工作时间是5个小时左右，其他时间都被沟通，喝水，休息，上洗手间等占据，所以如果某个任务估算超过5个小时，那就代表了这个任务完成需要超过一天的时间。
7. 对于开发任务，估算尽可能的细，一般来说，每个任务的估算不应该超过5个小时，如果超过5个小时，就应该再把这个任务细分。只有尽可能细的估算任务，总的时间是大概精确地，因为估算时间是一个正态分布，有的任务估算的时间偏大了，有的时间任务估算的时间偏小了，估算越细，总体下来估算还是准确了。

3.1.2 任务分配问题

注意几点：

• 不要担心别人做不好，学会授权，辅助培养.
• 多给别人选择的机会.

也可以尝试改善分配工作的方式：所有任务列出来，然后进行分配(每个人从任务池挑选适合自己的，自己想做的)

3.1.3 进度跟踪

不是安排了开发任务就放任不管了，需要进行进度跟踪。
可以 每天的站会 也 可以单独的沟通，主要是为了 提前发现问题，对 进度，风险把控。

站会需要关注的3个问题：

• 昨天做了什么？
• 今天准备做什么？
• 需要哪些同事配合或遇到什么困难？

站会注意事项：

• 避免讨论具体问题，会议后私下讨论。
• 时间最好为5~15分钟之内。

站会只是提了一个方式，根据实际情况而定，如果大家都加班到了10点，你还一大早9点开站会或者开会同步问题，我想大家心里一定是TMD的，换位思考，共情下.

3.1.4 多任务并行如何处理

将所有的需求列入需求池，按照每周的开发计划来，不急就排到下周或者下下周，排期.
如果真的很急，那就找上上级以及相关人员商讨，任务的优先级，看看那些需要扔出来的.
比如 有需求 A1, A2, B1, B2 正常弄，中间插入 C1，说的很急，必须这周完成，那么找上上级以及相关人员商讨，如果B2优先级不高，那就排到下周去.
多任务并行需要考虑优先级，人力资源等等问题.

4. 目标管理

作为技术管理，一定要确保团队目标与公司目标一致、个人目标与团队目标一致，只有这样，才能产生协力，有效实现预期。
让每个人都有参与感(共同制定团队目标和个人目标. 让员工参与到上层目标分解到团队目标，团队目标分解到个人目标的过程)
三种目标(公司目标，团队目标，个人目标)[必须符合Smart原则]
团队，公司，个人目标一致，才能产生协力，有效实现预期.
要将团队成员的个人目标与团队相结合，就必须理解下属的痛苦，快乐，为何在这里工作等，
针对每个具体的个人来考虑团队目标对于他个人的意义.

OKR(“O”就是目标，—Objectives，“kr”即关键结果——Key Results)

比如定了目标，提升团队的10%效率，关键结果 有 公共库，统一开发环境等等.

5. 时间管理

四象限法则：

6. 压力管理

从一个程序员走向技术管理岗位，压力真的很大，原来只是管好自己就OK拉，现在不仅要管好自己，还要管理下属，还有和其它部门沟通，还要面对领导以及更高级的管理，更悲惨的是，你还要对整个团队的结果以及成长，状态 负责任到底；

新任 技术管理 会担心 自己不称职，担忧别人对自己的看法，评价，这些心理和情绪活动，会带来连绵不断的压力；

情绪控制很重要，如果情绪失控，受到压力大喊大叫，推卸责任，逃避，沮丧，团队的成员也会慢慢变成你的样子，可怕，可怕；所以，要尽量避免用消极的行为应对压力，要努力积极的面对压力，用于承担责任，一起以解决问题为目标。

学会暂停：当领导批评你，同事指责你，下属埋怨你，产品经理怼你，… …先暂停10秒再来反应，避免被打或者逃的本能控制；可以建立仪式化帮助控制自己的情绪(比如默念三声“解决问题”或深呼吸三次或闭眼10秒钟)
问问自己下列问题：

• 真正的问题是什么？
• 自己这么做，有助于问题解决么？
• 自己的目标是什么？
• 自己这么做，能实现目标么？
• 淡定，不控制情绪，会让自己现在或将来 惹祸上身么？影响工作发展么？
• 会弄僵自己与他人的关系么？
• 给别人带来伤害么？

宣泄情况应当以不伤害他人为原则

常见的宣泄方式：倾诉(家人，朋友，同事，心里咨询师，陌生人 倾诉，书面倾诉—压力日记)，声音(比如大笑等)，哭，运动(健身，散步，跑步，爬山，羽毛球等)，睡觉，冥想

7. 冲突管理

竞争：高度坚持不合作(强迫政策)，牺牲一部分的利益，换取自己的利益或团队整体的利益，特征是正面冲突，直接发生争吵，争论 或 其它对抗方式，为了取胜不惜任何代价；
回避：不坚持与不合作，双方意识到冲突存在，试图忽略和放弃冲突，不采取任何措施，也不维护自身利益；
妥协：中等程度的合作；冲突双方都让出一部分 要求 和 利益；特征 就是 没有明显的 输家 和 赢家； 

8. 沟通 

沟通 是 无论技术人员，还是技术管理者，都应该必备的被动技能

沟通一般有两个目的：1. 获取 或 同步信息；2.达成共识，得到承诺；

有效的反馈机制：

• 自我评估：项目评估，关键目标分析.
• 下属的反馈：一对一沟通，周期性会议
• 同级的反馈：一对一谈话，邮件等.(同级可以是其它部门负责人，比如测试，产品等)
• 上级的反馈： 主动，持续，周期性的让上级给你反馈.
• 结论：向他人收集反馈，事先准备话题列表，提高沟通效率. 收集反馈信息后，进一笔分析，分出正面，负面. 只有将反馈与经历结合，炼化成经验和教训，才能指导后续的行动，不断进步.

8.1 沟通的几个要素

1. 沟通应该形成闭环
2. 沟通最重要的环节，倾听，第一，体现对对方的尊重；第二，通过聆听别人把话讲完、讲透，更容易理解别人所要表达的真正含义。有效聆听才是沟通中最为重要的。
3. 还有最后一个，需要注意，情绪的控制，一切的沟通是围绕解决问题的，不是争吵，更不是抵触情绪，会给别人留下不好合作的印象.

8.1.1 沟通循环四步

首先是倾听，澄清倾听后的理解，提出自己的观点，最后确认对方是否了解我们的观点.

8.1.2 沟通的三大要素

8.1.3 保持信息一致性

不要进行‘信息过滤’，对上要如实报告，对下要如实传达

8.2 作为技术管理者，日常的沟通分为几种

8.2.1 向上沟通

向上管理以及沟通搞清楚几个问题：

• 表现符合上司的期待吗？
• 上司信任你吗？
• 了解上司的管理风格吗？
• 上司有那些优点吗？
• 了解自己的需求与期待吗？
• 与上司讨论过自己的职业生涯规划吗？
• 了解上司的文化背景吗？
• 适应于多为上司共事吗？

需要做到的几件事情：

• 喜欢你的上级，不要抱怨或者恨他，至少要理解他。积极配合老板完成工作。
• 了解上级的处境，为他排除万难，助他一臂之力，让你的老板工作更有成效。
• 把上级当成鲜活的个体，摸透老板偏好的工作习惯，向老板的习惯靠拢。
• 了解上级的强项和弱点，代替老板完成他不擅长的，无法照顾到的或者不愿意做的工作。
• 让上级知道你打算做什么，不打算做什么，正在忙什么，目前处于什么状态。主动反馈。
• 珍惜老板的时间和资源，不要用琐事耗尽老板的时间和经历。
• 管理双方的预期和目标。上级每年，每季度都会对你又期望。主动沟通，及时反馈，避免造成上级对你的期望和你自己的期望有偏差。

主动，持续，周期性的让上级给你反馈，定期和上级沟通，了解他对你的评价，聆听他的建议（一方面汇报自己的工作，让他知道你的状态，另一方面管理过程遇到的困惑抛出来，请他指点下）.

8.2.2 横向沟通

8.2.3 向下沟通

其实，对待技术人员最要紧的两个字就是——尊重。
如果我们能给他们足够的尊重，他们就一定会配合我们的工作.(其实无论是技术人员，还是其它人，我们都应该尊重别人)
多和下属沟通交流，了解他的生活，工作，真正地关注，关心，倾听对方。（比如聊房子，车子，房贷，喜欢的球星，游戏等等）

可以定期进行一对一的沟通，回避与下属的沟通，就是放弃了彼此了解，建议信任的机会，团队会越来越消极… …

一对一沟通，首先对话前问自己（来自关键对话）：

参考谈话过程：

1. 开始时阐明目的，为沟通定调：比如，“今天想请你帮忙我，我这段时间管理上做的事情有什么效果”。“和你谈谈最近的工作结果，一起讨论下一步工作安排”。等等
2. 分享事实经过和你的想法：比如，“月初引入每日站会… …担心给大家带来负担，因此想…” 。
3. 征询对方的观点，鼓励对方做出尝试：比如，“我想知道你对这件事的看法”。“我希望听你坦诚地讲讲发生了什么事情”。征询对方观点，多用开放式问题。

8.2.4 其它沟通(外部客户或其他合作单位的沟通)

9. 其它

9.1 思考方式

PDCA循环：计划，行动，检查，纠正

复盘：回顾目标，评估结果，分析原因，总结规律

5W2H方法：Why为什么？What做什么？Who 谁做？when 什么时候做？where 哪里做？how 怎么做？how much 做多少？
Why为什么：为什么做这个需求？
What 做什么：需要做哪些事情？
Who 谁：需要哪些人参与？
When什么时候：事件范围和具体日期？事件表？
Where什么地点：在哪里做？
How怎样做:用什么方法完成？计划是怎样的？怎样做完成好？
How much：质量如何？做多少数量？做到什么程度？耗费成本？

9.2 自我营销

所有一切的价值，取决于你能给它人带来如何的价值.
自我品牌风格，写博客(高质量文章)，开源社区，开源库，写书 等等.
品牌符号(统一的logo熊猫，网名 冰雪情缘).
品牌是干什么的？TV开源爱好者.

9.3 自我相关

承担责任：更多金钱还是更多责任，长远看，正确选择应该是更多责任
引人注目：记录活动日志 提供演讲或培训，分享 发表意见 保证“曝光率”
自学：增加技能和知识，培训课程，相应的资质证书，学会分享
成为问题的解决者：解决别人无法解决或不愿意解决的问题
关于办公室政治：不与同事讨论公司与其它同事不好.