项目管理：问题探讨与解决方案

前言 近期，在项目管理过程中，发现了两个值得深思的问题： 有的同事任务做完了，但是暴露出很多显而易见的问题； 项目月末统计及时完成率，出现人人达标的情况。 这两个问题，都在一定程度上反映出任务执行过程中、项目管理方面存在一些方法不对，或者制度漏洞，导致没有达成预期的效果。 现在，就基于这两个问题，好好分析以及给出对应的解决方案。 任务要做好，而不是做完 在会议室验收功能的时候，有个同事开发的功能模块，比如设备列表，暴露出很多问题。而且，还是一些很明显的问题： 列表只是展示 10 条数据，没有滚动条，没有分页，导致后面的数据都看不到； 点击删除按钮的时候，没有二次弹窗让用户确认，而是直接删除了，删除之后列表也没有更新。 这些虽然是小问题，但是表面风平浪静，实则暗流涌动，从中可以窥见在水面下的深层问题： 第一个就是没有用心在开发这个功能，这些都是很明显的问题，一些细节都是约定俗成，并不需要别人反复和你强调。 第二个就是换位思考，假设你是用户，在使用自己开发的功能，难道就没觉得有问题吗？ 任务要做好，而不是做完，做完只是机械地执行，做好就需要动脑思考。 任务执行过程中，到底有没有对这个任务的方方面面了解清楚呢？ 任务的背景是什么？为什么要做这个功能？什么人在用？到底会关注哪些细节？这个功能定好的实现方案，是否有更好的？现在遇到的这些问题，不解决的话，会留下什么隐患？ 经过这样反复思考，如果觉得有问题，就应该及时反馈、暴露出来、及时沟通和处理。 而不要觉得，多一事不如少一事，差不多就行了，要是反馈的话，搞不好还增加工作量，我才不傻呢。 大部分人都会这样想，并没有什么问题，还是那句话，人之常情。 只是，要算一笔账的话，就会知道，很划不来。 因为，如果后面功能验收出了问题，除了影响你在工作上的口碑，还有可能会返工，那还是要增加工作量的啊。 那还不如，从一开始就做到位了。 当然，有人会说，要是每做一个事情，就经常反馈、提建议，让人觉得自己很难沟通，怎么办？ 确实，有时候，要的就是执行命令，而不是习惯性抬杠。 但，我想说的是，要看从集体利益，还是个人利益的角度出发了，如果是集体利益，而不是私心，只要说的有道理，都是应该听取的。 凡事都可以商量着来。 完成比完美更重要 在 2024 年 8 月，3A 大作《黑神话：悟空》上线以来，全网一片好评，很多人评价，包括我，都说是划时代的作品，会在游戏的历史长河中，被铭记于丰碑之上。 但是，美中不足的是，后面两章，明显没有前面几章那么精细，赶工痕迹特别明显，特别是第六章，整一个大石敢当，实属无语，感觉有点敷衍了。 如果好好打磨，会更上一层楼。只是没有办法了，没那么多时间了，所以，就像主创冯骥说的： “完成比完美更重要。” 在现实生活中，同样也是如此，很多坚持打卡的事情，早睡早起啊、坚持跑步啊、坚持控制饮食啊、坚持看书学习啊等等。 有一些人，比如我，会陷入完美主义的陷阱，比如要在草稿纸上写一段话，如果第一个字感觉没写好，就会撕掉重写，这个现在看来，是有问题的。 就好像人生，就好像打牌，不可能每一次开局都那么完美，只能是基于现有的牌，来不断调整策略、方法，然后能打赢。 之所以写一个字，没写好，就可以撕掉重写，无非就是撕掉一张纸的成本过低罢了，没有伤筋动骨，当然不会觉得有什么。 但是，无形之中，会养成这种较真的、不切实际的完美主义的思想，对于做好一些事情，是有害处的。 而这种思维，和上面提的 “做好，而不是做完” 的区别在于，是有先后顺序的，不同的阶段，不同的思维，不应一概而论。 最后 总之，不管是工作还是生活，我的结论是： 首先要有 “做好，而不是做完” 这个意识，等这个意识在你脑海中生根发芽，这是第一步。 很多事情，你确定自己是真的倾尽全力了，只能做到这一步了，再怎么责备你也没办法了，就算拿把刀架你脖子上，也不会更进一步了。 然后，这个时候，才可以说，完成比完美更重要，这是第二步。 这是一个递进的思维意识，而不是像二极管一样，非黑即白，本身就是要辩证地看待。 只是大部分人，没有第一步的意识，就妄想直接跳到第二步，来为自己的懈怠开脱。

