工作中我们时常会遇到一些有挑战的事，如果处理不好，很有可能会打击自我信心，同时带来一些不利的影响。那我们该如何去面对这些有挑战的事情呢？本文从心态层面和技术层面具体谈一谈。
首先我们不能潜意识认为所有的事情都是“容易”的，或者是“困难”的（潜意识有时是不对的）。我之前常犯这样的错，对自我的技术很有信心，这种信心可能是来源于之前了解过相关领域的知识，或者别人说很“简单”，或者只是盲目的想去“试一试”。还有一种情况是，一些“不成熟”的领导在分配任务时，会把任务的完成周期设定的非常的短，让你误以为这件事情很容易（否则为啥完成周期如此短呢？）。遇到以上的这些情况，我们首先要告知自我内心的是：“先平静下来，让我们先分析一下当前的状况，看看实际情况到底如何？”平静的内心是前提，也是我们必须要做到的。过于轻敌可能会带来灾难性的影响，因为一旦事情的难度超过了我们的预期，非常容易引起心理崩溃。 这里其实有心理学的知识，就像我们其实会对身边的人进行“打分”，当我们打不过“强大”的对手时，其实内心并不会太难过，反而如果打不过“弱小”的对手时，心里上反而会很难受，然而其实两者的水平可能是一致的，只是我们认为它们不同罢了。过于谨慎和担心也不太好，凡事的畏畏缩缩的会给领导和同事带来“这个人扛不住事儿”的不好印象。只有先冷静下来，不受外界压力的情况下，才可能做出理性的判断。在自己没有足够把我的前提下一定不能立即给对方承诺（很多产品经理非常push，需求都没写清楚就要求研发给出上线时间），而当前能给出的承诺是先花一段时间进行合理的评估，在此基础上再给出完成时间。
那如何去评估呢？这和具体的事情有关。如果是一个系统的技术选型，那么我们就需要研究具体的业务，目前常见的业务架构种类。可以查阅网上的资料，或者和同事聊聊，一般都会有一些新的思考点，然后根据这些点进一步深入了解和思考。技术选型要解决的问题并非如何去实施这个功能，反而是如何做更好（功能，性能，可扩展性，可排查性），因此广泛的去了解是非常有帮助的。如果有时间，还可以去了解一些相近系统的设计方案，因为很多设计方式是可复用的。如果技术方案已经确定，那该怎么去评估呢？比如我们需要通过gpu对某一块代码计算进行加速，我们可以先去调研一下网上是否有开源的代码已经满足业务的需求，因为通过现成的代码可以快速的验证我们的期望是否正确（某些领域使用gpu计算的效果不如cpu）。如果没有现成的代码，那么我就需要评估一下做这件事情的代价，比如需要学习cuda语言的成本（nvdia显卡支持的框架），完成demo开发的成本。我们甚至需要多考虑一些，比如cuda语言和c语言的交互，虽然我们对c语言已经熟悉了。这些思考点需要和相关的同事和领导解释清楚，当我们把合理的“证据”摆在他们面前时，会远远比“这件事很难”这样的话有说服力得多。甚至我们可以把想到的评估方式先让他们进行选择，并和他们商量下一步前进的方向。
完成评估后，我们需要对接下来做的事情设定一个范围，这是很重要的，因为很多的需求往往存在大量的不确定性，如果我们任由这些不确定性存在，反而会加大实现的困难度。想想在我们解决问题的过程中，不避免会遇到各种各样的困难，可能一时还解决不了的，这时如果在需求层面还存在大量的不确定性，对自己心里上的打击不是更大么？或者是否都开始怀疑之前启动这个项目的必要性了呢？我们可以这么来做，首先和需求方详细沟通产品技术方案，明确各个功能点的优先级；在实现过程中，我们首先要保证的是完成那些优先级高的功能点。这样的好处是，如果对于一些优先级不那么高的功能点，我们一时没有解决思路，我们可以放心的把它们先放一下。这样更有可能让我们在完成的过程中保持良好的心态。
那么具体实施过程中，我们需要遵循什么步骤呢？
标签：需要,事情,挑战,如何,一件,完成,如果,我们,评估 来源： https://blog.csdn.net/zhanglehes/article/details/120459610
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。