这次培训，由于时间问题，很多问题都没有深入探讨，导致我对某些问题理解不深，可能对问题理解有所偏差，首先我这篇文章主要从以下几个方面来论述的感受。
用木桶效应论述系统思考
原理：
我们知道，一个木桶盛水量是与他最短的相等的，对比做项目，质量与进度就是一个相对矛盾问题，你不能一味的追求进度放弃质量，也不能一味最求质量放弃进度，最后结果就是有进度与质量构成的“水桶”，你的产品的水平高不高，就看你这做木桶用的木头最短的高度够不够。
危害与事例：
在实际做项目中，我们往往做事的时候找不到这样的系统思维，远期效应和近期效应相冲突的时候，往往只注重近期效应而忘记远期效应，比如测试，大家都说忙，忙了半天也看不到代码质量的提高，bug量一直居高不下，以前的老bug在经过几轮迭代后又出现，感觉老在失控状态，但是大量的人力投入后，也不见好转，投入的资源也不见成效，大伙都有感受这种测试的问题，但是谁也没有说大伙停一下，我们来检查下出了什么问题，为了照顾进度一味增加人力，但是新人进来也会增加培训的工作量，又不能马上进入项目，还有人一多，又会出现沟通管理，绩效管理，进度管理等一些管理计划，方式的变更，最后增加的人力消失在这无尽的漩涡里。最后项目项目就进入一个奇怪的圈子，增加资源不见起效，再增加资源，还不见起效。最后项目组集体来做测试吧。
分析事例：
为什么会出现这样的问题？那当然是系统思维的欠缺！具体分析如下：
一.首先远期利益无法与近期利益相结合的系统思考
大伙不顾现在存在问题，一直追求短期利益，盲目测试，没有长效的测试计划，及方法，这种不能兼顾长远期利益做法结果就是，测试们一直很累做测试，但是项目质量也不会有好转。
二.增加人力与之带来的成本的系统思考
世界上最复杂的东西不是电脑，不是飞机，而是人，没有什么东西比人更难琢磨，没什么比人的七情六欲更复杂的了，项目里在增加人力后，其实人的管理问题就摆上桌面。在项目中。特别是软件这类的项目，不像生产线，可以批量重复动作（比如我以前待过的仁宝电脑厂，每个员工就像机器人，完成同样的动作就行），软件项目是脑力密集型的，很难有重复劳动，(如果有厉害的程序员都会把他自动化掉)这样就意味着项目中的每个人都很难被替代，也就意味了不是每个人进项目组就能马上上线工作的，新人加入项目后，会经过相当一段的培训期，在这期间我们将会发现新员工的优缺点，来安排相应合适的岗位。那这期间的成本，又会拖累老员工的进度，怎么合理的增加人力安排培训，我们没有这样的培训计划，也没有这样系统思维，只是口头上的口号，这是不起作用的，套用老师的话，不接地气，以前我们新员工到岗，都会有一份员工培训计划，比如去年李国强经理给我做的员工培训计划（现在还在我文件夹里），可惜这个优秀的传统并没有坚持下来。
三．短期的人力资源短缺与人员职责划分的系统思考
我们项目老有个奇怪的现象，开发人员即是开发人员，也是测试人员，测试人员测试中，老是无故被开发中断，因为开发在测试中发现了bug情不自禁给改了，又上传到服务器。造成测试环境中断，最后测试也不是测试人员而是系统环境管理员，开发成了测试人员，又成了开发人员，虽然人手不够是现实问题，老搞得开发不像开发，测试不像测试，大家职权不清，测试过程乱的一锅粥。也不是办法（现在大家也意识到这个问题了），短期我们看来是人力少（到底是不是人力问题上面也论述了，这里是单讲这个问题），但是我们项目似乎又把这个搞成一个传统习惯的趋势，每次遇到问题，老是一伙人全部按上去，除了测试工作其他都不做了。这样测试做好，开发也做不好。
自己对问题的几点思考和想法
我们已经知道这些问题的根源是系统思考，那么知道了“道”，但是光有“道”没有“术”是不接地气的。我想到的“术”。
如果是我该如何？
1.多问自己为什么会出现这样的问题
很多事情，在你没有明白其原理时，上去做都会有问题，出了问题不可怕，可怕是不去思考，最后搞死自己。
2.当出现问题，我准备采取措施时候，想想我的措施会不会造成其他管理的变更？变更结果是好是坏，对其影响。
最典型的例子就是，比如我遇到测试人力不够的问题时,要思考的是
1. 测试组人不够，开发组肯定加过去。
2. 开发组人加过去怎么管理？肯定不能让开发那伙人占了主导，让他们随便乱改，得让测试组的人领导。
3. 这次就这么过了，如果下次还这样搞，那么我开发人员都得停下手中的工作去搞测试，会影响项目进度。
4. 怎么让测试人力充足，在考虑成本情况下，能不能用技术的手段节省人力，比如回归测试怎么自动化。
5. 如果技术手段还不够怎么增加人力，招聘需要什么样技能的？
6. 新员工进来后，怎么培训使之尽快上岗？
7. 试用期后新员工是否符合我的需求？
8. 怎么将新的人力加入项目组合适的位置？
