技术管理工作
管理者能力
作为技术团队管理者，无论具体管几个人，最好能够拥有以下能力，才能满足各个需求方提出的需求：
- 深入理解一门或多门编程语言
- 深入理解多种流行的框架
- 系统架构能力强，拥有复杂系统的设计经验
- 积极跟随开源社区
- 积极了解业界技术发展
- 沟通能力强、情商高
- 有产品意识，不是技术迷
- 会带人，服从领导，责任心强
- 会写专利
- 再会点别的更好
- 随叫随到、工资不高
工作职责定位
一家企业能够生存，一定是业务开展得不错，作为技术团队管理者我们需要做到技术与业务的融合，需要保证我们的付出可以为企业带来长久的利润。只有成为“技术的业务派，业务的技术派”，才能让技术引领业务，并创造价值。这其实也是技术管理者成熟的标志。
一位管理者最重要的是给团队指明方向，包括技术方向和业务方向，还有个人成长方向。与下属相比，领导者的优势不只在于他的专业能力，还在于他的眼光和胸怀。既然选择做技术管理，你就要有成就他人的心胸，同时还要有超出一般人的眼界，能够给予团队正确的方向。同时，要保持对技术的兴趣，多关注新技术的发展，否则你很难在重大的技术决策上做出正确的决定。
工作品质定位
成熟的人具备一些典型特征，他们重视诺言、不夸夸其谈、有学识而含蓄内敛、心胸宽广、不以自我为中心、勇于承认错误、意志坚定。凭自身的品格、实力与信誉在人群中从容地来去，这样的人流溢着非凡的魅力。成熟的人刚强豁达，待人宽容、知足乐观，他们知道为人处世的原则，懂得如何处理好与朋友、同事的关系。
作为团队负责人，我们也应该有硬汉本色，不能惧怕外在的威胁。团队成员都在看着你，你决不能懦弱，要勇敢。举个例子，很多时候并不是你想团队怎么发展它就怎么发展的，很有可能你的团队刚刚明确产品目标、技术目标，人员也根据这些目标刚招聘到位，正准备大干一场的时候，忽然听说另外一个团队正在做一模一样的事情。别以为这是笑话，很多大公司都存在这类问题，多数原因在于缺少顶层设计（当然也可能是顶层有意设计的，目的是让两个团队竞争）。面对这类情况，你可以选择退缩，转向另外的方向，也可以选择混混日子，等着被解散，但无论哪种选择，你的团队都有可能瓦解。每个人都有自己的职业定位，想做的产品、技术没了，有能力的人就不跟你玩了。我个人更倾向的是，在领导层不明确哪个团队做的前提下，对内组织团队尽全力做下去，而且要做好，对外则勇于承担责任，敢于接受挑战。
作为一名技术团队管理者，你要做的是比别人更早接触新技术，更深入地理解系统架构，全面提高管理团队所需的方方面面的能力，而所有这些都需要勤奋。在
如果不吸取失败的教训，那么失败就仅仅是失败。
无论是绩效考核，还是职位升迁，亦或是问题处理，都不应该由少数几个领导通过闭门会议的形式完成，而应该是通过制定逻辑严谨的规章制度，通过类似任职资格考核的方式完成初步考察，然后通过事情责任制方式明确个人的成绩、责任，最后通过有员工代表、相应部门代表参与的会议讨论决定，这样可以让整个团队朝着健康的方向发展，而不会让一部分人感觉被边缘化，从而滋生小团体。
团队领导者需要具备决策能力，决策能力又是与自身的技术积累，以及吸收新技术、新知识的能力密切相关的，保持一颗开放、积极的心态，保持对技术的严谨调研态度，以数据说话，这样才会做出正确的决策，而不是盲目决策。
我们需要倡导“开放、共享、追求极致”的团队文化。人才是我们最大的财富，所以要建设以人为本的团队文化，创造出沟通顺畅、敢于挑战、喜欢创新的团队氛围。
【为人处世】为了公司、自身的形象，我们需要无比庄敬自强，公平待人，不可欺负弱势的人，也不可以做损及他人或自己的事。同时，我们需要一个谦卑的团队负责人，谦卑的人不会固执己见，而是会虚怀若谷地聆听他人的言论。伟大的人物也不可能整天仰望山巅，他也会蹲下来为他的弟兄濯足。快乐与金钱和物质的丰盛并无必然关系。一个温馨的家、简单的衣着、健康的饮食，就是乐之所在。漫无止境地追求奢华，远不如俭朴生活带给你幸福和快乐。内心能够保持这样心态的团队领导者，在面对很多困难时，因为有家人的支持，有团队的支持，有内心平和心态的支持，会更能克服困难，勇往直前。
【宽容】很多时候，我们确实会面临工作无功而返或者辛苦一年都碌碌无为的情况，但这并不是我们不努力，更可能是产品或者技术的风口还没到，我们走得有点过快了，或者方向有点走偏了。另外一种情况可能是团队成员的个人能力问题，有时候确实会遇到一些思维比较慢的同事，你布置了调研任务，也花费了时间做了详细解释，但是他就是理解错了。这种情况下我觉得需要看这位同事的以往工作绩效，以及他对这项任务的工作态度来做出反应。我常说的是，这个人如果自身能力较弱，不愿承认，那就是作死。如果自身能力很强，也很积极做事，这个时候我们应该多放权，让他自己思考，他也会乐于如此。如果自身能力不强，但是他对自身弱点有认识，工作态度很好，这个时候犯错了，我们不能过度责骂，应该宽容对待，先问清楚原因，然后和他一起分析过程，帮助他成长，只要他成长了，我们的团队整体也会受益。
【终身学习】功利性的学习是非常狭隘的，收获也是非常有限的，但是终生学习的回报却是不可估量的。爱因斯坦曾经说过，复利（Compounded Interest）是这个世界上的第八大奇迹，那些理解并学会使用它的人将最终获得巨大的财富。那些不理解它的人会付出巨大代价。复利的效果不仅可以应用在财富的积累，也能应用在知识的积累上。
记住，一个人只有严于律己，长年累月专注做好一件事情，并且坚持终生读书、学习，才能享有并保持随之而来的成功、荣誉和认可。
【以人为本】如果你有卓越的人才，并给予相应的尊重和鼓舞，让他们能够积极参与工作，那么你会做出卓越的产品。如果你有卓越的人才和卓越的产品，利润就会随之而来。作为管理者，你的工作中很重要的一项；绝对不可忽视你团队的人，并始终要坚持以人为本。
【保持身体健康】虽然我能理解健康的重要性，但经常无可奈何。一个现场问题出现了，我们要一直忙到凌晨，可能偶尔还需要通宵应对。但是空下来以后，一定记得好好睡一觉，把睡眠补回来。因为只有保持身体健康，才能更好地带领团队。
团队建设、人员管理
管理基础
首先聊聊什么是科学，如何定义科学？科学通常需要按照前人的理论和数据继续向前走，深入钻研，管理靠的是个人实践。我不建议在没有准备好的情况下匆忙地转到管理上，你以为进入管理岗就可以学管理，你是拿你的短板和别人的长板比较，一定会遇到很多麻烦。观察、假设、校验，是一切科学实践的基础，管理活动也是类似的，你观察到某位员工最近好像不怎么说话了，产出也没有之前那么高了，就会假设他是不是遇到问题了或者想要跳槽了，最后通过直接沟通或侧面了解检验假设的正确与否。通过不断地刻意训练，慢慢积累自己的管理经验，再想着怎么去拿捏平衡，完成类似艺术形态的进化。
管理团队
【技术尊重】成功地管理程序员最重要、最关键的因素，是在技术层面得到他们的尊重。如果没有技术尊重，那么你的每一个具体想法，都可能会遇到主动或者被动的阻碍。正是由于这个原因，那些在职业生涯的某个时期没有做过程序员的团队管理者，会觉得有效地管理程序员是一件极其困难的事情。
【强化现有的团队】培养杰出程序员。
【团队组成】杰出的程序员需要一群称职的程序员来配合，依赖他们完成日常的开发工作，实现设计好的系统和产品。
【效率管理】明确结果和目标；高效与工具化；高效的组织；
【引导工作】团队管理者的一项重要工作是引导事情走向正确的方向，并确保团队成员之间以及与其他团队之间有正确的沟通方式。需要注意的是，引导的最终目的是为了让事情完成，而不是把关注点放在如何完成上。对于一个团队管理者来说，要想最大化地利用自己的时间和技能，就要引导程序员自己做出正确的决定，而不应该自己就把决定做了。这样做可以帮助下属员工培养技术、积累经验、建立自信，还能获得具体执行决定的员工的认同。
【保护成员】我们要学会保护团队成员，让他们免受组织中的各种问题、争议和“机会”的干扰。在一些稍大的公司内部，官僚主义会通过各种文书工作来忽略或者缓冲每天的各种请求和问题。在小一些的公司里，面对的挑战是各种销售驱动的机会、客户驱动的争议问题，以及管理驱动的想法，你作为团队领导者，可能是他们最后或者唯一的防线。
【任务责任制】应当明确每项任务，确保为每项任务指定一个负责人，推进任务。
【主动沟通】承担并顺利地完成与员工的主动沟通，这是你的职责，千万不要轻视沟通能力，这一能力对你的晋升起决定性作用。两个人只有面对面坐下，看着对方交谈，沟通才不会有障碍。如果你有团队成员在外地或者国外，作为团队主管，你应该主动去拜访他们，并且坚持在那里待一段时间，第一次拜访越早越好。
【被动沟通】如果一名团队成员在你不太方便的时间来找你聊天，一定要先把手上的工作放下，专心跟他交流，他可能想鼓起勇气告诉你一件大事。聊天的内容可能很简单，比如缺少完成任务所需要的相关资料或者技能，也可能很重大，比如即将离婚、家人病重或者其他对他个人有重大打击的事情，而这些事件对你的工作时间表都有重大影响。如果你的团队成员知道自己受到了最高优先级待遇，那么在事情将变得很糟糕的时候，他们来找你交流的可能性就更大了。
【会议记录】记住，没有记录的会议，相当于没有开过。每一个重要会议，都需要有完整的会议记录，包括参加人员、讨论议题（逐一写下来）、讨论过程大体描述、每一个议题的最终结论（包含流程图）、遗留问题、下一次会议时间及议题等。
【人才评测机制】每个岗位级别对技术级别有要求，即技术级别是岗位级别的必要条件。部门内部各级资源主管评定员工是否可以升级岗位级别。岗位级别在部门内是有固定比率的，所以存在一个高技术级别的员工无法担任高级别岗位的可能性，但考虑到人员是流动的，这个现象不太会持续很久。员工在当前项目组表现特别出色，给予直接升级，每个部门有小比例名额，以提高员工在项目中的积极性。可能存在1个部门的14级工资超过另一个部门15级工资的情况，公司每隔2～3年会进行工资调整，避免这种情况长期存在。
产品开发过程管理
经验和教训
开产品或者技术方案会议的时候，大家最容易犯的错误就是，自己先绘制了原型图，甚至产品架构图，直接来讲解自己的方案。这是一个完全错误的会议方式，基本上浪费了所有人的时间。离开这个会议室，懂的人懂，不懂的人还是不懂。当不懂的人去执行的时候，就需要摸着石头过河，再局部找你沟通，从而失去了大局观和整体性，也失去了自己思维模式之外的解决方案。于是，二流的产品就这样出现了。建议需求评审会议可以分为三个步骤：会前提供材料，会中讲解、讨论，会后解决疑问、缺陷。
针对这类需求理解不一致的情况，总结如下：
- 开任何会议，一定不要上来就讲解方案，应该先讲解场景。每个场景先讨论背后的需求并定义清楚，这也是软件本身的意义——模拟业务；
- 大家一起讨论，研究这个场景背后的需求是不是最佳场景，能不能删除这个场景，或者是否有其他场景可以代替这个场景同时还能满足背后的需求；
- 如果是需求的最佳场景，再开始讨论这个场景下的产品解决方案；
- 这个时候你打开事先设计好的产品原型图、产品流程图、状态图、用例图，你会发现有很多需要修改，修改之后就是大家一起生成的方案。
开发进度管理
为了有效控制进度，开发经理需要请各个小组每天召开“晨会”以检查昨天工作进展，并且布置当天工作；另外，每周五下午召开周例会，项目组全体成员都要参加。
晨会
晨会的检查基准是各个小组的底层计划，以检查和确认为目的，不展开讨论。晨会规定在15分钟以内，每个小组的成员站在白板前面完成。第一步，检查状态。成员逐个说明昨天任务的完成情况，今天计划的工作任务，以及遇到的问题。第二步，调整计划。根据昨天任务的完成情况和个人任务的调整，小组一起对“底层计划”进行适当调整，确定当天每个人的工作任务。第三步，解决问题。首先审核昨天列出的问题的状态。然后，将今天每个提出的问题记录到白板上。除非可以当场解决的简单问题，否则不对问题展开讨论，只记录到白板的问题栏。会后由相关成员讨论问题的解决方案，或另行安排时间组织专题讨论。
周例会
周例会检查和调整项目计划，关注的问题是：任务完成了吗？没完成的原因是什么？怎么调整？先确认了状态，再讨论该如何调整工作或计划，并一定要落实到具体的行动方案上。
产品质量的重要性
质量是一种管理，是一种控制，是一种预防。只有成熟的组织，成熟的团队，才能做出高水平的产品来。质量就是你的最高水平，以及你对用户理解的最高水平。你只有发挥出自己的最高水平，并且全身心投入，从根本上解决问题，才能带来更好的用户体验，更好的质量。
架构能力培养
应用架构是从业务到IT转换的第一步。应用是对（系统）能力的分组，实现业务功能并且管理数据。应用架构描述这些应用之间的结构和逻辑关系，应用架构设计的一条重要原则是技术中立，也就是说应用最好是技术无关的。同样的，技术架构是描述支撑应用的技术实现的架构，比如技术标准、平台架构的设计、硬件基础设施的架构设计（比如网络拓扑）、系统请求响应的处理过程等。应用架构师必须是业务专家，直接承接从业务到IT的转换。应用架构师是否能做技术协调管理就要看分工和能力了。
应用架构师的职责不同于网络架构师，网络架构师“不求有功，但求无过”。应用架构师架构的目的是直接为企业创造价值，为企业发展提供动力，提高管理水平。因此，应用架构师在进行架构时要充分理解用户的需求，准确定义用户的需求，通过与用户交流从而为他们开发综合的解决方案。应用架构师在架构过程中会在不同程度上影响人员、流程和技术，一旦他开始进行架构的构建，就是在创造一种环境和条件，让流程更加有效、高速和符合用户的需求。如果说CIO的工作是一个从无到有的过程的话，那么应用架构师就是一个从有到优的过程，要通过统一的规划管理使企业的IT资源发挥更大的价值。
个人层面需要不断地输入，学习新的知识，保持对行业、领域内新技术的更新。看论文可以被认为是架构修炼的一种方式，因为很多论文写得比较严谨，也比较系统化，了解一个系统实现的细节对于架构方面的成长很有好处。
从一个程序员到架构师是一个很大的变化，架构师需要从大的方面考虑，而不只是考虑这个模块该用哪种设计模式去开发。总的来说，想要成为架构师，需要有耐心，不断学习，拓宽自己的视野，不要局限于自己眼前的项目，多关注开源技术，多关注热门技术社区的新动态。