技术调研/预研
技术方向需要通过技术调研、技术预研来帮助团队成员逐步认识、理解和明确，这是一个必然的过程，技术团队领导应充分重视并直接参与。
本章主要介绍和解决以下问题：
·为什么需要进行技术调研。
·什么是技术调研，具体的思路、过程是什么样子的。
·什么是技术预研，具体的思路、过程是什么样子的。
·其他相关讨论。
4.1
概述
4.1.1 技术调研和预研的差别
技术调研和技术预研是存在一定差别的，主要是立项时所处的环境、目的等存在差异，总结起来可以简单用一段文字描述：技术调研是针对粗粒度需求实现方案进行的研究，很有可能对所需技术根本不清楚，需要通过调研项目来完成技术了解、技术选型、技术可行性分析、技术方案设计等工作。技术预研是针对细粒度需求的实现方案进行的预先尝试，主要针对的是通过技术调研所选择的技术，同时结合我们产品化时的实际需求，对实现时存在的不确定性因素、细节等进行预先研究、尝试，从而减小产品化过程中的技术实现风险。
正是由于所处环境、项目目的的不一致，由此产生的技术调研报告和技术预研报告的内容也会差别较大。技术调研报告首先阐述从需求整理到明确方向再到搜索技术调研方案及初步筛选的过程及结果，接着介绍具体的测试方案确定、测试环境搭建、测试用例编写及运行的过程，最后针对调研项目中得到的一些实际业务场景下的运行数据进行对比、分析，通过解释数据产生的原因来明确下一步计划。技术预研首先根据细化的需求（有可能是产品化需求的一部分难点需求）对系统整体进行定义，接着通过列举方案明确本次预研论证过程，再通过论证过程反复执行列举、论证、推翻、再列举这一过程，最后是对本次预研获得的最终结论进行总结。
从最终的输出报告来看，技术调研一般针对每一项技术都会有一份单独的报告，然后汇总成一份调研报告（对各项进行汇总、对比、总结），而技术预研一般只有一份报告，通过这份预研报告说明预研项是否成功，是否可以采用该种方案、技术并进行下一步的产品化立项。
4.1.2 参与调研和预研的重要性
对于一个技术负责人来说，职责范围内有许多工作，比如组建团队、了解产品，但更重要的是设计靠谱的技术方案。故首先要了解系统存在的问题、产品未来的走向和技术团队的现状，针对这三点，亲自设计一个最优的技术方案。
为什么技术负责人要亲自设计呢？因为技术负责人亲自主导或参与了设计，就能有针对性地去解决问题，即便将来系统遇到瓶颈，也能更好地优化或者重新设计。不要用各种理由来回避做这个事情，在任何阶段这都很重要。再者，如果别人问你，你的设计和其他公司的设计方案有什么区别，或者是否可以用开源框架搭建起来从而替换你们自主研发的框架，你怎么回答？你如果没有对类似的技术、框架进行过调研，怎么能够准确地回答这些问题？如果没有对技术难点进行预研，你怎么敢把设计对应的需求写入产品化需求？你不怕最后实现不了吗？
为了更好地设计系统、理解技术，你一定要组织调研项目和预研项目，这是因为你或者团队不可能什么技术、框架都懂，更何况技术发展非常快，只有针对技术进行调研、预研，才能够真正跟上技术发展的潮流，否则终有一天你会被技术岗位淘汰。
4.2
技术调研
4.2.1 技术调研思路
到底怎样做才算是完整且优秀地完成一次技术调研？
教技术的书籍很多，但是教调研的书籍几乎没有，即使有也不会教那么细。我曾因这类工作而彷徨、受挫，现在又看着新人彷徨、受挫，于是就有了想法进行尝试总结一个范式出来。我觉得想要做好一个技术调研项目，要了解需求、挑选技术，还要进行技术可行性分析、测试、输出分析结果。
1.了解动机
除了自己发起的技术调研，其他技术调研也都需要先了解需求。“了解需求”这是一个人尽皆知且每个人在技术调研前都会去做的一件事。但不夸张地说，在这个阶段栽跟头的人最多。
很多人，特别是新人，在这个阶段出问题的原因大概有以下几点：
·畏畏缩缩，担心一开始问太多会显得自己很无知，担心对方轻视自己；
·听到几个关键字就以为已经了解需求，没有在意对方说的一些细节；
·在对需求有疑惑的情况下还硬着头皮做，缺乏沟通意识；
·没有分阶段与需求方沟通，可能在快完成时才发现需求理解错误要推倒重做。
收到调研需求之后，我们需要整理并明确整个调研项目的背景。为什么会有这个技术调研项目存在？这一点肯定是有答案的，例如不满足用户的高并发需求、不满足用户对于各种Chrome浏览器的支持。明确了用户背景，就很容易描述该项目提出的背景了。
2.明确目的
了解了调研动机之后，接下来，需要明确本次调研项目可能涉及的具体技术内容（可以不明确，通过模糊搜索方式进行初步筛选即可），确定调研过程中需要对各个技术的差异点、技术实现原理进行总结，并通过测试数据、数据对比及原因分析，分析哪种技术或者框架适用于用户提出的实际需求。这些都是调研的目的。建议你在这一环节增加提问方案，自己给自己提出一系列问题。
调研的过程是怎么样的、为什么选择这些技术作为调研方向？
1）这些技术分别是什么？
2）技术调研方案、用例分别是什么？
3）各个技术或框架之间的区别是什么？
4）各个技术在通用场景下的优缺点是什么？
5）各个技术在用户提出的特定业务场景下的优缺点是什么？
6）根据得出的测试数据，为什么会有这样的结果？
针对这些问题，我们可以进一步明确在本次调研过程中，需要获得以下数据和内容，才能回答以上这些问题：
1）总结各个技术或框架的实现方案、细节、原理；
2）记录调研过程中的各个细节；
3）明确调研测试方案、测试用例；
4）列举各个技术之间的区别；
5）记录测试数据并从原理上解释；
6）列举各个技术是否适用于业务场景；
7）为技术预研项目输出调研结论。
3.确定步骤
在充分了解需求的前提下，调研本身会显得轻松点。
需要注意的是，进行调研时要合理安排时间，调研过程往往伴随着对新知识的探索，很容易“沉迷于学习”。别忘了这是一项工作。
个人有个小技巧，按照以下步骤来做往往效果不错：
1）尽量多地收集各种方案和资料；
2）迅速粗略地过一遍上述方案和资料，大体上总结出几种可能合适的方案；
3）针对几种方案，一边调研每种方案，一边做笔记；
4）最后拿着笔记做最后的横向对比；
5）得出结论，同时因为做了笔记，反馈的素材也有了。
以上是关于“如何做”。需要说明的是，这只是我的个人习惯，你有自己的做事风格更好，没必要强行一致。
还有一点需要注意的是，千万不要埋头苦干。“沟通”应该是贯穿始终的一件事，前面也提到了，对需求的理解偏差可能会导致整个调研工作推倒重来。那么该如何沟通，以及沟通些什么呢？
对于第一个问题，如何沟通，我的方案是，阶段性地去跟需求方或者跟有经验的同事讨论。比如一个技术调研分为四个阶段，那每完成一个小阶段，就可以尝试去沟通一次（必须强调一下，规则是死的人是活的。假如对方很忙的情况下，你偏要强行打扰对方去沟通，或者一个很小的技术调研你也按阶段多次去沟通，就尴尬了）。
对于第二个问题，沟通的内容，我认为主要有以下几点：
1）对需求细节分别进行确认；
2）将自己的工作进度汇报给对方（这一点很重要，一方面是让对方知道你在做什么及完成到哪个阶段，另一方面是假如你路走偏了，对方能及时知道并纠正）；
3）将自己当前的工作成果告知对方。
一般来说，一个调研过程分为以下几步，这些步骤也应该体现在你的调研报告里：
1）调研过程介绍：对需求进行整理，明确调研的方向，初步筛选，选择技术调研过程；
2）调研技术简介：逐一说明调研技术的实现原理、规则；
3）测试环境：对测试环境进行说明；
4）调研技术测试方案：包括通用测试方案和业务测试方案；
5）调研技术测试用例：包括通用测试用例和业务测试用例；
6）调研技术测试数据对比/分析：包括对通用测试场景和业务测试场景的测试结果数据进行对比并分析原因；
7）调研总结：对业务方案进行总结，从性能、技术评测、需求方、产品化、综合等多个不同的角度评判调研结果，选择可以用于技术预研的技术；
8）列举现有不足和下一步工作计划。
注意，需要明确的是，针对每一种技术或框架，调研过程中应该明确采用相同的测试场景、测试数据、测试方案及用例，绝不可以有差异，否则调研结果本身就会受到质疑。
4.结论跟踪
做完技术调研后，一定要有成果。这里所说的结果可以是调研之后发现“某个方案是最佳的”，也可以是调研之后发现“尚无解决方案”，还可以是调研后对需求本身提出质疑。
反馈有几种常见的展现形式：
·比较大的技术调研可用PPT的形式展现出来。比如有同事调研“兼容Android6.0权限管理”，用一个PPT将技术方案的选择、6.0权限管理的原理、最终方案的选取等内容分享出来就特别好。
·假如是简单的技术调研可以以文档的形式展现，推荐用markdown来写，也可以github/gitlab直接展示。
·可以以邮件或口头的形式进行反馈。
个人比较推荐文档的形式，因为这适合大部分调研工作。反馈的内容有几点是需要写进去：
·简要说明下调研需求；
·介绍跟需求相关的前置知识；
·目前有哪些方案，具体分析各个方案的优缺点及适合的场景；
·技术调研的结果是怎样的，不可行的话是因为什么，可行的话说说最终决定使用何种方案（自己无法决定的话可以开个分享讨论会），并说说该方案跟其他方案比有何优势；
·假如是新库的引进，需要简要介绍该库的使用方法及内部原理；
·调研过程中碰到了哪些问题，如何解决；
总而言之，把一次技术调研当成一次绝佳的学习机会来做，那反馈的内容就不会显得空洞。
反馈的时机，需要在保证质量的前提下，尽量主动、提前向需求方或组内其他同事提出。一方面是你的反馈对别人而言也是一个学习机会，另一方面主动推送一件事是一种优秀的表现。
4.2.2 调研过程
一般来说，调研过程需要按照“需求整理→明确技术方向→搜索技术调研方向→调研方向初步筛选→选择技术调研方向→确定调研测试方案及用例→调研执行→调研数据对比→调研结论”这样的顺序，当然调研的执行过程也可以并行执行。
1.需求整理
我们首先需要明确这次调研背后实际的业务需求，比如说需要支持什么样的业务场景、是否需要支持横向扩展、业务的实际场景是怎么样的、是否包含高可用的海量数据读取等难度较高的技术、是否需要我们使用开源技术（因为可以看到源代码，闭源或者商用版本容易出现后续维护和费用问题），这些都是业务方会提出的需求。
我们需要将上述业务需求转化为技术需求，从技术层面理解业务需求，例如高可用就可以转化为“没有单点失效，任何一个单点都不会造成数据不可访问”，又比如是否需要支持横向扩展，可以转化为“数据动态分散在不同的服务器上，可以通过动态添加服务器节点增加系统容量”。
技术需求转化完成后，我们可以明确本次调研项目的技术调研方向。因为只有明确了技术方向，我们才可以进行技术选型，进而继续我们的调研工作。
注意，业务需求转化为技术需求后，最好可以组织一场内部的评审，喊上产品经理、技术骨干，一起讨论是否存在理解偏差。
2.技术选型
不知道你有没有遇到过这种场景：开发团队内有人不断高呼某某新技术、框架，想把最新、最热的技术应用到项目里。这些人可能是因为读到了相关的博客，或者是看到了Twitter上的讨论，也可能是刚刚在InfoQ的技术大会上听到了精彩演讲。开发团队开始采用这种时髦的新技术（或者软件架构设计范式），结果他们却没法更快开发出更优秀的产品，反而开发的速度降下来了，后续版本的交付也出问题了。有些团队甚至干脆专心修复Bug，停止开发新功能。这是为什么？这是由于没有根据实际需求进行技术选型。
一般来说，技术选型的决定方式有以下三种：
1）有的团队会根据社交媒体上的讨论来决定选择哪种架构；
2）团队会跟风走，哪个热门就选哪个；
3）有的团队坚持通过技术评估手段进行选型。
前两种方法没有评估在实际需求驱动下的性能数据，属于简单粗暴的方式，一定会为未来埋下隐患。第三种方式首先会明确该技术/框架所使用的需求范围，根据需求明确技术调研方向，然后通过技术评估手段进行选型，最终的选型结果需要需求提出方、技术调研方、技术专家代表等多个维度人员参与，以事实作为评判标准。
（1）先测试、研究，再决定
针对新技术提供的功能，在决定采用之前花一两天搭个原型，然后组织大家分析利弊。你可能会遇到若干能彼此替代的技术，可以让团队里不同人用不同的技术来搭原型。
（2）何时开始
原则上说，应当选择投资回报最大的时间点开始。大多数技术是用来解决特定问题的。你遇到了那个问题吗？那个问题重要不重要？会不会节省很多时间？新技术带来的好处能不能抵消学习成本和重做的成本？如果我们的开发速度从一开始就降低到正常水平1/2甚至1/4会如何？想想新技术还值得吗？
优秀的团队有更多自主权——一些团队确实比其他团队更快出成果，他们也更容易厌烦自己手头的工作。这些团队可以更多、更快地引入新技术，但这不是省略快速搭建原型或者黑客马拉松的理由。相反，如果这样的团队在交付上遇到了麻烦，一定要加倍小心。
（3）找到对的人
有良好技术背景的人——那些人了解不同的范式，理解编程的理论（算法和并发），受过良好工程文化熏陶，这样的人很少会去凑热闹。
有经验的人——年轻的开发人员更喜欢凑热闹。如果有多年的开发经验，见过许多技术，踩过许多坑，在技术决策时就更容易做出客观的判断。
（4）技术采用生命周期
技术采用生命周期，即Technology Adoption LifeCycle，是一个用来衡量用户对某项新技术接受程度的模型。这个理论最早源于1943年Ryan和Gross对玉米新品种的扩散行为研究，而后Everett M.Rogers提出了扩散曲线，并将采用者分为五种类型。
技术采用生命周期的形状是一个钟形曲线。这一曲线将消费者采用新技术的过程分为五个阶段，分别包括创新者阶段（2.5%）、早期采用者阶段（13.5%）、早期大众阶段（34%）、晚期大众阶段（34%）与落后者阶段（16%）。
·创新者阶段：有很多的坑，但却不乏众多爱好者乐于踩坑。
·早期采用者阶段：有一些开发人员在尊重自己的直觉和喜欢的前提下，开始使用该技术。
·早期大众阶段：各大论坛、技术会议开始纷纷报道，这时候需要慎重思考之后决定是否采用。
·晚期大众阶段：标准、社区已经完善，大部分人都在使用了。
·落后者阶段：除非万不得已，否则没人再用了。
我们的使命是使用创新技术并将它们应用在我们的软件开发过程中，并且能够解决新技术所带来的应用鸿沟，因此，处于创新者阶段、早期采用者阶段的技术不适合我们，因为它还没有形成完整的社区支持，已经处于落后者阶段的技术也不适合我们，因为我们已经有更多的选择了。
（5）何种方式
可以通过网络搜索（进入Google，搜索你选定的关键词，最好是若干个），找到国外专家推荐的相关技术，逐一记录。接下来，按照技术方向进行分类（很多技术或者框架的原理都是类似的，可以归为一类），然后按照某种条件进行筛选，例如按照开源协议的约束条件、宽松程度进行重点考虑，或者根据社区的热度进行筛选。
3.明确方案
经过前一步的挑选后，我们明确了技术选型，接下来，需要明确实现方案和测试方案。
（1）实现方案
实现分为设计、编码两个步骤，首先需要针对通用场景和业务场景分别进行设计。通用场景一般是针对几个技术的通用能力进行比较。以数据库为例，我们需要测试几种不同数据库的读、写能力，包括串行读/写和高并发读/写，这两点都需要进行测试程序的设计和编码。
（2）测试方案
测试场景分为通用测试场景和业务测试场景两部分，虽然分为两个测试场景，但是测试方案一般来说是一样的，差异点是执行场景、并发程度不同。还是以上面说的数据库测试场景为例，无论哪种场景，我们都需要通过执行SQL语句或者类似数据“增删改查”的方式进行测试，如果是关系型数据库，DML语句一般会涉及SELECT、INSERT、UPDATE等。
接下来是针对通用测试场景和业务测试场景分别设计测试方案。通用测试场景指的是针对数据库本身进行高强度的插入、更新、读取等单一操作测试，不需要按照实际业务场景的数据量，可以任意扩展，即通用测试场景不会对插入数据量、读取数据量设置上限。这里需要注意，数据表最好和业务场景一致。这一方案积累的数据可以作为通用场景下的对比基准数据，为后续调研报告提供支撑。
业务测试场景指的是完全模拟现有或者未来需要实现的业务的实际场景，包括业务流程、数据表结构、数据表的数据量等。在这里我们需要具体解释我们的业务流程，不要泛泛而谈，最好能够画结构图，把流程解释清楚，同时也要解释我们的数据表设计思路。
（3）测试用例
关于通用测试场景的测试用例，我们还是以数据库调研为例。这里我们可以列举出“只写测试用例”“只读测试用例”“只更新测试用例”三种情况，所以对于业务测试场景，我们需要根据业务的实际场景来操作，例如对读写并发这样的业务进行用例设计，需要开启多个线程或者客户端同时执行业务SQL语句。
4.执行方案
由于前一节中设计了测试用例，所以我们这里的执行方案就需要执行测试用例。当然，需要首先完成测试程序的代码编写工作，并完成单元测试。
在通用测试场景下，我们需要按照业务的数据表形式，在各个调研数据库中分别创建这些数据表。注意，这里只是确保数据完整性，并不一定是完全参照我们的业务实际数据表设计方式。针对通用场景执行插入、读取、更新操作，以每秒可以执行的原子化操作（TPS）作为对比值，例如读取1万条数据的测试用例执行、插入100万条数据的测试用例执行、更新1万条数据的测试用例执行。
在业务测试场景下，我们一般需要按照业务流程执行测试用例，例如插入、读取、更新操作是并行执行的，而不是像通用场景下只有单一操作。
无论上述哪一点，执行结束后的输出数据都需要保存下来，最好是采用图表方式进行展示。
5.讨论结论
调研结论是调研项目的重点部分，我们需要清楚地描述我们的数据对比以及结论。
我们首先需要对技术的设计原理、参数进行对比，以数据库为例，对比内容如下所示：
·是否开源协议；
·是否支持分布式；
·分布式设计架构原理；
·是否支持事务；
·数据类型；
·存储方式；
·查询方式；
·稳定性。
接下来，我们需要针对给定场景的对比测试结论进行分析并且描述清楚，列举每一项技术是否适用于我们设计的场景，并给出具体原因。
然后我们需要进行总结，需要覆盖性能角度、技术评测角度、需求方角度、产品化角度以及其他因素等。
·性能角度：分为通用场景和业务场景，描述哪种技术的性能最佳。以数据库为例，需要说明具体插入、读取、更新，分别哪种技术最强，差距多少，为什么会有这样的差距。
·技术评测角度：这一栏基本是对于技术的设计原理、参数这一块的综述，需要用简洁的语句描述清楚哪一种技术最适用，为什么；
·需求方角度：将用户提出的几种业务需求场景转化为技术场景后并进行描述，说明哪种技术最适用，为什么；
·产品化角度：如果技术不适用于产品，我们需要按照产品优先级来分析、处理问题；
·其他因素：针对一些不属于以上几个角度的因素逐一列举、对比、总结。
以上所有过程全部完成之后，我们需要选择某一项或某两项技术、框架、方案作为下一阶段的工作技术基础。下一阶段可以是预研项目，也可以是产品开发项目，我个人推荐是预研项目，这样的流程较为合理，风险较小。
4.3
技术预研
4.3.1 技术预研思路
在产品规划的指引下，难度较大的关键技术的预研将在项目立项之前以技术预研项目的方式开展。待项目正式立项后，难度较大的关键技术已经攻克，后续产品开发团队的职责是集中更多资源，在非常短的时间内开发高品质产品并推向市场。这就是预研项目的意义。
1.了解动机
立项预研项目之前，我们需要首先明确以下两点：
1）是否需要立项预研项目：你所困惑的是不是属于预研项目范畴？技术上一定需要预研吗？
2）是否有实际的需求：你目前技术上或者方案上满足不了了，必须预研？
立项预研项目一定是有背景存在的，大多数情况是当前的技术或者方案无法满足用户需求，或者一个全新的产品形态在产品经理脑海中出现，经过头脑风暴发现还存在若干技术或者方案选型难点，如果贸然立项，很有可能出现产品开发延期的情况。因此，需要在产品开发项启动前，明确存在疑惑的技术点。这时候，预研项目就可以启动了。
也有另外一种情况。在技术或者方案调研完毕后，我们列出了下一步计划，一般来说就是预研项目计划，即对调研项目所产生的成果物进行进一步的实践，通过局部实现方式验证调研过程的正确性。
无论哪一种，最终都来源于需求。没有需求，什么都不会启动。
2.明确目的
首先需要了解用户需求，例如用户提出需要系统具备横向扩展能力，这一点就是很明确的需求。了解需求后，我们需要对现有系统进行剖析，是否支持横向扩展，如果不支持，是哪里存在问题，逐个模块分析后找到最终原因。接下来需要对当前情况进行解释，最好配有设计图或者测试数据，这样可以让读者更加直观了解当前情况。
情况了解清楚之后，我们可以讨论、总结预研目的，例如提出一种新的系统架构方案、采用新的开源框架等，最终的目的是满足用户的需求。因此，不能满足用户需求的预研项目成果是无效的。
3.确定步骤
预研项目一般来说分为以下几个步骤：
1）搜索预研需求。
2）明确预研目的。
3）确定预研方案，需要针对各个方案（包含当前方案）进行各维度对比，指出每个方案的设计和实现原理，指出存在的不足。然后结合方案进行具体的实现，并测试数据。
4）根据方案的对比、测试数据对比，我们可以明确提出的方案是否适用于用户需求，如果适用，可以推荐进行产品化立项；如果不适用，需要找到备选方案继续预研。如果实在找不出来（这种情况很少出现），需要反思用户需求是否合理，可以继续采取头脑风暴方式。
4.3.2 预研过程
1.技术介绍
明确预研需求之后，我们需要对所选择的方案或者技术进行介绍，也就是定义和综述。定义指的是对基本概念进行介绍，而综述指的是对当前该技术的发展及应用进行介绍。综述应注意以下几点：
·技术研究设定的工作目标应可验证；
·明确技术适用的范围，以便于后续研发项目的可行性研究；
·指明研究的局限性，明确写出后续待完成及验证的研发工作；
·在进行技术研究时，应注意借鉴过程资产库中的经验库，以及可重用和通用的模块库等；
·当有多种技术路线需要研究、比对时，应在关键技术分析报告中对各技术路线进行对比。
除此之外，我们还需要对该技术应用的参考文献逐一列举，以说明自己是参考了大量论文或文章后才得到预研技术或方案的。
2.明确方案
这一环节我们需要列举所有预期可能满足需求的解决方案，重点说明需要被本预研过程验证的一个或多个解决方案，并说明其各自的优缺点，以及提供潜在改进方向和应用可能性。
明确方案也需要有大量的论证，为什么你选择了A方案，而不是B方案？它们两者之间的优缺点是什么？针对业务场景的适用度如何？例如对于分布式系统，我们可以列举单体型架构和微服务架构。两种方案列举后，我们可以将两种方案都实现并对比，也可以采用排除法。如果采用排除法，需要先对比两种方案，例如对比两种架构的优缺点。
采用哪种方案，不能只看技术先进性，还是需要结合自己的实际情况进行预研。注意，只有首先明确方案，才能执行方案。
3.执行方案
根据前面确定的方案，我们需要进行预研方案的论证，这个过程一般分为若干阶段，采用方案列举—论证—推翻—再列举，或者总体方案—模块方案等方式进行阶段划分。
执行方案的第一步是方案列举，这一步需要做到深入理解。如果你对方案的实现原理不了解，那么无论怎么解释都是很空洞的。第二步是论证，需要从整体开始论证，逐渐下沉到各个重要模块，只有重要模块论证通过，才能进入下一步。第三步是尝试推翻论证的结果，这一步建议召开部门内部评审会，让不同角色发声，你需要逐一解释。如果出现解释模糊的情况，那么说明你的方案存在疑点，需要回炉重做。只有这三步论证都通过，才能进入讨论结论步骤。
4.讨论结论
预研工作的输出为技术可行性分析报告（技术介绍文档、技术环境搭建文档、功能验证文档、性能测试），有优越性和风险性评估。着重探索和解决技术实现的可行性，使得能够在需要时为产品开发提供支撑。
输出的过程如下：
1）根据公司技术规划和产品研发确定预研技术方向；
2）收集和整理有关预研技术的论文、专利、标准，了解预研技术的现状和未来发展方向；
3）对预研技术原理、技术方案进行全面、深入的分析，关键技术进行仿真和验证；
4）对研究成果进行总结，形成专利、标准提案；
5）编写预研技术可行性报告，为公司产品规划和研发提供决策依据。
需要通过各种数据对比、架构对比、原因剖析等方式，给出被排除的方案的排除原因，对被选择的方案应明确说明其优缺点。
4.4
其他相关讨论
4.4.1 各种开源协议介绍
现今存在的开源协议很多，而经过Open Source Initiative（OSI）组织批准的开源协议目前有58种（http://www.opensource.org/licenses/alphabetical）。常见的开源协议如BSD、GPL、LGPL、MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。
这里我们来看4种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的开发人员/厂家参考。
1.BSD开源协议
BSD开源协议（Original BSD License、FreeBSD License）是一个给予使用者很大自由的协议。使用者可以“为所欲为”，可以自由地使用、修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但“为所欲为”的前提是，当你发布使用了BSD协议的代码的产品、或者以BSD协议代码为基础对自己的产品做二次开发时，需要满足3个条件：
（1）如果再发布的产品中包含源代码，则新的源代码必须带有原来代码中的BSD协议。
（2）如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
（3）不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件并进行发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者进行二次开发。
2.Apache Licence2.0
Apache Licence（Apache License，Version2.0、Apache License，Version1.1、Apache License，Version1.0）是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改、再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：
（1）需要给一份Apache Licence。
（2）如果你修改了代码，需要在被修改的文件中说明。
（3）在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。
（4）如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以更改Apache Licence构成。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
3.GPL
我们很熟悉的Linux就是采用了GPL（GNU General Public License）。GPL协议和BSD、Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码作为闭源的商业软件发布和销售。这也就是我们能用免费的各种Linux的原因。
GPL协议的主要内容是只要在一个软件中使用（“使用”指类库引用，修改后的代码或者衍生代码）GPL协议的产品，则该软件产品也必须采用GPL协议，既必须也是开源和免费的。这就是所谓的“传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，所以商业软件或者对代码有保密要求的部门就不适合集成/采用GPL协议作为类库和二次开发的基础。
其他细节还有如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
4.LGPL
LGPL（GNU Lesser General Public License）是GPL中一个主要被类库所使用的开源协议。它和GPL要求任何使用、修改、衍生自GPL类库的软件必须采用GPL协议有所不同，LGPL允许商业软件通过类库引用（link）方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生代码，则所有修改的代码中涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
4.4.2 对技术发展的预估
作为一名技术团队的管理者，你必须了解当前技术发展趋势，并能够对趋势进行分析，进而明确自己团队未来1年、3年，甚至是5年、10年的发展目标。要拥有这一能力很难，但是你不得不做到。
我们可以通过科技网下载所需要的论文，这一点可以帮助我们了解当前国内较新的研究成果。而对于国外论文，我们可以通过Google Scholar进行检索，也可以通过一些国外比较流行的科技网站来进行信息获取、知识学习，这些都有助于我们建立自己的知识储备体系，帮助我们完成对技术发展的预估。
除了搜索论文以外，我们也可以通过关注一些大咖或技术企业的公众号，了解最新的科技方向。还有就是技术峰会，这类需要自己筛选，有一些会议是以宣传自身产品为目的的，并不是为了做技术分享，这些需要自己体会。
4.4.3 开源的好处
在开发的圈子里，开源已成势，无论公司大小都在开源。个人开发者更不必说，github已是标配。而开源与使用NodeJS一样，对个人而言是潮流，对团队而言是一种技术态度。
开源这件事虽非洪水猛兽，但因为开源可能会为一些人转移公司代码提供一种正大光明之理由，从而对公司造成损失，所以在公司层面上很难说清利弊。但现在避而不谈开源就是掩耳盗铃。开发者及各公司使用开源软件的情况越来越多，使得对开源的贡献成为相当一部分技术人员的一种技术理想。他们希望从开源获得成就，通过捕获粉丝以获得崇拜感。所以，有的公司允许开源，有的公司不允许，也有既没说允许也没说不允许的。一般允许开源都会有相应审核机制，对开源的选择权主要取决于每个部门自己的考虑。比如现在的BAT，开源都有相应的审核机制。
开源不仅意味着公司技术有了影响力，而且开源后技术需求的输入会变多，外部会给内部提供许多技术需求，从而通过从外部推进内部加快技术产出与技术创新。创新后再回归到开源，进而构成技术闭环。需求持续输入可让技术像产品一样迭代升级，提升功能单一的技术生命周期；需求多样化可以提高创新能力，从而让技术更有生命力。
在获得影响力之后，简历的收集渠道会扩宽，会有同行主动给你发简历；同时也会给现在团队成员带来平台的成就感，也能让外界技术人员对团队成员产生认同感，这对于技术人员来说非常重要。
