攻坚性项目，遇到的同学不一定很多，但一旦遇到都会是很棘手的问题，一般都伴随着巨大的压力，往往有种不成功便成仁的悲壮。
1

前几天，星球里也有同学分享了一个类似的项目，其中遇到了类似的问题。

我想起2017年的时候，自己也做过一个类似的项目，是一个对外的大数据分析系统，那个项目对于我来说，也算是个攻坚性项目了。

在此之前，我做过存储系统，当时接手这个项目的时候，以为自己可以很容易搞定，存储嘛，总有很多东西相同的，但后来才发现事情比自己想象的要复杂的多。

因为不单需要考虑存储选型，考虑SQL解析，数据计算，数据可视化，查询交互转SQL语句等事情，还要考虑上报链路的稳定性，可靠性等，其实是个很复杂的系统。

当时我们的团队里面没人有相关的经验，我leader 也以为我本身做过存储，应该不是很大的问题。对于这个系统的期待也比较高，对时间周期，项目质量都有一定的要求，我当时也傻，就这么接了下来。

然后我花了一周多时间去做调研，才发现实际情况比我预想的要复杂的多。这个时候，我开始意识到，如果按着原计划走，一定会挂，一定完成不了任务。

所以我就在思索怎么去做这个事情。我意识到，这个项目本身的复杂度要远远高过原先的预估，远远高过我的判断和我leader 的判断。

我自己由于进行了调研，已经意识到系统的复杂性，但我的leader 没有意识到，并且他坚信这个事情不是很复杂，按他的说法，如果我搞不定，他就准备找其他人搞。

这对于我而言，是很棘手的事情。如果我直接跑过去跟leader说这个很难 ，要更多的时间和更多的人力，势必引起争执，而且当时的我也没有很好的办法可以证明这个系统会有多复杂，只是从直觉来判断，比预想要复杂的多。

我只能按原计划正常地推进这个事情，拉上我团队的同学一起进行系统调研和系统选型。

我很关注实际遇到的困难和对应的解决方案。每当有新的进展或新的困难出现的时候，我都会第一时间找到我的leader, 跟他汇报目前的进展和遇到的困难，并且详细描述问题是什么，我们准备的解决方案是什么。

说实话，当时对于不少的难点，我们心里也没底。比如当时做系统选型，有不少的开源系统，各有优劣，而由于产品本身没有上线，我们对未来的需求也不能够准确把握，纠结于不知道应该选择哪个系统，才可以保证扩展性和性能等指标。

这个过程中，我不断地跟我 leader 沟通。当然不是跑过去跟他说 “老大，我们遇到这个困难了，不知道怎么解决，你看看怎么办？” 如果是这样，估计他很快就换人了，他会觉得你是一个问题制造者，不是解决问题的人。

我的做法是跟他汇报目前的进展，遇到的问题，并且详细描述问题的细节，最后给我们的解决方案。有时候没有解决方案，就给出后续执行的一些想法，比如说找某某某专家请教，比如说去哪里找哪些资料来佐证各种猜想等。

在这个过程中，我leader 也真实地感觉到了这里的困难和实际系统的复杂性，他自己的预期也在不断的调整。

最后，虽然我们的项目没有取得预想的成功，但我们那次的考核还是不错的，而且还给我leader 留下了不错的印象。他觉得我的技术能力还不错，能在一个陌生的领域一步步地探索，一步步地给出解决方案。
2

后来我去总结这个项目，我发现这类项目，需要关注两个方面：一个是项目本身，一个是人。

一般性项目，大家都很熟悉，给出的时间预估，人力预估，困难度预估都是比较准确的，只要定期地汇报项目进展就行。

但攻坚性项目就不一样了。即然是攻坚性项目，那肯定是团队不熟悉的领域，团队里面肯定也没有擅长这方面的专家，要不就不需要攻坚了。

这个时候，大家对于系统，对于项目的预估大概率是不准确的。技术人员都会过于自信于自身的能力，对一个陌生的方向，总是会过于轻率地给出自己的预估，觉得没有那么难，就像现在很多同学看待机器学习这个领域一样。

这个时候，人就是特别关键地一环了，特别是你的上级或者是关注这个项目的其它领导，一定要及时地控制好他们的预期，要及时地调整好他们的预期。

攻坚性项目，作为项目执行人的你，肯定也是边走边看的。

你没办法一开始就给出一个完整的项目路径，完整的项目预估。

自己的认识和对系统的预估也是随时在发生变化，随时在调整的，所以你也要随时地跟项目相关人同步进展，同步遇到的困难，并且学会控制他们的预期，降低他们的预期。

实际汇报地时候，不要做抱怨者，也不要做问题制造者，没有人会喜欢的。

我觉得比较好的汇报方式是： 当前的进展，遇到的困难，对于困难的解决方案或自己的想法，需要给予的资源支持等。

你要成为发现问题并解决问题的人，而不是发现问题，制造问题的人。

