在讲清楚技术管理者需要做哪些工作之前，我们通过一个驾马车的比喻类比描述下。
在驾驶马车之前，我们首先要看看马车的定位是什么(拉人?运货?等);其次，要看看目的地在哪里，该走哪条路，朝哪个方向行进;再次是当前马匹的情况怎么样(满员?伤病?等)。这些对应到管理中，就是得弄清楚团队的基本职能、工作目标、团队情况及可选路径，它们代表这方向性的东西，可简称为“管理规划”。
当我们开始驾驶马车时，至少需要做两件事：一边抓住马缰，关照好马的状态和组织分工;一边挥舞马鞭，协调好整个马队的前进方向和节奏，让马匹一起用力把车拉到一个个里程碑和目的地，完成一段一段的旅程。前者对应到管理中，很像是在做人和组织相关的工作，我们称为“带人”，或者“团队建设”;后者对应到管理中，很像是在完成一个个项目或一项项任务，我们称为“做事”，或者叫“任务管理”。
综合上面的比喻示例，可抽象概括下技术管理者需完成的工作如下，下面将展开说明。
(以下内容部分来自果见-刘建国系列文章)。
一、管理规划：“敢问路在何方?”
管理规划对于技术管理者来说，非常之重要。在日常工作中，技术管理者往往需面对大量纷繁复杂的事情，特别是有很多救火类的工作。但在忙乱之余，是不是有一个“全盘规划”的指引，清不清楚把团队带往何方，这才是不同leader领导水平的差距所在。出现问题就解决问题，是一种“问题驱动型思维”。而今天我们所谈论的"管理规划"，就是要回答"把团队带往何方"的这个方向性问题。通过理清未来的发展来理顺当前问题的带团队思路，称之为“规划驱动型思维”。
1、职能
在我们开始管理规划之初，首先要弄清楚就是“这是一支背负着什么样职责和使命的团队”。在明确之后，才能决定了你需要设定什么样的工作目标，并通过哪些要素来衡量你的目标;决定了你需要什么样的人加入你的团队，以及需要多少;还决定了你选择什么样手段，投入什么样的资源来完成工作。这个问题是如此重要，可将其作为管理规划的第一个要素，称之为团队“职能”;这是管理工作的起点。
1)职能层次
团队职能可分为两个层次：基本的职责和升华的使命。前者解决的是团队生存问题，后者解决的是团队发展问题。
职责。是团队职能的下限，即至少要完成的工作。如果这些职责都搞不定，意味着团队的基本价值都不能体现。一般来说，团队的基本职责，是由上级给定的，上级在把这个团队交给你负责的时候，已经给你提了期待，只不过有的上级会明确交代，而有的上级默认你很清楚。所以，你无论如何都需要弄清楚团队的基本职责，否则肯定会失职。
使命。是团队职能的上限，即，如果我们团队做得好，就能承担更大的职责，体现出更大的价值。使命达成后的愿景，常常是令人期待和憧憬的。使命愿景常常是团队leader自己的规划和设想。上级一般不会作出这样的要求，最多就是提一下期待，团队做不到也不会认为是团队失职。
2)设定职能方法
①收集信息。可从多角度收集方方面面的信息，包括上级、同级和下级。对上级而言，需关注上级对团队的期待和要求，特别是用什么维度来衡量团队工作。团队的初始定位和基本职责，一般都是上级直接给定的。同级，则需关注与兄弟部门的职能边界，做好无缝衔接、共同发展。下级则可与大家讨论对团队工作的看法，以及对未来发展的期待。这也可为后续的沟通做好铺垫。当然最为重要的是管理者本身对工作的理解、期许。
②提炼和升华。团队的职责和使命，不能只停留在leader的脑海中，为了方便记忆和传播，则必须从上述信息中进行提炼和升华。提炼和升华有三个要点：
职责的提炼。基于上级的期待和要求，以及你对业务核心价值的理解，最好用上级和团队成员、兄弟部门都易于理解的语言，对职责进行简短化提炼，并尽可能长时间稳定下来。
使命的升华。基于基本职责，寻找团队对于部门和公司的独特价值，并和行业发展趋势结合，设定自己的期待。要注意使用基于“结果”的描述，而非基于“过程”的描述，基于结果的描述会更有使命感。
确定衡量维度。一般来说，团队的职责和使命决定了衡量的维度，但是如果有明确的关于衡量维度的说法，会让员工对职责和使命有更深刻的理解。需要根据自己团队的职能，向员工明确传递，什么指标维度对团队是最重要的。
③确认和主张。提炼完成之后，接下来就是确认和主张。确认主要是和自己的上级确认，得到上级的认同和支持后，就可以向团队内外进行主张了。主张的过程，就是一个长期宣贯的过程，不可能一蹴而就。这也是团队的文化建设的重要组成部分。
2、目标
在明确了团队职能后，下一步就是确定目标。类别前面的比喻，就是需要明确要去的目的地在哪里，才能评估需要什么样的马、多少匹，以及有哪些路线可以选择。这个关于"目的地在哪里"的问题，是管理规划的第二个要素，称为“目标”。
1)设定目标意义
问题明确的目标，对于技术团队管理非常具有意义。
目标设定，可以实现资源的有效配置。明确的目标可以让你把资源投注在有效的方向上，从“该做什么”去调配资源，而不是“能干什么”。
清晰明确的目标可以凝聚团队成员的力量，让大家劲往一处使，提升团队凝聚力。大家因为相同的目标而并肩作战，在一起取得成就的过程中建立起深厚的“革命友情”，这对凝聚力有莫大帮助。
清晰的目标，还是执行力的必要要素。回想一下，有多少工作是因为目标不够清晰，而最终有始无终。
清晰的目标还能提升判断力。当面对某个突发状况快速决策，你非常清晰想要的是什么。
清晰的目标本身就是激励，当员工很清楚自己的工作目标，方向感很清晰的时候，他们更容易进入一种投入度非常高，沉浸其中、物我两忘的工作状态。
2)目标设定原则
目标的设定，可遵从SMART原则。
Specific - 明确性。把目标设定到可以衡量的程度，就叫做明确了。常见的误区是，只做过程化描述，而没有结果。因此，面对这类问题和挑战的钥匙叫做“结果导向的描述”。
Measurable - 可衡量性。跟明确性紧密相关。在具体实施上，可参考有量化指标的KPI，或者目标导向的OKR形式。
Attainable - 可达性。标准上，不能定一个完全实现不了的很高的目标，也不能定一个不需要努力就能实现的很低的目标。定义一个有挑战且努力能达到的目标，才是恰当的。
Relevant - 相关性。对于技术团队来说很难跑偏，因为技术这个角色决定了其工作内容必定是和上、下游及上级目标相关联的。
Time-bound - 时限性。所有的目标都是基于一定时限的，缺少时间限制的目标没有意义。
误区：以资源定目标
常见的一类问题是基于现有资源做目标，而不是基于远方的目标往前推。常见的说法就是，“我们团队只能做到个程度”、“这些项目能做完就不错了”等。其实，更为合理的做法是，从上级的角度来讲，你的团队需要保证哪几项重要的结果，然后再看看如何调配和补充资源。简言之，破解之道就是“以终为始”。
误区：目标变来变去
定义的目标，有时不得不面临一些调整。有些是因为业务的原因，有些是因为上级领导变更的缘故等等。应对此类问题的方法就是“设定专业目标”，用专业目标来增强团队的内在定力。简言之，就是“做正确的事”。
误区：事情太多忙不过来
这是一个优先级的问题，可遵循“重要/紧急象限法”进行分析。具体可参考下图，原则就是将“重要紧急”转换为“重要不紧急”，尽量减少“不重要紧急”类工作;以上措施就可以减少上述问题。
3、团队
针对团队，可以从多个视角来看待。
1)根据团队目标去梳理团队
作为管理规划的一部分，团队规划是管理者必须重点考量问题。这里需要去设定”团队目标”，即在某个时间点，团队发展成什么状态。有如下衡量指标：
团队的规模。也就是你团队有多少人，这其中要理清楚有多少人是现有的，有多少人是接下来要新增的，即实际人数和预算人数，加起来就是你规划的团队总规模。
团队的分工。即，你的团队都负责哪些业务，每个业务配置了多少人力，以及这些人员都如何分工，人力分布和业务目标是否匹配等。
团队的梯队。一个团队的梯队情况代表了团队的成熟度和复原力。梯队成熟的团队，不会因为一些偶然的因素(例如核心人员离职)就随便垮掉。复原力强的团队只是短暂影响部分业务进展，但是不会伤筋动骨、元气大伤，很快就会恢复正常。
2)从资源角度来审视团队
在很多互联网公司里，技术团队往往是最昂贵的资源和成本。作为一个管理者，在盘点自己当前人力和预算人力的时候，需要有成本意识，要考虑投入这么多资源和成本是否值得，是否合理。其实，即便你不考虑这个问题，你的上级也会考虑，所以，你预算人力的时候，最好能给出十分充分的理由。
3)从人才培养角度看梯队规划
对团队的盘点，还需要从人才培养角度来看。即，到下一个时间节点，你需要重点培养出哪些人，给他们什么样的平台和空间，以及你有能力提供给他们什么指导和支持，期待他们能够胜任什么职能和角色。
4、路径
在选择路径之前，需先考虑一个重要因素-资源。脱离资源评估的路径选择是没有意义的。
1)资源评估
这里所提到的资源，不仅仅包括通常意义上的“人、才、物”，还包括其他一些容易忽略的因素。
人。最为常见的资源，为参与到项目的人员。
财/物。一般也是围绕着团队的人员来说的。
时间。最容易忽视的一类资源，时间长短直接影响人的投入。这里需要参考上级的预期，及你个人的客观分析，需要综合你对紧急重要程度的理解做出判断。
信息。是另外一个常被忽视的资源。有的时候，你需要更多的公司内外的信息，你的工作如果需要特殊的信息和数据，需要提前和上级沟通，寻求必要的支持。
权限。是否需要获得某些权限，作为资源投入。比如获得绩效评估的权限，以此来掌握人员激励的手段等。
2)路径评估
站在管理者视角上，就需要评估一段时间内的产出效率。完成一项工作，原来还有很多的手段可以选择。对于你来说，不同的方案意味着着多大程度的成本呢，可以尝试使用如下评估表。把你认为的“大”“中”“小”填入下表中。这个表格最大的意义不在于让你去评估每一种方案的成本大小，而在于扩展你的管理思路，看到解决问题手段的多样性，避免思路过于单一，就达到目的了。在不同的公司、不同的期待之下，不同的管理者会做出不同的选择。这不同的选择会带来不同的效果，同时也意味着不同的成本。
对于自研来说，由于靠自己团队的力量，资金开销比较低，维护成本也可控;而由于需要边学边做，时间成本会比较高。
对于招聘来说，不确定性比较高，招聘顺利固然好，但招聘不顺则时间完全不可预期，整体上时间成本比较高。
对于借调来说，如果能借调到合适的人，各方面的成本是最低的，但是需要这个事情足够重要才能获得支持。
对于跨部门合作来说，项目推进的可控性取决于合作情况，这里最大的风险就是合作成本能否控制住。
对于外包来说，时间和资金成本一般都可控，用来做尝试性项目或者demo是比较合理的。但如果是长期的任务，你会发现外包的解决方案可维护性比较差，迁移和替换的成本会比较高。
采购云服务，对于中小公司来说，其实是很好的解决方案，对人才成本、维护成本、时间成本，都可以降得很低，特别适合初创公司，所以你看业内的云服务层出不穷，确实有价值。
商业方案，是时间成本很低，资金成本略高的一种方案。在应急的情况下，或者是公司非核心业务的场景下，这倒不失为一种好的解决方案。
二、团队建设：“众人拾柴火焰高”
团队建设的核心，在于提高“效率”。参照之前的”工作目标达成分解图”，可将其划分为个体、个体间和团队三个层次。
针对个体而言，重点在于提升能力和个人意愿。
针对个体间而言，在于加强分工和协作。
针对团队，在于构建梯队和文化认同。
1、能力
1)能力分层
员工的工作能力是由三个方面共同决定的，下图可见。
人格力量。通常是指一个人在面对某一情形时稳定的态度和表现，比如迎难而上、坚持不懈、积极正向、主动担当等等。这些人格力量对于个人能否搞定一件事情有时至关重要，但是培养起来却不是一朝一夕的，关键在于平时。
通用能力。没有一个统一的标准，比如我会把沟通表达能力、团队协作能力、快速学习能力等作为重要的通用能力，并和我的团队达成共识。这些能力是可以迁移的，会伴随员工受益终身。
专业能力。对于技术人来说，一般是指技术能力。很多公司都有技术能力衡量标准和体系，用于评估工程师的技术水平。所以，工程师专业能力的评价维度和标准相对于通用能力更加有据可循。
2)鼓励学习
可以组织多种形式，鼓励员工学习。
第一类：帮助员工自学。可组织内外部培训、购买书籍等形式。
第二类：相互交流讨论。可通过定期复盘、技术交流、代码审核等手段进行。
第三类：工作实践。给员工独立负责重要工作的机会，并给予辅导和反馈。
对于提升员工个人能力来说，最关键的往往不是学习的方法，而是学习的意愿。对于很多团队来说，并不缺少学习的机制，而是没有能够有效激发员工的学习动力。主动学习的员工总会是少数派，不只是公司的员工如此，社会生活中的人们亦是如此，所以有人说，“学习是反人性的事情!”。可通过下面多种手段，激发很多员工的学习动力了，你甚至可以把学习和成长放入团队文化建设当中。当然，如果你要把学习作为团队文化的一部分，那就需要你自己首先有学习的“基因”。
推 - 给予压力，推动他们学。比如提出明确的学习机制、工作要求，必要时与绩效、晋升机会、调薪挂钩。
拉 - 指明方向，引导他们学。通过树立榜样、配备导师、辅导方式，引导大家学习。
放 - 给予空间，让他们自主学。在可控情况下，给予员工空间、机会及耐心，让员工充分施展。
2、激励
1)理论 - 马斯洛的需求层次模型
最原始的驱动力主要来源于对生存和安全的渴望，需求层次处于“马斯洛需求模型”的最底层。这类驱动力是人们为了寻求生存下去的基本要素而努力。
第二类驱动，就是“奖励好的行为、惩罚坏的行为”，也就是人们经常念叨的“胡萝卜加大棒”。这是被广泛认同的激励方式，也是当前大部分管理者最常用的激励手段。
第三类驱动，更加强调自驱力。随着中国经济和文化发展，物质奖惩和别人的评价变得不如从前那么令人关注。很多 90 后职场人有着自己笃定的价值观。此外，在这样一个信息时代，员工的创造力更能为公司创造价值，而创造力需要更多的自主和差异。
2)如何激励
第一，激励要立体。你需要从单一的激励维度，升级为更加立体的激励体系，从而适应新职场环境的要求。
第二，激励在平时。不能指望一些临时性刺激方案来做好激励，激励体系的搭建应在平时。当员工跟你提离职的时候，它就已经不再是一个激励问题了。
第三，激励要设计。由于每个人的业务特点不同、团队性质不同、管理风格不同、员工特征不同、问题挑战不同，所以不要迷信别人给你的激励建议，我更建议你充分考虑自己面临的实际情况，结合自己的特质和激励框架，来设计适用于自己的激励体系。
3、分工
不能简单地认为分工一定是件好事。分工是不是好事取决于协作水平，协作水平又受限于管理者的管理水平。通常分工的目的是为了实现规模化(多人干大事)或实现专业化分工(用人之长、避人之短)。
组织结构
从一个业务所涉及的各个角色的分工情况来看，互联网领域最常见的组织结构有两类，一类是矩阵式的，一类是BU式的。
矩阵式结构。员工按照角色被划分到不同的团队，每个团队都有自己的负责人。要做项目的时候，会有专门的项目经理来向各个角色的leader协调人力，然后把申请到的各个角色的人组织在一起去完成这个特定项目。一旦项目完成之后，人员将回归各自团队去迎接新的项目。人力资源是按照角色“横向”来组织的，而项目执行是按照任务“纵向”来推动的，就形成了一个纵横交错的矩阵式结构，所以叫矩阵式组织结构。这类组织架构的好处是各个角色团队的专业度都会很高，而且角色归属感比较强，资源调配灵活;但不足之处是项目执行起来较为低效，因为每次都要重新申请人力，而且每次的项目团队都需要重新磨合。
BU式结构。就是“业务单元”式，也叫事业部制，是指做某项业务所有的人员和资源都统一调配，无论这个事业部是大是小，都角色齐全。这样做的好处是团队长期合作磨合充分，协作效率高，执行速度快;不足是各种角色自己都要有，资源冗余和浪费比较多。另外，由于某些角色不在业务主干上，团队规模比较小，能力要求也不高，所以其角色专业度很难提升。
4、协作
“就是只要一句话，甚至是一个动作、一个眼神，对方就知道是什么意思。”显然，协作水平很高的团队，就好像一部良好运转的机器一样，既有分工，又彼此紧密连接，形成一个有机整体。其核心在于：
一是建立协作机制，通过机制来约定协作的动作，以此来保证大家“动作协调”;
二是提升团队凝聚力，通过提升团队成员间的信任度、认同度和默契度来降低协作成本，提高协作效率。
可以说，“硬件”靠机制，而“软件”靠凝聚力。
1)提升凝聚力
设立共同愿景。想提升团队凝聚力的时候，总是希望大家“心往一处想，劲往一处使。这就要求团队首先要有一个使命和愿景，有一个共同的长远目标，供大家“往一处想”。如果团队有着自己的使命，又能得到团队成员的普遍认同，大家会更容易朝着一个方向共同努力，也更容易肩并肩地一起迎接挑战，即所谓的“志同道合”。
提升员工归属，让员工从心里就认为自己是团队的一份子。你要分给他一份职责，人的内心深处是渴望承担适当的责任的。有当员工清楚自己能为团队做出什么贡献的时候，才会心安，才会感受到自己是团队的一份子。要让员工清楚他肩负的职责对于团队的意义，让他觉得自己做的事有价值，这就是所谓的“事对”。
要营造良好的团队人际关系，让彼此间形成紧密的连接。团队成员间良好的关系，和团队凝聚力的提升是互为因果的，所以不要小看能促进员工间关系的一些小事，恰恰是这些小事，能够促使员工间的合作关系走上正向循环的轨道，员工会因为喜欢和团队的人相处而觉得有归属感。这就是所谓的“人对”。
明确亮出团队的文化价值观。团队的文化和价值观是否是员工认同和欣赏的，决定了他能否长期留在团队。价值观方面的冲突是很难调和的，好的团队文化本身就是一个筛选器，最终留在团队发挥核心作用的都会是认同团队价值观的人。因喜欢一个团队的文化和氛围而产生归属感，这就是所谓的“味对”。
加强相互了解。团队成员间需要不断深入地相互了解和认同。可以通过一些方式增加员工间了解，例如团建活动。这里是需要花点心思去设计的，对增进大家的了解和信任做必要的设计。
共同面对挑战。一起面对挑战的时候，特别能够让大家拧成一股绳。显然一起扛过枪的兄弟，感情是很铁的，毕竟是经历过不离不弃的并肩作战。可以通过攻关项目、紧急故障等，甚至是一些组队的对抗性游戏，都可以得到提升。
5、梯队
一个团队的梯队，就好像一个团队的“骨架子”，这“骨架子”是否健康良好，决定了团队是否健壮。其重点在于梯队的规划和建设方面。规划在前文已谈到，建设就是需要选拨人，并培养成核心骨干的过程。
1)选拔人才
对骨干人员的选择要遵从你团队建设的理念。除了基本的个体能力要强，有成长潜质之外。更重要的是强调其协作能力，因为这些骨干未来不是一个人工作，而是要带领团队的。要强调其行为风格和价值观与团队整体文化相匹配。例如团队强调“勇于创新”，那么一个墨守成规的人员显然不适合成为骨干去培养。
2)培养人才
对齐期待，达成共识。常用方式是IDP，即个人发展计划。可以将IDP与绩效结合起来，就是说培养人才也是要以做出绩效为依托，而不只是为了培养而培养。通过IDP可以对齐你和培养对象彼此的期待，让他清楚你关注的是什么，在这个事情上形成共识，从而形成良好的互动和有效的反馈。但在这过程中需要注意，不要以晋升等作为承诺。一方面，晋升等是需要靠员工表现来获得，而不是靠承诺;另一方面也要留有培养失败的退路，避免不必要的人才流失。
提供机会，做好授权。培养的过程是需要在做事上体现的，你需要给培养对象足够的发挥空间，也就不可避免地要做工作授权。
工作授权三段法
授权整个过程可划分为事前、事中、事后三个阶段。其重点在于事前的安排和事后的反馈。因为既然是授权，事中最好不要干涉太多，只做约定好的check和支持就好。
事前阶段。管理者首先要明确此次授权的初衷是什么。如果是有多重目标，那么主次关系如何。进而让培养对象明确你的期待是什么。此处可沿用目标管理的SMART原则，双方需要明确要求、口径等。在完成授权任务后，需听取其对工作的看法和思路，进而大致判断是否可行，规避风险。最后约定一个沟通机制，为事中做铺垫。
事中阶段。需要管理者定期了解工作进度、评估风险，必要时给予支持，而不是放任自流。在支持方面可遵循“授人以渔”的原则。
事后阶段。对于授权后的工作结果进行评估，并与培养对象充分沟通反馈。注意你的授权目标本身不仅仅只有事情，还有培养目标的。对于培养对象在工作中好的表现，要给予充分肯定，特别是要其优势所在;针对不足之处提供1~2条修改建议，以利后续改进。
6、文化
团队文化就好像是团队的气质和调性，它会吸引“气味相投”的人持续加入，而把不符合团队气质的人筛选出去，越来越鲜明的团队价值观让大家紧密地聚拢在一起，从而让团队越来越“结实”，越来越“经得起折腾”，不断增强团队的耐力和韧劲。关于团队文化部分，我之前有文章专门说明，这里就不展开了。
三、任务管理：“不以规矩，不成方圆”
我们研究任务管理，就是为了把事情做出来，产出实实在在的业绩和成果。作为结果导向的管理者，这才是管理工作的落脚点。同时，也是验证管理规划是否合理、团队建设是否有效的最重要的标准和依据。对任务执行，可划分为三个阶段：
在做事之前，我们需要回答的问题是：要做哪些事?先做哪件，后做哪件?也就是分清楚轻重缓急，也叫优先级梳理。
在做事过程中，我们要确保事情的进展按照计划推进，尽在掌握之中，也就是有效执行。
在做事之后，我们要复盘做事的整个过程，并从过去的经验之中抽取一些流程机制，以便以后在类似的场景下也可以做得更好、更顺畅。
1、轻重缓急
对于每个团队来说，当下能做的工作是有限的，增加并发并不会让大家的产出更高效，所以，多任务并行问题归根结底还是优先级问题，即，你要优先保证哪项工作的顺利进行。
1)重要紧急四象限
2)判断标准
如果做，收益是否很大?收益越大，这个事情就越重要。
如果不做，损失是否很大?损失越大，这个事情就越紧急。
3)应对策略
对于“计划内的工作”，关注它在一个规划周期内的价值和收益有多大。收益越大就越重要，也就越需要给予相匹配的优先级、资源和关注度;收益相对不大，就放入“To do list”，作为待办任务处理。
对于“计划外的工作”，看损失是否足够大，这里包括自身损失和因中断正常工作带来的损失。损失够大，就按照紧急任务安排，以止损为核心目的;如果损失可控，就放入“计划内工作”列表。
4)持续改进
原则上，管理者的中心应该在那些“重要不紧急”的工作上，这些是对团队长期受益的，应该作为主要目标。
“重要且紧急”的工作，要分析其紧急原因，将其流程化、自动化，逐步过渡到不紧急的状态。
“不重要紧急”的工作，往往是事务类的，可交由下属处理，长期可通过自动化改进其紧急状态。
“不重要不紧急”的工作，要反思其价值，是否仍然作为核心工作之一。
2、有效执行
在项目执行中，是否能有效执行，取决于多个因素。
目标清晰。在执行之初，就需要对目标有明确且具体的定义，具体到可执行层面;而且要确保上下级对其理解是一致，没有偏差。当目标出现变化时，要做到及时同步。如果目标不清晰，必然会引起员工在紧急程度、质量水平和效果取舍上的偏差，最后也就引发了执行上的偏离预期。
责任明确。明确工作的“唯一”负责人，避免出现无人负责、多人负责等情况。负责人要起到对应的责任，有关项目中所有涉及项目执行和协调的问题都要负责。
机制健全。不要沉迷于依靠个人完成项目，需要有完善的流程和机制，让员工做事有依据。同时对应还需要必要的监督机制，不要将“流程机制”束之高阁。
沟通到位。在执行中，强调主动沟通意识，要做到沟通闭环，而不要想当然。
3、流程机制
在任务执行之后，针对任务中可抽象出来的部分，可制订必要的流程机制。在指定过程中，可明确几个原则：明确目标、责任到人、检查复核、降低成本、全员共识。避免出现为了流程而制定流程的情况，要做到尽量简化，能解决具体问题。
观点：人靠谱 OR 机制靠谱?
人的靠谱度的方差比机制大，即，人靠谱的时候比机制靠谱，人不靠谱的时候会比机制更加不靠谱。即便是最靠谱的员工，也会由于身体状态、精神状态、情绪状态以及外部干扰变得偶尔不靠谱;而机制的意义就在于，当人不靠谱时，事情也不至于变得很差。所以，机制是为了保证做事的“下限”的。同时，机制有很好的迁移性和传承性，不会随着某个人的缺位而产生大的影响。因此，必要的机制是不可或缺的。
番外篇：“如何做好技术判断?”
作为技术管理者，和普通管理者最大的区别，就是"技术"二字，这也是技术管理者最鲜明的标签和最大的竞争力。从技术工程师到技术管理者的转型，有很多做事的思路和方法都需要转变，其中一个重要的转变就是你和技术的关系。其核心在于从技术实现者到技术应用者的转变，不断提升的是技术的使用能力，而技术实现能力由于投入的时间越来越少，会逐渐减弱。从技术管理者自身来说，既然你选择了做更大的事情，就不得不适当放弃一些细节，放弃一些技术实现能力，不断提升你的技术判断力，让团队行走在正确的方向上。
1、角色转换
技术管理者，对待技术与技术人员会有所区别，是有个角色的转换。
技术实现者：程序设计能力、编码实现能力、技术攻坚能力和技术评估能力，都是需要具备的，主要关心的是"怎么做"，属于"how"的范畴。
技术应用者：技术评估能力变得尤其重要，因为技术管理者主要关心的是"要不要做"、"做什么"，属于"why"和"what"的范畴，是要在综合评估之后，做出决策和判断的
2、评估维度
1)结果评估
要回答"要不要做"，希望拿到什么结果，你要从哪几个维度去衡量结果，从哪几个技术指标去验收成果。事关每项工作的效果和业绩，对结果的评估能力最为关键。虽然结果验收都是放在项目完成后，但是在事先就要明确如何验收，这样才能让大家有的放矢，以终为始。
2)可行性评估
可行性有两层含义：一是"能不能做"，二是"值不值得"。作为技术管理者需要做好角色转换，更多从"值不值得"着手，就是成本收益问题。收益，往往是显而易见的;而成本，就有很多方面需要考虑了，这正是体现技术判断力的地方。
资源成本 — "人财物时"。需要投入多少人、多少时间，甚至是多少资金和物资在该项目上，这项成本相对容易评估。
维护成本。这是评估技术方案时要重点考虑的。考虑维护成本是技术管理者和架构师视野宽阔、能力成熟的体现。这里面包括：技术选型成本、升级成本、问题排查成本、代码维护成本等。
协作成本。多人协作所增加的时间精力开销。一个方案的协作方越多，需要沟通协调的成本也就越高，可控度越低。如果可能的话，尽量减少不同团队和人员之间的耦合，这样会大大降低协作成本。
机会成本。这是技术管理者做决策时要意识到的。即当你把人力、时间花在这件事上，同时就等于放弃了另外一件事，而没有做另外这件事将带来什么样的影响呢?就是你要考虑的机会成本。
3)技术风险评估
也叫技术风险判断力。即，有哪些技术风险需要未雨绸缪，考虑该技术方案带来最大损失的可能性和边界，以及在什么情形下会发生。这项评估工作很考验技术管理者的技术经验和风险意识，而且需要借助全团队的技术力量来做出准确判断。
