1.1.0GA已发布,禅道、jira、itest 一键搬家到Codes及批量式工时填报可用! 查看版本说明

Codes项目管理研习社 项目进度跟踪三不要

21221... 2025-04-11 18:08:22.0

项目进度管理是项目管理中最重要,也是最难的一环。很多时候,因为时间或者其他原因导致我们只关注重要的里程碑进度,而对中间项目进度管理松散导致项目延期或失败。在失败后都不知道失败的根本原因,搞的自己都没法好好总结与提升。出现这种情况的主要原因是没有做好“三不要”,具体如下:

一、不要漂浮空中不落地

在制定项目计划后,就只看电脑屏幕前的表格进度,这样只能知道哪些任务完成了,哪些任务延期了,最多还从备注里知道为什么延迟了。不要以为这样你就掌握了项目真实的进度,你可能只掌握了项目进度的表象

“俯瞰”进度是必要的,同样“落地”任务细节问题也同等重要。

细节决定成败,而且你需要了解关键卡点的细节,才能真实的知道:问题在哪里,需要哪些资源来加快问题处理,会出现哪些风险影响到项目的各个方面等等。如果我们只是俯瞰,不进入关键问题的细节,用里程碑节点来设置检查点,那么很大可能在检查的时候才暴露问题,而且这时并非真实的问题。在这个时间节点处理已经完全的晚了,而且你必定会花更多的时间去梳理问题,发现真正的问题在哪里。

那么我们如何“落地”任务细节?

并非所有的任务细节都需要门儿清,我们需要把精力放在关键问题上。我们可以通过每日站会或者检查任务列表沟通环节发现问题表象,根据表象问题分析得到真实的问题在哪里。这个方法百试不爽

只要知道了本质问题在哪里,下一步需要判断他是关键问题还是非关键问题。非关键问题指定责任人与完成时间,在截止时间内跟踪关闭即可。如果是关键问题,那么需要评估是否可以按时解决,需要哪些资源协助处理,对整体项目有多大的风险,将精力放在关键问题上,将问题与风险前置。

积极“落地”不在“漂浮”是例行惯例工作事宜,也是重点精力规划的投入。不能因为其他原因就只“漂浮”式管理,注定失败

二、不要觉得成员会自己推动问题

团队成员只关注自己的任务状态,任务状态出现问题如果寄托于他们自己能快速解决,这是一个误区。这里说的是快速解决即在合适的时间范围了解决。一般来说,这样的问题都会被滞后,直到拖不起或者引发新的问题的时候才会推动解决。如果不进行干预推动,这样的问题会越积越多,当达到一个项目进度容忍阈值的时候,会引发大问题,比如:项目延期,成本超支等。

所以需要积极推动项目中的问题处理,做到不积压不滞后,在源头控制项目风险。项目经理推动问题的处理,可以跟快的协同资源,确定优先级,解决方案以及处理后评估。可以让问题处理的更加及时,同时也能控制和避免更多的风险发生,保证项目成功。

三、不要不把外部关联方纳入管理

如果是独立的项目,不和外部产生关联,那么外部管理安放的管理基本不用担心。

如果是项目不能独立运行,需要外围协调与支撑。那么外围的相关方需要纳入管理,而且需要密切管理。虽然外部的相关方在技术方案,资源投入,项目计划,验收上线等阶段的明确开始结束时间很难协调,但也需要努力的沟通获取,并纳入自己的项目计划,并实时跟踪和确定当前外部状态,在必要的时候也可积极投入沟通或者向上沟通,推动外部进展达到预期。

外部关联方如果不管理到位,不在发现问题时提出风险,并告知项目相关方,那么很大概率是外部无法在项目计划的范围内完成相关工作,进而项目不的不顺延,造成项目满意度极低。


Codes 是国内首款重新定义 SaaS 模式的开源项目管理平台,支持云端认证、本地部署、全部功能开放,并且对 15 人以下团队免费。它通过创新的方式简化研发协同工作,使敏捷开发更易于实施。并提供低成本的敏捷开发解决方案,如事件驱动实现的 “事找人”、自动生成工作周报,多事项闭环迭代,日报与工时填报融合、同步在线离线测试用例、流程化管理缺陷、低代码接口自动化测试和 CI/CD,以及基于迭代的研发管理和测试管理等,践行敏捷开发。主要功能有:需求池、原型管理、工单管理、工作汇报、需求管理、任务管理、测试管理、缺陷管理、自动化测试、项目文档、工时进度管理、风险管理、项目管理(支持多种模式),统计分析等。
Codes 旨在提高各职能部门和人员的协同工作效率,优化软件产品敏捷开发周期,管理员工工作计划和工作负载,便于领导层从全局视角把控各个软件产品的研发进度和风险管控。主要用户有部门领导、产品经理、项目经理、软件研发人员、软件测试人员、项目实施人员和销售人员。