大家如果有遇到类似的攻坚性项目，记得一定不要闷头苦干，一定要保持跟项目相关人，特别是自己leader的沟通。

工作的结果其实有两部分：一个是实际的产出，一个是考核的结果。说句政治不正确的话，项目产出是属于公司的，考核才是你自己的，所以大家要特别关注这个问题。
以上是自己的一个项目经历，给大家描述了当时的一些情况，也给大家分享了那个项目给我的启发和收获，希望能给大家带来一些帮助。

前几天看到一个博文，里面说到了技术知识掌握的三个层次。我觉得划分的挺好，而且跟我自身的理解也很一致，所以就想按着这个划分，来写写自己的一些理解了。
1. 第一层次 what

what — what is it ?

这是最基础的层次，如果这个层次都达不到，那做技术工作几乎是无法胜任的。

顾名思义，在这个层次，你需要了解一个具体的技术是什么。

对于语言来说，是一个语言的基础语法。比如赋值语句，循环语句，变量的定义，类的定义，相较其它语言的一些独特性等。

对于基础知识来说，比如操作系统里面，线程，进程的概念，锁的概念；比如数据库里面，数据库表的定义，视图的定义，主键索引，辅助索引等。

对于一个框架来说，比如框架由哪些部分组成，能够提供哪些功能，有哪些API，有哪些类。一些常用的API或类适用于什么场景，需要怎么样的配置和传入怎样的参数等。简单来说，就是要会使用这个框架。

当然，一个框架有很多功能，不一定要全部掌握，但基础的，常用的，还是要会的。语言也是一样，对于很生僻，几乎不怎么用的，没掌握问题也不大，但基础的，常用的，就一定要掌握了。

以上都是特定领域技术知识的一些基础概念，掌握这些是达到第一层次的要求。

按照这个标准来说，大部分的程序员，都还处在第一层次，还在第一层次挣扎。

达到这个层次，做一个一般的程序员应该是没大问题的了，去面试，去到一般的公司，问题也不大。

很多同学在工作一段时间后，达到了这个层次天花板，然后就觉得自己没有提升了，也不知道怎么提升。这个时候，你需要做的不是转换方向或者寻求其他，而是应该开始考虑进阶第二层次了。
2. 第二层次 how

how it works !

顾名思义，它是怎么工作的。

比如 Java ，你写完一段Java 代码后，编译器会解析你的代码，将其转换成为字节码，然后虚拟机会装载字节码，并开始执行起来。

这里，你需要知道虚拟机是怎么运作的，怎么装载字节码，怎么分配内存，怎么回收内存等。

再比如 C／C++ , 你需要了解变量的内存是怎么分配的，内存是怎么布局的，指针在语言的实现层面是怎么一回事。

对于操作系统，数据库就更重要了。

在第一层次，你知晓了线程，进程的概念，也会用程序去fork 线程和进程。在第二层次，你需要知道线程，进程在操作系统里面是怎么一回事，是怎么工作的，用操作系统提供的观察工具来观察会有怎样一种表现，比如进程的调度，锁的竞争，CPU的消耗，等等。

第二层次是一个很宽泛的层次，细致来看，可以再分解出很多子层次。

比如，对于一门语言，框架，底层系统的运行机制的了解，细分下来，可以细分出很多不同的小层次。有人可能只是从原理上了解；有人可以深入到源代码的层级；有人除了源代码还可以根据运行表现推导出具体的实现。

我觉得能够从第一层次进阶到第二层次，一个人的技术生涯就可以被极大地延长，比如说，技术可以做到 40岁甚至 50岁。

所以在第一层次的同学，一定要想办法进阶到第二层次。
第三层次 Why

Why — Why is it like that 。

如果能到这个层次，我觉得对特定技术知识的掌握是到了一个很高的层次了。

举了个例子，语言的设计。一开始的时候有Ｃ语言，后面为什么发明了C++，有了C++之后，为啥有要来一个 Java ？ 这是个可以深入思考的问题。

C++ 设计者甚至专门写了一本书来阐述背后设计的思考 :《C++语言的设计和演化》。 如果你能看懂并理解里面的内容，估计对程序设计语言的理解会深入很多。

对于操作系统，数据库，也是一样的道理。 你会去思考，为啥需要引入进程，引入线程的概念，他们是为了解决什么问题，如果不这么设计，会有更好的设计方法吗？

对于语言的各种框架，也可以进行这种思考，甚至可以拿同个领域不同的框架来进行对比分析。

当你可以站在设计者的层面去看待一个语言，一个框架，底层系统的时候，你的理解绝对是要超越很多人的，而且对这部分知识的掌握也要超过很多人。
最后

以上就是我理解的技术知识掌握的三个层次。这个划分不是什么官方标准，而是我个人经验的一个总结。这个划分，我觉得还是比较符合实际情况的，对于一些同学应该会有实际参考的意义，至少可以对比下自己对知识掌握的一个程度，也可以知道后面要往什么层次去进阶。