如何有效地控制项目进度

Posted 2022-12-03 ycyk_168

      软件开发的项目周期大体分为3个阶段：获取需求和定义产品、开发和测试、部署和运维。

     在获取需求和定义产品阶段，需要防止的不是进度太慢而是过快、过草率。特别是对于创业公司的产品经理来说，很可能因为看到开发人员无事可做而感到压力，所以尽快完成产品定义，而没有充分了解市场和竞争对手信息，没有与合作伙伴充分沟通，没有做深入的思考。这些因仓促而隐藏的问题，发现得早则导致开发阶段大量返工，发现得晚则导致产品上线后不受欢迎。常听一些人说现在互联网开发，讲究快速迭代和敏捷，边做边想，返工也正常。这是一个误解。快速迭代指的是将不同版本之间的周期缩短，小步快跑，而不是在一个版本的周期内来回折腾。

     在开发和测试阶段，项目管理重在跟踪进度和保持沟通—用集成和演示跟踪进度，基于Bug沟通问题。要做到各个模块外部接口相对清晰稳定，并尽早完成各个模块间的集成，最晚不超过开发周期的1/4时间。第一次集成之后，就应该开始每日集成和每周演示。每日集成使得测试团队每天能同步测试最新的代码，帮助开发团队尽早发现问题并及时了解技术细节上的进度；每周演示使产品经理、项目经理和管理层能从用户的角度感受产品，使他们对产品有信心。集成和演示是项目管理的心跳，合理利用它们，有助于及时把握项目的健康程度。无论开发流程多敏捷，工程师能力多强，记录和跟踪Bug都是必不可少的。开发团队和测试团队的沟通都应该基于Bug，才能言之有物。开发工程师每次提交代码都应该记录是针对哪个Bug的，每日工作简报都应该写今天关/开了哪些Bug。要在每日晨会（站着开，一般15分钟内）时说好，今天打算解决哪些Bug，其中有哪些点不清楚，需要和谁沟通。

       在后期部署和维护阶段，要快速响应。考验的是团队成员的责任心和抗压能力。系统运维工程师要深夜工作，因为部署可能要在流量低的时候进行；项目经理要保持能随时沟通，做出快速而准确的决定，鼓励团队并做出表率；一旦出现高危害Bug，开发团队要在24小时内准备好补丁。Amazon的做法比较有趣：在产品刚上线一段时间内，开发工程师要保持24小时开机。如果自己负责的模块中出现高危害Bug，那么很可能会在深夜被系统运维工程师叫醒。这样不仅能保证快速响应，还能让工程师意识到：前期代码不好好写，后期就别指望能好好睡觉了。

每个项目经理都希望能有效地控制项目进度。但这件看似简单的事情，实际操作起来却常常不尽如人意。即使在成熟的大公司里，有着完善的项目管理流程，配备着一流的团队，项目延期事件还是频频发生。这里分析主要的三个原因。

常见的原因之计划不清

很多项目经理，项目完成得很好，计划也做得很漂亮，却总是计划赶不上变化。原因在于，有些时候，按工作量预估的发布日期却得不到领导的同意，领导有时会说我们现在就是和时间赛跑，这个项目必须在某某时间发布。这将致使计划推倒重来，一切都要赶进度。而对于其他团队成员来说，这份计划没有同他们商量，无异于强压任务。项目还没开始，抱怨声就不绝于耳。因此，项目工具选得好、任务划分细致清楚只是做好技术的基础，更重要的是项目计划要得领导和团队成员的认同，并愿意为之全力以赴。总之，想做好项目计划，要做好以下三点。项目计划前，先和产品经理、上级领导沟通好，确定这个项目的轻重缓急。团队成员要达成一致意见，项目经理不可独断专行。项目计划要细化到天、功能点要责任到人、确定里程碑点。

常见的原因之需求问题

