03.入职新项目
在职业生涯中，从研发岗位转向技术管理职位，通常有以下几种路径：或是在现有团队中逐步晋升，自然而然地承担起领导职责；或是把握时机，接受上级的任命，实现角色的转变；亦或是通过跳槽，以空降的形式进入新的组织。而我的情况则是跳槽到新的公司，再一个项目组苟了一段时间，突然被调到一个新的项目组，作为十人左右的后端研发组长，结合了上面的二三两种途径；再真实入项之前，首先面临的挑战是接受业务方的面试和评估，以确定我是否满足他们对于该岗位的专业要求。
因此，在这篇文章中，我们将从两个关键的角度出发，深入探讨加入新项目时需要关注的各项事宜。
1. 入项面试
在上一篇文章中，我们概述了新项目的背景情况。这是一个从零开始组建的全新项目组，由项目经理（PM）负责从无到有地构建团队。该团队的服务对象是兄弟单位，其首要任务是将整个项目的产品研发工作，从委托的第三方外部公司，完全迁移至这个新成立的项目组来承担。
对于团队的配置，标准构成包括产品组、前端组、测试组以及后台组，其中后台组进一步细分为业务、中台和订单处理三个关键部分。
此次参与的面试者则主要是产品组长、前端组长、测试组长以及后端组长。而面试官则由上级公司的分管领导以及业务方公司的高层管理人员共同组成。他们不仅评估面试者的专业能力，还会考察我们是否能够与各小组长协作，推动项目的整体研发工作。
1.1 面试准备
本次面试与常规的求职简历投递所经历的面试环节相比，存在显著的差异。它主要倾向于对应聘者进行岗位胜任能力的评估，即一场以任职资格考核为主导的面试。不论是面对哪一种面试类型，我们的基本目标始终不变，即全面而准确地展现自身所具备的专业能力，并在此基础上，通过有效的沟通和展示，提升面试官对我们与目标职位匹配程度的认识和评价。
那么怎样才能增强我们的表现力呢？ 俗话说 “三军未动，粮草先行”，做一件事情的前期准备工作，非常重要；同样的我们需要做一些面试准备，但是这次的面试主题与形式不是很确定，我们的准备工作很难做到有的放矢，那么这种情况下，我该做什么？
a. 确定主题
在大多数情况下，成熟个体所展现的行为和动作。都带有明确的目标导向；作为参与的一方，我们有必要提前深入理解并掌握这一目标的本质。
简单来讲，就是我们需要尽可能的去搞清楚，这次面试的面试官是哪些人，目的是什么，怎么样的表现才是对方希望看到的
以我们常见的求职面试为例，通常会有技术面、领导面、HR面等几个环节，那么每个面试环节的目的就相对明确了
- 技术面：这一阶段的主要目的是评估求职者的技术实力，以确定他们是否具备满足岗位要求的能力。因此，对于求职者来说，他们需要在这个阶段充分展示自己的技术能力，包括解决实际问题的能力，以证明自己具备完成工作的技术能力。
- 领导面：这一阶段的主要目的是评估求职者的综合能力，包括技术能力和领导潜力，以及他们的价值观是否与公司的文化相匹配。因此，求职者需要在这一阶段展示自己的项目管理能力、跨团队协作能力、沟通能力、逻辑思维能力和表达能力等软实力，以给领导者留下自己是一个可靠、能抗压的员工的印象。
- HR面：这一阶段的主要目的是评估求职者的稳定性，以及他们对薪资等待遇的期望是否合理。在这一阶段，求职者需要表达自己的职业规划和期望，同时也需要合理地争取自己的权益。
总的来说，每个面试阶段都有其特定的目的，求职者需要根据这些目的来准备和表现，以便更好地通过面试，获得理想的工作机会。
那么以本次述职面试来说，面临这种信息不明确的述职面试时，理解面试的目标至关重要。从提供的内容来看，此次面试的核心目标似乎在于评估参与者是否具备承担特定项目产研（产品研发）工作的能力。因此，组织方可能会专注于以下几个方面：
- 技术能力：评估参与者是否具有完成项目所需的专业技术和实践经验。
- 项目管理：考察参与者是否有策划和管理整个产品研发过程的能力。
- 团队协作：判断参与者在团队合作中的沟通、协调能力以及领导力。
- 问题解决：测试参与者面对研发过程中可能出现的问题的应对策略和解决问题的能力。
- 适应性和学习能力：了解参与者适应新挑战的能力和学习新技术的速度。
- 压力管理：评估参与者在面对紧张工期或高难度任务时的抗压能力和稳定性。
鉴于此，为了在面试中表现出色，我们可以做以下努力：
- 准备充分，确保对相关技术和项目细节有深入的理解；
- 能够举例说明过往成功管理和执行项目的实例；
- 展示出良好的团队精神和领导潜力；
- 准备好针对可能遇到的技术或管理挑战的解决方案；
- 证明自己的学习能力和适应变化的能力；
- 显示出在压力下保持冷静和效率的能力。
b. 预设问题及回答
基于上面的分析，结合我自己在这个项目组的定位，这个面试过程大概率会问两方面的内容
- 技术能力评估
对于技术问题，更多的应该是一些场景类、或者实际应用难点的解决方案之类的问题，不太会出现零散的知识点
这个就没什么好准备的，因为没啥方向，只能靠自身积累与临场发挥
- 团队管理评估
这方面的问题大概率也是跑不了，核心就在于是否有自己的管理方法论，如何发挥出团队内1+1 > 2的能力；在这里我们就可以提前给自己预设一些相关问题
如何保证你们的团队战斗力？
这一次的项目迁移，你准备怎么做？
跨团队部门的项目推进怎么进行？
如果有临时的、非常紧急的需求，怎么保障？
（在面试过程中，有两个问题确实比较相关，后面详细再说）
c. 准备提问
一般来说，面试的最后都会预留给面试者提问机会，请把握这个机会，在每次的面试过程中都准备几个问题，面对不同的面试官抛出不同的问题，这种时候，对方的答案其实并不重要，重要的是你想借助这个问题，表现出来的个人特质
还是以找工作的面试为例，给出几个通用的问题示例
技术面问题可以是
- 咱们这个项目除了平时日常的需求交付之外，还会有一些性能优化、重构迭代、技术瓶颈之类的问题么？
- 团队的技术氛围怎么样，有没有一些技术分享之类的活动
领导面的问题可以是
- 日常的需求交付主要是项目内就可以完成交付了么？会出现跨团队、跨部门的交流么？
- 团队规模怎么样，今年的主要目标是什么，现在达成了多少，如果我来可以在这里扮演什么样的角色，有什么可以发挥的地方？
1.2 面试过程
这一次的面试，算是我职业生涯中的一个特殊的经历了，面试官有六位，还有一位主持... （这么多人，说不紧张是真有点虚）
抛开一些无关痛痒的细节，对一些有意思的问题下面进行一个复盘
1.2.1 技术问题
所有的面试官中，只有一个是技术出身，问了两个相对常见的技术问题
电商的超售问题怎么解决
比较常见的一个技术面问题，那么这个问题怎么回答呢？ 首先再回答这个问题之前，认清自己的定位，我来是并不是只做一个高级码农的，所以这个问题的回答就不应该仅局限再技术的解决方案上，不妨站在更高的角度，从业务视角来看这个问题
下面是我针对这个问题的回答：
超售在电商系统中是一个相对常见的问题，但是怎么处理这个问题，一般根据实际的业务场景可以区分为两种，一类是我货就这么多，超卖的这些我发不了，因此不允许出现超售；另外一类则没有严格的库存限制，多卖一些也没关系，今天没货，明天可以有，因此允许超售卖一些
对于第一种情况，属于存粹的技术问题，对库存卡得比较严，比如秒杀，本来就是活动价卖，如果超售我就亏了；所以我们先从技术角度出发，来看一下如何杜绝超售这种问题
超售问题在电商系统中确实是一个常见的挑战，需要根据实际的业务场景来选择合适的解决方案。以下是对四种方案的简要解释：
方案1 - 数据库写锁：
- 这是最直接的方法，通过在数据库添加写锁来确保库存扣减操作的串行执行。
- 优点：实现简单，逻辑清晰。
- 缺点：在高并发情况下，性能和用户体验可能较差。
方案2 - 分布式锁：
- 使用分布式锁机制来控制并发操作，减少数据库长时间锁竞争带来的压力。
- 优点：减轻了数据库的压力。
- 缺点：实现相对复杂，需要考虑锁的管理和维护。
方案3 - 乐观锁+事务：
- 结合乐观锁和事务机制来替换数据库写锁，实现库存扣减。
- 优点：相比直接使用数据库写锁，性能更好。
- 缺点：实现方式更复杂，需要处理冲突解决和回滚。
方案4 - Redis计数器：
- 利用Redis的高性能特性，使用其自增/减计数器功能来进行库存管理。
- 优点：可以提供更高的性能和吞吐量。
- 缺点：需要额外的后台任务进行库存校准，或者在低库存时进行事前校准。
对于第二种情况，即允许一定程度的超售，商家需要从业务角度出发进行库存管理和超售处理，我作为商家应该如何做自己的库存管理
Case 1 - 充足库存：
- 如果商家拥有充足的库存，超售一些不会对运营造成影响，可以正常处理订单。
Case 2 - 预留余量：
- 在设置库存时，预留一定的余量，允许出现一些超售。这样即使发生超售，也不会立即导致缺货问题。
Case 3 - 多平台库存调拨：
- 如果商家同时在多个平台上销售商品，可以在不同平台之间进行库存调拨。例如，当一个平台发生超售时，可以从其他平台的库存中调拨商品来补充。
Case 4 - 多层库存模型设计：
- 设计多层库存模型，如三层库存模型：销售库存、可售库存和实物库存。通过区分不同层次的库存，可以更好地管理库存和预测需求。
在这个场景中，商家采用了一种动态的库存管理策略，这种策略考虑了实物库存、预计到货数量以及在不同销售平台上的销售需求。以下是对这种策略的详细说明：
实物库存：
- 这是指在全国范围内各个仓库中实际存储的商品数量。实物库存是商家当前可用的库存，可以直接用于满足顾客订单的需求。
预计到货数量：
- 这是指商家根据生产计划或供应链信息预计在将来某个时间点会到达仓库的商品数量。这部分库存虽然还未到货，但商家有信心它将在未来成为可用库存。
可售库存：
- 可售库存是实物库存和预计到货数量的总和。它代表了商家认为可以用于销售的总库存量。这个数字是商家愿意对外承诺的销售数量，它考虑了未来一段时间内库存的补充情况。
平台销售库存：
- 商家会根据不同电商平台的销售渠道和市场需求，将可售库存分配到各个平台。例如，京东分配800个，天猫分配600个，拼多多分配1000个。这些数字反映了商家在各个平台上愿意销售的库存量，并且可以根据实际销售情况进行调整。
通过这种多层次的库存模型，商家能够更灵活地管理库存，应对超售风险，并优化跨平台的库存分配。这种策略使得商家能够在保证服务质量的同时，最大化销售机会和利润。
电商系统，与很多的三方系统交互，怎么确保交互一定会成功呢
回答这个问题时，很多小伙伴会会不自觉地将自身定位于接口调用方的角色，这样就容易导致回答不够全面；除了扮演接口调用方的角色之外，我们在多方系统交互中，同样可能充当接口提供方的角色；因此，对于这一问题的回应，应当从接口调用方和接口提供方这两个不同的维度进行深入分析
一个简单的回答如下：
与外部系统的交互非常常见，站在自身的角度，通常有两种类型，一个是我们的服务依赖外部提供的接口，还有一类则是别人依赖我们的接口；下面我们将分别进行说明
对于外部的接口依赖场景：
在实际的业务场景中，对外部接口的依赖程度不同，可能对业务连续性产生重大影响。特别是在强依赖的情况下，外部接口的可靠性直接关系到我们自身业务的稳定运行。以下是针对强依赖场景的一些常见管理和应对策略：
冗余设计：建立备份系统或服务，以便在主服务不可用时切换。这可以包括部署多个外部服务实例或使用不同的服务提供商。
故障转移（Failover）机制：实现自动故障转移到备用系统或服务，以减少停机时间。这要求有快速的故障检测和恢复机制。
重试策略：为失败的请求实现自动重试逻辑，特别是在临时性问题（如网络抖动）引起的失败情况下。
限流与熔断：通过限流防止系统过载，以及使用熔断器模式来预防系统性故障传播，一旦检测到异常行为，熔断器会“断开”，避免进一步的调用。
服务降级：在外部服务不可用时，提供有限的或后备的功能，保证核心业务的持续运行。
接口缓存：对于外部接口的结果进行缓存，减少外部接口的调用次数，降低出现问题的概率
对于弱依赖，也有多种处理策略可以采用，以降低外部接口不稳定对业务的影响。以下是几种常见的处理方式：
- 降级策略：在弱依赖的情境下，当外部接口出现问题或访问延迟较高时，可以选择不调用该接口，或者使用备份方案来替代原有的服务。这种策略通常不会影响核心业务流程的进行，因为弱依赖通常不是完成业务流程所必需的。
- 同步改异步：将同步的阻塞调用改为异步的非阻塞调用，可以提升系统的响应速度和用户体验。例如，在用户购票成功后，而不是立即执行推送消息的操作，系统可以在后台发送一个推送消息的异步任务，由消息队列消费这个任务来实现用户消息的推送。这样即使推送服务暂时不可用，也不会影响主要的购票流程。
- 限流与熔断：对于可能引起系统不稳定的弱依赖服务，实行限流措施可以避免过多的请求压力传递到下游服务。而熔断机制则可以在检测到异常行为时自动中断服务调用，避免系统被进一步拖垮。
- 监控与预警：通过实时监控系统的健康状况和性能指标，一旦检测到问题，可以及时触发警报并采取相应措施，比如启动备用系统或执行其他应急计划。
- 依赖治理：建立一套强弱依赖治理机制，通过科学手段持续稳定地获取应用间的依赖关系、流量和强弱数据。这些数据可以用于指导系统改造、故障应对决策等场景，提前发现潜在的依赖问题，避免它们影响用户体验。
对于提供接口给外部的场景：
这种主要是别人依赖我们的接口，当然也属于三方系统交互；常见有两种方式，一个是外部主动调用接口的拉模式，另外一个则是我们回调通知对方的推模式
对于"拉模式"，问题就演变成如何保证我们接口的可用性，那么我们可以采用的策略有：
- 集群模式提供，解决单点问题
- 接口熔断限流，防刷，避免被外部方无节制的调用打挂
- 通过缓存、并发、代码优化等方式，提高接口的性能
- 设置降级策略，当接口不可用时，切换降级方案对外提供支持
- 添加报警监控，实时感知异常，减少故障时长
对于"推模式"，这个对于接口设计方而言，一个设计重点是尽最大努力通知对方，因此我们需要重点考虑的是；
- 确保不漏推： 如将回调的任务持久化，当回调成功之后才将这个任务标记完成； 通过后台任务不断的扫描这些需要回调通知的任务，确保都会推送到
- 设置最大重试次数：不应该因为一个任务永不成功，导致无限重试，每个任务设置一个阶梯的重试时间间隔，超过最大次数之后不再回调
最后再对上面的回答做一个总结，对于三方系统的交互，无法保障100%的成功率，对于系统设计本身，我们应该通过实际的业务场景、重要层级，设置不同接口的可用性，如我们常说的四个9，五个9；我们的设计理念应该是最大程度的保证可用，并且再真的出现问题时，及时发现，立马相应，快速修复，减少问题的影响范围
1.2.2 其他问题
为什么从互联网企业跳槽到现在这里？ 对现在公司的企业信息化怎么看
出乎预料的一个问题，再面试当前这个公司时都没人问这个，结果这次居然被问道了；再听到这个问题时，有一些懵，也有些措手不及。已经回忆不起当时怎么回答的，当然从事后的反馈来看，应该答得还可以。
这个问题本身的答案并不重要，我更想说一下面对这种没有固定答案、且自己之前没有思考准备过的问题时，我们应该怎么处理
首先，遇到意料之外的问题时，不要着急回答，现在脑子里简单过一下，大致想一下回答框架；当然在实际的面试过程中，不可能留给我们很多空白时间来思考，因此一个简单实用的应对方案即，再缓慢的将问题复述一遍，一边拖延时间，一边找这个问题中的关键词
接着将上面的关键词进行拆分，将一个问题拆分成多个子问题，分别进行回复；再这个过程中，我们需要重点注意回复的技巧，正如我们写文不可能通篇一个大段一样，我们的回复也需要分个一二三，不管这个一二三条的逻辑关系是否合适，但是我们重点需要的就是给人一个条理清晰的认知
其次，再回答时，注意避重就轻，将问题转移到自己熟悉的领域，可以通过自问自答的方式来转移话题，比如上面问题中，我一直是搞互联网的对企业信息化没有了解过，那么我就可以这样回答
我为什么会从互联网行业转到这里呢？因为我个人之前一直再互联网内的公司工作，可以简单的从我的过往履历中说一下我对互联网的看法，我再xxx干的xxx .... 最后再提一下，对于企业信息化，这块由于之前没怎么接触过，但是我个人又比较喜欢接触新事务，从之前的服务人、到现在的服务企业，感觉是一个非常有意思、有挑战的事情，也正好可以打开我个人的视角
对即将接受的这个项目了解多少
回答套路如上，具体结果省略
项目的产研迁移，怎么保证不出问题的同时，又能支持任务的迭代交付？
这个问题虽然看着比较具体化，但实际上，是一个相对通用的问题模板；对于考核一个人，能否完成我们的要求时，比较常见，就是看一下这个事情交给你之后，准备怎么干，有没有目标计划，有没有行动章法
回答这样的问题，首先就是认清自己的定位，小兵还是攻坚，百夫长or统帅？
以我个人的实际场景来说，本身是来当研发组长角色，因此更多的需要站在能否以技术leader的角色，带领大家完成这个系统的迁移，那么这个过程中对我的要求是什么呢？
- 再团队内培养他人对自己的信任感
- 能攻坚、能做任务分配拆解
- 发挥团队力量，完成任务目标
对于这个项目的开展，我们首先需要搭建对应的成员班底，因为这个项目毕竟是将一个生产运行的系统，从外部迁移到新组建的项目团队，因此对于我们的人员要求较高，所以我们会优先从公司内抽调一些资深靠谱的小伙伴，来作为前期的攻坚手； 对于我们个人而言，需要做的事情则主要围绕在目标制定、任务拆解、结果校验上，大家前期以事驱动，新逐渐的团队，不存在明显的责任划分，根据大家的实际表现，来动态调整职责任务的分配。再团队内部，第一阶段目标主要是以磨合为主，养成大家的配合默契，同时也是对我个人的挑战，一个是再这个过程中充分的展现自己的能力，让别人可以信服自己，其次则需要再这个阶段认清团队成员的梯度情况，然后根据不同的人来制定不同的目标，以小步快跑的方式，实现一个一个目标，从而完成最后的项目迁移
针对这个工作展开，之前有准备一个思维导图如下，可以按照这个进行回复
领导的临时紧急任务，如何支撑？再有限的时间内，确实完成不了，怎么处理？
在实际工作中，我们经常会遇到领导突然下达的紧急任务。在这种情况下，我们首先需要考虑的不仅仅是如何去完成这个任务，更重要的是要理解这个任务的重要性和合理性，以及领导的核心诉求和他期望的结果。我们需要从结果出发，逆向思考这个任务的合理性，以及是否有更合适的方法来实现这个结果。在技术层面，往往有多种方法可以达到相同的效果，但它们的成本可能会有很大的差异。
一旦我们确定了这个任务必须被处理，我们就需要开始分析并拆解这个任务，识别出哪些部分是核心的，哪些部分是耗时的。我们可以优先处理那些核心且容易实现的任务，并将这些任务交给能力强的同事。对于那些既核心又难以处理的任务，我们可以专门指派人员来处理。这里所说的任务拆解，实际上更像是我们常说的任务优先级设定，我们需要优先保证高优先级的需求得到满足。
当我们在分配任务优先级和人力资源之后，如果发现时间仍然不够，我们应该如何处理呢？
- 针对这种情况，我们首先需要考虑是否是人力资源不足。如果是，我们可以通过协调人力，增加人手来解决。如果可以通过加班来赶进度，那么我们可以牺牲一些个人的休息时间，加班赶工。
- 如果增加人力无法解决问题，我们可以考虑将任务分为多个阶段，按照最小的迭代单元进行分批交付。在截止日期之前，我们可以先上线部分功能，确保整体功能的可用性，然后再逐步完善。
- 如果我们在有限的时间内连最小的迭代单元都无法完成，那么我们可以考虑使用临时方案进行交付。例如，我们可以先用模拟数据或者静态页面来暂时替代。
以上是基于任务工作量评估的处理策略。当然，在执行过程中，我们也需要关注每日的进度同步，及时上报问题和风险。除了保证功能的交付，我们还需要关注交付的质量，上线后需要密切关注，并进行长期的跟踪和优化。
1.3 小结
在面试过程中，无论是入职新项目的面试还是一般的面试，以下几点是非常重要的：
- 前期准备：了解公司背景、职位要求和面试流程。研究可能的面试问题并准备好回答。确保自己的简历和求职信准确无误，突出自己的优势和与职位相关的经验。
- 条理性回答：在回答问题时，尽量按照一二三四的分段式回答，清晰地表达自己的观点和想法。
- 语速与语调：注意回答的语速，不要过快也不要过慢，确保清晰可懂。语调要自然，避免单调。
- 减少小动作：保持良好的身体语言，减少不必要的手势或面部表情，以提高个人的印象分。
对于重要的面试，如年终/中述职或晋级答辩，可以采取以下策略：
- 模拟面试：找一些小伙伴充当面试官，进行多次模拟面试，以便熟悉面试流程和提高应对能力。
- 自我录音：如果找不到人进行模拟面试，可以通过手机录音的方式记录自己的回答过程，之后回放并分析，找出不足之处进行针对性的改进。
- 持续练习：面试技巧的提升需要时间和练习，不断练习总会带来进步。
下面也是我再面试完毕之后，主持这场面试的项目经理给我的反馈，整体评价是再几个面试者中最高的（通过这一次的面试，我本人再PM这里也刷了一波存在感，留下了非常好的印象，后续的工作展开也确实得到了很多的优待帮助）
2. 职责认知
进入新的项目组之后，很容易想到的就是如何融入团队，但是在这里，对于技术管理而言，我则更想说一下，如何对自己做好角色认知和角色定位
如果我们是以研发的角色进入一个新的团队，那么我们的自我定位则比较明确，快速熟悉项目、能迅速上手，做需求交付；那么做技术管理而言呢？
同样的对于我个人而言，面对即将进入的项目组，同样面临这些问题。我来干什么？ 上面的领导希望我干什么？ 我又能干什么？
接下来我将从角色定位、职责要求说一下我个人对这些的理解
2.1 角色定位
从研发到管理，必然是存在一些改变的，假定看我这些水文的都是资深的研发小伙伴，接下来的视角将重点放在从“研发工程师”到“技术管理”的角色转变上
以下内容，主要摘抄于 《知行-技术人的管理之路 by 刘建国》
2.1.1 职责使命
对于研发而言，我们的职责就是干好上级分配的活，或者更进一步，对于一些资深的小伙伴而言，老板有一个想法，我们可以从技术的视角来做拆解、、分配、落地、执行/亦或者判断是否有必要做这个事情
对于管理者而言，不是自己来做这些任务的研发执行，更多的则是让其他的小伙伴来做最终的落地，比如上面资深小伙伴的任务拆解、分配、推进等大多都是技术管理的工作要求。这通常也意味着，上级只是帮我们设定一个目标，剩下做什么、怎么做，都是我们需要考虑的
2.1.2 负责对象
对于研发而言，通常我们只需要对自己负责，做好自己的工作内容即可
对于管理者而言，向下需要对自己的团队负责，整体团队的成长、绩效、输出、口碑都是需要自己来维护与经营打造；向上则需要对自己的领导负责，有没有浪费公司资源，顺利完成公司分配的任务，达成or超出既定的目标
2.1.3 关注焦点
对于研发而言，一般是过程导向，关注脚下，是否有一步一步将工作执行到位
对于管理者而言，通常则是目标和结果导向，我们有没有完成既定的目标，后面准备做什么
2.1.4 工作内容与能力要求
对于研发而言，主要是靠个人的专业能力作为产出，做需求、任务的实现交付，项目系统的运营维护；因此技术专业性通常是核心且最重要的衡量指标
对于管理者而言，出了技术判断力之外，还需要目标管理能力、团队规划能力、项目管理能力、沟通协调能力、团队建设能力等等，需要看方向的、带人的、做事的更加多维和立体的能力
2.1.5 任务来源
对于研发而言，任务一般来自于上级安排，主要是听指挥
对于管理者而言，出了上级安排的任务之外，更多的需要自己筹划、然后再主动去与上级沟通确认，从被动接活到主动“找事”
2.1.6 实施手段
对于研发而言，通常都是动手实干，亲力亲为，主要的贡献就来自于自己的专业产出
对于管理者而言，更多的是统筹，靠整个团队一起来完成
2.1.7 合作维度
对于研发而言，合作的通常是和平级的小伙伴，一起做好研发工作，常见的合作对象是共同参与的研发、测试、产品、ui等
对于管理者而言，合作的对象就比较丰富了，如需要和上级合作规划好整个团队的目标，和下级合作做好落地执行，和平级管理者合作完成联合项目，有时候还需要和平级的上、下级去一起协调资源和进度
2.1.8 合作关系
从团队成员的合作关系来看，对于研发者而言，与团队内成员是“竞争与合作”的关系，日常的工作大多需要共同协作推进，但是大家应该也都经历过资源的竞争、绩效的争取
对于管理者而言，在团队内一个显著的区别则是不应再有竞争的关系了，我们和团队应该处于全面合作的关系，对于管理者的评价标准更多的是看整个团队的产出
2.1.9 思维方式
对于研发而言，通常是执行的思维方式，如何将一件事情落地，更关注过程与实时细节； 通常研发的估算排期比较保守，因为他们需要确保能完成才愿意答应
对于管理者而言，虽然也考虑风险和成本，但是更习惯于去关注做一件事能带来的可能性收益，并以此来判断是否值得投入资源去做，这种更多的是“规划思维”
由于管理者总是在盘算和筹划一些可能会对公司和团队有价值的事情，而没有仔细考虑风险和成本，所以在工程师的眼中，管理者时不时会提出一些“不靠谱”的期望和需求，但这正是两个角色关注的东西不同造成的。而这恰恰是一种很好的合作与互补
2.1.10 技术视角
对于研发而言，技术是核心生产力，用来保障我们做好实施的主要手段，更多的是以运用的角度来看待技术
对于管理者而言，技术是达成目标的手段之一，通常是结合实际场景，判断这个技术是否合理，当前最优，经常需要做一些技术决策。对于技术管理者而言，切忌技术崇拜，不能为了追求时髦而引入各种没什么用的技术栈
2.1.11 小结
接下来以表格的方式将上面的对比进行小结如下
| 维度 | 工程师 | 管理者 |
|---|---|---|
| 职责使命 | 拉好车-做好自己手头的工作就无咎 | 驾好车-引领整个团队往前走 |
| 负责对象 | 对自己负责 , "管好自己就可以了" | 对公司(上级)和团队(下级)都负责 |
| 关注焦点 | 过程导向:脚下的路 | 目标和结果导向:是否达成目标 |
| 工作内容 | 内容单纯 , 主要靠专业能力 | 多维立体 , 所需能力维度大幅增加 |
| 任务来源 | 上级安排 | 自己主动规划&向上沟通 |
| 实施手段 | 主要靠自己 | 主要靠团队 |
| 合作维度 | 平级合作为主, 维度单一 | 360 度合作, 维度立体 |
| 合作关系 | 和团队成员是平级竞合关系 | 和团队成员是全面合作关系 |
| 思维方式 | 执行思维, 习惯关注确定性风险 | 规划思维, 习惯关注可能性收益 |
| 技术视角 | 技术实施视角 | 技术评估视角 |
角色认知的改变，并不是一蹴而就的，需要你我们不断的自我审视和有意识的纠偏，这也是我们做转变的第一道门槛。
2.2 职责要求
上面是认识到角色的定位，我们知道应该往什么样的方向进行转变自己，但是接下来我们应该做些什么呢？
简单来讲，我来这个项目，到底是让我来干嘛的!
接下来我将以个人实际的体验，来反推一下，一个技术管理的职责要求
2.2.1 任务清单
因为这是一个新组建的项目团队，初期目标就是将系统从外部团队接手到项目内，所以给我的任务就比较清晰了
- 人员招聘，团队组建
- 研发管理流程规范制定
- 项目迁移，外部对接
- 需求交付，任务实施
对于项目前期，需要干的事情实际上比较明显，无非就是 团队建设 + 标准规范 + 任务交付，至于接下来怎么来做些事情，我会再之后的文章中分段说明
2.2.2 管理图谱
下面是一个我个人感觉很有收获的图谱，同样分享给各位小伙伴，当然由于我个人能力有限，以下图谱的内容，再后续的阐释中，可能会有一些偏差谬误之处，还请多批评指正
