如何做一件有挑战的事（一）

       工作中我们时常会遇到一些有挑战的事，如果处理不好，很有可能会打击自我信心，同时带来一些不利的影响。那我们该如何去面对这些有挑战的事情呢？本文从心态层面和技术层面具体谈一谈。

       首先我们不能潜意识认为所有的事情都是“容易”的，或者是“困难”的（潜意识有时是不对的）。我之前常犯这样的错，对自我的技术很有信心，这种信心可能是来源于之前了解过相关领域的知识，或者别人说很“简单”，或者只是盲目的想去“试一试”。还有一种情况是，一些“不成熟”的领导在分配任务时，会把任务的完成周期设定的非常的短，让你误以为这件事情很容易（否则为啥完成周期如此短呢？）。遇到以上的这些情况，我们首先要告知自我内心的是：“先平静下来，让我们先分析一下当前的状况，看看实际情况到底如何？”平静的内心是前提，也是我们必须要做到的。过于轻敌可能会带来灾难性的影响，因为一旦事情的难度超过了我们的预期，非常容易引起心理崩溃。 这里其实有心理学的知识，就像我们其实会对身边的人进行“打分”，当我们打不过“强大”的对手时，其实内心并不会太难过，反而如果打不过“弱小”的对手时，心里上反而会很难受，然而其实两者的水平可能是一致的，只是我们认为它们不同罢了。过于谨慎和担心也不太好，凡事的畏畏缩缩的会给领导和同事带来“这个人扛不住事儿”的不好印象。只有先冷静下来，不受外界压力的情况下，才可能做出理性的判断。在自己没有足够把我的前提下一定不能立即给对方承诺（很多产品经理非常push，需求都没写清楚就要求研发给出上线时间），而当前能给出的承诺是先花一段时间进行合理的评估，在此基础上再给出完成时间。

       那如何去评估呢？这和具体的事情有关。如果是一个系统的技术选型，那么我们就需要研究具体的业务，目前常见的业务架构种类。可以查阅网上的资料，或者和同事聊聊，一般都会有一些新的思考点，然后根据这些点进一步深入了解和思考。技术选型要解决的问题并非如何去实施这个功能，反而是如何做更好（功能，性能，可扩展性，可排查性），因此广泛的去了解是非常有帮助的。如果有时间，还可以去了解一些相近系统的设计方案，因为很多设计方式是可复用的。如果技术方案已经确定，那该怎么去评估呢？比如我们需要通过gpu对某一块代码计算进行加速，我们可以先去调研一下网上是否有开源的代码已经满足业务的需求，因为通过现成的代码可以快速的验证我们的期望是否正确（某些领域使用gpu计算的效果不如cpu）。如果没有现成的代码，那么我就需要评估一下做这件事情的代价，比如需要学习cuda语言的成本（nvdia显卡支持的框架），完成demo开发的成本。我们甚至需要多考虑一些，比如cuda语言和c语言的交互，虽然我们对c语言已经熟悉了。这些思考点需要和相关的同事和领导解释清楚，当我们把合理的“证据”摆在他们面前时，会远远比“这件事很难”这样的话有说服力得多。甚至我们可以把想到的评估方式先让他们进行选择，并和他们商量下一步前进的方向。

       完成评估后，我们需要对接下来做的事情设定一个范围，这是很重要的，因为很多的需求往往存在大量的不确定性，如果我们任由这些不确定性存在，反而会加大实现的困难度。想想在我们解决问题的过程中，不避免会遇到各种各样的困难，可能一时还解决不了的，这时如果在需求层面还存在大量的不确定性，对自己心里上的打击不是更大么？或者是否都开始怀疑之前启动这个项目的必要性了呢？我们可以这么来做，首先和需求方详细沟通产品技术方案，明确各个功能点的优先级；在实现过程中，我们首先要保证的是完成那些优先级高的功能点。这样的好处是，如果对于一些优先级不那么高的功能点，我们一时没有解决思路，我们可以放心的把它们先放一下。这样更有可能让我们在完成的过程中保持良好的心态。

       那么具体实施过程中，我们需要遵循什么步骤呢？