（转）如何有效地管理好技术团队？

转自（https://cn.100offer.com/blog/posts/307）

技术管理是一个综合性岗位，要求你具有技术能力、管理能力，也要懂一些心理学，情商也要高一些，说实话，你想做好这个岗位，真的不容易，尤其是在中国。我相信今天的分享过程中，您可能会对我分享的经验有些疑问甚至质疑，这都是正常的，我们可以去书店看看，管理类的书每隔一段时间就会换一批，80年代世界学亚洲四小龙，90年代学日本，近20年学美国硅谷，现在中国起来了，大家开始学华为、学阿里、学腾讯。这就是管理，它确实是在变化着的。它不像技术书籍，比如C++，一本C++ Primary出了11个版本，流行了几十年。我在InfoQ和IBM开发者论坛担任专栏作家，今年下半年开始重点针对技术管理工作写了一些文章，坦白说，一般来说写完一段时间后我就在考虑有些内容可以做些修改，因为每天都在出现不同的状况，每天都会学到新的管理方法论，无论是偏向纯技术的管理，还是偏向项目流程或是针对人的管理。

 

本次 Live 主要包括以下内容

1. 优秀的技术管理者需要具备哪些能力？

2. 从四个维度谈谈如何做好团队管理

3. 产品开发过程的管理

4. 技术调研 VS 技术预研？为何需要参与调研和预研？

5. 软件架构责任以及业务、技术、架构三者关系

 

一、优秀的技术管理者需要具备哪些能力？

今天的分享主要针对技术团队管理者品质、团队管理的四个维度、产品开发过程管理、系统架构理念等几点内容，时间有限，不能针对各个方面深入介绍，请大家见谅。其实我们作为技术团队管理者，每天都需要关注技术、产品的发展趋势，也需要具备产品意识，所以我们的工作范围也会包括新技术理解（英文文章阅读和翻译、技术框架原型搭建）、产品布局（专利）等等，

对于一名技术团队管理者来说，他需要具备一些品质，例如成熟、勇敢、热爱技术、勤奋、脚踏实地、逻辑能力、公平、一线作战精神、决策能力、开放姿态、为人处世、真诚、宽容、仔细、终身学习、时间管理、以人为本、身体健康等。这里时间有限，我举几个例子。

1.成熟

技术团队内部有一些员工，也许他们不善言辞、不会说好听的话，但是只要你交给的任务，一定尽全力完成，遇到有不懂的地方会主动请示、沟通，个人姿态摆得很低，这样的员工内心非常成熟，知道如何做事，体谅上级、努力工作，而不是把精力放在正经工作以外的地方，这样的员工是团队的中坚力量，是不可或缺的成员。我认为衡量一个团队的凝聚力是否强大，看看这类员工占比多少就知道了，缺少这类员工的团队，一定不会有什么了不起的成绩。

每天回到家，我开始我的另一份职责[1]，洗澡、洗衣服、陪孩子学习、陪家人聊天、写作，这就是生活，一个男人结婚、生子后的生活一定是与单身时不一样的，也不要觉得这不是男人干的活，要能理解生活，主动且乐于承担生活的重担。

坦率地说，我作为一名技术面试官，一直对较为成熟的、能吃苦的、能理解别人的人，情有独钟。身在职场，我们都需要可靠的团队成员一起帮扶前进，团队很重要。任何不成熟的人，最终都会在职场上流露出他的自私、明哲保身、浮躁、乱说话、懦弱等品质，所以一些自认为能力很强，认为自己不受重用、永远在底层的员工，在埋怨领导之前，你应该多多自我反省，是不是工作职责没有承担起来，是不是自己的为人处世让别人很难堪而不自知，是不是开口闭口都是以自我为中心。

2.勇敢

我们作为团队负责人，也应该有硬汉本色，不能惧怕外在的威胁，团队成员都在看着你，你决不能懦弱，要勇敢。举个例子，很多时候并不是你想团队怎么发展它就怎么发展的，很有可能你的团队刚刚明确产品目标、技术目标，人员也根据这些目标招聘到位，正准备大干一场的时候，忽然听说也有另外一个团队在做一模一样的事情，别以为这是笑话，很多大公司都存在这类问题，即缺少顶层设计（也许是顶层故意设计的，让两个团队竞争）。面对这类情况，你可以选择退缩，转向另外的方向，也可以选择混混日子，等着被解散，我觉得无论哪种选择，你的团队都有可能瓦解，谁都有自己的职业定位，想做的产品、技术没了，有能力的人就不跟你玩了。我个人更倾向的是，在领导层不明确谁做的前提下，对内组织团队尽全力做下去、做好，对外力挑责任。

我想到了电视剧《长沙保卫战》的对话，参谋长对薛岳将军说："你若下地狱，我绝不上天堂"。这也是我在团队遇到严重挑战的时候，我对所有成员说的第一句话，想做成事情，你或者你的核心下属，必须站出来。

