做过很多项目，有的时候冥冥中能感到不放心，就是一种心里很没底的感觉。最近我就在想，怎么判断一个项目有没有问题？
一个项目的执行过程如下：
-
产品/老板等根据现有的问题，提出一个需求
-
产品召集研发、测试等同学做需求评审，提出上线时间
-
研发同学写技术方案并评审，预估出开发时间，测试同学粗估出测试时间
-
研发同学开发
-
测试同学写测试case，并评审
-
测试同学进行测试，包括一轮、二轮、回归等
-
项目上线
我觉得有问题的情况可能出现在如下几个位置
1.需求阶段：有时候需求可能不合理，对如何分析项目的思考，不合理的原因可能是因为脑子一热提出来的、设计过重、没有发现根本原因所以方案不全面等。
-
后果：导致的后果就是ROI特别低，费老鼻子劲完成任务，收获比较少，而且会导致核心的任务后移了。
-
解决：从研发角度看，有时候挺难解决的，因为凡是需求都肯定能找到需要解决的问题，不能说完全没有价值。要么自己看的足够深，能够说出本质，大家都信服，要么自己的影响力比较大。在这一步上battle挺累的，少部分成功了，一些升级后也成功了，大部分失败了。
2.需求评审：评审过程中大家提出了很多问题，而且是比较重要的，这说明这个项目是没有考虑全面的。还有一种情况是评审的时候，对应的研发、测试都没有拉全，这说明产品与技术团队不是很熟悉，也不是很好的事情。
-
后果：如果继续推进，大概率仍然有很多隐藏点没有发现，这些点会在UI、UX、技术方案设计、测试过程中不断被发现，然后需求不断变更，大家都累。即使上线后，也有可能影响到用户体验。没拉全研发人员则需要重新对评审。
-
解决：可以产研定好一些规则，如果出现几个P0级别的问题没有考虑到，就重新完善一下方案，不要追求速度。当然这个解决方案也是很理想化了。至于找不全人的情况，还是提前找个POC研发或者PMO，确认一下人员吧。
3.技术方案：这里出问题一般都是大问题。首先是技术方案不清晰，原因可能是懂了但是写的不好，还有一种情况是不太清楚细节，写了个大概出来。后一种会很麻烦，问细节的时候往往答不出来，需要下去再想想。技术方案意味什么，我觉得意味着对每一个关键节点都考虑清楚了，甚至说要在哪里改都想清楚了，或者说技术方案就已经是伪代码了。另一个是估时不准，往往因为各种压力，时间压缩的比较严重。
-
后果：很多细节没考虑到，测试的时候很多问题；有重大问题没考虑到，无法完成开发；写完的代码和技术方案差异过大，对线上影响过大；时间压缩过于严重，无法保证质量。
-
解决：技术方案评审可以定标准，核心问题不知道的重新设计。这种虽然也比较理想化，但是还是可以实现的。倒排期这种问题，我发现只有大家怨念太多、离职的人多了、线上事故多了，倒排这种才会减少。
4.开发：这里很多都是各种各样的细节了，如不按照技术方案写、代码写的不严谨导致panic或cpu/mem高，高并发等特殊case没考虑全、数据库没加锁、表没加索引、代码写的混乱、没有注释等等
-
后果：上线一堆问题
-
解决：强制单元测试、加强代码review、靠测试同学、加强同学的编码能力
5.测试用例：主要是怕测试用例写的不全，这个可能是因为测试同学没有深入了解需求，或者对研发的技术方案设计了解不深。我有一个测试同学，他会看开发的代码，让我安全感满满。
-
后果：有问题没测出来
-
解决：研发自己要提高质量；测试也需要深入了解需求和技术方案，想好所有细节；做好自动化测试
6.测试：这里怕两点，一个是每一轮测试都能测出新的问题，量还不少，这就让人比较怕。二是测试的问题，研发没有深入追查，按照自己的想象给了个解释，然后resolve了。
-
后果：一般会导致上线延期，毕竟总有问题出现要修复要复测。还有一点是让人没底，不知道还有多少问题是没有发现的
-
解决：提前做好测试用例；研发和测试都需要严肃对待发现的问题，最好能考虑一下是什么原因导致的，是个大问题还是个小问题
7.上线：没有上线计划。尤其是多个团队合作的时候，没有上线计划就是个噩梦。我记得看过很多次上线顺序出现问题导致回滚的事件了
-
后果：上线乱糟糟，大家不知道按照什么计划处理
-
解决：花时间写一份上线计划，大家对齐，这个时间是值得的
写在最后：本来想简单写写，但写了之后发现各个阶段出现的问题其实挺多的，解决方案也有，每一个都可以写个单独的文章出来。但我想说的是，方案一般公司都是有的，但方案都是冷冰冰的，真正需要的用心靠谱的同学。不知道大家有没有这种经历，和某个同学合作过后，还想继续合作，为啥，真的是放心，这个阶段交给他/她，你就知道是没有问题的。我是幸运的，每个阶段我都遇到过这种靠谱的同学！