作者：Limber Cheng
在本章中，我主要谈一谈关于两种项目的操作：其一是策划、文案类，即非技术层面的运用；其二是研究应用类，即技术层面的实施方面。
麦肯锡(Mckinsey)有一个经典的工具包模型的办法
太阳底下没有新鲜事，他们累积了大量的项目分析，凡事遇到了怎样可以使用哪一种策略，并且其回报率是怎样的等等十分详尽的策略分析，并且很骄傲的认为掌握了这套工具包策略就可以有非常高效的解决方案。而确实，麦肯锡的做到了世界第一，甚至做成了一个传奇。咨询公司有着高度的案例分析、案例整理能力。就像我和高盛的投资分析师聊天的时候感慨的，高盛用人工智能、机器学习来为他们进行投资分析的一个大前提就是，高度的模块化，或者说海量的资本积累——海量的案例以及数据积累。
这样高度的模块化的结果就是，过往的历史十分的清晰。一切皆可查，在我需要这些材料的时候，可以用最快的时间将资源整合到我的手上。而这也是项目的第一步，获取大量的相关信息。并不是一个人对于这个项目多么的熟练就能够忽视一切的撸起袖子干。得到信息之后，需要快速的在脑海里进行一个简单的整理。而整理的速度越快越好。
获得信息、整理信息的目的，都是为了建立一个简答的模型。比如说一个花园应该怎么进行建造，我们在研究了大量的信息之后可以有一个很简单的框架。而用框架完成框架。其中仍然有一个实际操作性的问题，那就是如何“浮”起来。
学过游泳的人自然不会忘记，第一次放开扶手向前滑动的恐惧——道理我都懂，可是就是不敢。岸边或者漂浮物的安全感或者说扑腾在水里的那种恐惧感让我们开始害怕，可是自己在此之前，学了动作，做了热身，为的就是这么一下。而在这里的时候，我们会开始犹豫。而做项目的时候也一样，害怕一个开始，尤其是在研究了大量的背景材料之后，这个时候，如果有一个老司机带的话，就完全不同了。老司机会像庖丁解牛一样，告诉你应该怎么开始，甚至直接带你走，你在旁边有样学样。然后慢慢的带起自己的信心，再慢慢的带动自己所研究得到的模型。
在实际操作的时候，往往我们会忽略一个很简单的事实，理论和实践的一个略微的差异。很多时候我们看到的都是什么“你想的简单哦。”的说法，觉得理论一定会比实践更轻松，毕竟空想而已。而一些复杂的项目则不是。
最近出版社想请我写一本书，这本书的理论部分相当晦涩难懂，一开始出版社关关看到我的书就直接蒙圈了，表示这样子根本不会有人买，主要就是大量的抽象的理论。而后来我的做法就是，跳出这个怪圈，或者说跳出这个诡异的教科书设定。就很务实的，我想要完成一个东西，我需要什么？在我介绍需要的部分的时候，大量的解释能够做的方面。但是即使如此，还是十分难懂。最后的做法干脆简单，就是让人直接上手做。因为如果连问题本身都不明确，或者连目标本身都不知道是什么，那么寻求帮助又有什么用呢？这种就是一种很经典的策略“Learning By Doing”的策略。这种策略是面对那种高度依靠意会的东西，比如语言。在没有学会几句外语之前，就得努力的说些东西，或者写点小句子。小的时候大家做木匠活小桌子小椅子，也是这般起色的。而编程也是这种东西，学C++的刷完了C++ Primer，想要一份C++的Project，而最后甚至都不知道怎么写，明明知道了class，知道各种东西的写法，可真的要写project却不会。那么C++本身不算什么东西，而那种离开安全区的勇气或许直接用横冲直撞的Learning By
Doing的策略，反而会更好
我在实习的时候，听到一种说法，“年轻人最宝贵的东西是他的品质，成事是矢志不渝的愚者。”我的老师的说法更为偏激，只要一个年轻人有足够的韧性，是否有天赋似乎不算什么，因为以他的本领，年轻人能取一瓢饮足以受用终身。就如我先前提到的米开朗琪罗一般，他的天才是基于大量的素描的练习上展开的。这不间断的基础的练习体现了一个大师的功底或者素养。而一个做项目的人的基础，就是大量的摄入资源的能力。一个程序员最有价值的地方，就是自己能够独立完成一个项目，而不是完成一个个复杂的功能。
项目感，可能是最重要的东西。
关于这篇文章：
“这篇文章由我一位目前在英伟达实习的同学撰写，我现在代其将这篇文章整理后发布在这里，著作权归原作者所有。”