3.热爱技术

虽然我个人不太认同阿里的一些价值观，但是他们确实在技术上做了蛮多工作，推动了一些技术发展。2016年"天猫双11全球狂欢节"，单日交易额定格在1207亿元，被阿里定义为整个社会走向"新零售、新制造、新金融、新技术、新资源"的起点。经过8年的双11锻炼，2016年阿里技术创造了惊人的记录—每秒同时创建17.5万笔订单以及1秒钟同时完成12万笔支付，支撑起了全球范围内最为庞大且复杂的交易体系和交易规模。正如阿里CTO所说，如果没有对梦想的坚持，以及对实现梦想的不懈努力，阿里不会是现在的阿里。实现梦想需要有强大的技术实力作为基础。以计算为例，双11有大量的计算，一切关于搜索、推荐、人工智能的"梦想"都需要计算平台的强力支撑，阿里如果不打破传统Hadoop框架的藩篱，自研非常高效的离线和实时计算平台，用户在交易的过程中就不可能有现在的体验。

我在IBM开发者论坛发表了20多篇文章，有一次同事通过一篇文章搜索到了所有文章，他很吃惊，跑来和我说，只有非常喜欢技术的人才会这样做。是的，我很喜欢技术，所以我才会和喜欢技术的人相处得很好，才可以一直带领着软件开发团队。

说点自己的想法。我对团队的技术要求一直都是"我们输出或者呈现给别人的技术能力，需要且必须是在公司内部占据技术权威之一，说是之一，是因为不能否定公司内部类似技术领域部门的技术能力。我们必须让别人知道我们是专家，我们团队很牛。如果被别人列举我们团队技术怎么这么差，我会认为这是对我人格的侮辱，我会非常的愤怒，只要我是这个团队的领导，我决不允许这种情况发生"。有一点需要注意，只有做好当前的事情，你才有资格谈技术理想。

4.一线作战精神

2年前的一个夏天，我带领的团队购买了10多台服务器，用于分布式计算实验。收到到货的消息后（到货时间很难估算，所以没有提前联系货车），相信一般领导都会让下属或自己联系货车，但是我评估了一下时间，需要等2周时间。我们等不起，所以我带着1个下属，骑着自行车到了仓库，然后和大客车师傅（多厂区之间运送工作人员）商量是否可以把机器放在行李层进行运输，得到肯定的答复后我俩把服务器运上车，然后我让他骑车回去，我跟着车一起回，回来的路上给其他的组员打电话，全部到楼下集合，自己抬上去。一个下午完成服务器运送、搭建、调试网络等等所有工作（路由器、插线板、网线等等我已经提前准备好了）。这是我所理解的一线作战精神、作战方式。

 

二、从四个维度谈谈如何做好团队管理

关于团队管理的四个维度，主要包括向下管理、向上管理、对外管理、自我管理。

1.向下管理

 

（1）技术尊重

要了解程序员，你首先需要深入理解他们使用的工具、流程，以及程序设计的艺术。你理解得越深入，在和下属程序员进行技术对话时，参与能力就越强，越容易获得他们的尊重。微软的一位程序架构师这样评价比尔.盖茨："盖茨最喜欢和他的程序员一起将程序分析到比特、字节层面。在技术战斗中他可以非常轻易地守住自己的阵地，他之所以可以获得程序员的尊重，因为他可以轻易地战胜他们"。

成功地管理程序员最重要、最关键的因素，是得到你管理的下属的技术尊重。如果没有技术尊重，那么你的每一个具体想法，都可能会遇到主动或者被动的阻碍。正是由于这个原因，那些在职业生涯的某个时期没有做过程序员的团队管理者，才会觉得有效地管理程序员是极其困难的事情。

（2）进度管理

我有一块小白板（不是那种很大的），我把它放在自己的面前。每天早上我都要写上今天需要参加的会议、自己要做的事情，此外，每天上午半天时间我会和每一个项目（产品开发、预研、调研，都可以）的团队成员过一遍当前进展。大家坐下来，好好谈谈已经实现的设计或代码，对疑惑、问题进行讨论。因为这种方式可以确保自己不仅仅依赖于状态报告、项目时间表，这种方式也可以让你能够接触到说真话的员工，他们会告诉你哪些地方做的不够好，并且会主动请求团队管理者帮助，而不需要团队管理者来催促他们。最高效的团队管理者往往都是坦率的，也往往对下属有足够的时间，能让员工找到他们说出自己的想法，他们会认真倾听。

如果往长远看，一些虽然不紧急但是很重要的事情，如果迫于压力被放下后，到后面往往需要花费好几倍的代价才能弥补回来，技术管理者需要时刻保持警惕，警惕地做出决策，做正确的事情，要能够为公司的长远利益负责。

（3）保护成员

