团队管理之性能实施团队日志6-Toy模板网

这篇具有很好参考价值的文章主要介绍了团队管理之性能实施团队日志6。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、从问题统计看进度风险

从统计来看，近三个星期过去了，发现了 59 个问题。28 个是性能问题还需要再细分类型，现在这个还是粗了点，比如说配置问题、代码问题。
所以笼统说来除了这里的功能问题之外，其他的基本上都是性能问题，也就是59-11=48个。
团队管理之性能实施团队日志6
从实际工作的感觉上来说，因为是 9 个系统并行的性能实施，也就是说一个系统平均 6 个性能问题。

我再一次统计了系统角度。

显然系统五、六、七、八、九的统计是有问题的，应该是有些问题没有报上来。
考虑了这几个系统，一是因为有一同事负责了其中两个系统，并且还带了一个非常初级的新人，事情经常被打断；二是新人负责的系统根本不知道什么样的问题该报；三是系统九并不在我们团队测试的范围里，现在报出来的问题是其他系统的相关分析中看出来的。
下个星期要多关注这几个系统的具体情况。
其实做管理的分析报表是能看出不少问题的，而从报表中看出来的问题，就需要再细追一层，看是什么具体的原因，再想办法解决。
下周可能要加强这几个系统的技术支持，或许要进行人员调整。

二、项目计划的调整

上一周发现的问题，杂七杂八地分析了一下之后，对整体的项目状态有了了解。就像大部分的项目一样，现在这个项目也是处在混乱的问题爆发期。
从管理流程上看，项目整体计划、团队间协调、配置管理、版本管理、人员调配、风险控制等方面都是存在不同程度的问题的。
上周我也找了客户方高层沟通了一下，他们也是意识到了这些问题，只是百废待兴。
项目是新的不说，各方人员也是新的，所以这些问题出现在各方磨合、项目推进的过程中在主观上是合理的。
上周我也把几个系统的计划后移了几天。
团队管理之性能实施团队日志6

不仅移了单个系统的，也把全链路端到端的性能实施计划后移了。
估计周一会引来一些讨论。
对我来说，没什么可讨论的，如果有问题阻碍了我的实施计划，我就会强制性地往后移。因为之前这个计划已经正式的announce了，并且没有人提出非议。
周五的时候，我跟一个系统的负责人说了问题之后，说会把计划往后移，他觉得是可以压缩性能实施的时间的，所以整体计划不用移。
这样的讨论在我十多年的工作经历中出现了很多次。性能实施也就是在这样的讨论中慢慢地被压缩，直到压缩至体现不出价值走个形式的结局。
如果这个性能实施同样被其他团队的问题或者管理的问题压缩了，那和我之前做的那些失败的项目又有什么区别呢，登时就没了做下去的兴趣，无非是又一个失败的项目。
在我的经历中，有一些项目是我做地觉得非常成功的，计划和进度都在预期之内。
严格地把控项目进度，并不是严格地把握项目计划。计划可以变更，但是具体的工作任务时长被压缩是只能以牺牲质量为代价的。
所以项目管理并不是，给你几个人，给你安排一个目标。就拼死拼活地做出来。在项目中，我看多了这样的不讲理的安排。

三、商务合同带来的实施风险

跟项目组的人员讨论了合同的内容，算了一下，八系统88人天，每个系统的性能实施只有11人天。这合同签得也是没谁了。留下了走过场的隐患。
我见到过不少性能实施的项目是这样安排的，如果不是整个团队都技术超高的，那肯定是项目已经是熟得不能再熟的了。不然这样的合同就是完全的不理智。
而对眼下这个项目中出现这么多问题，是不可能的事情，所以计划的后移也是必然的。

无论如何，项目还是要做下去，项目管理要做的就是把资源、进度、风险都put on table。
我不想自己做过的项目，在上线运维中出现本来应该发现的性能问题，对各方的代价都很大。对自己做的工作也会非常不认可，这种打击会导致对自己和行业的失望。
做过运维也做过性能实施的人都应该有这样的感触。当我们在线发现一个性能问题的时候会抱怨，这么明显的问题性能测试都发现不了吗？要他们干嘛？
而只做性能实施的人，如果不能贯穿前后的思考，也必然会落下这样的把柄。

希望所有做性能实施的人都能让自己的工作体现出该有的价值。

相关系列：文章来源地址https://www.toymoban.com/news/detail-476496.html