当我们在做技术调研的时候，到底需要做什么？怎么做？

一、序

日常工作中，或多或少都会有接触到一些技术调研的工作，有些是亲自参与，有些是分配给其他人来完成。

技术调研的过程中，会碰到一些问题，并且解决一些问题。有些技术调研可以做的非常完美，得出的结论让人无可挑剔，但是有些就显得不那么严谨，总能让挑剔的人找出一些问题。

抛开技术调研，我们只看调研的话，在生活中就比较常见了。例如：计划旅行的攻略、挑选一件商品，这些都是有借鉴意义的。只是这些生活中的例子，是对我们自己负责，没有做好可能会影响出游的心情或者损失购买机会。

可在工作中，技术调研的好坏，能根本上决定了公司在做这个方向上的产品方案，所以，当被分配到技术调研工作的时候，尽力做到最好。

二、技术调研发生在什么时候？

既然是调研工作，那在现有的环境下，肯定不会存在确定的方案。有不确定性存在，才需要专人来做调研。

那么，什么时候会需要技术调研？

新技术。

“某人” 已经做到了，但是不确定实现细节。

想做 Xxx 功能，不确定能不能实现。

新技术没什么好说的，程序员的行业技术迭代快，今天出个小程序、明天出个快应用，就算只是拿 Android 来说，最近 Google 也要发布新系统 P、适配又多了刘海屏。

这些你只要耐心等，总有一些愿意分享或者乐意尝鲜的人，写出一片文章来分享出来。但是一般这样的文章，总有一些不足的地方，就是考验作者的水平，并且作者也只会站在自己的视角。而在公司为角度，需要确定的方案，而不是模棱两可的结论。

那些“某人”已经做到的功能，相信每家公司的产品，在市面上肯定不会是独一无二的，一定是存在竞品的。竞品也是在不停迭代的，有时候会有一些有亮点的实现。这个时候就会有产品经理跑来问你，这个 App 的 Xxx 功能，原理是什么？我们能不能做？我想再改进一下你看能不能做到？

最后一类，就是完全没有依据的，属于产品经理的创新功能。但是提出创新功能的人，并不了解提出的创新功能，是否能被现有的技术所实现，如果能实现的话，需要做什么？可能会有哪些限制？

这些，就是技术实现需要解决的问题。

三、开始技术调研

3.1 理解需求

理解需求说的非常的老套，但是它真的很重要。

在开始做技术调研的时候，一定要理解需求方的深层意义。明确这次技术调研的目的，它是用来实现什么需求？

你只有理解清楚需求方的真实意图，你才能更好的进行技术调研。

但是既然技术调研充满了不确定性，所以一个详细的功能需求，可能并太不适合技术调研，你可能更需要的是一个泛需求。

举个例子：

“小程序-王者荣耀群排行” 的功能，表现出来就是有人分享小程序到微信群里，你进去就可以看到群成员的排位排行信息，这是产品经理所看到的功能。

此时，产品经理提过来的调研需求是“分享到群里的小程序，能不能拿到群成员的信息？”。你看看官方文档就可以回答“做不到”。再问“为什么它可以？”，“大概是腾讯内部产品有私有接口？”。

可这并不是产品经理的核心目的，核心目的是想建立分享人和微信群成员的关系。

那你接到这样的技术调研，你首先看完文档发现无法“直接做到”。但是你发现可以在小程序中，拿到几个数据：谁分享的、分享到那个群、谁进入过这个小程序分享。也就是说，我们只需要通过服务器将这三份数据，建立一个基本的联系方式，我分享出去的这个群，你曾经进来过，我们之间应该是有某种联系的，这其实是产品经理的真实需求。

所以，在做技术调研之前，充分的理解需求，想清楚需求方到底是想干什么，更深层次的需求到底是什么。

3.2 合理安排时间

技术调研，一定是不确定的技术点，而技术调研的过程，也是一次对未知技术的学习过程。

合理的安排自己的时间，是非常有必要的，否则很容易的沉迷在未知中，无法自拔。要时刻谨记，这是一项工作，是需要有 Dealline 的，无论成或不成，都需要在最后时刻，交出一份调研的反馈。

3.3 调整心态

技术调研的始发正是因为技术实现的不确定性以及当前团队技术储备的短板上，所以才需要一次技术调研。

有时候，技术调研真的是没有结果的，当你找不到解决方案的时候，不要沮丧，这都是正常的，调整好你的心态，才能应对这些不确定。

我们并不需要把技术调研当成一次找解决方案的过程，有时候严谨的证明“无法实现”也是一个优秀的技术调研。

3.4 尽可能搜集资料

