团队版本交付不断延期，我们应该如何追回进度，赶上工期的一些思考

Posted 2023-04-19

参考技术A

再三思考之下，就想谈谈近期发生的一些事情给我带来的思考，近期我们团队有一个比较大的版本需要开发，该版本影响面较大，也是配合市场销售的一个版本。但是在开发的过程中，遇到了不少的问题，最终导致该版本不断的延期，截止到deadline，团队依然没有完成该版本，导致我们进行了一些调整，对公司来说，也是带来了不小的影响。此时我就在思考，我们后续面对这种情况，应该如何做出反应，作何应对措施才能让损失降到最低或者没有损失。

"项目经理常常会遇到这样的困境：项目交付时间被定死了，但是基于现有的资源完 成项目几乎是不可能的。遇到这样的情形，我们难道就束手就擒了吗？

答案肯定是否定的， 接触互联网项目管理以来，团队经常遇到这样的困境：老板已经把项目的交付时间 确定好了。但是项目团队经过初步估算后发现，就当前 的范围、资源、质量要求而言，完全没有可能按期交付。相信这样的情形也同样困 扰着其他一些项目经理。

我们应该如何应对这种情况呢？我们该做些什么？加班、 加人？

也许这些都是方法，却都是非常规的，在我所在的团队较少将这些方式作 为项目计划的一部分，原因如下。
（1）加班。一方面，在弱矩阵项目结构的组织中，项目经理没有绝对的权力要求团
队成员进行加班，即使项目经理将加班视为解决时间紧张的方案也未必能够实施； 另一方面，团队成员的工作是一个持续的过程，一个项目结束后就会马上有另一个 项目的任务，成员在加班的状态下会消耗比平常更多的能量。这与人在跑步的时候 一样，突然加速快跑冲刺肯定消耗大量体力，但是能量总是守恒的，一般在加班过 后，团队的士气和效率都会处于较低的状态，而且这个状态会持续较长一段时间， 势必影响其在下一个项目中的表现。

（2）加人。一方面，在项目需求已经出了初稿的时候再去招人是比较困难的事情， 人员的到岗速度并没有那么快。就算不需要重新招人而是从其他团队调人，也并非 易事，因为该人员必须在技术上很适合该项目，而且有时间过来协助。另一方面， 新成员的加入，会增加不少沟通成本，理论上讲，一个原来有n人的项目，每增加一 位新员工就会增加n条沟通渠道，这势必会增加一些沟通成本。我们平常也经常说1 个人两天完成的工作量往往大于两个人一天完成的工作量。所以这种方式也不作为 我们处理时间紧张问题的常规方式。

那么我们后续该如何解决这个问题呢？我想我们可以考虑下面一些选择。

一般项目都有关键约束因素和浮动约束因素。关键因素是决定项目是否成功的因 素；浮动因素是指可以调整的重要影响因素。在时间作为关键约束因素的项目中， 范围就成了可浮动的一部分。我们会重新回顾需求文档，根据需求的优先级，重新 划定本里程碑的范围，将一些锦上添花的功能先拿掉，剩下主体功能。在互联网的 项目中，产品经理或者策划在定需求的时候可能只是按照他们的期望定了范围，他 们总是希望在最近的里程碑将所有需求开发完，往往有一些需求并没有那么迫切， 对用户来讲可能也无关紧要，不需要非得在本里程碑完成，完全可以将这些低优先级的需求放到下一个里程碑完成，或者本里程碑可以完成这些需求的简单实现，在 下个里程碑进行完善。

在顺序开发的项目中，若时间不够充裕的话，往往测试的时间就会被压缩，最后导 致测试不充分，产品的质量不过关，测试期Bug“绵延不断”，交付后仍可能出现严 重的Bug。为了避免这种现象的产生，时间比较长（3个月及以上）的项目，我们会 采取分批提交的方式，将需求分2~3次提交，让测试同事提早介入。在第一批功能开发 完成时测试同事就可以开始测试，开发人员此时就能开发接下来的功能。这样就能减 少测试同事在开发阶段等待的时间以及开发在测试同事测试过程中的等待时间，提高了 团队的效率，缩短了整个里程碑发布需要的时间。如果有可能的话我们甚至可以按 功能提交，每完成一个功能测试同事就开始测试。不过该方式下，很多时候开发可能 身兼多重任务，修复第一批功能Bug的时候同时开发第二个功能，此时就需要项目经 理细粒度地跟进情况，及时发现问题，将开发任务和修复Bug的优先级定义明确。

关键路径即该项目中所需时间最长的一条路径。项目之初，理出关键路径，将关键 路径外的功能交由一些相对不稳定或者时间不固定资源（实习生、外部人员）去协 助完成。这些功能就算不能按时完成，整个项目的提交也不会受到太大影响。这样，更多的资源就能被分配到关键路径上，集中力量解决问题。

项目之初，若是时间不充裕，在定交付标准的时候可以适当降低Bug修复的标准。一 些修复代价较大且影响较小的Bug可以暂时不修。等到项目进入测试阶段，根据当前的情况，我们会重新评估之前的标准，看是否需要重新调整。关于Bug的优先级重要 性，测试同事在报告Bug的时候会有一个初步的判断，经过团队分类后会最终确定下 来。那些被“剩下来”的Bug，可以在里程碑结束之后修复，但是这都不会影响到关 键功能的使用。

以上方法，均需根据项目组的实际情况剪裁使用，“让你的团队赶上工期”。没有 最完美，只有最适合。"

学习进度条--第三周

	第三周
所花时间（包括上课时间）	10小时（包括上课2小时）
代码量（行）	123行
博客量（篇）	2篇
了解到的知识点	利用虚函数来来实现多态；代码需要不断地测试以保持正确性和必然性。 利用for循环及if判断语句时应该思路清晰，弄清楚先后顺序，及条件关的相关联系； 阅读《构建之法》团队合作，使用功能团队模式更加适合交流，现在我们需要加强合作； 团队的开发模式不同效率也有所不同。