项目管理中常见的问题有哪些（一）

问题一，线上出bug了，是先找责任人，还是先处理问题？

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

问题二、追求研发速度，还是追求研发质量？

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

问题三、某个模块有缺陷，需要时间重构。但是新需求又很多，怎么办？

无论是历史原因，还是啥原因，一旦发现某个模块没办法进行迭代的时候，就需要安排时间审查、重构代码。做项目又不是比谁做的功能多。早期公司为了生存求快，可以理解。等到公司度过生存期进入发展期，就应该早点还技术债，不然越到后面越难改。

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

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

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

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

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

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

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

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