前言 书接上回，前面已经对“做好，而不是做完”的问题，进行分析和提供解决方案了，就是这一篇文章，现在就要对“项目月末统计及时完成率，出现人人达标的情况”的问题，进行分析和总结，希望能梳理出有价值的东西。 任务及时达成率数据不够客观 我设计的项目管理系统，存在任务及时达成率、及时验收率，都人人达标的情况。 这个是什么原因的呢？ 实际上，是因为我们对任务变更没有做管控导致的，而为什么不对这个做管控呢？ 原因是插入需求的频率过高。 为什么过高呢？ 因为项目业务肯定是要根据客户反馈的情况，去做调整的。要第一时间去响应客户的需求。 所以，很多时候，虽然我们制定了项目计划，但在执行过程中，经常出现任务变更的情况，而这个时候，没有去深究到底要不要、应不应该变更，而是默认允许变更了，只要有产品、后端、前端、运维等一方出现需求上面、或者任务执行未及时达成，影响后续关联的任务，那么上面的任务就会出现变更的需求，而这个时候，身为项目负责人，是应该综合考虑和判断，是否允许变更的，但是没有去抓这个环节，只是都是默认变更了。 这个本身就是一个漏洞了。 因为对于研发而言，如果你不允许插入需求，那么就太僵硬、死板了，但如果总是允许这样插入需求，那么项目计划就很容易失控，久而久之，项目成员就容易出现一种心态，反正最后都是要变更计划的，那么今天做完，还是明天做完，有什么区别吗？ 反正制定的里程碑时间，制定的版本发布时间都是要改的，每次好像都没有及时达成过，那么早一点做完，迟一点做完，又有什么区别呢？ 这种思想一旦萌生，就很难消除了，要从根源上，从制度上去解决才行。 实际上，还是回到项目计划的目的、里程碑的目的来说的，这个在之前很多篇的文章中叶提到过了，就是项目计划的目的是，有一个方向和时间节点，就好像大海中有一个灯塔一样，大家都朝那个方向前进，而不是，张三往东走，李四往西走，王五往南走，那还怎么做事情？这是其一，其二就是要求项目负责和项目成员，在面对任务变更，各种突发事件时，应该怎么充分发挥自己的智慧，通过有效的策略，就好像打仗摆兵布阵一样，先做哪些，再做哪些，怎么去争取资源，怎么去和其他成员、上级领导协调沟通，以致能够在时间要求内，及时达成里程碑，就像打胜仗一样。 单个项目管理，直接是项目负责人，对项目的把控，其实更为具体和实际，其实，还是很简单的，但是多个项目管理，还是有点难度的。实际上也不能说是难度吧，只是那种要靠他人来成事的情况，会更明显。自己没办法直接介入，要知道引导，辅助，以第三方视角，去掌控全部的事情。 不是单点突破，而是回到源头 所以最终还是要回到项目的完整的生命周期，对每一个环节，都要深入分析和研究，确保自己是真的做到位了。 下一篇，就说明一下完整的项目生命周期有哪些。

项目完整的生命周期

前言 在软件开发过程中，我们经常会遇到一些探索型的功能开发任务，就是那些没有做过、没有参考案例、甚至整个部门都没人有经验的功能开发。 这种任务往往充满了不确定性，也最容易出现问题。 书接上回 还记得之前张三和李四因为临时方案爆发的争论吗？ 李四最近的开发工作一直都差强人意。 每次功能做完在会议上演示，总是会被挑出很多问题：功能实现丢三落四、界面样式不够美观、逻辑处理不够完善等等。 问题表现 这个问题到底出在哪里呢？是李四做事情不够用心吗？ 经过一段时间的观察，我发现问题主要出在两个方面： 问题一：需求沟通不到位 首先是需求沟通的问题，很多时候，需求给出来的时候就存在可协商的空间，什么意思呢？就是需求描述不够明确，没有达到可量化的程度。 比如只说 “界面主题色是蓝色”，但没有给出具体的十六进制值。对于开发人员来说，蓝色可以是天蓝色、浅蓝色、粉蓝色，甚至深蓝色。 结果等开发完成了，你又不满意了，说想要的是深蓝色。这个时候功能都实现完了，找谁说理去？ 问题二：探索型任务的特殊性 第二个原因是，李四的开发任务是探索型的任务，这类功能没有做过，甚至整个部门就他一个人开始做。 对于这种类型的任务，最容易出现的问题就是口头沟通的局限性，两个人在座位上你一句我一句地讨论功能实现、技术预研、技术框架、设计方案、函数封装等，都是口头沟通。 因为没有参考案例，沟通双方很容易出现 “我觉得我说清楚了，你觉得你听明白了” 的情况。 结果呢？ 等功能开发出来，李四觉得自己已经做到位了，张三一看，觉得和之前沟通的完全不是一回事儿。 解决方案 面对这些问题，我们应该怎么办呢？ 对策一：需求量化是基础 首先，需求必须可量化、可验证，这是解决问题的第一步。 颜色要给出具体的十六进制值，尺寸要给出具体的像素或百分比，功能要明确输入输出，性能要给出具体的指标要求。 所以说，模糊的需求必然导致模糊的结果。 对策二：方案文档不可少 其次，对于探索型任务，方案文档是关键。 李四应该在开始敲代码前，先在脑子里过一遍整个开发流程，找出可能存在的技术难点和争议点，针对每个难点提供 1-2 个解决方案，然后形成方案文档，文档应包括：做什么、为什么、怎么做、有什么问题、怎么解决、结论。 一来可以把思路梳理清楚，二来可以提前预知可能出现的问题，把风险在开发前就排除掉。 对策三：多人讨论是保障 最后，一个人拍脑袋决定的方案往往存在隐患，正确的做法是召集项目负责人、相关同事等一起过一遍方案文档，大家从不同角度提出意见和建议，明确解决方案和实现方式。 为什么要这么做？ 因为每个人掌握的信息不同，多人讨论可以避免信息盲区，可以发现个人思考中忽略的问题，最重要的是，集体决策可以分摊责任，如果最后方案还是不太理想，也怪不到某一个人头上。 总结 说实话，探索性功能开发确实充满挑战，很多人会觉得这类型的任务，最大的难点是在技术层面的攻关，但实际上，只要做事情的方式不对，同样得不到自己满意的结果。 所以说，探索不代表可以随意，创新也需要规范。按照正确的流程和方法去做，你会发现，很多看似复杂的问题其实都有章可循。

