《想让下属成长，付出 80% 的努力就好》
A 和 B 管理的小组
公司事业部某个小组，20 余人，划分为 2 个小组，每组 10 人。小组分别由 A 和 B 两个人管理。
两个组的成员负责的工作比较传统，不涉及代码等计算机相关的知识，根据测试用例进行执行即可。业务内和自动化相关的内容由 C 负责。
小组成员的日常工作
A 组成立较早，负责人比较传统，每天接活、派活，最终对任务进行验收和整理。A 组内员工每天完成 100% 的工作量——即 9 点上班开始测试用例，到下午 6 点下班前基本可以完成。
B 入职后，每天只给员工安排的 80% 任务，员工在下班前基本有 1 个多小时的空闲期，可以玩手机，可以去吃下午茶，如果下班前有没有完成的任务，B 也会安排到第二天。
A、B 与 C 的困境
A 和 B 日常非常忙碌，分配任务、检查任务、对测试出来的问题进行分类，和上级与其他部门的研发对接。同时负责自动化技术相关的 C 随着业务压力陡增，也出现应接不暇的情况。
B 的管理思路
入职不久后 B 熟悉了部门的业务情况，首先把 C 的工作包进行了拆解，安排 C 将自动化业务中比较简单和常见的业务进行下放，通过培训让 B 组成员掌握了自动化执行、常见自动化测试问题解决等技能。
B 组的同学常年负责手工测试，加上 B 有意控制手工测试的工作量，大家对于能够接触到自动化测试相关的培训也是欣然接受。于是在日常的能力培训与实践中，B 组的成员逐渐在工作中为 C 分担了相当大一部分的工作。
A 组的员工因为工作量一直都是 100%，在比较忙碌的情况下需要完成 120% 的工作，能够准点下班就喜上眉梢了。在面对开展的如火如荼的自动化培训方面选择了草草了事，简单的学习了一些就不再关注。
对工作量的拆解
B 依然每天只分配 80% 的工作，组内员工每天承接的手工测试用例并未改变，而培训后的组员掌握了一些常见和简单的自动化工作，开始承接一些不定时的自动化工作，实际工作量达到了 100%。而 C 得以从琐碎的工作中解放，拥有更多时间开发更加高效的自动化测试工具，让 B 组的员工工作效率更高，闲暇之余彼此还会讨论工作精进的事宜，同等工时下人效逐渐超过了 A 组。
依葫芦画瓢
在 B 组员工逐渐掌握了不少自动化测试后，B 如法炮制，将项目中比较琐碎的内容进行工作包的拆解，例如测试报告的整理、测试问题的回顾、测试任务的下发逐渐交由组内的成员负责，而 B 拥有了更多的时间和精力去关注项目中需要深入挖掘的风险，持续完善组内的项目、和其他部门的同事对接。
双赢与双输
B 组的员工逐渐从单纯的手工测试过渡到了掌握自动化测试技能、对测试问题可以进行独立评估的的工程师，颇为战斗力超强的队伍风范。同时 B 也得以受益，集中精力对测试项目进行全盘把控，无需事事亲力亲为，同期可以承接更多的测试项目。而 A 组员工却始终淹没在无穷无尽的工作汪洋中无暇分身，难以成长。A 最终在业务线变得繁杂后无法承受庞大的项目压力而亡。
结语
在现代化管理企业中，似乎人人都在追求超饱和的工作量，领导们总是告诉下属要付出 120% 的努力，而这显然是违背人性的。从企业的长期发展来看，组织的健壮性取决于日常工作的目标。如同考试一样，总是要求学生考到满分，或者比满分还要更高，几乎是没有几个人可以达到的。而要求学生考到 80 分就好，而结果往往会超出预期。阶段性的胜利带来的成就感会为员工的长期发展打下良好的基础。
想让下属成长，付出 80% 的努力就好
1、那 A 组每天要比 B 组多做 20%，同等工期下是不是比 B 组要先完成项目测试，是不是节约了工期？
2、后面 B 组做简单的自动化工作，是否能赶上 A 组每天多做的 20% 的工作量，超过 A 组的工作，并节约了工期？
A:你清高,就干 80%
有点理想化了吧，而且过于高看了自动化测试的作用
事实上 实践中会发现自动化一般并不会节约成本,反而会因为脚本的频繁维护而增加成本.
对 A 和 B 两个个体来说也是一样的道理，说明了划水摸鱼学习的重要性
实际情况是：
领导：B 组工作不饱和，A 组超饱和，把 B 组 1/5 的人调给 A 组，A 组辛苦了，这个月集体评 A。
我算是见识了啥叫纸上谈兵
自动化是可以用于完成重复的、可标准化的工作，但是并不会减少工作量，反而会增加......
《提升下属主动性，使用模板化思维追踪问题》
除了将自动化测试工具的基本运维工作拆解后指派给下属，还需要自己负责的测试业务内容进行拆解，从而从庞大的问题海洋中脱身。
自己干
在对业务内容进行拆分之前，工作内容非常的庞大和复杂，其中对于测试问题进展的追踪是最耗费精力的。基本的流程主要包括遍历问题，询问研发问题根因，与研发核对修复进展，和测试沟通复测计划，最后确保问题闭环。当负责的业务线数量非常庞大之后，光是遍历测试问题就会花掉非常多的时间，容易陷入碌碌无为的怪圈。
让下属干
之前尝试过让测试同学负责追踪自己问题的进展，但是下属汇报的风格和质量参差不齐，不得不花时间针对汇报进行查漏补缺，结果花费的时间还比自己做的更多，后来不得不收回下放的业务。
制定问题追踪的模板
有了之前混乱的经验教训，将问题追踪的内容定义为一张卡片，对格式做了统一规范，再次下方问题追踪的业务时，明确要求汇报时需要以卡片的形式提交。
在主动沟通中成长
汇报问题有了固定的模板，就意味着填写的过程中需要和研发人员进行对接。例如表格中的 “问题跟因”、“下一步进展” 往往需要研发输出。在这个过程中不仅让测试人员加强了和研发的沟通交流，还推进了问题的进展，也让测试同学了解到了更多业务中的技术细节。
汇报的卡片更新时间可以交由自动化提醒完成，每次更新卡片都会让系统更新最新的时间戳。如果系统检测到 7 天内未闭环的任务没有更新进展，会自动发出提醒，要求测试同学及时更新进展。
问题日志
源源不断的卡片最终形成了测试项目管理中的问题日志，采用看板的分类形式，有利于测试项目经理迅速明确当前项目的风险。
如果将卡片的状态置为已修复，那么看板上也会有自动更新对应的状态。同时也可以直接用鼠标将卡片从 “未解决” 的区域拖动到已解决。
形成良性循环
原先庞大的测试问题，经过了一轮过滤和筛选后，问题就会比较明确和清晰。一开始下属在上交问题卡片时难免会出现填写有误或者理解有误的情况，所以在遍历问题卡片时，也是一个很好的培训成长下属的机会，灌输自己对业务的标准和理解，从而让团队内部对问题的认识理念达成一致。
结语
模板化思维特别适合基层的管理者，而且可以根据业务程度的不同，选择性的将业务问题的追踪下放给测试人员。
如果两组都是干一样的活，我很想知道凭什么 B 组可以每天只干 80% 的活，剩下 20% 活给谁干了？
每天都累积 20% 的活不干，那只能是项目的测试周期一直延长，这样领导会让你这样干下去？
另外，让技术水平参差不齐的功能测试人员接手自动化测试是个很愚蠢的决定，因为到现在我还真没有看到一个真的零门槛上手的 UI 自动化测试平台或者框架，除非公司的业务都是百度搜索那一级别的。
B 的 20% 哪去了？
B 的人你说让他学他就能学？
真学了的人你留得住？
加上自动化，其实总的任务量会大于 100%，因为维护是大头
感觉人的因素在这里面影响太大了，B 组在现实中不一定会接受这样的分配，真的就是看人！
哈哈，我是来评论的。诚然，作为管理，我自己是期待 B 的 20% 可以带来至少 40% 的收益，或者大家常说的提效。
我最近也做了类似 B 的事情，出于让外包同学多方面成长的初衷，我让外包同学尝试去做一做自动化，还做了好一些专门的辅导工作，最后结果是……
- 为什么自动化要我做，而不是别人做？为什么别人能更早下班，我就要呆在这搞自动化？
- 本周自动化进度还是 0，原因是业务测试任务太重了搞不过来……
- 同一个问题，说了三四遍还是搞不懂，只会死记硬背，不会理解问题……
- 稍稍变式不一样的问题就没能力独立解决，即使他手头有着联通世界的互联网搜索工具……
- 个人工作和生活分得比较开，下班之后就不再想碰工作了，所以上班的时候尽量多学一些（然后下班很早【摊手】，又不愿意比别人付出额外多的时间）
只能说，成长真的是个人的问题，作为外人不要想着自己能去改变什么，也没义务去帮任何人成长。尤其是每个人的 “个人强度” 还不一样，有些人很脆弱无法逼迫自己往前多走一步，但有些人却能越战越勇。并不是让大家去学，给大家空间学，大家就真的能成长起来，这一套理论在人的惰性前是完全无法经受考验的。
当然，除非你是他们的管理者，对他们的成长有一定责任，否则还是不要浪费时间（+ 浪费感情）了……