我们做过项目的团队管理者一般都有这样的经历，团队成员正在专心处理现场问题，莫名其妙被人投诉，投诉可能来自市场部门，也可能来自技术支持，或者兄弟研发部门，所有情况都有可能。也容易出现团队成员每天被大量无用的会议烦扰，不去的话就要被投诉，这类情况在大公司司空见惯。

我们要学会保护团队成员，让他们免受组织中每日泛滥不绝的各种问题、争议和"机会"的干扰。在大一些的公司内部，官僚主义政治会通过各种文书工作来忽略或者缓冲每天的各种请求和问题。在小一些的公司里，面对挑战的是各种销售驱动的机会、客户驱动的争议问题，以及管理驱动的想法，你作为团队领导者，可能是他们最后或者唯一的防线。

（4）任务责任制

每项任务都必须有且仅有一位负责人（Designated Responsible Individual，DRI），如果有两个指定负责人，那就没有人负责了。开发经理的职责是确保为每项任务指定负责人，而不是亲自去完成每一项任务（开发经理可以指定其中的某一项工作由自己直接负责）。应当明确每项任务，确保为每项任务指定一个负责人，推进任务。还要定期检查以下三个问题："是否清楚整体的目标？是否清楚你的任务对实现整体目标有怎样的贡献？对于你所负责的那部分，有哪些东西妨碍你达成目标？"。我自己的做法是，只有担任任务责任人的同志，才能在考核中得到良好或优秀的评价（前提是把事情做好，做不好就要承担责任），没有担任任务责任人的同志，最多只能给予合格评价。

我们实行了任务责任制，这种长期责任，不是我们的管理保守了，而是在内、外合规的条件下，鼓励在集体主义下的个人主义更好地发挥。我们呼唤英雄，也要宽容英雄的一些过错。英雄要更加自律，天降大任于斯人也。

2.向上管理

 

向上管理其实是四个管理方向里最难的一点。什么是向上管理呢？向上管理指的是如何有效管理你的老板以及你要汇报的那些人。另外你还需要弄清楚如何汇报、如何沟通，以及要采取什么样的其他行动，才能让你的老板认为你是一个高效而成功的程序设计经理。

管理你的老板看起来似乎是一件比较奇怪的事情，但实际上成功地管理好你的老板可能比管理好你的团队还重要，至少对你个人而言是这样的。这背后的原因在于，成功并不只在于你做了什么，更需考虑别人如何看待你所做的成果，现实中外在认知往往比实际行动更重要。

3.对外管理

当你被聘请或提拔为程序设计经理时，你需要仔细研究组织架构图，找到各个职能部门的主管，想办法让自己逐渐了解他们，或者是各部门中与你同级的经理。请他们吃午饭，或者偶尔停下来跟他们聊聊天。提前建立起彼此之间的跨部门纽带关系是很有必要的。以后你真需要向他们发出请求或寻求帮助的时候会更加容易。

跨部门的纽带关系不仅能帮助你自己，也是促进不同部门团队之间双向协作的重要途径。在跨部门活动中，尽可能成为一个领导者，而不是追随者。你的主动参与将提高你在整个组织中的形象，帮助你在很多看不见的方面取得成功。你在这些活动中花的时间，将会获得大量回报，因为它们可以提高你的工作执行能力。

4.自我管理

"平级很难管理怎么办"，这是网友的一个问题。看到这个问题时，我想起了米歇尔[2]在去年美国大选之前的民主党全国代表大会上，这样描述自己的想法，"When they go low，we go high"。当你遇到你觉得很难相处的人时，你需要告诉自己，保持自己的职业素养，不要轻易被别人激怒、烦恼，依然保持一颗平常心，努力把自己的工作做好。

对于平级的人，你确实拿他没办法，我的建议是找你们共同的领导反映你的困惑，或是通过你的领导找到他们的领导，由领导层沟通。对于所有的管理类问题，我觉得首先要自我检查，确保不是自身的问题，然后是沟通，保持高效、简单的沟通，这样可以帮助你至少说出自己的困惑，最后是放松自我，不要被不值得的事情或人所烦恼，过好自己的每一天，全力做好自己的工作，不断提升自我价值，抽出时间陪伴家人，这才是你应该做的。

 

三、产品开发过程管理

1.开发进度管理

"向进度落后的项目中增加人手，只会使进度更加落后"，这句话摘自《人月神话[3]》。

根据伊格尔森定律[4]："自己写的代码如果有半年时间没有看过，就跟别人写的代码没什么区别了。"这句话的意思是，代码看起来会很混乱，难以理解，并且同样无法通过进度估计来预测项目成功完成的时间。

《华尔街日报》的一次采访中，微软CEO纳德拉透露自己每月有一个周五会和公司最高领导层开一次8小时的会，在另外的3周里开4小时的会，讨论的内容从财务表现到产品使用率的实时数据，覆盖面相当广。他这样做的目的是为了可以让公司的高级管理层保持统一战线。