一定要尽可能的搜集资料，通读它们，可能解决方案就在某些细节中。

当你在公开的现有资料中，找不到答案的时候，你也可以选择阅读源码（如果有的话），一些开源项目，文档并不一定尽善尽美，但是因为已经被开源了，我们可以很方便的阅读它的源码。在源码中找答案，要知道源码是不会骗人的。

针对一些竞品调研的需求，如果找不到头绪，其实还有一条路可以走，那就是对竞品进行逆向分析。通过阅读逆向后的代码，找到实现的思路，也是一种不错的方法。

其实这些都是方法，都是术，核心就是在你的能力范围内，找到所有可以找到的方法，来完成这个调研工作。

3.5 向他人寻求帮助

当你的调研工作，因为一些技术细节无法推进下去的时候，你也可以考虑寻求其他人的帮助。

虽然正是因为你所在团队没有此方向的技术积累，才需要进行调研，但是并不代表团队成员无法对你提供帮助。每个人有自己的涉猎面，有自己的思考方式，多和其他人沟通，可能能带来一些灵感让我们将调研的工作推进下去。

当团队成员无法提供帮助的时候，也可以在网上寻求别人的帮助，加社群、发文章都是一个不错的办法。但是要记住提问和沟通的技巧，大多数时候，别人只能给你提供思路，而不是完整的解决方案。

一个带着套路的提问方式是：

我想做 Xxx 功能，xyz 已经实现了，但是我并不知道细节。我已经尝试了 1、2、3… 种方式，但是没有符合我的预期，你有什么更好的想法吗？

这样的套路提问法，表达清楚你想做什么，你已经做了什么努力，但是没有成功，那么对方在这个具体的上下文语境中，有没有什么好的想法或者思路，来解决这个问题。

重视别人的思路，有时候可以让你茅塞顿开。

四、反馈调研结果

技术调研之后，无论是找到了解决方案，或者被认定此方向行不通，都一定要公开的反馈出来，让大家知道结论。

一般来说，我比较看好的反馈形式有：

4.2 分享会

对于一些大型且完整的技术调研，我倾向于开一个技术分享会。当然，分享会需要有完善的 PPT 和配套的说明文档，这些都是需要提前整理和准备的，有时候在这个整理的过程中，你又会发现新的思路。

分享会不仅可以增强团队的技术氛围，不仅可以提高了自己的演讲和教与授水平，同时也将新的技术知识，在团队中和大家同步，相信不会有人拒绝一场干货满满的技术分享会。

有心做好分享会的话，我希望你不要仅仅把它当成一次调研反馈，而是当成一次真正的技术分享来做。这样大家也能从你的这次调研上学到东西，而不是跟着你的思路得到你的结论。

4.2 文档+邮件

当调研的题目非常的单一的时候，组织一场分享会，无疑是耽误时间的，这个时候可以选择更轻量级的形式：文档+邮件。

整理出一份调研文档，并以邮件的形式发送到大家手里，和大家同步此次调研的结果。

无论使用哪种方式进行反馈，最好都要落到文字上。

五、反馈的内容

你最终选择使用分享会，或者是文档邮件的形式，在你反馈内容中，都一定要讲清楚技术调研相关的所有细节，以保证读到此文档的人不会对你想表述的内容有疑惑。

具体的反馈内容，我觉得一般需要包括：

技术调研的核心需求。用来干什么。

你都从什么渠道收集到了那些有效的资料。

做了那些尝试，如果成功，最终选择的方案是什么，并说明原因。如果失败，也要说明做了那些失败的尝试。

如果找到解决方案，需要说明使用此方案的前提条件、使用场景、会不会有潜在的问题。

调研的时候，碰到的问题，思路如何。

调研反馈之所以要写的这么详细，一方面是为了让大家知道此次调研的结果，你的思路是什么样的，你做过什么尝试。另一方面，也是看看别人在你现有的调研基础之上，有没有更好的解决方案。

不要在意别人对你调研结果的质疑，觉得他是在质疑你的能力，要有独立完整的自尊体系，不受他人所影响。有人提出问题，这说明有人在认真的思考你的问题，和别人辩解的过程，也是让你和大家更清晰的理解此次调研的过程，道理是越辩越明的，技术也是一样。

六、写在最后

当你的 Leader 将这件调研任务分配给你的时候，大多数情况下是对这件事情有大概了解的，正常来说是符合你当前的技术水平，或者稍微垫垫脚能够得着的，所以遇见问题，不要轻言放弃，尽力的解决吧。
当我们在做技术调研的时候，到底需要做什么？怎么做？

原文 当我们在做技术调研的时候，到底需要做什么？怎么做？

参考文献

[1]技术调研的模式