项目管理中常见的十个问题

项目开发过程中会遇到很多问题，今天我分享十个常见问题及应对思路。

问题一，写的代码出 Bug 了，是先找到问题原因，找到责任人，还是先处理问题？

不是每一个问题都值得被追责的，指责也不能修复 bug。发现问题后，关键是解决问题。问题解决后，再作复盘。复盘的目的也不是追责，而是为了防止问题再次发生。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作，应互相帮助，而不是互相指责。把矛头对准问题的解决办法，而不是人。

问题二、快速实现功能让项目上线，还是追求研发质量？

古语说：欲速则不达。但如果项目眼看着就要延期，怎么办？项目负责人有压力，研发人员也有压力。这种压力会让你走捷径，只看眼前利益。哪怕项目负责人不愿意走捷径，怎么落实呢？如果你考核开发人员要准时完成任务，你怎么保证他不会用一些”特殊方案“呢？堵不如疏，还是要用流程来解决这个问题。可以跟团队成员约定好，在项目开发过程中，因为时间不够，但有其他更简单的方案应对时，可以把解决方案抛出来，让大家一起决定。虽说我知道不走捷径本身就是走捷径。但有时候还是要妥协。但这种妥协，就算会遗留一些问题，只要我们知道，有应对方案，就不可怕。

问题三、发现程序有缺陷，需要时间重构。但是新需求又很多，我该怎么办？

及时反馈，是高效协作的基础。一旦发现原来的实现有问题，就要立即做出反馈。要明确线上的问题优先级是最高的。不能因为新需求而忽视对线上问题的修改。这种情况有时候很难，需要你在团队内承认自己的问题。但从另一个方面说，如果你没有犯过任何错误，只能说明你没有努力去工作。

问题四、我们在讨论需求的时候，到底是对事还是对人呢？

这是在做需求讨论时，我们都应该自问的一个问题。明明都知道应该对事不对人，但每个人或多或少都有一些自我主义。你很可能见过，对方案设计的讨论失控变成了情绪化的指责——做决定是基于谁提出了这个观点，而不是权衡观点本身的利弊。

很多争论都是主观判断引起的，而解决的方案就是改变沟通方式。最好的沟通方式是 yes,and 或者 yes, if。先肯定其观点，再提出疑虑或者新的东西。举个例子，同事 A 针对项目提出了一个实现方式，你觉得有问题。但不要直接说这个问题，应该先肯定 yes，谢谢 A 提供的方案，我们是不是还需要考虑多端登录的问题?（and 贡献新东西）。

问题五、写的代码由于人员变动，导致没人能维护。

所有的系统开发久了都会变得很复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。我有一个观点，每一个开发人员都应该理解需求背后的目标或者理由。只有理解需求，你才懂你的代码。想要解决无法维护代码问题，需要从源头开始做规范。

• 经常做代码审核，让团队内的其他成员检查你运行的代码。在你不说明的情况下，其他同事能看懂，间接说明你的代码风格很清晰

• 做好单元测试，单元测试帮助你很自然地把代码分层，分成很多可管理的小块，这样就会得到设计更好、更清晰的代码。同时，它能直观看到结果是否与你所想的一致。

问题六、我能力不行，开会时不应该提出自己的见解？

团队存在的意义就是承认一个人干不过来，需要团队一起去干。每个人都会犯错。如果你准备提出一个想法，却担心有可能被嘲笑，或者你要提出一个建议，却担心自己丢面子，那么你就不会主动提出自己的建议了。然而，好的软件开发作品和好的软件设计，都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点，远胜于单个想法为项目带来的价值。事实上，很多公司都会安排一些初学者来提意见。

我们每个人都会有好的想法，也会有不对的想法，团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。记住，任何一个专家都是从这里开始的。你不需要很出色才能起步，但是你必须起步才能变得很出色。

问题七、领导在会议上决定执行一个错误的决策，你作为下级，是否当众提出疑问？

如果你非常确定决策有问题，我建议还是要提的，只是要注意提建议的方式，不要用主观观点去质疑，而应该摆事实。（最好的方式是在会前提出）

如果你没提出，或者提出后方案还是被确定了（不管是什么样的方案），每个团队成员都必须通力合作，努力实现这个方案。

问题八、有一门新技术出现，要不要使用？

根据自己的需求来选择新技术。首先你得明确你需要什么，要解决什么问题。根据具体的问题来评估使用新技术。其次，要了解新技术的利弊，每一个技术都是有局限性的。最适合的才是最好的。最后，你要清楚使用新技术需要付出的代价。

许多新技术都是基于现有技术和思想而开发的，这些新东西也是逐步完善。如果你紧跟技术变化，那么学习这些新东西对你来说就是了解这些增量的变化，如果你不跟踪变化，技术变化就会显得很突然并很难理解。这就好比少小离家老大回，你会发现变化很大，很多地方都不记得了。然而，对于居住在那里的人们，每天看到的都是小小的变化。所以非常适应。

如果你想尝试一门新技术。我的建议是先小范围尝试，宁可慢，不能错。

问题九、如何才能跟上技术变化的步伐呢？

• 迭代和增量式的学习，每天计划用一段时间来学习新技术，当你听到一些新的名词时，简要地记录，然后在计划时间去了解。

• 互联网给了一个我认为最好的方式，找到这个领域里的某一位或几位牛人，跟着他们学。有线上课程的看课程，有线下活动的参加线下活动。出了书的看书。

• 明确自己不需要精通所有技术，也不可能精通每一项技术。只要你在某些方面成为专家，那很容易用同样的方式在新领域成为专家。

• 要理解新出现的技术是为了解决什么问题而开发的，它能用在哪些领域。从而规划自己的项目和职业生涯。

• 应用技术时，必须先评估新技术的优势。然后用一个小的原型系统去验证。

• 打造一个学习型团队，每周固定时间做分享会。让每个人参与。提高学习效率。

问题十、编码过程中发现需求有问题，怎么办？

首先，要明确这种现象是正常情况。哪怕有需求评审会，我们也没办法找出所有问题，有些问题只有在编码的过程中才会发现。

其次，不要自己想解决方案来规避或解决问题。有些你以为的问题，在业务上并不是。或者可以用一些非技术的手段来解决这个问题。

最后，梳理清楚问题，然后跟产品负责人、开发负责人、项目经理一起讨论。如果早上有晨会，可以在晨会上把问题抛出来，确定讨论任务和时间，但不在晨会上做详细讨论。