为了有效控制进度，开发经理需要请各个小组每天召开"晨会"检查昨天进展，布置当天工作；另外，每周五下午召开周例会，项目组全体成员参加。

（1）晨会

晨会的检查基准是各个小组的底层计划，以检查和确认为目的，不展开讨论。晨会规定在15分钟以内，每个小组的成员站在白板前面完成。步骤如下：

第一步，检查状态。成员逐个说明昨天任务的完成情况，今天计划的工作任务，以及遇到的问题。确认任务的完成情况不涉及执行细节，仅需要回答："完成"或者"未完成"。开发经理进行标准，一般任务按时按成可用打钩表示，未按时完成需要特别标记出来。检查完成后，将任务的完成情况分成三类："按期完成"、"延迟完成"和"延迟中"，并进行汇总统计。

第二步，调整计划。根据昨天任务的完成情况和个人任务的调整，小组一起对"底层计划"进行适当调整，确定当天每个人的工作任务。

第三步，解决问题。首先审核昨天列出的问题的状态。然后，将今天每个提出的问题记录到白板上。除非可以当场解决的简单问题，否则不对问题展开讨论，只记录到白板的问题栏。会后由相关成员讨论问题的解决方案，或另行安排时间专题讨论。

（2）周例会

周例会检查和调整项目计划，需要一定的讨论。关注的问题是：任务完成了吗？没完成的原因是什么？怎么调整？先确认了状态，再讨论该如何调整工作或计划，并一定要落实到具体的行动方案上。

姓名		部门名称		项目名称		时间		上周主要工作
编号	工作内容	周一	周二	周三	周四	周五	周六	周日	合计	结果	未完成原因
1
2
3

只有提前建立工作结果的验收标准，才能确定如何才算是完成任务了。

项目计划要想落地，需要细化分解到每个人的工作任务中去。个人工作计划可以通过白板的方式管理，实时反映进行情况。

计划进行调整和更新是常态，因为"计划本身没有用，不断地进行计划才有用"。底层计划的管理使用简单的白板就可以发挥巨大的作用，可见，软件开发中"人"才是最重要的，没有"人"的主观能动性，再高级的管理工具也难以发挥作用。

2.项目管理重要性

项目管理是核心能力之一。而其他方面能力的积累也往往依靠项目管理能力的转化。譬如，核心技术的积累，首先是基于最佳实践，而最佳实践只能依靠强有力的项目管理能力才能脱颖而出。而把最佳实践转化成解决方案，也是靠项目管理能力的支撑。最后再通过项目管理，把解决方案转化成核心技术产品或平台。

很多开发经理会看轻项目管理能力，其实这是错误的。项目管理是一种软实力，只有逻辑能力强、对于业务和技术都非常了解的人才能既做好开发经理，也做好项目经理，其实也只有两者都能管理得当，我们的开发项目才能够真正发布成功。

项目管理的重要性，大致包含以下几条：

（1）支撑公司收入：无论是产品型公司，还是外包型公司，最终都在通过一个个项目的形式落地，你可以把一个产品从咨询开始到客户付款的整个过程当成一个项目。这时候，大家明白了吧，没有项目的支撑，公司哪来的收入？哪来钱养活技术人员？公司的注册资金不是用来发工资的，大家的工资是通过客户付款产生的。

（2）项目进度把控：技术人员很容易犯的错误是技术优先，对项目的进展不太关注，而项目管理的目标就是要让这一点不出现问题，也只有做好项目管理才能真正解决进度把控问题，你不能单纯地认为只需要给开发人员添加KPI就行了，如果真的可以，为什么会有OKR的出现？为什么日本的软件企业越来越不行了，要知道，他们可是KPI的发明人和强有力的执行者。

（3）人员工作安排：缺少强有力项目管理能力的技术领导，很容易让团队的部分成员陷入迷茫，提出的命题很大，但是落实到每位技术人员身上，一部分人会迷茫，他不知道每天应该干点什么，所以最好的方式是对工作进行拆分，每天的工作要能说清楚它的具体目标、要求标准等，这样才能让大家觉得自己的存在感。

 

四、技术调研 VS 技术预研？为何需要参与调研和预研？

1.调研和预研差别

 

 

技术调研和技术预研是存在一定差别的，主要是立项时所处的环境、目的等存在差异，总结起来可以简单用一段文字描述：

技术调研是针对粗粒度需求的实现方案研究，很有可能对所需技术根本不清楚，需要通过调研项目完成技术了解、技术选型、技术可行性分析、技术方案设计等。技术预研是针对细粒度需求的实现方案预先尝试，主要是针对通过技术调研所选择的技术，结合我们产品化时的实际需求，对实现时存在的不确定性因素、细节等进行预先研究、尝试，为产品化过程减少技术实现风险。

