如果你接到一个任务是做技术方案调研，请你一定要非常重视，因为你的工作将很大程度上决定这个项目未来的发展潜力，是做出花儿来，还是做进死胡同，你都将负有直接责任。这不是一份简单轻松的活儿，其实所有“打地基”类型的工作都是如此，但往往人们总是忽略了这个环节的重要性，匆匆忙忙就开始了，在错误的道路上一路狂奔。不幸的是，当发现问题的时候，可能因为项目过于庞大，想调头调整已经几乎不可能了，只能继续硬着头皮向前。

回想我自己的职业生涯，也有好几次技术方案调研选型没做好，导致后面的坑越来越多，有些项目迫不得已废弃了，也有些项目遗留到现在成为了耻辱柱。每次有同学喷的时候，我也跟着喷，假装我不是始作俑者😅。

所以这篇文章，就是总结了一些我认为该如何做好技术方案调研的经验，希望能够帮到你。

重视起来

做好技术方案调研的第一步，就是要重视起来！

这是一件非常严肃的事情，你一定要当成是一件正经的事情去做。有很多工程师（包括我原来也是），觉得技术方案调研不就是去网上看看资料，最多弄个demo，用业余时间抽空搞搞就可以了，这是非常错误的想法。你会利用业余时间去开发某个项目核心模块吗？我想不会吧。而技术方案调研的重要程度丝毫不亚于前者，一定要把这件事当成是一件正经的事情，保证有足够的精力和资源去做，不要再想着用业余时间凑合看看就好。

明确需求

是的，你没看错，很多人在技术方案调研之前，是没有搞清楚需求到底是什么的。不信你可以抓一个正在做技术调研的同学，问问需求到底是什么。为什么敢这么说呢？因为大部分开发者在正式开始做之前都不会认真地阅读需求文档，脑袋里通常只是大概有个印象要做什么，剩下的就是边做边看。

以前我就曾经犯过一个错误，当时产品经理跟我说想实现一个在线office word编辑的效果，在没弄明白到底要做成什么样之前，我就朝着在线编辑word文档的方向去调研了，对比了若干方案后跟产品一沟通，结果才发现产品经理想要的只是一个能够灵活定制的富文本编辑器，并不需要word那么复杂的功能。

什么叫明确了需求呢？

首先是脑海中要有画面感。想象一下最终做成什么样了，所谓的“以终为始”。如果想象不出来，那就是没搞清楚。

其次是要确保你跟对方理解的是一致的。多沟通，多聊，别嫌麻烦。

最后就是将需求点按照必要程度分类整理出来。哪些是核心功能一定要满足的？哪些是锦上添花最好可以有的？例如：

必须要满足：
1. XXXX
2. YYYY
3. ZZZZ

最好能满足：
1. AAAA
2. BBBB
3. CCCC

这一步的产出，对于后续开始正式调研筛选比较至关重要。

调研方案

总算到了该调研的步骤了，“哈哈哈我会！”，但是等等，这里也有很多需要注意的地方。

请一定按照下列顺序依次调研：

1. 大厂方案
2. 开源方案
3. 自研方案

上面列的每一步不一定都要有，但如果你想调研其中的某一步，那么一定先把前置的步给走完了。比如你想造个轮子自研一个，那请你先把大厂方案和开源方案先看了再说。为啥呢？因为这个顺序能够最大程度地保证调研的完整性，让你做到胸有成竹。

以上所有方案，在调研的过程中，你都需要结合之前总结的需求列表，依次对比确认是否能够满足需求。最好是列一张表，方便记录和观察对比。

除了功能需求是否满足外，你还需要考虑一些额外的东西，例如开发成本、维护成本、是否付费、定制化能力、稳定性、性能等等。

怎么看大厂方案呢？

注意，要看大厂，不要看小作坊。因为大厂业务量大，遇到的坑多，其次大厂的工程师人才密度大，如果有些问题他们都搞不定，那你大概率也搞不定（虽然很不愿意承认，但是这大概率是真的）。

你可以根据业务场景，筛选出几个典型的大厂方案，然后去针对性地研究。还是以前面的例子，如果想让你调研一个富文本编辑器。你可以想想哪些大厂的什么业务用到了富文本，比如腾讯文档、石墨文档、google docs、语雀文档等等。如果你恰好认识腾讯的同学，那你就可以直接问他，或者让他帮你打听一下腾讯文档用的什么技术。当然如果你谁也不认识，那也没关系，你可以去社区搜一搜或者问问其他人（比如v2ex论坛），通常都可以找到一些分享资料。

不过大厂的方案有时候也有一些坑，所以还是推荐尽可能多地打听打听，而且为了确保不出现偏差，至少看个3家以上的比较稳妥。

怎么看开源方案呢？

这里首推万能的awesome系列。github上有很多热心的开发者会将一些常见的话题整理成awesome列表，你可以试试用awesome + 你想要搜索的主题，例如：awesome rich text editor。比如这就是搜到的列表：

这么多项目，哪个靠谱呢？别看star，这玩意水分太大。看看仓库是否有人在不断维护（但注意分辨fix typo这样的维护方式），看看issue都有什么问题解决地怎么样了，看看文档是否详细是否容易理解，看看npm下载量多少。开发者团队信息也是非常关键的，如果这个项目本身是一个产品的开源版本，有持续稳定的公司负责更新，那这显然比某个个人项目要靠谱得多。

另外一个很有效的办法是向身边的大佬请教，如果你谁也不认识，也没关系，老办法，去社区上问问其他人吧（不得不说v2ex真是一个神奇的网站，或者去stackoverflow上提问题）。向他人请教的方便之处在于他会同时告诉你可以怎么做以及会有哪些坑，不过缺点在于得到的信息可能有些片面不够完整。

对了，开源项目别忘了关注一下license信息，避免以后潜在的法律风险。

怎么调研自研方案呢？

其实通常都不需要走到这一步的，如果你不小心走到了这里，请再思考一遍，上面的方案真的都不满足吗？如果你的回答是都不满足，并且非常确定，那也不必自我怀疑，勇敢造轮子吧，其实想想还挺刺激的。

不过这一步严格意义上说不算是调研，更像是出技术方案，这是一个复杂的话题，以后有机会再聊吧。

跑通demo

到了最后一步了，这一步也是很关键的，talk is cheap，show me the code！

经过前面几步选定了方案之后，一定要做一个小demo（有时候可能是若干个），证明你的方案是可行的，因为很多问题只有当亲自上手开发的时候才会被暴露出来。在实现demo的时候，你可以将重点关注在需要满足的需求上，而将其他一切无关的内容都简化或者省略掉，比如mock数据或服务、简化功能逻辑等等，因此理论上构造demo的成本不会很高，别担心。

除此以外，demo的另一个最大价值在于它绝对非常有说服力。这就好像一个创业公司如果不但有ppt，还能做出一个产品原型出来，那将会更容易引投资人。人这种动物，都是对看得见摸得着的东西更放心也更感兴趣。

还是以我个人为例，以前我调研技术方案没有给demo，对方总是跟我反复沟通确认，可一旦我给出了demo，对方似乎就立刻被说服了，效果就是这么明显。

ps：如果你时间充裕，最好对每种符合条件的可能技术方案都做一个demo。

总结

好了，以上就是我对如何做技术调研的经验了，总结一下：

1. 提高重视
2. 明确需求
3. 寻找方案（大厂>开源>自研）
4. 跑通demo

但愿下次不再会有人diss你的方案🤟。