初级技术经理人题库及答案

初级技术经理人题库及答案一、选择题1.技术经理在项目启动阶段的首要任务是：A.编写详细的技术方案B.组建项目团队并明确角色C.估算项目成本与预算D.与客户进行技术细节谈判答案：B解析：项目启动阶段的核心是“人”和“目标”。技术经理的首要任务是组建一个具备相应技能的项目团队，并清晰定义每个成员的角色与职责，这是后续所有技术和管理活动的基础。虽然A、C、D也都是重要工作，但均需在团队初步组建和方向明确之后才能有效开展。2.在进行技术方案评审时，以下哪项是最应关注的原则？A.方案是否采用了最前沿的技术B.方案的成本是否绝对最低C.方案的技术可行性、风险与业务需求的匹配度D.方案是否与竞争对手的方案完全一致答案：C解析：技术方案评审的核心是评估其是否能在可控风险下，可靠地满足业务需求。盲目追求前沿技术（A）可能引入不可控风险；单纯追求成本最低（B）可能牺牲质量或可维护性；模仿竞争对手（D）则可能忽略自身业务的独特性。因此，可行性、风险与需求匹配度是决策的关键。3.某开发任务原计划需5人天完成，目前投入了2名工程师工作了3天，已完成任务的60%。根据当前进度，要按时完成该任务，最可能需要采取的措施是：A.增加一名工程师B.要求现有工程师加班C.减少任务功能范围D.重新评估任务优先级答案：A解析：首先进行挣值分析。计划价值（PV）为5人天。实际成本（AC）为2人×3天=6人天。挣值（EV）为5人天×60人天。成本绩效指数（CPI）为4.在团队管理中，发现一名资深工程师对分配给自己的任务经常拖延，且代码质量下降。技术经理首先应该：A.在团队会议上公开批评，以示警告B.立即将其调离核心开发岗位C.私下进行一对一沟通，了解原因D.将其任务分配给其他更可靠的成员答案：C解析：人员绩效出现波动，其背后往往有个人、技术或环境的原因（如家庭问题、职业倦怠、对技术栈不熟、对任务价值不认同等）。作为技术经理，首要职责是充当教练和倾听者，通过私下、真诚的沟通（C）来探寻根本原因，这是解决问题的基础。公开批评（A）会伤害员工自尊，破坏信任；直接调岗（B）或剥夺任务（D）是逃避管理责任，且未解决问题根源，可能对团队士气产生负面影响。5.关于技术债务，以下描述最准确的是：A.技术债务是坏的，应该在项目初期完全避免B.技术债务是软件开发中一种可管理的权衡策略，需有计划地偿还C.技术债务只存在于遗留系统中，新系统不会产生D.偿还技术债务应优先于所有新功能开发答案：B解析：技术债务比喻为了短期利益（如快速上线、满足紧急需求）而在代码、设计或架构上做出的妥协，这些妥协会在长期增加维护和变更的成本。它并非完全“坏”，有时是一种合理的商业策略（B正确）。完全避免（A）不现实且可能错失市场机会。新系统在快速迭代中同样容易产生技术债务（C错误）。偿还技术债务应与新功能开发取得平衡，根据债务的“利息”（即对当前开发效率、系统稳定性的影响）来优先级排序，而非绝对优先（D错误）。二、填空题1.在敏捷开发中，用于可视化工作流、限制在制品数量并促进持续改进的常见实践是__________。答案：看板方法解析：看板方法的核心原则包括可视化工作流、限制在制品（WIP）、管理流动、使规则显式化、实施反馈循环和持续改进。它是敏捷实践中用于流程优化的重要工具。2.技术经理在评估团队产能时，不应简单地将个人产能相加，而需要考虑沟通、协作和上下文切换带来的__________。答案：损耗或开销解析：布鲁克斯法则指出，为一个延误的项目增加人手，可能会使其进一步延误。这是因为新成员的加入增加了沟通路径和培训成本，即团队协作存在固有的损耗。因此，团队产能通常小于个人产能之和。3.一个软件模块对其他模块的依赖程度高，而其他模块对它的依赖程度低，该模块的耦合类型属于__________。答案：扇出耦合高或传出耦合高解析：在软件工程中，耦合度衡量模块间的相互依赖性。一个模块依赖其他模块的数量称为“扇出”。扇出高意味着该模块控制或依赖于多个下级模块，复杂性较高，修改时影响范围可能较大。4.在项目风险管理中，对已识别风险的发生概率和影响程度进行定性或定量分析的过程称为__________。答案：风险分析解析：风险管理过程包括：风险识别、风险分析（定性/定量）、风险应对规划、风险监控。风险分析是在识别风险后，评估其可能性和影响，以便对其进行优先级排序。5.当团队采用微服务架构时，技术经理需要特别关注服务间的__________管理、数据一致性和分布式系统的监控。答案：通信或网络解析：微服务架构将单体应用拆分为多个独立部署的服务，这带来了服务发现、负载均衡、容错（熔断、降级）、API网关、分布式事务（数据一致性）和跨服务链路追踪等新的挑战，核心是服务间通信的可靠性与可观测性。三、简答题1.简述技术经理在代码审查（CodeReview）过程中应关注的重点，以及如何营造积极的代码审查文化。答案要点：关注重点：（1）正确性：代码是否实现了预期功能，逻辑是否正确，有无边界条件错误。（2）可读性与可维护性：命名是否清晰，结构是否良好，注释是否恰当（解释“为什么”而非“是什么”）。（3）设计与架构一致性：是否符合项目既定架构和设计模式，是否引入了不必要的依赖或复杂度。（4）测试覆盖：是否包含恰当的单元测试或集成测试，测试用例是否充分。（5）安全性：有无常见的安全漏洞（如SQL注入、XSS等）。营造积极文化：（1）明确目的：强调审查是为了保证质量、分享知识和共同成长，而非挑错或指责。（2）制定准则：建立清晰的代码规范和审查清单，减少主观争议。（3）以身作则：经理自身提交的代码也应接受审查，展现开放态度。（4）正向反馈：首先肯定代码中的优点，再以提问和建议的方式提出改进意见（如“是否可以考虑...”）。（5）控制节奏：限制每次审查的代码量，要求及时响应，避免审查成为瓶颈。（6）鼓励讨论：将审查视为技术讨论的平台，鼓励被审查者解释设计思路，达成共识。2.作为技术经理，当接到一个“不可能完成”的紧急项目需求（如极短工期、超高要求）时，你会如何应对？答案要点：（1）冷静分析与澄清：首先与需求提出方（如产品经理、业务方）深入沟通，澄清需求的背景、核心价值和所有约束条件。区分“真实需求”和“提出的解决方案”。（2）专业评估与透明沟通：组织技术骨干进行快速评估，量化“不可能”的原因（如所需人天、技术瓶颈、依赖资源等）。将评估结果、潜在风险和所需条件（如更多时间、资源、或简化范围）以数据和事实的方式，清晰、透明地反馈给需求方和相关干系人。避免简单说“不”，而是提供专业分析。（3）探索替代方案：与团队和需求方一起头脑风暴，寻找折中方案。例如：采用MVP（最小可行产品）分阶段交付；调整非核心功能的范围或质量要求；寻求外部资源或现有解决方案的支持；或采用更激进但风险可控的技术方案。（4）管理期望与争取支持：基于评估和替代方案，与干系人协商一个现实可行的目标、范围和计划。如果需求确实不可妥协，则明确需要上层决策者提供的额外支持（如加人、加钱、承担明确风险）。（5）记录与跟进：将沟通结论、决策依据、调整后的计划及已知风险正式记录，并确保团队和干系人达成一致。在项目执行中持续监控风险。四、计算与分析题1.某技术团队维护一个核心服务，其可用性（SLA）承诺为99.9%。在过去一年中，该服务因故障总共不可用了45分钟。此外，团队每月进行一次计划内维护，每次维护导致服务不可用30分钟。（1）请计算该服务过去一年的实际可用性百分比（不考虑计划内维护）。（2）请计算该服务是否达到了99.9%的SLA承诺（不考虑计划内维护）。（3）在SLA协议中，计划内维护时间通常被排除在可用性计算之外。若考虑此规定，该服务过去一年的实际可用性是多少？（4）基于当前数据，为了确保未来一年达到99.9%的SLA（不含计划内维护），故障导致的年度累计不可用时间必须控制在多少分钟以内？答案与解析：（1）一年总分钟数：365天故障导致的不可用时间：45分钟。实际可用时间：525600−实际可用性：×100计算过程：1−（2）99.9%的SLA对应的允许不可用时间上限为：525600×实际故障时间45分钟远小于525.6分钟，因此达到了SLA承诺。（3）计划内维护每年12次，每次30分钟，总维护时间：12×根据协议，计算可用性时应排除计划内维护时间，即可用性计算的分母和分子均扣除该时间。总业务时间（分母）：525600−故障导致的不可用时间（分子）：45分钟。可用时间：525240−实际可用性：×100。（计算：1可见，在排除计划内维护后，计算出的可用性与(1)几乎相同，因为计划内维护时间从分子和分母中同等扣除。（4）要达到99.9%的可用性，允许的不可用时间上限为525.6分钟（计算见(2)）。因此，故障导致的年度累计不可用时间必须控制在525.6分钟以内。这是一个更宽松的目标，但团队应致力于远低于此值，以提供更高可靠性。2.你管理着一个由8名工程师组成的敏捷团队。团队的历史速度（Velocity）稳定在每两周（一个迭代）完成40个故事点。现在有一个新项目，经过初步梳理，其产品待办列表（ProductBacklog）总规模估算为320个故事点。（1）不考虑其他因素，仅基于当前速度，团队完成整个产品待办列表大约需要多少个迭代？（2）业务方希望项目在12周内上线第一个可交付的版本。技术经理计划为此版本规划一个“最小可行产品（MVP）”，其范围应控制在多少故事点以内？（3）在项目进行到第4个迭代时，团队速度突然下降至30个故事点/迭代。经了解，主要原因是引入了两名需要大量指导的新成员，以及一个关键外部系统接口不稳定。作为技术经理，请分析你可能采取的应对措施。答案与解析：（1）所需迭代数：总故每个迭代2周，总计需要8×（2）12周包含的迭代数为：12/基于当前速度40点/迭代，6个迭代能完成的故事点数为：6×因此，MVP的范围应控制在约240个故事点以内。技术经理应与产品负责人协作，从320点的待办列表中，根据业务价值优先级，筛选出价值最高的240点左右作为MVP范围。（3）应对措施分析：a.针对新成员融入问题：指派经验丰富的工程师作为导师（Buddy），进行结对编程和知识传递。为新成员安排相对独立、难度适中的任务，逐步建立信心。在迭代计划会议上，适当降低对新成员产出的预期，将学习成本纳入考量。b.针对外部接口不稳定问题：立即与提供接口的外部团队负责人沟通，明确问题的严重性和对项目的影响，要求其给出稳定性修复的时间表。在技术上，考虑实施容错机制，如熔断器（CircuitBreaker）模式、请求重试与退避、以及优雅降级（Fallback）方案，以减少对不稳定接口的依赖。在团队内部，可以针对该接口开发一个模拟服务（MockService），在外部接口不可用时用于开发和测试，保证团队进度不受阻塞。c.项目管理调整：向产品负责人和干系人透明沟通速度下降的原因、影响及应对计划，重新调整对近期交付预期的期望。考虑在接下来的1-2个迭代中，适当降低承诺的故事点数量（例如，从40点降至30-35点），以反映当前的实际产能。加强每日站会，密切关注由接口问题和新手任务引发的阻塞项，并迅速协调解决。五、案例分析题案例背景：你是“智联出行”公司网约车平台后端服务团队的技术经理。团队负责的核心服务“订单匹配引擎”近期频繁出现性能抖动，在高峰时段响应延迟（P95）从正常的200ms飙升到2s以上，导致部分用户叫车超时失败。团队已紧急扩容了服务器（CPU和内存），但问题未得到根本缓解。你召集了一次技术会议，资深工程师A认为问题出在数据库查询慢，工程师B认为是某个外部地理信息服务（GIS）接口响应变慢导致的，工程师C怀疑是新发布的智能派单算法有性能缺陷。大家各执一词，且都有一些零散的监控图表支持自己的观点。问题：作为技术经理，你将如何系统性地领导团队定位并解决这个生产环境下的性能问题？请详细阐述你的步骤、方法和过程中需要注意的事项。答案要点：1.立即止损与监控强化：设立熔断与降级：立即评估是否可以对疑似有问题的组件（如GIS接口、新算法）实施熔断机制或降级方案（例如，在高峰时段切换回更稳定的旧算法或使用缓存的地理数据），快速缓解对用户的影响。统一监控视图：整合零散的监控数据，建立一个统一的性能仪表盘。关键指标必须包括：服务整体入口流量、响应时间（平均、P50、P95、P99）、错误率；下游依赖（数据库、GIS服务、算法服务）的调用量、响应时间、错误率；系统资源（CPU、内存、磁盘I/O、网络I/O）利用率。确保数据具有可比性和关联性。2.系统性问题定位：数据驱动，假设检验：要求每位工程师用数据支撑观点。引导团队将问题分解，并设计可验证的假设。数据库假设：分析慢查询日志；检查高峰时段数据库的CPU、锁等待、慢SQL数量是否与服务延迟峰值强相关；对比扩容前后数据库负载指标。外部服务（GIS）假设：查看调用链追踪（如APM工具），确认GIS服务调用在延迟峰值期间的耗时占比；检查GIS服务的独立监控，看其响应时间是否同步恶化。新算法假设：进行A/B测试或特性开关，在低流量时段或特定区域灰度切回旧算法，对比观察延迟指标。分析新算法的复杂度，审查其代码中是否有循环、递归或高内存消耗操作。利用profiling工具：在测试环境或生产环境（通过安全采样）对服务进行CPU和内存性能剖析（Profiling），找出消耗资源最多的函数或代码段。分析调用链：利用分布式追踪系统，找出在延迟高的请求中，时间具体消耗在哪个服务、哪个方法或哪个网络调用上。这是定位瓶颈最直接的手段之一。3.根因分析与解决方案制定：确定主因：综合以上数据，找出导致性能抖动的首要根本原因。可能是单一原因，也可能是多个因素叠加（如新算法在某些场景下触发大量低效数据库查询，同时GIS服务偶尔超时加重了问题）。制定解决方案：针对根因，制定具体、可衡量的解决方案。若是数据库问题：优化SQL语句