正是由于所处环境、项目目的的不一致，所以技术调研报告和技术预研报告的内容也会差别较大。技术调研报告侧重于阐述从需求整理到明确方向，再到搜索技术调研方案以及初步筛选，接着是具体的测试方案确定、测试环境搭建、测试用例编写及运行，最后是针对调研项目所提出的一些实际业务场景的运行数据对比、分析，通过解释数据产生的原因，明确下一步计划。技术预研首先根据细化的需求（有可能是产品化需求的一部分难点需求）对系统整体进行定义，接着通过列举方案明确本次预研论证过程，再通过论证过程反复执行列举、论证、推翻、再列举这一过程，最后是对本次预研获得的最终结论进行总结，为产品化提出技术验证通过结论。

从最终的输出报告来看，技术调研一般针对每一项技术都会有一份单独的报告，然后汇总一份调研报告（对各项进行汇总、对比、总结），而技术预研一般只有一份预研报告，通过这份预研报告说明是否预研项成功，是否可以采用该种方案、技术进行下一步的产品化立项。

2.参与的重要性

对于一个技术负责人来说，你的职责范围内有许多工作需要执行，比如组建团队、了解产品，但更重要的是设计靠谱的技术方案。

首先要了解系统存在的问题，要了解产品未来的走向，要了解技术团队的现状，针对这三点，你需要亲自操刀，设计一个针对目前最优的技术方案。

为什么要亲自呢，因为你是技术负责人，如果你不了解技术，就无法进行技术管理，如果亲自主导或参与了设计，你就能有针对性地去解决问题，即便将来系统遇到瓶颈，你也能更好的优化或者重新设计。不要用各种理由不去做这个事情，在任何阶段这都很重要。再者，如果别人问你，你的设计和其他公司的设计方案有什么区别，或者是否可以用开源那些框架搭建起来替换你们自主研发的框架，你怎么回答？你如果没有对类似的技术、框架进行过调研，你怎么能够准确地回答这些问题，如果没有对技术难点进行预研，你怎么敢把设计对应的需求写入产品化需求，你不怕最后实现不了吗？

为了更好地设计系统、理解技术，你一定需要组织调研项目和预研项目，这是因为你或者团队不可能什么技术、框架都懂，技术的发展非常快，只有不断地针对新出现的技术进行调研、总结、预研、总结，不断地往返这样的过程，你才能够真正跟上技术发展的潮流，否则终有一天你会被技术岗位淘汰。

 

五、软件架构责任以及业务、技术、架构三者关系

1.软件架构责任

 

一个软件，因为某个业务虚拟化的需要而产生，后续不断地更新、修改，推动软件逐渐变异、长大，当该软件不再被需要（因为业务的消失），或有更好的软件来替代时，该软件就会被废弃，完成使命而消亡。软件的整个生命周期也会发生切分，从而形成两个子生命周期，即软件开发生命周期和软件运行生命周期。

作为软件架构师，必须时刻把针对软件的生命周期和业务的生命周期的识别放在第一位。软件生命周期的核心在于软件运行生命周期，以及围绕软件运行生命周期的拆分和组织，业务生命周期的核心在于围绕业务核心生命周期的拆分和组织。

对于软件生命周期，必须要深入思考软件开发的生命周期和软件运行的生命周期。在这个基础上，要根据业务的情况合理地进行软件开发生命周期的架构分拆，以及软件运行生命周期的架构拆分。软件开发的拆分和软件运行的拆分的目标最终都是为了支持业务流量的增长。

在代码层面，要对业务代码和访问代码做好架构拆分。业务代码是软件访问生命周期的核心，软件运行的拆分受限于软件代码的拆分。因此要确保业务代码符合业务的生命周期，使得业务生命周期活动的结果积累在生命周期的主体上，也就是内聚性，避免散落到访问代码中。这样软件的拆分就不会有太大的问题。

架构在软件发明前就已经存在很久了，我们应该多向大自然、艺术界、建筑界学习架构，因为软件并不是虚无缥缈的事物，它和我们的现实生活是紧密相关的，它的实质是来源于生活，最终又通过软件服务回到生活的一个全过程实践。企业软件架构的设计不仅仅要注重于某一个系统功能，更需要给企业一个可进化的、可持续发展的、不断创新的平台，这和国家的整体发展也是类似的，只顾经济发展指标，不管不顾任何的环境污染，甚至于某水务局副局长说"经济越发达的地区，水越黑！"，一派胡言、其心可诛，急于求成，急于靠GDP让自己升职，才是这些人内心的写照。

团队达到一定规模之后，技术管理者的架构职责（也可能是有独立架构师存在）的主要时间就需要花费在思考上面了，当然你也可以继续编程，但是编程的目的是验证架构是否合理，所以不要受是否需要编程这一思维的束缚。如果设计得不好，那么团队就会走很多弯路，如果想要设计得很好，你必须自己或者带领团队做很多的测试、预研工作。作为架构职责，你需要多多思考，很多时候看起来很忙、事情很多，但其实真正思考时间太少了。

