这是鼎叔的第十九篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。

4 月 23 日周日，鼎叔返场再次参与小道消息播客，和主持人老徐和兔子继续畅谈。本文是返场直播的第一部分，重点分享项目测试时间不足怎么办，以及 leader 如何同时修炼好管理和技术。

在之前的直播中，鼎叔分享了他关于向上管理、向下管理，跨团队跨部门管理，以及 leader 自我修炼的经验。欢迎查阅：聊聊 leader 的向上管理和向下管理 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483800&idx=1&sn=96aa54572e672ec236b8bfb3dc9b9ac7&chksm=c24fb4faf5383dec9369e842487b711d55121fb8fd6d08fc4f9fb092c3ecdebf72ee501d6e7e&token=912696903&lang=zh_CN#rd
，聊聊 leader 的自我修炼 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483802&idx=1&sn=bcbd8484c38b95b7c83e73e6e560b53e&chksm=c24fb4f8f5383deed7ab529402e7bc27751832010f8c3a9a612bd89f20399791f9b60b514e5c&token=912696903&lang=zh_CN#rd

本次返场，继续分享涉及多维度的项目管理和人员管理问题。

本文是根据分享，精简和提炼出的文字版本。点击文末链接，收听完整音频分享。

01
如何应对为了守住项目上线日期，缩短测试时间的情况？
一、放平心态，坦然接受
做项目必然要面对交付的风险，测试团队经常被推到风险 “兜底人” 的角色——且不论这种做法是否正常，但确实存在。因为测试阶段之前的环节延误，而导致留给测试的时间变短的情况也经常发生。

在这类事情发生后，只要我们已经做好 “分内” 之事，尽到专业精神，实际上并不会承担太大指责。哪怕项目失败了，也很少真的归咎于测试。

二、面对测试时间可能被压缩，应该重点把握的几件事
尽早跟产品或项目经理或者开发，充分沟通整个项目的交付周期，并明确测试独占周期。
“尽早” 是多早？这时候还在项目规划中，开发可能还没开始写代码。我们在这个阶段就要考虑好，需要多长时间留给测试独占。

什么叫做 “独占”？就是在开发写完代码并且正式提测后，单独留给我们开始测试到最后完成测试的一段时间。

一方面我们要公开透明地给出测试所需的独占周期，如果测试时间会被压缩，也好明确能接受的最短时间。

比如，预估的测试独占周期是七天，但是产品或者项目经理说只有五天测试时间。我们可以只用五天来测试，但是要公开一份项目关键角色签字承认的风险声明：通过倒排，把原本七天的工作按照优先级放在五天来做；如果发生一些意外或者发生一些问题，那么有可能要放弃优先级低的两天的工作，或者是降低质量。如果像这样规划好，在这五天保证好基础的质量，就算上线后有一些小 bug、小故障，我相信大家也是可以接受的。

另一方面要考虑，测试独占周期里面的所有测试工作，是不是只能按顺序 “串行”？比如说，我们的测试工作包括兼容测试、性能测试和功能测试，在时间有限的情况下，这些不同类型的测试工作是否可以并行，在短时间做好更多的工作。

B. 不是只能在提测后进行的事情，可以左移到独占周期之前来做，并且透传给项目的关键角色。

到底有哪些事情可以左移呢？以我自己现在所做的大型项目为例，可以左移的事情大概有这些：
01

通过提前计划测试范围和测试策略，估算所需测试人力，预测后期可能需要借调多少测试人员
有一些大型项目，在测试阶段会很慌乱的一个原因就是，突然临时找了一堆人来协助测试。如果临时抱佛脚，虽然人力增多，但是可能比原来的质量更差。作为测试负责人，当我们预见到人力有可能不足的时候，就早一点把可以帮助测试的人力卷入进来，提前告知他们后期有可能要来协助我们做测试。可能这些测试人员手上已经有其它项目要跟，我们至少可以先给他们分享一些项目资料——比如已有的测试资料、测试用例和测试策略等知识，让他们先从学习的角度做好准备——后期就能更好地缓解测试资源的不足。
02

把一些专项规划提前做好
什么专项呢？比如说测试环境。

越是项目时间紧张时，测试数据和测试环境经常是导致 “意外” 发生的主要原因之一。怎样提前构建好测试环境呢？其中一个做法就是，让开发在我们的环境里做自测。有的公司会实行 show case：在开发提交集成测试前，要当着测试、产品和 leader 的面，做一个代码能够正常运行的的 show case；开发同学为了保证自己的代码在 show case 时跑通，会自觉做大量的环境搭建和数据准备，以及自测。

