总结项目进度管理经验

总结项目进度管理经验内容摘要：

员。 综上所述，项目管理想要更好地发展，就摇把目光放远些，追求精益管理，无疑是未来项目管理发展的主流。 6 小督办解决 项目 管理大问题 A 集团公司经过十年的发展已经形成一家以化工产业为主，并涉及相关上下游不同行业的集团化公司，集团总部对下属各分公司 的管理方法有财务管控，也有全面的经营管理，还有参股的独立核算型的分公司， 2020 年为提升集团公司整体的管理水平。 集团公司在信息化方面进行了整体的规划，在原有财务系统的基础上，又使用了 ERP、OA系统。 集团在规范化及效率方面都了很好提升。 不过最近一次小小的失误，给公司造成了不小的损失。 不仅丢失了客户，还对公司的品牌形象造成了恶劣影响。 这让集团高层开始思考，如何更好地对细节进行把控。 管理者身居高位，事必躬亲不现实，事无巨细很累人，但用什么方式来弥补细节失误所可能带来的损失。 集团公司提出 要加强内部的监管，把问题处理在萌芽之中，对各职能范围内出现问题实行问责制。 在各分管领导看来，定战略、带团队、打硬仗都没为题，但却常常免不了在不起眼的细节处摔跟头，如今集团公司的一纸令文也可谓是当头棒喝。 如果说，以前的失误是可以弥补的，这次的教训却让大家开始怀疑结果型的工作管理是否合理。 有没有更好的管理模式。 过程管理如何更好地实现。 过程管理的重要性不言而喻，但由于管理面广，并非事事都能时时跟踪。 即使工作通过OA 系统实现了电子化，也依然难以实现理想中的过程管理状态。 OA。 当想到 OA 应用以来，公司在 流程管理上的提升，高管们再一次想到了 OA 系统。 有没有办法通过 OA实现更加科学规范的过程管理。 当各位高管聚集在信息中心时，所有的压力突然间转移到了信息中心的 c主任身上，问题像雪片一样飞向信息中心，都是需要支持的。 还好，多年的管理经验让 c主任很快冷静下来，梳理思路、分析总结，他发现问题集中在两个方面： 在管理范围内但是没有直接参与的流程，也可以随时查看； 如果我发现问题，是不是可以随时给出建议，进行指导和指正 ,从而影响执行的结果。 这不就是 “督办 ”。 c 主任突然想起不久前在泛微公司的 OA 深度应 用培训，主题就是“督办 ”。 当时感觉这个功能确实是为整个 OA系统锦上添花了，但并没有深入思考这个功能的业务应用，现在看来，一些小小的功能背后可能隐藏着管理之道呢。 马上行动。 c主任赶快找来文档查看，并咨询了泛微公司的客服人员，终于吃下了定下丸。 “流程督办：为了满足一部分管理员不在流程设置的流转范围内，但是需要对某些流程进行监督催办，系统通过提供流程督办功能来指定相关人员对指定类型的流程有查看的权限，并能对流程提出相关的督办意见。 ”就是这样。 C 主任马上和业务部门的负责人进行了沟通，在泛微客服 人员的协助下搭建了测试环境。 当各分管领导再来信息中心的时候， C主任要做的，就是登陆系统，点一下督办菜单，把所有督办事宜展现出来。 督办功能的上线使用顺理成章。 很快， “督办 ”功能成为高管们最常使用的工具之一。 由于高层的督办，事务处理效率在原来基础上又提升了一个台阶，细节的把控更加到位，管控风险大幅降低，信息化助力企业提升管理能力得到了又一次的验证。 综上，在项目管理中，负责监管的督办其实负有很大的责任，虽然作用不是很明显，但是对于一个项目来说，却是无可替代，举足轻重的。 7 谈谈 SCRUM 中的 项目经理 1. 谁喜欢被管制 公元两千多年前，我们脚下的这片土地，处在一个人人向往的太平盛世，以至于现在我们这些后人，都时时引之以为荣。 （更有些高高在上的人，不知脸皮为何物地吹嘘当世可以为它的翻版。 ）这段我们向往的历史，即是 “ 文景之治 ”。 其治理策略更为人所熟知 “ 无为而至 ” ， “ 轻徭薄赋 ” ， “ 与民休息 ”。 （说白了，就是什么也不干 ? ） 很不幸，作为开发人员，似乎我们很难碰到像刘恒或刘启那样的老板。 正好相反，项目经理或者更高级的主管们往往会在我们沉静在思考中时，像苍蝇一样嗡嗡地飞来采集进度 不懂技术的，只是一个会说话的监视摄像头；略知技术的，往往会提出一些干扰性大于操作性的建议；即使有真的精通技术的，除了提了建议炫耀自己的专业实力，更多的是打击开发人员并养成其依赖性 ...... 结果 ...... 我常常听到下面的人抱怨：我们 领导烦死了，除了监工啥也不干 ! 同样有趣的是，我也常常听到管理者抱怨：下面这些员工啊，素质低，爱偷懒，不把工作当回事，只图完成任务交差而已。 软件开发归根到底是人为主导的行业，人性化是无法忽略的。 我们渴望在软件开发工作中抛弃官本位，拒绝垂直命令，解放自己，同时也解放管理者。 2. SCRUM 的一个原则 – 拜托，请您不要管太多。 SCRUM 提醒经理 们，你的任务是支持开发人员，扫清障碍。 而不是传统的命令和控制。 习惯了当官的人不明白 支持。 只是支持。 不会吧。 那种自我膨胀和虚荣的感觉都 没了。 我必须得控制，得发号施令。 再说不这样也不行啊，不催项目就会延期。 让我们对比一下大家常见的真实世界和 SCRUM 提倡的情景吧。 看看究竟那种方式更有成效。 场景一：初步制定了一个开发周期计划以后，开发组和项目经理一起开会讨论计划，表述了计划日期和原因以后： 真实的世界 = 开发组长（小心翼翼地）： “ 您看着计划如何，同意否。 ” 项目经理： “ 恩，还行。 不过我觉得这个功能看起来没有那么难吧，嗯哈 ...你们估算的时间怎么这么长。 ” 开发组长 : “ （陈述原因） ......” 项目经理： “ 哎 ...大 家加加班，辛苦点嘛 ...有什么要求尽管可以提嘛 ...（画饼。 通常提了要求也得不到满足） ” 后果：开发组不得不听从上头意见加班，满肚子怨气，责任心进一步降低了。 开发组长觉得自己的评估遭到否决，自己的话语权被剥夺，还要为了缩短的时间不断压迫成员。 SCRUM 的世界 开发组是交付成果的真正负责人。 = 开发组长（小心翼翼地）：您同意否。 项目经理：你们觉得该计划没问题。 能按时按质量完成。 开发组长：是的。 项目经理：那就按照你们的做。 后果：开发组长对自己有了信心，开发组成员感觉到了自己的话语权（虽然 是很有限的），即使加班，也是对自己的计划负责，怨不得上级压迫。 场景二：开发组例行会议 . 项目经理也来凑热闹 真实的世界 = 会议开始，开发组长打开一个 word 或者什么文档，然后请每个人轮流汇报进度。 会议进行中，每个人轮流汇报进度 ...项目经理突然就汇报中的某问题提问，开发人员回答解释 .... 会议趋于尾声，开发组长请项目经理发言 项目经理： “ 恩，我觉得 ...你们应该注意 *@$$，你们还要 %$...还要 %$T$” 会后结局：开发组认为自己被干涉，上面管的太多太琐碎。 SCRUM 的世 界 只有开发组自己才能对自己负责。 = 项目经理： “ 我不应该出现。 这个会议不是为了向我汇报成果展示绩效 , 而是为了解决开发过程中的问题，应该由他们自由讨论。 ” 会后结局：高效的会议。 组员不只是为了秀自己的进度给上级，更关键的是提出了自己的问题和困惑并得到其他成员的支持去解决问题。 场景三：交付成果审查，项目经理发现了一个问题 真实的世界 = 项目经理： “ 你们这里有一个漏洞，我知道一个解决方案，你们应该 $$@...” 结果：开发人员的信心被打击，并趋向与养成对经理审核的依赖性 SCRUM 的世界 项目经理不应该干涉过多，发现问题，解决问题都应该留给开发组自己。 = 项目经理： “ 恩，非常好。 不过好像没有考虑到一个问题， (但是我不会说出来 )，我相信你们自己会发现，请仔细审查一下。 ” 结果：开发组自己发现并解决问题，面子被照顾，并且日后会更加认真。 同时对项目经理的专业能力表示赞同。 场景四：不干涉不行 重回老路。 实施 SCRUM 有一段时间后，项目经理发现开发组的工作效率和工作热情都提高了。 一切似乎进行的不错，开发组长和组成员都开始从心里对项目，产品有了较 高的负责心，不再只是单纯为了对付上面的任务了。 可是有一天，项目经理的上司，公司的高级经理来了。 高级经理要求审视所有进度和发布成果。 在项目经理完成展示后，高级经理很不高兴。 高级经理： “ 这个项目。