2.业务、技术、架构三者关系

业务、架构和技术之间是共生的关系，而不是互斥的关系。

技术人员很多时候所关心的技术，和业务的主要目标往往不是直接对应的。业务是负责某一部分的业务，只是业务架构树的分支节点。只有直接解决业务问题的那个技术或业务，也就是树的根节点，才会和业务直接相关。由于业务和技术属于两个不同的树，也就是说有两个不同的根节点，因此只有沟通才能解决问题。

技术总是在人类对业务目标要求不断提高的情况下产生，其目的是为了获取更大的利益。所以：技术是为了解决业务问题而产生的，没有了业务，技术也就没有了存在的前提；有了更好的技术后，效率较差的技术，就会慢慢地被淘汰，从而消失，一切都遵从人类的利益诉求。

不同技术之间有两种关系：

在解决同一个业务的前提下，更高效、更低成本的技术，会淘汰低效、高成本的技术。这是人类利益诉求所决定的；通常刚开始解决核心业务问题的核心技术的效率是比较低的，只是把不可能变成了可能。慢慢就会有提高的需求出现，改进技术的要求就会变得很迫切。技术所解决的业务生命周期慢慢就会开始发生拆分。非核心生命周期分离出去后，要么使用现在的技术来实现，要么形成新的技术，服务于更广泛的业务。

在业务生命周期拆分之前，技术是由一个主体串行地执行并工作的，这就是导致效率低下的原因。从业务生命周期中把非核心生命周期分离出去之后，非核心生命周期会形成新的技术，由不同的主体来执行。新的技术可以独立地与核心技术并行工作，提高了原有技术的效率。因为要解决的核心业务问题并没有发生改变，所以拆分所形成的是一个树状的架构。

也就是说，先有业务问题，才会有技术来解决业务问题。而业务的长达要求，提高了对技术的要求，导致了对业务生命周期的拆分，以并行的方式提升效率，形成了架构，也形成了新的技术。所以在这三者的关系里：

业务是核心，技术是解决业务问题的工作，而架构是让业务长大的组织方法。架构需要用技术来实现拆分，技术需要架构来合理组织，以提升效率。

这就是三者之间的关系。软件和业务最终是要合体的。

 

 

Q&A

Q1.我做技术十几年了，做管理也好几年了，技术还行吧。管理觉得很不成功。主要比较性格"面"，对同事太软。是不是性格比较懦弱的人不适合做管理？

A1.首先，管理的本质是，对于表现比较好的团队成员要给予帮助，对于工作不负责任，能力差的就该怎么办怎么办.某种程度上来说，性格太懦弱的，确实不适合做管理者。我今年去校招的时候，遇到一个研究生女生，已经拿到了京东的offer，她技术问题回答的不错，后来询问她的性格，她告诉我说，她在毕业前和几个驴友环岛骑行一周，别人对他的意见不一，她说她会根据不同的意见进行汇总，好的积极听取，不赞同的会积极沟通，我认为她有较好的管理才能。

Q2.一个工程师A擅长做某事，但这件事跟工作无关，B希望A帮忙做这件事时，A拒绝了。然后，B向A的领导反映了这个情况。A的领导，应该如何处理呢？

A2.我们假设A做的事情是技术相关的，和工作无关的，首先，我要确定A做这件事情是在做完本职工作之外做的，如果是和公司发展有利的话，我可以帮助A一起做这件事情。同时，B没有必要一定要A帮忙做这件事情，可以自己一个人来做。这时候，要看领导是什么出身和看法，如果是技术出身，并且技术对公司发展有利的话，我会乐意一起做做这件事情。

Q3.一个紧急项目需要处理，负责这个项目的人休假了，又没其他人能接手。这种情况如何处理呢？

A3.首先，我是不允许这种情况发生的，我的每个任务都会确保两个备份成员，两个成员都要知道互相在做什么事情。可以A对B进行备份，C对B进行备份，A对C进行备份。互相备份的方式，如果出现一个人休假，就不会影响工作了。作为团队的管理者也要自己有动手能力，如果是在不行就要自己上了。如果出现一个人离职导致整个项目或者业务都要取消，这就是管理者的失职了。

Q4.A和B是工作中的搭档，项目出了问题，未查清原因前，A会当面说B做得不好，B为此生气。领导虽然进行了调节，但A和B关系一直很僵。领导该如何处理呢？

A4.一般来说，如果做技术管理的话，不太会出现这种问题的。因为，如果项目出现问题，作为管理者，我首先是要去问的，要去查明原因，而不是还没查明真相之前不要去说别人说的不好。做程序员要实事求是的，不要挑是非，这是一个人的职业素养。如果说真的出现这种情况的话，私下去找两个人说明清楚，同时要进行职业素养教育，不允许出现这种在人前去侮辱别人的情况。