还有比如压力测试、安全保障等方向，也可以提前规划：要不要做，需要什么样的环境来做，具体包括哪些方面等。提前列好清单，安排好负责人。
03

让技术能力比较强的测试同学参与 code review
如果测试同学参与 code review，至少就能够知道这一次版本发布中提交的代码跟上一次比，主要的差异是什么，开发到底引入了哪些变化。那么，这些变化可能就是这次测试的重点。如果 code review 后发现，很多东西没有变更，那没有变动的部分，在测试时投入的精力就少一点，只做一些经典的 regression。而是把更多的精力放到 code review 发现的风险点上。
04

预设应急响应 SOP
应急响应的 SOP 需要关注的点包括：一旦发生了线上异常，谁做第一步的追查，告警要发送给谁，什么样的角色小组要做回滚，要采取什么措施进行止损等。

综上所述，围绕着测试时间不足的问题，我们要梳理好风险清单，针对每一条风险都要有一个结论。常见的结论包括：首先明确，如果某个风险发生了，对业务的影响大不大？假设影响并不大，我们希望它尽量少发生，但是真的发生了也不会有很严重的后果。第二点是指定一个责任人或者一个角色，处理风险。第三点是规划好缓解的措施，比如可以提供支持的后备人力和团队。第四点是做好监控，一旦发生我们再响应。

相信如果我们做到这些，加上前面所说的在项目中公开测试独占周期、测试方案和计划，就已经在能力范围内做到足够专业，哪怕项目上线后真的有问题发生，也不会有人对我们做太大的追责。

02
左手管理右手技术，测试团队管理者应该如何做好自我发展？
管理是一个非常长的修炼的过程，可以说它一半是艺术，一半是科学。想要成为一个很牛的管理者，需要不断学习。单纯要做好一个测试团队管理者，或者是一个技术团队的管理者，需要学习的东西已经非常多了。

一、方法论
首先是更好地管理团队的方法论，然后还有很多演练性的东西，比如说脑暴会、沙盘等。这些可以通过 MBA 或者一些技术 leader 专属的培训资源来学习，但相比学习资源，更重要的是与人交流。

二、多与人交流
如果参加过管理者修炼的课程，就会发现，老师在课上教授的教材，其实网上也找得到，更重要的跟你一起上课的人。所以如果你能跟自己周围优秀的 leader 同学，或者是跨部门、甚至跨公司的优秀 leader 多切磋交流，参加一些管理沙龙，对于管理能力的提升会非常有帮助。

管理不同于技术，掌握了一门技术，你可以在这个方向越挖越深。而对于管理，因为管理者的性格和团队情况的差异，所以需要不同的解决方案；并且没有最优解，只有适合和不适合，以及最终的效果是高还是低。

三、实践和总结
有了管理的理论和学习交流的社区，接着就是一边实践一边做 AB test。在自己的团队中，用不同的管理方法都试一试，慢慢积累效果好的管理方法变成自己的武器。换了一个部门、一个公司，之前好的管理手段还可以复用。

管理经验是可以不断正向积累的，前提是你真的把管理当做重要的事情对待。我也看到很多的测试 leader 或者是开发 leader，他们觉得管理这个事情比较 “虚”，还是 “务实” 一些把项目跟好。一年下来，可能除了自己去参加培训，不会在自己团队里做任何的管理实践。我也见过很多的 leader，觉得管理不就是打考核，不就是跟员工沟通绩效这些简单的事儿吗？这些做法还是把管理想象得太简单了。

修炼到高阶的管理者，一定是让自己的下属觉得跟着自己干是有收获的。这个收获不只是技术上和项目上的收获，也包括做人，做一个成熟的职场专业人士；员工会把管理者当做导师，能够跟着管理者学习成长。另一方面，通过管理者好的营造方法，团队氛围也更加健康，让下属觉得在这个集体非常开心。

在管理层的晋升上，也不是说只要管理做的非常好，就一定有机会向上晋升。还要看你把握关键项目的能力，还有一部分的运气。但是机遇出现前，你有没有足够多的影响力，能不能让老板放心，是需要靠你自己进行长期积累的。

如果你在自己团队内树立了良好的口碑；其他团队的同僚也觉得你在管理上做的很好，要向你学习；同时适当的把一些管理成果展现给上级，或者邀请上级来参与自己的一些管理上的举措，让上级也对自己的管理能力认可。当合适的时机出现时，你就更能把握机会更上一层楼。

