壬寅年 己酉月 己卯日 秋高气爽 天气转凉 昨天大风
昨天看到项目计划中已经有了很多内容。
也就是说计划感觉已经写的差不多了。我仔细看了一下之后觉得这个计划不可行，就是样子挺像。
然后我问管理组，这个是你们商量之后写的吗？他们说不是。原来是另一个学员觉得管理组的动作太慢了，就越俎代庖了。
这其实源于之前我说的：所有人都可以参与所有事。也怪我没有说清楚，我是想表达的是，如果有兴趣，你可以参与所有的事情，但是当你不能做现在别人正在做的并且会有冲突的事情，你可以跟他建议，但是不能直接上手。因为如果大家都直接上手去改别人在做的文档，那就乱了套了。
晚上10点多，临时拉了一个会，讨论了一下，聊到11点多。其实这样的沟通是很必要的，就是要统一认识。根据我的经验，性能项目的管理部分做的都是非常非常潦草的，基本上不怎么管，全靠事情往前推。
很多项目中性能计划或者方案也都是只走走形式，并没有认真去思考计划的价值和具体的使用方法。
我跟他们说这个计划执行不下去的几个点：
1. 不应该把任务分一个个具体的人，而应该分给一个组。由组长或组员去分配时间。因为我们不是一个强制性的组织管理，有些人没有时间也是经常的事情，如果把事情给了具体人，但这个人又临时没有时间导致任务延迟了，其他人主动承担任务做下去的可能性也不大。这就失控了。而分给一个组的话，那这个组的所有人都要看着自己组的任务有没有完成，毕竟有负责的组员会主动推进。就算是没有人主动，作为管理者也要考虑后招。
2. 任务分配不合理。像下图这种，这里面的的子任务时间是昨天被我删掉了。这个方案总时间是写7天。7天！一个方案？！这得多拖拉的人呀。
看这一个方案的不同部分分给不同的人写，这也是不合理的。 因为方案的不同部分是有逻辑关系的，不同的人不可能写的思路一致。
还有这种任务分配。
这也是不合理的，因为数据在不同的脚本中可能是相同的，也有些是需要关联的，这里每个脚本都让不同的人来做，那不是重复的工作量很大吗？并且这个时间也不合理，4天的时间准备数据，那是不是说这些数据以后就可以一直用，不用再重新准备了呢？这也不现实，因为通常我们都是在执行的过程中还要再准备数据的。
3. 任务串并行关系有问题。像这种。
分析阶段和执行阶段一定是并行的，通常我们都是遇到问题就要分析解决问题，而不是和场景执行串行。
另外，分析的时候也做不到各个技术组件独立分析，而是要综合关联分析，所以这个任务逻辑就有问题了。
其实管理组的组长也写了个计划，发给我看了，在任务细分上倒是没有太多的区别，不过是多了产出物和风险的部分。如下：
对于产出物的部分，首先，那一列都不像是产出物，而是动作，所以不合理。其次，也没必要专门写一个word版本的文档，直接放到计划里加一列就行了。
对于风险的部分，列了两条，确实都是风险点，但还不够。比如说：技术不足、管理不力、环境问题产生阻塞、串行任务冲突导致时间不可控等等。
这里不仅要列风险，还要列责任人和应对策略。不然就是光知道有问题，但不知道怎么解决，那就是管理者的失职了。
面对以上的问题就是要做的事情是：修正计划。
今天的日记先写到这里。
有兴趣了解我们的线上培训的，可以看下我们的招生简章和大纲。
7DGroup性能工程高级班招生简章-第二期
标签：事情,不合理,7DGroup,性能,任务,计划,时间,日记 From： https://blog.51cto.com/u_15181572/6172664