Q5.如何打造公司产品的技术竞争力和质量？

A5.我始终认为技术和产品是不能分开的，如果抛开产品，只说技术的竞争力是没有意义的，任何技术和框架都是为产品服务的。你需要根据你们公司的产品进行调研，找出整个行业里做相同产品的人的技术框架，进行研究对比，优缺点，你就能知道用你的技术的竞争力和产品的质量行不行，而且你可以对产品进行完成的系统测试，并拿到数据。

Q6.请问作为团队的中层管理者，总感觉时间不够用，做好自己的工作的同时还要去兼顾管理，老师是怎么权衡的？

A6.我有几个方式，第一，我有一个小黑板，每天我会把自己要做的事情紧急程度进行划分，首先要去做的是最重要的和最紧急的事情。第二，我需要培养自己的左右手，把任务分好，让左右手帮忙我做这个事情。比如说我要做一个测试，我会把测试的思路讲清楚，让具体的人来做，把控整个流程，最终形成的报告进行检查。如果完全由我自己做这个事情，可能我一天都做不完，如果我把自己的左右手能力都培养好的话，我就可以空出时间做其他的事情。

Q7.团队中如何减少明显粗心大意导致的bug？如何提高团队效率减少加班甚至不加班？技术或者技术方案上的攻坚，管理者应该承担又或者做到什么？

A7.首先，第一个问题，如何减少bug，你们团队应该有代码审核环节吧？所有代码，每半个月或者一个月都有一次代码审核，可以把一个人的代码指定给3个人，可以公开式的或私下的代码审核。如果代码质量太差，可以公开式的去提问题提意见，让对方去改。过一段事件后，就会发现粗心大意这种情况就会减少了。另外，需要单元测试和集成测试、系统测试去把控测试过程。所有产品都要经过这3个测试才能发布，有些互联网项目如果时间比较紧急，可以做多轮测试去测试核心的功能。另外，在中国做IT不可能不加班，因为目前对于希望多输出的要求和期望太高了，我们只能说减少加班。如果管理者做的不错的话，可以提高整个的效率，一个是个人的效率，一个是团队协作的能力，都需要去培养。

Q8.比较偏技术向的，不写代码就手痒的，在小团队里面如何做好管理呢？

A8.我觉得写代码和技术管理没有冲突，可以每天给自己安排一些代码的工作，或者可以接触一些新的框架和调研的工作就可以了。只要每天把自己的管理工作做好，自己去写代码就可以了。最重要的是，你怎么去把管理工作进行细分，让别人觉得你管理做的很不错。

Q9.技术管理的技术要求？

A9.对于技术管理者最好是有团队用到的某项技术是比较深入的了解，其他还不错，是平均水平，这样你就在某个方面是拿的出手的，有说服力的。同时，你还要培养一些核心成员，这些核心成员不仅技术不错，而且还是尊重你的，这样这些核心成员就可以帮你把团队管理好。所以，你不需要全都很深入的了解，但是需要有拿的出手的技能，你的综合能力要比较强。

Q10.另外其实我个人性格是比较内敛的，会不会不太适合做管理层啊？

A10.我不认为内向的人不适合做管理者，生物学上来讲，内向的人感情更加丰富，大脑的脑电波的回路更长，内向的人对于别人心理的敏感度对外向的人更高。所以，你在家里和生活是可以内向的，但是工作该做的就去做，该说的就去说，否则就会影响你的职业生涯。如果你完全不喜欢说话的话，可以走一些技术专家的路线。现在技术专家也是很有前途的，现在所有成功的创业公司，都会有一个技术大咖做CTO，越是细分的行业越需要技术，你不说话没有关系的，你只要把你的东西做出来，技术深度展现出来就可以了。

Q11.如何提高团队的整体技能和效率？

A11.这是人员培养的话题，想要提升整体效率的话，首先要进行培训，我刚进公司的时候，都是工作几年配给我的，我觉得不太行，最好是我自己来招聘的。当时刚好赶上校招的两个学生，当时我们一起去深圳做项目的部署，做数据库的迁移，从关系数据库像分布数据库做迁移，中间我们做小程序来做这个事情，当时，我们在机场，我教他们来做这个事情，我们把需要做的工作项目都列出来，分工写好，一个在机房，一个在办公室，如何进行交互的分工，在机场全部分工完毕，之后我们到深圳一起进入工作状态，半个小时之后所有的机器到位，再过一个小时，所有数据迁移完毕，当时在场的工作人员，也就是甲方，第一次看到这个工作方式，工作效率和时间效率很高，就给了我们很高的评价。也问了一下团队的背景。所以总的来说，团队的效率提升是团队管理者的工作，要给他们洗脑，要告诉他们什么样的工作方式才是最职业的，也要有能力去总结归纳。

Q12.技术团队管理中对人和事的管理有何不同