来源 | Canva

以上是我的答案的前半部分，下面来说一下后半部分：到底应该多修炼技术，还是修炼管理能力？

个人认为，作为工程师出身的管理者，还是尽可能把技术修炼好。如果你既是一位非常懂测试的专家，又是一位管理者，会更有前途，否则可能只会在特定的公司发展得好。当前这个公司的老板可能非常欣赏你，但是万一局势发生变化，比如一些业务调整，你必须换部门，甚至你可能换到其他公司；在这种情况下，强管理弱技术就存在很大的风险。甚至在被迫寻找新机会时，你的技术实力可能根本无法支撑自己换工作。

如果你属于高阶的 leader，会更有可能发现技术的缺失带来的风险：因为越高级的 leader，在市场上的 “坑” 就越少。如果你没有很强的技术积累（从零到一、或者从一到十的系统化的技术积累），技术上的沟通表达不够专业，其他公司的老板可能也不放心把一个大团队交给你来带。

假设我的团队有一个 leader 的空缺，在挑选候选人时我肯定不会只看 ta 管理上的经验。我首先会看 ta 在相应的业务线，有没有一个完整的系统化的思考？ta 的测试策略是不是经得起推敲的？只有当我觉得 ta 认知的深度和广度能够撑得起这个团队的发展，我才会考虑让 ta 成为候选人。我不会单纯因为某个人在某家公司做了五年、十年的管理就直接让这个人上任，相信其他公司也是一样。

作为测试团队管理者，首先要打造自己体系化的管理思路，另一方面要积累属于自己的核心项目经验。这个经验既可以支撑你在当前公司的发展，也能为你将来寻找新机会加码。

如何积累核心项目经验呢？
你带的团队起了十个项目，每个项目你都有参与开会，做了粗略了解——这些项目都不能成为你的核心项目，因为你没有在项目发展中发挥实际作用。除非把这十个项目的 leader 都培养好，那也可以给自己的管理成果添彩。

一个核心项目，首先在公司里是受到老板关心和重视的；然后你要真的投入进去，在项目里起到主导作用。这个主导作用，不一定是画各种架构图或者写代码，或者做接口设计，而是参与从孵化到上线的每一个关键会议的技术讨论。同时在认真思考后，对现有的技术方案提出质疑和建议。不管自己的建议是否生效，至少自己是真正动脑子想过的。如果你做甩手掌柜，个人认为你不太可能在日新月异的技术行业，成为一个优秀的 leader。

但有一点要注意，你不能用自己的质疑去取代下属的决策。你可以提出一些不同的想法，但是不能因为你是 leader，就强制下属执行。而是多跟下属切磋，了解他们的想法，最终还是尊重团队的决策。通过这些思考、切磋和交流，在这个项目成功后，你跟别人聊这个项目，才能让人感觉你真的是其中的一份子。

从团队的角度来说，每个一线团队，既需要一个管理成熟的 leader 能够给大家更高的满意度，也需要 leader 在方案的把握上，能给出自己的见解，给大家一些指引。

如何帮助技术弱的 leader 更好地成长
在大公司，有的 leader 型人才，在晋升方面反而比不过一些强技术型的人才。因为技术专家的成绩说出来以后，容易得到各个部门的评委认可。而有一些 leader，ta 的专业职级还不高，但是又想晋升专业职级。Ta 能在技术上输出的东西非常浅，表现就是东一榔头西一棒——在整个项目中一下子搞搞质量，一下子搞搞度量，一下子搞搞改进，然后好像又懂一点点架构——但是什么都不深。这种情况下，ta 的晋升是非常痛苦的，而且也让人感觉 ta 不太适合作为一个优秀的 leader 来培养。

对于这样的 leader，我们会给 ta 一个核心项目，让 ta 去做更重要的主导角色。简单来说就是：缺什么补什么。如果 ta 对于架构学习不够，就让 ta 在项目里画架构图，给大家做架构的分享；如果 ta 对于质量意识不足，就让 ta 担任质量改进专项的负责人：原则是一定让 ta 自己上手实践。如果给了 ta 一定时间的实践机会，但是 ta 在某方面的意识还是不够，我觉得应该暂缓 ta 的晋升。还是可以继续给他机会，补上自己的短板。但是如果经过一定周期后，ta 还是没有进步，可能就有被替换掉的风险。

☟点击https://www.ximalaya.com/sound/529143008?source=m_jump ，收听完整音频节目