需求中的功能点要在PRD（产品需求文档）中罗列清楚，业务流程要写得完整清晰，交互细节要体现在视觉稿中。要组织项目组所有成员参加PRD评审，评审时要针对具体的问题，给出明确的处理意见。暂时不能确认的问题，问题跟进人要在限定时间内给出反馈，项目经理可以制定问题跟进表格。项目进行中的需求变更，尽量在前期提出。在项目管理的过程中，当前期的需求和计划都确
定后，项目经理不能只顾着跟进开发和测试的进度，也要阶段性地和需求方多沟通，让他们及时反馈意见。不要等到临发布时，产品经理跑过来说“我要的不是这样的，这里要改一下”。永远不要把问题留到最后一分钟，要超前一步，留有余地。下面是一个真实的案例。案例情景：该项目的整个周期为2个月，有3轮功能测试。当第3轮功能测试结束时，也就是即将进入预发布阶段时，产品经理才给出用户反馈并要求按用户的反馈修改。改动的地方涉及到页面的样式、文案、SQL语句和校验逻辑等，总共可能有20多个文件要被改动。项目经理建议只改页面的样式和文案，其他部
分先不要改，等下次升级维护时再改，否则可能会影响发布。而在多次交涉无果的情况下，开发人员只能硬着头皮修改，测试人员只能再重新测一轮。虽然大家努力地按需求方的要求做了，但项目延期已不可避免了。

常见的原因之沟通不畅

为某项目临时组建的团队往往来自不同部门，团队成员之间不熟悉，此时，要为团队建立一个沟通通道，确保沟通顺畅。常用方式为：建立一个内部网络空间，所有文档资源统一存放，供团队成员共享；利用即时聊天工具，建立一个项目群，每天通报项目进度；建立项目邮件组，所有变更达成一致后，发送邮件确认；每天要开15分钟晨会，每周一次周会，每周发送项目周报；跨团队项目，最好申请独立的项目室，所有项目组成员坐在一起工作，降低沟通成本。

重视细节

项目管理的目的是能够按照预定的成本、进度和质量要求顺利地对人员、产品、过程和项目进行分析和管理。在项目管理中，有些细节需要引起项目经理的重视。

根据经验规划

即先做少量的规划，再根据实践过程中得到的信息来做进一步的规划，这样可提高项目的可行性。试图预测未来的规划很难奏效，除非你是个预言家，否则应该尽量在项目中根据经验做规划和日程安排。

安排项目日程

首先，要按可交付物安排日程，而不是按功能；其次，要以迭代的方式安排日程；再次，要使用难度较低的工具安排项目日程。过度追求完美的项目时间表可能意味着在实际项目中浪费更多的时间。

足够的时间规划

日程安排是由整个项目团队共同制定的，因此，每个人都要对日程有信心。不过，天有不测风云，总会发生点儿意外，所以我们要做足够的时间规划，而且要使用波浪式规划，这样才可以随着环境的变化灵活地更新日程安排。

管理会议

在组织项目时，项目经理要尽量避免浪费时间的会议。要让团队将注意力集中在项目上，这是最简单、最有效的方式。在帮助团队朝着合理的交付截止日期前进时，要保证团队不受外界干扰和影响。如果会议对于任何人都毫无价值，那就取消掉；同时准许团队成员不参与无法贡献和收获价值的会议。也许有些团队成员会不高兴，认为你觉得他们不够重要从而不能参加会议。要跟他们解释清楚，你不让他们参会是因为他们太重要了。

速度图

如果只能绘制一个图表，那就选择速度图。速度图集三种度量方式为一身：需求、已完成工作和时间。虽然无法从中看到自己希望了解的缺陷率或成本，却能从该图中对项目的整体进度有所掌握。使用速度图可以使你在一张图中同时度量多个趋势：整体需求数量和已完成工作，其中包括所有的测试、文档以及项目需要等其他内容。这是最有用的图表，是项目经理的好朋友。但要注意，速度图只是获取数据的工具，不是目的。

测试

从项目开始就要坚持“减少技术债务”的原则，让测试与开发同步进行。测试会将项目的风险展现在众人面前，大家越早看到这些风险越好。在采纳顺序式生命周期的项目中，要让测试人员参与到需求分析阶段，询问他们关于产品需求的反馈；在采用迭代式生命周期的项目中，要请测试人员帮助评估原型；使用增量式生命周期的项目，只要有可供测试的部分，就可以让测试人员尽早开始测试功能；在实施敏捷的项目中，要确保测试人员与开发人员一起工作，以开展技术层面的测试。同时，还要让测试人员与产品负责人一起，编写面向客户层面的测试。