A12.我比较喜欢的方式是就事论事，因为我比较年长，所以他们私下有什么问题都可以跟我讲，我也会帮助他们。如果回到工作方面，就事论事，如果事情做得好，我会奖励，如果工作做的不好，就算私下跟我关系多好都不行，该怎样就怎样。比如说加薪，我的态度是一定要按照绩效来，不能因为你家里条件差，就给你多加薪。也不能因为你家里条件好少加薪。我觉得需要对工作的绩效和产出进行负责。另外，人是一个有感情的动物，跟人交流无论是私下还是公开都要留面子，如果有问题建议私下进行简单有效的沟通，把你认为的问题的严重程度讲清楚，找到好的解决方案。

Q13.怎么才能增强自己在团队中的影响力？就是怎么找存在感？

A13.作为团队管理者，你要有很多的品质，你向下管理团队成员的时候，要有技术的影响力，让别人信服你的技术，你的影响力和存在感就有了。如果你是新到一个团队的，我建议你每天和大家一起吃早饭午饭，这样你的存在感就在了。或者每天找一位团队成员去交流项目的进展和遇到的问题，给予他一些帮助，或者一起改代码，一起做实验，也就是增强你的影响力，也就有存在感了。影响力和存在感其实是绑在一起的。你如果感到自己的影响力不够的话，你可以自己去找一些工作去做，比如说，我最近在研究阿里的代码编写规范，对其进行研究，我在总结这些东西的时候，感觉自己在写一本书，这样可以增强自己的影响力和存在感，前提是要把本职工作做好。

Q14.两种发展路径，技术和管理，哪个对技术要求更高呢？

A14.纯技术，纯管理和技术管理，这3条路径。阿里的一个合伙人，是一个技术大牛，阿里很多开源的框架一手都是他做的。但是他不适合做管理，他适合作一个老师傅，把一个资质不错的新人丢给他的话，这个新人过一段时间也就成了技术大牛。纯管理的话，对技术要求不是很高，更重要的是技术的宽度，这样容易进行沟通。技术管理的话，不仅要懂技术，还要不断学习新的技术，既要深度又要广度，还要很高的情商，还要懂一些心理学，为人一定要坦荡豁达。

Q15.请问跟团队里比较资深的技术，沟通，有什么技巧？

A15.我们举个例子，如果团队中有技术比你好，还比你大五岁的人，你该怎么办，这些人，可能是不喜欢做管理喜欢做技术，或者不适合做管理。首先，如果这个人人品比较好，你要去尊重他，像大哥一样去跟他沟通，在沟通过程中，要尽量展现自己的技术优势，让他觉得你还不错，凡事多听听他的意见，多沟通，逐渐他就会成为你的抓手和拥护者，关键是看他对于你的配合程度，如果技术比较好，你要更加尊重他。

Q16.小团队和大的团队管理有何不同？

A16.我觉得就和我们的分布式的系统一样，系统变大了，就要分为一层两层，如果团队大到一定程度之后，一定要对于团队职责进行细分，你要有小组长或者经理去帮你承担一些事情，他们能够管理好自己的小团队，所有的团队又可以通过3-4个人汇报给你，有些项目你可以亲自抓，有些项目你可以分给你的小组长，每个小组长都可以分到一些工作，这样他们每天占用一部分时间和你交互，其他时间你可以做自己的事情。

至于大团队和小团队的区别的话，如果是大的团队的话，你要把控的是整个产品和技术的方向，密度可能粗一些。如果是一个小的团队，团队工作的每一个环节，你都要负责到。

Q17.我目前团队中有人不服管教，不听指挥怎么办？ 想听一下老师解决方法？

A17.我把你这个问题稍微扩大一下，我上周有一个读者遇到了一个问题，他空降到公司之后，很多人都不服。我建议是首先每天要找一些人去沟通，先找一些对他比较友善的人，评估下他们的能力，如果感觉还不错的话，把一些工作优先交给他们。当然首先要自己对于工作和业务熟悉下，尽快上手，在跟不服管教的进行沟通瓦解。肯定有一些人是不服管教的，如果你把情况稳定下来了，实在还是有不服的话，万不得已，只能开除掉一两个人。但是前提你要有产出，把本职工作做好，因为老板让你过来，是让你解决问题，有较高的产出的，所以 你要把产出的过程中的牺牲讲清楚，这样你才能得到你老板和其他核心骨干的支持。

Q18.那有没有什么团队管理的书籍推荐啊？

A18.我之所以要去写团队管理的书，是因为国内没有相关的一线城市实践类的书籍。如果是CTO的话，你可以去看看一号店或者京东CTO写的书，你可以搜一下，可能对你有帮助。如果你是高级经理的话，目前还没有有效的相关的书，很多是细分的，研发过程管理和系统架构的书可以参考下，技术调研也没有相关的书籍，纯管理的书可以看一些细分的书，比如说，如何和下属进行沟通，这类书籍，可以上京东搜索一下。