前言 说实话，这个事情真的太常见了。在项目开发过程中，时间紧、任务重，大家都想赶紧把功能做出来，这种时候往往就容易出现一些临时方案。 但是呢，临时方案这个东西，用好了是救急，用不好就是埋雷。 今天就给大家分享一个真实发生的案例，看看在项目紧急情况下，我们到底应该怎么处理。 事情是这样的 李四最近在赶一个项目的进度。说实话，时间真的太紧了，按照正常的开发流程，根本来不及完成所有功能。于是呢，李四就动了个心思，用了一些临时的解决方案。 比如说，有些条件判断、有些循环逻辑，本来应该是根据接口返回的数值来动态设置的，但是为了赶时间，李四直接把这些值硬编码写死了。这样做的好处是，功能马上就能跑起来，测试也能顺利通过。 但是呢，这种做法在功能、代码规范上面肯定是有问题的。就像你盖房子，本来应该用钢筋混凝土浇筑的柱子，你用了几根木头临时支撑一下，虽然看起来也能立起来，但是，随着楼面东西越来越多，顶不住是时间问题。 矛盾爆发 项目负责人张三在重构代码的时候，就发现了这个问题。说实话，张三当时就火了，在项目进度例会上直接就和李四争论起来了。 从张三的角度来说，这种低级错误真的无法理解。代码规范这种约定俗成的东西，难道还需要一遍一遍地强调吗？如果每个人都这样随意修改代码，那项目质量怎么保证？ 从李四的角度来说，他觉得很委屈。当时项目时间那么紧张，我想出了临时方案，至少保证了功能按时上线，自己不但没被表扬，反而被批评，心里真的很不好受。 双方都觉得自己有道理，看起来这个问题真的很无解。 张三的问题 说实话，张三作为项目负责人，也有他的责任。 首先，代码审核没有做到位。这种明显的硬编码问题，应该在第一时间就发现，而不是等到项目上线后才提出来。 其次，在李四解释了原因之后，张三不应该过多指责，而是应该给出建设性的建议，帮助李四改进工作方式，避免下次再出现类似的问题。 李四的问题 李四的临时方案本身并没有太大问题，毕竟在紧急情况下，有时候确实需要一些特殊手段。 但是呢，他的处理方式有问题。在使用临时方案之后，他应该有更好的选择： 方案一：主动告知 在群里或者邮件中告知团队成员，说明自己使用了临时方案，并且承诺在时间节点过后会进行完善。这样既能保证项目进度，又能让团队成员了解情况。 方案二：默默完善 如果不想让太多人知道，至少在时间节点过后，自己要记得把这些临时方案替换成正式的解决方案。 但是很遗憾，李四两个选择都没有做。所以才导致了后来的争执。 总结 说实话，这个案例虽然看起来很简单，但背后反映的是项目管理中的一个普遍问题。 在项目开发中，我们经常会遇到各种紧急情况，这时候就需要我们有灵活的应变能力。 但是，灵活不等于随意，我们需要在保证项目进度的同时，也要保证项目质量。 最重要的是，遇到问题不要互相指责，而是要互相理解，共同寻找解决方案。 只有这样，才能让团队变得更强大，项目变得更成功。 记住，临时方案可以用，但一定要使用正确的方法，想出一个好点子，并不等于就解决了问题，要在执行层面也做到位，那才是真正的解决了问题，而不是出现新的问题。