核心人物是另一个要讨论的杂项，一个组的核心人物像操作系统的内核，完成大部分核心工作。这里当然不是指leader，尽管一个负责的leader应该完成一个小组70%的工作。这里所说的核心人物，可是说算作组内的中流砥柱，他并不一定负责组内事物的管理，但是所在小组中的核心工作任务他为熟悉和上手，是常说的“大拿”，业务和工作上，一个组必须要有这么一个人。对于这样的人，他的工作执行权力需要适当放大，但是工作量需要适当调整。怎么去合理的安排“大拿”的工作，对一个小组的工作成果影响很大。但是并不意味着不需要其他人，用少的人在短的时间内尽可能的多完成工作，并且不会身心疲惫，这并不是不可能，需要将两个关键点把握好，其中之一是物尽其用，协同工作中把每个人放置在合适的位置上，这里的合适不光指专长，还包括工作状态和心情，当然是相对而言；还有一个关键点，是领导的调度能力。操作系统有各种的调度算法，目的在于有效的使用计算机资源。领导需要了解自己组内的各种资源，并进行合理的调度，如果一个小组的所有员工都满足招聘时的JD要求，那么这个组如果无法很好的完成工作，95%的问题是出现在这个负责调度的领导身上。资源不在多少，在于怎么调度来达到优，好的程序员即使1M的内存也可以写出好的程序，即使如此预算也不可能像硬件发展一样可以用来挥霍。中国的社会压力很大，大把大把的程序员和测试人员，而且测试人员的收入也少的可怜，所以至少在我看来，所谓的人头预算在测试组应该不是多大的问题。

　　时间问题是后一个要讨论的杂项，其实国内大部分领导在这上面投入是多的。外界的约束中，时间和预算是大的两个，很多人不得不面临各方面的压力——时间太紧，即使不断加班也解决不了困境；预算不够，连基本的团建费用都没有，哪怕是一个冰棍；外行老大瞎指挥，看不懂代码却来指指点点。首先，先要解决这个问题，第二是在现实已定的情况下，怎么去制定计划。

　　解决这个问题，一般是沟通。沟通能解决这个问题是有原因的，资源（时间、预算和人头）是申请的，如果你的老大是内行而且是高手，那么只要不是刁难，他能够批复的资源，是在合理的范围内（IT这行业刁难的事情相对很少了）；如果你的老大是外行或者像某些国企的草包，又或者是某政府部门的烧钱高手，那么按IT行业的标准去申请资源，不能说九牛一毛，但不是困难；如果你的老大是外行却不舍得花钱，那么这也不是问题，这样的人胆小贪心，但是不傻，他很清楚的知道如果项目搞不定，损失大的是他自己，所以只需要把可能存在的问题和风险预估出来，并给出对结果的影响程度，批复资源的时候他自然会考虑到这些。这里有一种情况没有讨论到，是项目重要性的问题，项目如果是块肥肉，资源申请起来相对容易，如果是一个不知道几手的项目，或者临近被抛弃的项目，所谓的沟通可能解决的问题不大，如果找不到一个让老大们重视起来的理由，资源的申请有了上限，这时候能做的是像很多创业公司团队一样组内奋斗做出彩头来。

　　现在有很多管理类软件和系统，甚至一些移动端的app也开始支持事务的管理和计划，能够按照用户的输入进行提醒并给出任务完成情况的进度表示，一些漂亮的图表当然也是吸引用户的噱头，这些都属于项目管理的范畴，本质上没有差多少。但是事实上这些工具的效用并不大，某种程度上算作闹铃和备忘，对于管理来说是纸上谈兵，很多领导算看了一堆数据也搞不懂数字后面的含义，又怎么能给出可行性的决策呢？

　　我习惯上将项目进度管理分成两大类，像操作系统中有硬时钟和软时钟一样。时间相对固定长久不变的，需要严格按照安排去进行，以保证目标的定期完成，这种情况下buffer的制定和合理使用是关键所在，因为通常这类情况属于流程严格、协同作业相对规范的，保证了流程的稳定是关键的，有时候也习惯的将这种情况比喻成做“京官”，做好治安可以了，只要不出大事，能升官，大多数外企和小资员工都处于这种管理之中；另外还有一种，是不断的变化，甚至连目标都是三天两头的变化，这种变数太多的情况下，所谓的计划和管理挑战性同样也大，他们关注在不同的地方，需要在短期内达到优（贪心原则？），拿到成果，计划对于实际工作反而是后置的，你永远都看不到文档的随时更新，休假之后回来感觉自己已经脱离了组织，大部分创业公司属于这一类。一些原则的制定，可以帮助尽快投入决策，当然讨论的范畴是人为可控的，一些不可预期的天灾人祸的影响不包含在内；一些诸如各种请假，各种管理矛盾甚至在某衙门盖章这类事情对进度的影响，暂时也不包含在内——很多公司有专门的部门处理这些事情，至于部门如何划分每个公司不同，有些有专门打官司的，有些有专门洗脑的，有些有专门公关的等等。

　　我提的第一个原则，是深入项目原则，一个领导不深入了解自己所带的项目，他所带的团队不会。即使我提到的两大类公司招聘员工时要求侧重点不同，但是深入项目，哪类都需要，哪怕是空降的领导，也需要尽早的深入到项目中——当然空降对团队工作是极其敏感的，不必要时很少采用这种方式，一个连编译语言和脚本语言都无法分清的领导，去带领一个纯C或者C++的底层项目，我觉得这不是赶鸭子上架的问题，是上宇宙的问题；第二个原则是折中，曾经有一个鱼和熊掌的问题的讨论在IT界很流行，其实折中的问题在这个行业比比皆是，当然这里依然用操作系统举例子，不管是调度作业算法还是内存管理，终广为采用的大都是折中的方法，或者带有权值的进行；折中是优化的一种手段，有时候折中为了大化盈利，有时候为了小化损失，所以领导进行折中的前提是明确的知道项目的状态和各种方法的优劣；第三个原则是资源的高利用率，也是说，在安排进度的时候，让任务尽可能平均等待在员工手中，而不是让员工在等待分配任务，或者任务分配不均导致出现了问题却找不到原因，当员工知道什么时候主动认领适合自己的任务并给出正确的预估时间时，资源的利用率达到优。

　　到这里，基本上测试管理和自动化测试当中一些可以从操作系统中得到借鉴的主要部分已经讨论的差不多了，严格来说这种讨论是没有开始也没有结束的，甚至过程都不连贯。随着计算机行业的发展，测试的管理和实施也逐渐成为一门学问甚至学科，然而这个领域中大部分结论来源于归纳和总结，并非讲讲故事可以入行的。让人欣慰的是，这个行业发展到，本根性的东西却没有太多变化，无论测试管理和自动化测试，总会不断的从一些基本的原则中找到可以提升的地方。