正文
隐藏风险的识别
大多数情况下，后期的各种问题的主要来源就在于前期对于隐藏风险识别度不够。导致很多原本可以早期就进行方案修正或者是实现改变的问题，到后期才发现导致大换血或者是问题频发。
Task 前置
如果遇到第三方（不可抗力）的影响，可以先将后期的 Task 能够现在完成的前置，而不是等待不可抗力的自我修复（此时无所事事），这样会导致一旦第三方修复，我们的 Task 会突然暴增，这样神都救不了。
问题抛出讲技巧
对于问题要及时抛出，并且进行问题处理的过程跟踪，结果跟踪，在抛出问题的时候千万不要只抛出问题，要附带自己认为可行的解决方案，让接受问题的人来选择。
这样做事一种双赢，
一，问题的接受者不需要去思考问题的解决方案，只是简单的做个选择（这样可以大大的增加问题抛出后得到及时反馈以及解决的几率）
二，我们自己来决定的解决方案会对我们的实现更加有利，毕竟是我们考虑了实现方面所想出来的解决方案。
沟通的集中性，文档性
对于沟通，是个老生常谈的问题了，除非我们都是独立开发，否则项目中不可避免的就会出现沟通这个词，我们不需要做那种零散的沟通，你告诉我，我再转告他，他又转告他。信息在传递的过程中，是很难保证不变的，很多时候到了最后的接收者那里问题早就被改变意思了，而且这中的沟通过程太过于冗长，所以先把问题整理起来，然后直接团队一起一个 call ，或者是一次小型会议就解决掉所有的问题。然后沟通的结果一定要体现到文档上，白纸黑字的记录下来，以后大家就根据文档办事情，不要凭借着自己的记忆来办事情（好记性不如烂笔头）。
多 Task 并行处理
一般来说到了项目后期，Task 是比较重的，经常是多 Task 并行的状态，解决这个问题，就需要从四象限原则出发，对当天的 Task 做一个分类，先轻重，后缓急，然后再根据这个分出来的四象限来开始今天的工作，如果你是管理人员那么你在这里还可以进行任务的再分配，确定哪些是你做的，哪些是你可以分给团队其他人员完成的，还有那些是属于兄弟团队的事情，并且进行相对应的转移以及 Task 的跟踪。
需求挖掘
很多问题后期才会体现有很多也来自于需求挖掘不够，导致后面的工作，诸如测试用例，开发方向，实现方向，测试方向可能出现重大的偏差，所以对于需求我们必须要抱有一个怀疑态度，对需求必须要复杂化，越复杂越详细的需求，才能够给后期的工作提供更多的帮助（这里的复杂化不是文字描述上的复杂化，而是整个需求的详细化），越是粗略的需求分析，我们就越容易在项目后期来还这笔欠债（这个时候就没有那么好还了，高利贷日子越久越难还上）
遇到问题不能惊慌
惊慌解决不了任何问题，反而会让我们的智商下降，人在烦躁的状态下是很难进入状态的，就会导致项目进度十分缓慢，然后问题影响就会更加明显，然后就会更加惊慌，然后项目就会继续进度缓慢，如此的恶性循环对于项目还是自己来说都是百害而无一利的事情。所以在项目前期，就需要尽量的去发现这些潜在的问题（比如 Service 挂掉，比如第三方不能提供稳定的 Support，比如第三方的系统会有一些使用限制以及隐藏 bug。。。。。），然后大概根据这些最坏的情况想出一些应对的方案，使得真的发生的时候不至于感觉一下子天就塌了。
Buffer Time
做软件开发，重要的一点就是一个延时性，我让你今天完成这个功能，那么多半来说，你是完不成的，你会多需要一定的时间（虽然在计划的时候是认定确实能够完成，但是在这个过程中，多半都会延期），因此我们给自己（或者给团队）就应该要留下一些 Buffer Time 来应对这种情况的发生以及突发情况的发生。
精简的邮件
没有人愿意经常看长篇大论的邮件，通过邮件沟通的时候尽量让邮件内容变得精炼简洁，需要解决什么问题，不需要围绕问题的一大堆的详细描述，就只要问题的精华部分，读了就懂，这样会大大的增加邮件回复的及时性。
总之，怀疑的心态在 IT 行业是不要丢掉的，我们不能相信任何人，包括我们自己。
如有问题，希望不吝赐教！