技术管理一直是行业中热点，先有技术后有管理，技术好做，管理却难做，技术管理更难做。坦白说，技术管理岗既要保证自己的技术说服力，又要经常上一线工作，还要从管理上给予团队支撑，对于任何一位程序员来说，都不是那么容易理解和执行的。
一、引言
程序员不会带团队，就只能一辈子写代码，虽然写代码并没有什么不好，但是大多数程序员不愿意这样过一生，这也许是国情决定的。程序员要带团队，要成为技术团队的领导者，必须在技术和管理两个方面有所长。技术方面，要以CTO为榜样；管理方面，则应该像CEO一样思考。具体来讲，要成为技术团队的领导者，要具备多项综合性的能力，如：
- 技术开发能力：熟悉各种主流开发技术，精通其中部分关键技术；
- 项目管理能力：能主导和管理项目开发的全流程，并应对过程中发生的各种突发情况；
- 产品研发能力：熟悉产品研发的生命周期管理；
- 技术选型能力：能正确地对新技术方案进行调研和预研；
- 系统架构能力：掌握系统的软件架构方法论，熟悉各种常见软件系统的架构与设计方法；
- 团队管理能力：能正确地识人、用人。
二、作者简介
作者周明耀，海康威视高级技术专家（海康威视是AI和安防领域的龙头企业，最近被美国总统 Trump 列为重点监控公司），有超过10年的技术团队管理经验。也是一名IT技术狂热爱好者，一名顽强到底的工程师，推崇技术创新、思维创新，对于新技术非常热爱，致力于技术研发、研究，通过发布文章、书籍、互动活动的形式积极推广软件技术。著有技术畅销书《大话Java性能优化》、《深入理解JVM&G1 GC》。
九三学社社员，九三学社杭州青年工作委员会委员。
三、书籍内容
该书总共5章，5个章节内容相互独立。分别从技术管理工作概述、如何进行团队创建及人员管理、产品开发过程管理、技术调研/预研工作介绍、系统架构相关知识介绍如何具备技术领导能力。
2.1 技术管理工作
话说，技术管理这个话题是我这几年一直关注的，为什么会这样？因为带着专业技术能力的管理思维和思路，它是伴随着个人经历、周边影响、行业变化等等各种因素干扰的，每一次思考都会有新的理解产生，这是正常的，当下是技术变迁的大时代，没有谁能够固步自封而善终。
做好一名技术团队管理者，技术指的是实际的技术能力，例如全栈工程师就比较容易掌控技术团队，因为自己的过往经验确保了什么都懂，但是这个实际上不容易做到，而且，即便当下做到了，一旦脱离一线开发时间太久，过往的经验也就仅剩下经验了。产品指的是按照产品思维输出技术，很多一线技术经理实际上没有这个能力，所以容易导致技术和产品的脱节。管理指的是对于团队的软性管理方式，这一点很多技术大牛出生的技术经理会觉得很虚，内心充满了看不起的态度，觉得技术好才是第一位，这一点理解是不准确的，技术固然重要，但是缺乏职业化的管理思维，这个人更应该做技术专家，而不是技术团队管理者。
技术团队管理者需要培养的能力
克服从众心理。刚开始做技术管理时，有些事情决策时自己心理没底，就会出现自己没主见，人云亦云。勿求十全十美，自己做了新的主管，要好好表现，就会出现事情决策追求完美，追求细节，却苦了开发的兄弟。敢于挑战，喜欢创新。对公司老的体制，做法流程，有自己深度的思考，并且尝试优化或颠覆掉，或采用新技术，成倍的提高开发效率。包容下属的缺点。俗话说疑人不用，用人不疑。保持健康的身体。
找到属于自己的圈子
“成为管理者后要能够发现并组织一个属于自己知识交流的圈子”圈子分为工作内和工作外：
- 尝试参加各类技术管理论坛，交流管理技术经验
- 加入相关的线下组织，学习组织，提高各方面的知识，经验，眼界，胸怀
如何时成为技术管理者
“先打好技术基础，当你觉得每天只有50%时间可以做技术的时候，但你还是能够紧跟技术，甚至比你的大多数下属都了解细节的时候，你就可以尝试给自己加上技术管理的工作量了”。
不做“烂好人”的领导，要做有成绩对老板负责的领导。乔布斯被称为暴君，但做出了苹果。好领导应该是：“和他共事，绝对不会轻松，他不会给你讲段子哄你干活，也不会笑眯眯的安抚你的情绪。每周例会，是一场例行考试，每个人都小心翼翼，如理薄冰。评判一个管理者的好坏，不是看测验的民意，而是看输出的成绩。良好的干群关系和群众基础，有助于达到目的，但却不是最终目标，一个好的经理人，就是要做出好成绩，对老板负责。一个好的CEO，就是要做高利润或股价，对股东负责。这才是职业素养，这才是商业的原本逻辑”。
技术团队管理者，应该具备的能力：
- 深入理解一门或多门编辑语言
- 深入理解多种流行的框架
- 系统框架能力强，拥有复杂系统的设计经验
- 积极跟随开源社区
- 积极了解业界技术发展
- 沟通能力强、情商高
- 有产品意识，不是技术迷
- 会带人、服从领导、责任心强
- 会写专利
- 再会点别的更好
- 随叫随到
- 终身学习
一个人一生如果想要获得国人的成就，就注定于读书和终生学习形影不离。功利性的学习是非常狭隘的，收获也是非常有限的，但是终生学习的回报却是不可估量的。我们也许没有办法决定我们的出身和阶层，但是我们每个人都可以通过读书和终生学习，为自己塑造一个优秀的人格，实现个人的价值，提升和阶段突破。
2.2 团队创建及人员管理
我们要懂得，欲管理人，必先了解人。程序员之所以难管理，在于他们有着各种不同的个性。“管理人员是与人打交道，其任务是使员工能够协同工作、扬长避短。”
组建团队
“一流人才招聘一流人才，二流人才招聘三流人才”-乔布斯。组建一团队的基础是需要雇佣合适的成员。一支整体作战能力较强的开发团队，它雇佣的员工需要具备以下几点素质：
- 职业素养
- 做事专注
- 乐于挑战
- 永不气馁
- 承认错误
管理者首先必须学会管理程序员和软件团队的技巧，换言之，必须学会了解员工，包括如何聘用他们，激励他们，进而领导他们开发并交付出的产品。
STAR面试法
背景（SITUATION）:通过不断提出与工作业绩有关的背景问题，可以全面了解该应聘者获得优秀业绩的前提因素，从而获知所取得的业绩有多少是与应聘者个人有直接关联的，有多少是与市场的状况、行业的特点有关的。
任务（TASK）：每项任务的具体内容是什么。通过这些可以了解应聘者的工作经历各经验，以确定他所从事的工作与获得的经验是否适合现在的职位。
行动（ACTION）：了解他是如何完成工作的，都采取了哪些行动，所采取的行动是如何帮助他完成工作的。通过这些，可以进一步了解他的工作方式、思维方式和行为方式。
结果（RESULT）：每项任务在采取了行动之后的结果是什么，是好还是不好，好是因为什么，不好又是因为什么。
如果候选人在某个领域有很大的影响力，那么久没必要花两个礼拜的时间才把他们招进来。如果动作慢了，你就有可能错过优秀的候选人。
面试的人实在整个公司使用的，不是只给自己使用的，所以需要对技术严格把关，加强责任心，只录取技术能力过关的、性格适合做技术工作的人，不要受自身情绪影响，导致录取不合适的人。
管理团队
管理团队：向下管理、向上管理、对外管理、自我管理
最终目标：不要让你的下属陷入困境，不要让你的同事陷入困境，尤其在任何情况下，都不要让你的上级陷入困境。
“如果你想要建造一艘大船，不要立马好找大家开始收集木材，也不要立马分配任务和工作，而应该先教会他们憧憬广阔无垠的大海”
向下管理
成功地管理程序员最重要、最关键的因素，是在技术层面得到他们的尊重。
杰出的程序员需要一群称职的程序员来配合，依赖他们完成日常的开发工作，实现设计好的系统产品。
向上管理
向上管理指的是如何有效管理你的老板以及你要汇报的那些人。还需要弄清楚如何汇报、如何沟通，以及要采取什么样的行动，才能让你的老板认为你是一个高效而成功的员工。管理老板看起来是一件比较奇怪的事情，但实际上成功地管理好老板可能比管理好你的团队还重要。
- 了解老板：清醒地评估如何高效地与老板进行沟通
- 准备讨论内容：仔细挑选问题，只拿那些真正重要的问题去寻求老板的帮助
- 主动承担：当问题出现时，你可以尝试主动自荐，帮助解决问题。
不要把每一个问题都带到你老板那里寻求解决方案，仔细的挑选你的问题，只拿那些真正需要的问题去需求你老板的帮助。你可以非常好地管理团队并完成项目，但如果没有你老板为你护航，你的职业前途必然坎坷。一定要主动，做好向上管理，可能会得到更多的职业回报。你损失的只是时间和精力，但能得到的却更多了
进度管理
最高效的团队管理往往都是最坦率的，也往往对下属有足够的时间，能让员工找到他们并说出自己的想法，他们会认真倾听。如果组织中每个人都照章办事，不乱插队，整个组织就是高效的。如果每件事情都有位移的责任主体，出了问题能够快速找到问题根源，组织就会更加高校。
从长远来看，一些不紧急但是很重要的事情，如果迫于压力被放下，到后面往往需要花费好几倍的代价弥补回来，技术管理者需要时刻保持警惕，慎重地决策，做正确的事情，要能够为公司的长远利益负责。如果你发现自己经常需要讨论非常具体的命令以及如何执行，说明你没能很好地利用你的管理技能，或者没能赋予下属员工足够的权利
作为团队管理者，你必须指出大方向，然后做好充分的检查，以确保员工做出正确的决定并实践。优秀的主管要有足够的自制力，不再下属工作时瞎指挥。
管理禁忌
不懂技术的人如果做了研发团队的领导，很容易出现严重的问题。不懂技术的人很容易完全从产品角度考虑，忽略研发团队面临的困难和风险，忽略技术人员对技术的憧憬，造成团队超负荷工作、技术团队缺少技术愿景等情况发生。
遇到业务方提出的需求完成时间点过于苛刻的情况(其实就是一个压力传导问题，业务方收到了客户的压力，本来可以通过向客户解释来减少研发的压力和风险，但是选择直接施压研发)。这时候，你的这我不懂技术的团队老大可能会说，没关系，我们一开始并不需要一个完美的系统，你先上了再说，我们后面有时间再重构和完善(当然有的技术人员也会用“架构和设计师逐步烟花出来的”，这句话来证明“故障驱动”开发是值得的)，这样的想法本质上是错误的。
敏捷开发的实质是为了解决需求快速变化的情况，需要快速响应需求提出方，快速搭建产品原型用于验证实际效果，而不是说有了快捷就可以忘记软件工程理论。任何软件工程模型，都不会允许在需求完全不明确、描述不清楚的情况下，开始进行技术方案设计，也不会鼓励在方案设计确实的情况下开始编码。
一言堂： 技术团队如果出现喜欢搞一言堂的领导，逐渐会形成他的个人特权，刚开始不会让人感觉恶心，但是逐渐地他会越来越肆无忌惮，知道团队中有个性的、有能力的人全部离开，只剩下一些实在走不掉的、很能忍的，那么这个团队的整体战斗力就变得很弱。作为一名团队管理者，有一点需要做到：“不要作恶！”
频繁开会：会议规模越小越好。每个会议都必须有一个决策者。如果没有决策者或者会议中无法产生决策，这个会就不应该开。如果没有紧急的事，员工就有机会取消会议，也能让员工知道这是他的会议，占用的时间完全去决议他。因为是员工的会议，经理的发言应该只占10%的时间，剩下的90%都是倾听。
新员工
团队管理者一般都要负责为新员工寻找工作定位。需要考虑团队现有的人员配置，还要考虑到新员工的工作职责，以及团队领导、技术领导和架构师的座位。
老员工
管理者遇到的一个最典型的、最纠结的困难就是老员工处理问题。团队成长过程中必然有老员工和新员工，老员工甚至可能是你的朋友或者前同事。这种情况下，文化管理尤其重要，一旦管理不当就会出现很大问题，我们可以称这种情况为预期管理，预期如果没有管理好，有些人就会产生失落感，甚至对公司的方向和文化产生质疑。一旦一位卓越的员工对公司文化产生质疑，后果将会很严重。
一般情况下，初始团队都是金子，偶尔也会有一些铁存在，在中国，铁可能就是老朋友，“铁”，跟不上公司发展的老员工。团队中每个人在发展方向不一样，但有一个共同点，大家都希望朝着金子的方向走。
在公司发展快速的阶段，管理者却因为这个人视朋友或者老员工而忽略沟通，这时候老员工会产生失落感，而失落感将直接影响到一个人对公司的态度。
在公司快速发展过程中，铁非常重要。
相比较财务自由而言，当代社会更多的是应该看是否能力自由。
团队成员品质
一般可根据团队存在的目的和拥有自主权的大小将团队分为三种类型：问题解决型团队、自我管理型团队、多功能型团队。
组件一支团队的基础是需要雇佣合适的成员。不要贪图小利，一个人的职业素养非常重要，让别人觉得你的职业素养有问题，你的职业生涯也会很危险。专注的人，更容易获得成功，只有全力以赴才能精通。在工作中你一定会遇到各种各样的挑战，你所需要的是积极地迎接、应对这些挑战，而不是每次都退缩，越退缩就越容易失去机会，失去让自己过上自己喜欢的生活的机会。
永不气馁、承认错误
不管你做出多大努力，这个问题是不可避免的；在声明的某个时候，你会犯错。敢于承认错误，并积极地弥补错误所造成的损失，是一种非常可贵的精神，
忠诚
纵观当今巨头，如BAT，华为，各岗位的负责人，哪个不是在公司工作十年以上。大型团队的管理者：最好的方式从内部培养。如果从外部招聘，你需要了解他的管理风格，并成功交付项目的实际经验，还有稳定性。而对于小微企业来说，忠诚度更为重要，有的甚至会因人离开而导致公司运行不下去。
2.3 产品开发过程管理
理论好比是教人如何在地图上规划一条路，而实践则好比是要在现实中一步一个脚印地走完这条路。理论与实践之间的这个距离，是成为一名成熟的开发经理所必须跨越也是最难跨越的鸿沟。工程延期、Bug丛生、沟通冗长、人心浮动，这些现象可能是因为开发经理个人管理能力不或经验不足，也可能是整个细分行业不够成熟，没有形成方法论，造成各种混乱。其实这种现象在全球IT行业都是普遍存在的，需要大家一起透彻地总结、分析、实践。
开发经理的职责
- 对产品开发全过程进行组织和管理，按预期交付产品开发的成果
- 管理产品开发团队，为成员提供技术和业务上的支撑，使之高效而愉快地工作，并获得最满意的工作体验
- 管理对外关系，以取得外部对交付成果及过程的最满意评价
开发经理的素质
- 领导力
- 责任心
- 积极主动
- 抗压能力
产品开发过程全管理细节
研发管理体系框架一般包括概念、定义、设计、实践、验证，移交、维护等多个步骤。
项目启动会
目标：项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的，它与计划相辅相成，目标指导计划，计划的有效性影响着目标的达成。所以在执行目标的时候。要考虑清楚自己的行动计划。知道怎么做才能更有效地完成目标，否则，目标不清晰或是过高，都会影响项目的实际结果。
准备工作
在项目启动会之前,我们需要和用户沟通并明确用户需求。项目启动会需要说明项目目标、阶段划分、组织结构、管理流程等关键事项,并将这些内容写入PPT (最好是有固定格式和范文,让团队内部或者公司内部共同遵守),注意,这些事项需要达成一致意见。对于关键角色任命,事前也需要听取相关领导和项目主要干系人的意见。
参加项目启动会的人员包括部门高层领导、外部主要干系人,还包括团队资深经理、核心人员。
过程及议题
项目启动会一般由开发经理主持,议程如下:
- 介绍议程和来宾;
- 介绍项目目标、阶段计划、管理方法;
- 发布项目的组织结构图；
- 确认关键角色及其职责,并作出承诺;
- 参会人员针对介绍内容进行提同交流;
- 高层领导做项目动员发言,激励和鼓舞士气;
- 各个相关部门领导表态支持项目工作。
项目启动会后,会议的内容需要整理成《项目启动会纪要》。纪要中记录了项目的启动过程、项目组成员的承诺、各级领导的明确表态等。这份资料作为项百的第一份正式公告发布,同时宣布项目正式启动。意见的统一,是项目成功的关键,项目启动会、项目例会有助于统一项目团风的思路，使团队更为团结，也有助于提高团队士气。
经验和教训
启动阶段多方面工作混杂进行,开发经理容易忙乱,这个时候,需要迅速建立组织架构、明确分工,大家分头工作,然后再着手制定后续详细的项目计划。
项目启动会准备阶段,最好请一个有经验的专家一起参与,帮助开发经理落实很多关键环节,也需要组织团队内部进行讨论,确保在项目启动会上能够流利地回答参与领导提出的各种问题,包括技术类、产品类,这样有利于启动会之后各项工作的顺利开展。
项目启动会非常重要,其意义不仅在于宣布项目启动,而且是确认人员到位的关键时间节点。会议邀请涉及部门的高层领导出席和表态,可以让项目后续的推进获得广泛的支持。项目启动会一旦顺利通过,需要立即着手进行产品需求讨论、编写。
用户需求
为什么既要有用户需求,也要有产品需求?因为两者是有差异的,用户需求由用户提出,对技术一般不描述，只描述产品目标。产品需求是根据用户需求转化而来的技术实现需求，需要针对用户提出的产品目标进行细分，总结出具体的功能点,再针对每一个功能点细分为各种不同的操作流程，对每一个操作流理进行技术化定义。用户需求和产品需求容易产生差异，这是因为虽然大家都在谈需求,但是出发点可能不同,造成了双方关注点和思维方式不同。用户需求关注的是系统如何支持业务流程,背后的需求是“实现业务目标”。技术人员关注的是合理技术方案,背后的需求是“工作量"“实现难度”和“系统性能"
需求理解不一致
很容易出现的一种情况是,产品经理和技术人员不在一个频道上,所谓的征询意见完全是牵引式问答,你得到的永远是沉默式认同。
此时,整个方案的水平完全取决于讲解者一个人的水平,而对于一个非常复杂的方案,一个人是基本搞不定的,哪怕是非常优秀的产品经理。因为只有讨论才能产生灵感,才能发现自己未曾发现的需求,这就是头脑风暴的优势。
召开产品或者技术方案会议的时候,大家最容易犯的错误就是, 自己先绘制了原型图,甚至产品架构图,直接来讲解自己的方案。这是一个完全错误的会议方式,基本上浪费了所有人的时间。离开这个会议室,懂的人懂,不懂的人还是不懂。当不懂的人去执行的时候,就需要摸着石头过河,再局找你沟通,从而失去了大局观和整体性,也失去了自己思维模式之外的解决方案。于是,二流的产品就这样出现了。建议需求评审会议可以分为三个步骤:会前提供材料,会中讲解、讨论,会后解决疑问、缺陷。
针对这类需求理解不一致的情况,总结如下:
- 开任何会议，一定不要上来就讲解方案，应该先讲解场景。每个场景先讨论背后的需求并定义清楚,这也是软件本身的意义-模拟业务;
- 大家一起讨论,研究这个场景背后的需求是不是最佳场景,能不能删这个场景,或者是否有其他场景可以代替这个场景同时还能满足背后的需求;
- 如果是需求的最佳场景,再开始讨论这个场景下的产品解决方案;
- 这个时候你打开事先设计好的产品原型图、产品流程图、状态图、用图,你会发现有很多需要修改,修改之后就是大家一起生成的方案。
2.4 技术调研/预研工作
在做决定之前，有没有做足充分的技术调研、产品调研工作，能不能尽量详细地说清楚已有框架、产品的实现原理、优缺点、是否适用于你的产品场景等，这些都是前期技术调研的工作，也是体验我们脚踏实地做事的一个环节。
技术方向需要通过技术调研、技术预研来帮助团队成员逐步认识、理解和痛，这是一个必然的过程，技术团队领导应充分重视并直接参与。
为什么需要进行技术调研。
技术调研和技术预研是存在一定差别的,主要是立项时所处的环境、目的等存在差异,总结起来可以简单用一段文字描述:技术调研是针对粗粒度需求实现方案进行的研究,很有可能对所需技术根本不清楚,需要通过调研项目来完成技术了解、技术选型、技术可行性分析、技术方案设计等工作。技术预研是针对细粒度需求的实现方案进行的预先尝试,主要针对的是通过技术调研所选择的技术,同时结合我们产品化时的实际需求,对实现时存在的不确定性因素、细节等进行预先研究、尝试,从而减小产品化过程中的技术实现风险。
正是由于所处环境、项目目的的不一致,由此产生的技术调研报告和技术预研报告的内容也会差别较大。技术调研报告首先阐述从需求整理到明确方向再到搜索技术调研方案及初步筛选的过程及结果,接着介绍具体的测试方案确定、测试环境搭建、测试用例编写及运行的过程,最后针对调研项目中得到的一些实质业务场景下的运行数据进行对比、分析,通过解释数据产生的原因来明确下一步计划。技术预研首先根据细化的需求(有可能是产品化需求的一部分难点需求)对系统整体进行定义,接着通过列举方案明确本次预研论证过程,再通过论证程反复执行列举、论证、推翻、再列举这一过程，最后是对本次预研获得的最终结论进行总结。
从最终的输出报告来看,技术调研一般针对每一项技术都会有一份单独的最告,然后汇总成一份调研报告(对各项进行汇总、对比、总结),而技术预研-般只有一份报告,通过这份预研报告说明预研项是否成功,是否可以采用该种案、技术并进行下一步的产品化立项。
为了更好地设计系统、理解技术，你一定要组织调研项目和预研项目,这是因为你或者团队不可能什么技术、框架都懂，更何况技术发展非常快，只有针对技术进行调研、预研，才能够真正跟上技术发展的潮流，否则终有一天你会被技术岗位淘汰。
什么是技术调研,具体的思路、过程是什么样子的
想要做好一个技术调研项目，要了需求、挑选技术，还要进行技术可行性分析、测试、输出分析结果。
了解动机，除了自已发起的技术调研外，其他技术调研也需要先了解需求。“了解需求”这是一个人尽皆知且每个人在技术调研前都会去做的一件事。但很多人在这阶段上栽了跟头。
收到调研需求之后，我们需要整理并明确整个调研项目的背景。为什么会有这个技术调研项目存在?这一点肯定是有答案的,例如不满足用户的高兴发需求、不满足用户对于各种Chrome浏览器的支持。明确了用户背景,就很容易被述该项目提出的背景了。
明确目的：了解了调研动机之后,接下来,需要明确本次调研项目可能涉及的具体内容(可以不明确,通过模糊搜索方式进行初步筛选即可),确定调研过程中对各个技术的差异点、技术实现原理进行总结,并通过测试数据、数据对因分析,分析哪种技术或者框架适用于用户提出的实际需求。这些都是调研的目的。
调研的过程是怎么样的、为什么选择这些技术作为调研方向?
- 这些技术分别是什么?
- 技术调研方案、用例分别是什么?
- 各个技术或框架之间的区别是什么?
- 各个技术在通用场景下的优缺点是什么？
- 各个技术在用户提出的特定业务场景下的优缺点是什么?6)根据得出的测试数据,为什么会有这样的结果?
什么是技术预研,具体的思路、过程是什么样子的。
在产品规划的指引下,难度较大的关键技术的预研将在项目立项之前以技术预研项目的方式开展。待项目正式立项后,难度较大的关键技术已经攻克,后多产品开发团队的职责是集中更多资源,在非常短的时间内开发高品质产品并椎向市场。这就是预研项目的意义。
了解动机
立项预研项目之前,我们需要首先明确以下两点:
- 是否需要立项预研项目:你所困惑的是不是属于预研项目范畴?技术上一定需要预研吗?
- 是否有实际的需求:你目前技术上或者方案上满足不了了,必须预研!
立项预研项目一定是有背景存在的，大多数情况是当前的技术或者方案无法满足用户需求,或者一个全新的产品形态在产品经理脑海中出现,经过头脑风暴发现还存在若干技术或者方案选型难点,如果贸然立项,很有可能出现产品开发延期的情况。因此,需要在产品开发项启动前,明确存在疑惑的技术点。这时候，预研项目就可以启动了。
也有另外一种情况。在技术或者方案调研完毕后，我们列出了下一步计划，一般来说就是预研项目计划,即对调研项目所产生的成果物进行进一步的实践，通过局部实现方式验证调研过程的正确性。
无论哪一种,最终都来源于需求。没有需求,什么都不会启动。
明确目的
首先需要了解用户需求,例如用户提出需要系统具备横向扩展能力,这一点就是很明确的需求。了解需求后,我们需要对现有系统进行剖析,是否支持横向扩展,如果不支持,是哪里存在问题,逐个模块分析后找到最终原因。接下来需要对当前情况进行解释,最好配有设计图或者测试数据,这样可以让读者更加直见了解当前情况。
情况了解清楚之后,我们可以讨论、总结预研目的,例如提出一种新的系统架构方案、采用新的开源框架等,最终的目的是满足用户的需求。因此,不能满足户求的预研项目成果是无效的。
确定步骤
预研项目一般来说分为以下几个步骤:
- 搜索预研需求
- 明确预研目的。
- 确定预研方案,需要针对各个方案(包含当前方案)进行各维度对比,指出每个方案的设计和实现原理,指出存在的不足。然后结合方案进行具体的实现,并测试数据。
- 根据方案的对比、测试数据对比,我们可以明确提出的方案是否适用于用需求,如果适用,可以推荐进行产品化立项;如果不适用,需要找到备选方继续预研。如果实在找不出来(这种情况很少出现),需要反思用户需求是否合恩,可以继续采取头脑风暴方式。
2.5 系统架构
软件技术学习到一定的程度后，会面对软件架构师这一门槛。一直以来，在软件行业内部，对于什么是架构有很多的争论，每个人都有自己的理解，甚至很多架构师一说架构,就开始谈论应用架构、硬件架构、数据架构等。而事实上,架构在软件发明前就早已存在了。由于众说纷纭，莫衷一是，于是大家产生了很多困惑。软件并不是虚无缥缈的东西，它和现实生活是紧密相关的。业务和架构都是处理人的问题，只有和人的问题联系在一起，才是真正的系统架构设计。
系统架构
说到软件架构，很多人会认为获件架构就是一堆框架的给合,其实不对，软件架构本身是对干放件实体组织形式的阐述,使用框架的意义是快速软件架构的设计,不是取代软件架构设计,两者本质上是不一样的，它们的关系像是设计图纸和所使用的原材料的关系。软件架构就是通过对软件生命周期的拆分，在符合业务架构的前提下，达到软件本身访问增长目的的方式。这个增长需要软件研发的增长，也需要软件运行的增长,进而支撑业务的增长。
软件架构离不开软件开发团队的组织架构，这个组织架构是软件开发生命周期和软件运行生命周期的执行者。离开了组织架构,任何软件架构设计都是纸上谈兵，因为架构的核心生命周期就是架构的执行。
严格来说,只有业务才会进化,架构是支撑业务长大的。业务的核心生命周期相当于架构树的主干,主干没有变化,则说明没有变成一棵不同品种的树，因此只有架构的拆分不能叫作进化。随着架构拆分得越来越细, “树”长得越来越大，并行度越来越高,业务也就长得越来越大。
为什么需要架构师?
我们需要有人能够回答这些问题:
- 我们这个系统的边界是什么?
- 我们系统由哪几部分组成?
- 各模块之间怎么通信?
- 选择什么样的基础技术?
- 为什么要这样选择?
- 技术方案未来会遭遇哪些坑?
- 我们的备选方案有哪些?
- 从技术角度这个应用将来如何持续扩展功能?
这一系列的问题归咎为规划,因为做所有事情都需要规划,对于研发流程面言,规划阶段就是我们的总体设计阶段。
架构师职责
架构师要解决的问题都是人的问题。更进一步,架构师要解决的问题基本都是别人的问题。别人的问题解决了,架构师自己的问题才能解决。任何找上架构师的问题,基本都不是真正的问题。为什么呢?因为如果是真正的问题,提问题的人肯定能够自己解决,不需要找架构师。因此,架构师都要有觉悟,理解并发现问题永远比解决问题更加重要,遇到问题首先进行分析,不要急于解决问题。
谁是架构师
一个开发团队的领导,如果不能在架构方面给出意见,那就不能在整个设计环节给出自己的观点或者对团队进行指导,也就可能会在整个软件开发流程中脱节,进而丢失自己的技术领导力,也就做不成技术管理者。一名优秀的技术管理者,技术在前,管理在后,并不是说两者有太大的轻重差异,而是你需要花费70%的时间在技术上，只能花30%的时间在管理上，但是你需要用这30%的时间做完100%的管理工作。技术、管理,一样都不能差,架构能力也是一样。因此,一个好的领导就是一个很好的架构师。
当然,也可以有另一种方式来允许架构师角色独立存在。架构师可以由专门的个人或者团队组成,他们承担新技术、框架的调研工作，负责对用户提出的需求进行评估，采用新的技术做出产品原型、输出技术调研报告,供产品部门在技述选型和技术架构选型时参考，这也可以体现架柯师们水平和贡献。
软件架构师的责任
一个软件往往因为某个业务需求而产生,后续不断更新、修改,逐渐变异、长大,当该软件不再被需要(因为业务的消失)或有更好的软件来替代时就会被废弃，完成使命而消亡。软件的整个生命周期也会发生切分，从而形成两个子生命周期,即软件开发生命周期和软件运行生命周期。
作为软件架构师,必须时刻把对软件生命周期和业务生命周期的识别放在第一位。软件生命周期的核心在于软件运行生命周期,以及围绕软件运行生命周期的拆分和组织,业务生命周期的核心在于围绕业务核心生命周期的拆分和组织。
对于软件生命周期,必须要深入思考软件开发生命周期和软件运行生命周期。在这个基础上,要根据业务的情况合理地进行软件开发生命周期的架构拆分和软件运行生命周期的架构拆分。软件开发的拆分和软件运行的拆分的目标都是支持业务流量的增长。
架构在软件发明前就已经存在很久了,我们应该多向大自然、艺术界、建筑界学习架构的概念，因为软件并不是虚无缥缈的事物,它和我们的现实生活是紧密相关的,它来源于生活,最终又通过软件服务回到生活。企业软件架构的设计不仅要注重某一个系统功能,更需要给企业一个可进化的、可持续发展的、不断创新的平台。
团队达到一定规模之后,技术管理者(也可能有独立架构师存在)的大部时间就需要花费在思考上面了,当然也可以继续编程,但是编程的目的是验证架构是否合理,所以不要受是否需要编程这一思维的束缚。如果设计得不好,那么团队就会走很多弯路,如果想要设计得很好,你必须自己或者带领团队做很多的测试、预研工作。作为架构师、你需要多多思考,很多时候因为很忙、事情很多,导致真正思考时间太少了。
我认为该本书对软件开发的规律、流程、团队建设总结的很好。对一线的技术管理人员和想要成为技术管理人员的程序员有很好的指导意义。也可以学习如何搭建公司技术部门的组织架构，选拔合适的人才担任技术领导岗位。
三、序言整理
如何才能带团队，如何才能带出好的团队，是每个程序员都应该思考的问题。带领团队的能力，可能会成为每个程序员晋升的瓶颈。看看几位的点评：
3.1 序一 - TCL医疗集团产品中心总经理（贺军）
要做领导者，面对的不仅仅是技术问题和解决方案，还需要面对上级、下属、同级别同事、客户等各种各样的人群和各种各样的事件，这时候只有高智商和强逻辑性就远远不够了。要成为一个真正好的技术领导者，除了热爱技术、功底深厚之外，还需要不断提升眼光（眼界）和决策能力，修炼勇敢、真诚、公平、开放、包容的态度，修养个人魅力。从组建团队开始，以人为本，从心出发，平衡 “管”和“理”，并从中探索自己的管理哲学、方法论和行为准则。
3.2 序二 用管理的方式做技术 - 特赞科技CTO（黄勇）
“技术人员大的发展瓶颈是什么？” 当时我认为是技术方面入门容易，但深入很难，或许加强技术深度就是技术人员大的挑战。随着工作经验的积累，做的东西多了，接触的面也广了，加上对技术一直抱有由衷的激情，自己在技术深度与广度方面都有了明显的提升，也形成了一定的质变。但是，此时我更加迷茫了，到底应该如何走好自己接下来的技术之路呢？继续将技术深入下去，还是从技术转到管理？也许我曾经面临的这个问题，大家目前正在经历中。
技术就像无底洞，我们在洞口目测该洞可能只有10米深，但当我们走到10米深处时，却发现可能还有100米才能走到底，而且越往深处走，越感觉深不见底。如果感觉自己已经走到了深处，那里可能没人了，但某天也许会发现，还有更多的人比我们走得更深。
技术就像武功，人外有人，天外有天；但技术也不全像武功，它依靠的不是单打独斗，而是团队协作。当我们认为自己的技术已经达到了期望的深度时，应该选择更加灵活的方式来提升自己的“武功”，而不是一味地想让自己成为天下一，因为根本就没有天下一。此时我们更需要做的是，通过自己的管理技能去带领更多的技术人员，通过团队协作来取代单打独斗，用管理的方式做技术。
也许大家和我一样，选择了走技术管理的路线，去攀登更高的技术山峰。在攀登技术之巅的路途中，我们或许犯过类似的错误。
- 队员工作没有自己做得好，花时间去沟通还不如自己去做。
- 感觉自己的技术在退化，长期不写代码觉得自己没有价值。
- 发现自己不懂的东西越来越多，觉得把管理做好不太容易。
当大家遇到以上问题时，无须过多担忧和自责，更不要认为自己不适合走技术管理路线。其实以上问题只是一个信号，它在提醒大家，是时候提升自己的“软技能”了。
如果将技术能力视为“硬技能”，那么管理能力就是“软技能”，而软技能所涉及的面可能比硬技能更广，甚至更为抽象，其中很多软技能考验的不是单一的能力，而是综合的素质，比如素养、胸怀、情商、智慧等。有些方面可能受自己的成长环境所影响，但更多的软技能其实是可以训练的，而且完全可以通过正确的方法得到明显提高。
3.3 序三 - 职业经理人（高凌）
管理是一种实践，其本质不在于“知”而在于“行”。（Management is practice. Its essence is not knowing but doing.）——彼得·德鲁克（Peter F. Drucker）
对于多数勤勉的工程师来说，努力数年后走上技术管理岗位似乎是一件水到渠成的事，但要真正做好技术管理，成为一名优秀的管理者却并不太容易。不同于一般的项目管理和职能管理，技术管理的主体对象是最具特色的知识型员工，具有很大的不确定性。
每一种行业、每一个技术领域、每一家公司，甚至每一个技术团队，都有可能采用不一样的管理方式，我很好奇他想从哪些方面进行提炼。作者通过对自己的工作内容、经历进行总结，并且将自己的一些技术管理经验和理解分享给大家。该书从技术管理者的基本素质要求谈起，以软件开发工作中的实例来介绍他对技术团队建设、人员管理、产品开发过程管理的一些理解，并且重点介绍了作为技术管理者的另一个身份——技术总体负责人在技术调研、预研和系统架构设计方面的一些经验体会。
3.4 序四 技术领导之路关于技术领导 - 极客邦科技总裁（池建强）
有人把这个概念定义成一种职位，比如技术经理、技术总监。有人把它引申为技术上的洞察和优势。也有这么认为，如果你有能力把技术相关的资源有效地组织起来并完成一件有价值的事情，例如，发布一款产品，做一个项目，那么你就是技术领导者，或者说，你具备了一定的技术领导力。
单纯做技术，核心竞争力就是技术强，简单明了，做技术领导感觉就没那么明了，哪些是技术领导的核心竞争力？是对系统的整体理解，组织协调能力，个人品质素养，还是技术领导力本身？从职业发展角度看，技术领导最终会晋升为某个管理职位，而管理职位应该是一个更难胜任的职位才对。技术弱化带来的危机感（不安）的本质原因是什么呢？
简单来说，技术领导可能是个管理岗位，也可能不是，不重要。重要的是你要利用技术资源和团队资源把事情做成。从技术人员和技术领导的分布上来说，后者显然更难胜任。从分工上看，也不可能有那么多领导者。技术领导者的核心竞争力应该包括但不限于：技术能力，对事情整体的理解，能找到正确的方向，影响力，凝聚力，对人性的理解，资源。技术弱化为什么会带来的危机感呢？因为人们总觉得要有一技之长才会比较安全，但是优秀的技术领导会超越这些东西，他们关注的内容不再是某个具体的技术和实现，而是事情。让正确的事情，持续发生才是最重要的。
技术，技术，技术一旦技术人成长为技术领导之后，有个问题就会像“我是谁”一样一直困扰着我们：我还需要在技术领域孜孜以求吗？答案当然是要。你是技术领导啊，又不是产品经理。技术这东西是很实在的，泾渭分明，会就是会，懂就是懂，很难不懂装懂。在现在这个时代，技术是需要我们终其一生学习的东西。
管理看起来套路很多，其实最终都是人性和策略，理解人性，善用策略，就能做好管理。对于聪明人来说，有实践机会，管理可以在短时间内达到一个不错的水准，但技术永远需要长时间积累。钻研技术，并不是让你增加自己的代码量，事实上一个领导者每天深夜像打字机一样咔咔地提交代码，对组内成员是极大的压力。一个技术领导，更多是通过对技术领域的探求打磨自己的技术敏感度和技术决策力。
如何用好当下的技术解决现实中的问题，什么阶段引入什么技术，什么时候重构，什么时候重写，如何利用技术驱动产品，如何构建技术平台……这些都是技术领导需要思考并确定的问题，这些都将依托你强大的技术背景。
信任相信自己的团队，就能产生巨大的生产力。事实上，如果你选对了人，大部分看起来困难的事，都可以解决。
很多时候，团队的人跑过来问你怎么办，只是希望你给他们信心，而不是指望你去给他们写代码。除了需要资源协助的情况，大部分时候你只需要信任他们，然后等着他们告诉你，问题已经解决了，系统已经上线了，产品已经发布了。
程序员对技术的渴求和敏感度，就像枝桠对阳光和雨露一样渴望和迫不及待，只要等，大部分时候，他们都能找到出口。当然，真的遇到困难搞不定了，协调资源或自己提刀上阵就是了。
鼓励和批评把鼓励和批评放在一起说，因为它们是一对双刃剑。无节制的鼓励和表扬会导致你成为一个烂好人，而随时随地的批评会打击团队的自信心，人心离散，智慧之光凋零。如何取舍呢？你需要找到自己的平衡。
有的人喜欢多鼓励，少批评。在平时的交流和会议中，多给予鼓励和表扬，效果有时候比正式会议的褒奖更让人感觉舒适。少批评，但批评的时候一定是声色俱厉、毫不留情。有的人则相反，少有表扬，多为批评。时时严厉的人，偶尔一次褒奖，会让团队成员觉得如饮甘露，有时候效果也非常好。
四、心得
自主循环
我们带领一支团队，可能是1、2个人，也可能是几十个人，我们不可能做到事无巨细、一一谈话，很多时候需要分小组讨论，也要依赖于个人自主的工作态度，这就是我们所说的自主循环。
技术人员成长四个阶段：感知运动阶段、前运算阶段、具体运算阶段、形式运算阶段。
没有哪一个人的成功是可以很轻松得到的，我到现在也通宵，不是因为我不喜欢睡觉，而是因为我对工作有追求，既然有追求，你就要学会付出。
个人职业发展
想要发展的好，还是要靠建立在兴趣上的个人努力，以及另一个关键因素：领导或者导师。对于一个刚入行的新人来讲是尤为重要的，所有的职场价值观形成可能都与此相关。 对人的评价大多都会从技术能力高低转到价值观是否合拍上来。尽量做一个简单而靠谱的人，但是想做到确实需要一直持续努力。 IT行业的机会很多，每次失败最好都能从自己身上总结出原因，这样才能继续向前，从而提升自己。选择很重要，但先要想清楚自己想要什么，选择之后，被放弃的选择就不再重要了，重要的是怎么把选择的事情做好。
最好的技术能力比较强之后再转管理，水到渠成，技术不行的人即使转了管理，也难使人信服。情商就是如何站在别人的角度看问题，只有自己喜欢的工作才能真正地全身心投入。
坚持做正确的技术管理
最好的领导，思路敏捷而清晰，做事务实而高效，永远没有废话，永远雷厉风行。评判一个管理者的好坏，从来不看测验的民意，而是看输出的成绩。良好的干群关系和群众基础，有助于达到目的，但却不是最终目标。一个好的经理人，就是要做出成绩，对老板负责；一个好的CEO，就是要做高利润或股价，对股东负责。这才是职业的素养，这才是商业原本的逻辑。做人的最高境界是“仁慈的狮子”。仁慈的本性，但单靠仁慈，还无法成功。要有狮子的力量，才能赚钱养家，才能保护亲人，才能反抗欺压。“做个好人”和“做个好的管理者”，其实并不冲突。
不要计较当下职位
世上最讨厌的词是“烂好人”。善良发展到极致，就变成无原则的妥协。不断地调整自己的工作方式，不断地加强自己各方面的能力，特别是改正自己的弱点，这些才是你应该去关注和为之努力的。抛弃通道思维，建立雷达视角。没有管理，整个团队会乱，技术与管理结合的方法论掌握不好，真个团队的绩效输出都会差。你别指望纯技术通道的人能够输出业务部门能够理解的产物。也就是说，需要能够抛弃单一通道的约束，尽量做到全面的能力建设，即抛弃通道思维。最重要的是能力，而不是公司所给予你在“通道”上的认定资质。
你的雷达探索的面积就会越大。在这样的世界观里，我们不再追求人人都去做团队管理者，而是追求做一个靠天赋、靠能力吃饭的人。我们需要坚持学习，不然随着年龄的增加，你的优势会逐渐消失。抛弃通道思维，建立自己学习新知识的雷达视角，建立起自己的朋友圈，扩大雷达视角范围，对你一定会有用的。IT企业想要一直保持生存，必须要有不断的技术更新，因此必须依赖强有力的技术人员，没有技术能力的人、不爱学习的人终会被淘汰。能够一直不断的学习、不断地增强自己的综合能力、不断地自我积极调整以适应工作需求。这类人很成功，能够保持大体上的收入不断增长，一直到退休功成身退，能够真正做到这样的技术人员很少，大家共勉吧。
职业生涯过程中每个人，是每个人，都会遇到发展瓶颈，甚至是失败，这很正常。
技术VP
技术VP的职责：交付软件解决方案，确保业务健康，只有业务健康，工程师们的努力才有价值，团队才有可能继续发展。
CTO和技术VP，两者应该是合力开发产品，而不是谁领导谁的关系。对于一家科技公司来说，CEO和技术VP之间的合作至关重要。
研发人员很重要的是需要一位能知道他们、了解他们的大哥。你也要参与代码的过程，目的在于可以通过代码去理解大家、了解大家在想些什么。你作为技术领导者，必须融入这个氛围，了解一线员工他们在做什么，作为他们的发言人，代表技术团队跟公司管理层争取一些利益和福利，大家都会觉得这是我们自己的带路人。
CTO 规划技术愿景，技术VP跟多负责业务愿景。
保持身体健康！
文摘
一家企业能够生存，一定是业务开展的不错。作为技术团队管理者我们需要做到技术和业务的融合，需要保证我们的付出可以为企业带来长久的利润。只有成为“技术的业务派，业务的技术派“，才能让技术引领业务，并创造价值。-技术管理者成熟的标志。
一位管理者最重要的是给团队指明方向，包括技术方向、业务方向、个人成长方向。与下属相比，领导者的又是不只在于他的专业能力，还在于他的眼光和胸花。既然选择做技术管理，你就要有成就他人的心胸，同事还要有超出一般人的眼界，能够给予团队正确的方向。同事，要保持对技术的兴趣，多关注新技术的发展，否则你就很难在重大技术角色上做出正确的决定。
技术团队内部一些员工，也许他们不善言辞，但交付的任务，他们一定会尽全力完成，遇到不懂的地方主动请示、沟通，个人姿态摆得很低，这样的员工内心非常成熟，知道如何做事、体谅上级、努力工作，而不是把精力放在正经工作以外的地方，他们是团队的中坚力量，是不可或缺的成员。我认为衡量一个团队的凝聚力是否强大，看看这类员工的占比就知道了，缺少这类员工的团队一定不会有什么了不起的成绩。
在领导层不明确那个团队做的前提下，对内组织团队尽全力做下去，而且要做好，对外则用于承担责任，敢于接受挑战
我们输出或者呈现给别人的技术能力，需要且必须是公司内部的技术权威之一，说是之一，是因为不能否定公司内部其他部门的技术能力。我们必须让别人知道我们是专家，我们团队很牛。如果被别人列举出我们团队技术不尽人意之处，我会认为这是对我人格的侮辱，只要我是这个团队的领导，我绝不允许这种情况发生。但有一点需要注意，只有做好当前的事情，你才有资格谈技术理想。
作为技术团队管理者，你要做的是比别人更早接触新技术，更深入地理解系统框架，全面提高管理团队所需要的方方面面的能力，而所有这些都需要勤奋。要成为某个领域的专家，需要一万个小时的训练；学习一个东西如果只是能听懂，还不算学会；如果能够按照所学去执行，也才学会一般；如果能够把所学的东西用自己的语言表达出来，让别人听懂，这才算差不多学会了。在软件行业，没有在专业上的持续学习和成长，是不会成功的。
“古往今来，能成就事业，对人类有作为的，无一不是脚踏实地攀登的结果”-钱三强
“如果不吸取失败的教训，那么失败就仅仅是失败。”
程序员的工具是编程语言。包括：设计(Design)、建模(Model)、编码(Code)、调试(Debug)、重构(Refactor)、沟通(Communicate)、学习(Learn)、思考(Think)。
管理团队的风格，应该从十几年前的管理工人思维，逐渐提升为与知识分子沟通的方式。无论是绩效考核，还是职位升迁，亦或是问题处理，都与应该由少数几个领导通过闭门会议的形式完成，而应该是通过制定逻辑严谨的规章制度，通过类似认知资格考核(团队建设部分会深入介绍)的方式完成初步考察，然后通过事情责任制方式明确个人的成绩、责任，最后通过有员工代表、相应部门代表参与的会议讨论决定，这样可以让整个团队朝着健康的方向发展，而不会让一部分人感觉被边缘化，从而滋生小团体。
无论你是CTO、CEO，还是CFO，既然承担了团队负责人的实际工作，那么久应该每天召开例会，不断的抽时间和大家一起讨论架构、业务流程、技术难点、技术方向，这就是你的职责，不要来谈你有多忙，你的职务有多高，如果这的很忙，你可以任命一个临时团队管理者替你承担责任，而不是让你团队处于流浪状态。不管你喜不喜欢，既然你直接管理团队，就要以身作则。
建设以人为本的团队文化，创造出沟通顺畅、敢于挑战、喜欢创新的团队氛围。在团队文化建设方面，主要倡导的是 互联网文化、极客精神。
“有了真诚，才会有虚心，有了虚心，才肯丢开自己去了解别人，也才能放下虚伪的自尊心去了解自己。建筑在了解自己了解别人上面的爱，才不是盲目的爱”-傅雷、
仔细的人一般做事都比较负责，勇于承担责任，也懂得抓细节。抓细节是作为一名技术团队管理者必须做到的
所谓的管理浮于表面，一般都是说管理者不关注细节，例如不参与设计、不参与代码审核，而只是高喊要注意开发设计、注意开发质量，这样的领导对于技术团队来说，尤其是一线技术团队经理来说，是不合格的，也是不能服众的。、
一个仔细的人，他一定也是一个善于观察的人，而善于观察、思考其实也是一个团队领导者所必须具备的品质，否则他的团队一定会在某一阶段或者一直处于混乱状态。
时间管理
我们普遍存在着这样一个认知误区：多花时间=态度好=产出高。这是被否定的理论。
GTD（Getting Things Done）是一种高效的管理时间的方式。重要的事情优先完成，用一定的时间专注处理一些事情，然后再休息，再专注，周而复始。最好的方式是在每一天早上画上一定的时间来规划一天的安排。
你最重要的资产是 时间。对时间要吝啬，但同时对那些真正需要它的人或事要慷慨给予。
以人为本：人、产品、利润。人是第一位的。绝对不可忽视你团队的人，并始终要坚持一人为本。