个人的一些呓语。其实标题也可以改为"论公司技术氛围的形成——'潜龙计划'的执行？"
1. 前因
规模比较大的传统软件公司，或多或少都存在如下问题：
- 技术相较于互联网公司而言比较老旧。
- 软件复杂性主要体现在业务逻辑性上。
- 多个部门技术重叠，但无法形成更高层次的有效积累。
公司高层领导通常也意识到了这类问题，问出了：
- 现在是对于这一些比较流行且能够切实解决我们所面临问题的一些技术，出现了多个部门各自为战——单独研究，只在部门内部使用。我们应该如何将一门大家都认为认可的技术路线形成高层次积累，避免出现你研究完我还是得从零开始研究一遍的问题？
- 是否是应该成立一个专门小组（采取内部提拔或者外部招聘）来研究这些技术，然后强制要求其他部门来必须使用这个小组的研究成果？
- 如果真的推出这个小组之后，又如何确保这个小组真的可以将技术落地下去，而不是最后列举一大堆客观理由来证明这个技术确实无法落地？
2. 上述方法为什么不行？
-
技术小组的目标来自管理层授意，技术突破可能被当作是一个任务，一个换取薪水的工作。
-
研究小组组员脱离公司的实际业务，研究成果必然理论化，缺乏实践检验，无形中增加落地难度。
-
外部聘请的研究小组组员短时间内不了解公司的实际情况，决策容易出现偏差（例如对业务研发人员水平和基础设施估计不足）。
-
采取专门小组的形式会导致出现著名的"岗位墙"问题。技术成果落地经常出现的一个现象就是"这是我们的东西你们拿去自己先研究下，文档啥的因为时间比较紧急还没来得及更新(必然现象，尤其是文档没有纳入KPI考核指标的前提下)，落地中的出现解决不了的问题你再来问我"。
这类技术小组研究成果落地过程中，研究小组成员不直接进入一线全程参与的情形，很可能导致遇到的坑大部分还是业务部门自己解决(毕竟软件开发中大量的成本是来自沟通的)，这样导致的后果一是研究小组错失了一次研究成果面对问题时候的优化机会，二则是可能出现业务部门因为遇到的问题过多转而使用另外某个开源解决方案（基于解决方案成熟度，上手难度等多方面的考虑）。
3. 方法(臆想)
在正式介绍方法前，容笔者论述一些个人看法：传统软件行业里所谓的新技术研究成果，一般很少是在技术深度上有所突破，往往都是将业界已经比较成熟的，在互联网公司已经开始大规模使用的技术进行熟悉，然后与本公司的实际业务场景结合进行的落地。
以上特色决定了：
- 我们对于技术可能并没有互联网公司那么深刻的要求(例如许令波老师去年出版的新书《大型网站技术架构演进与性能优化》中针对大促销里秒杀场景的极致优化)，我们的研究成果最开始很可能只是熟悉和了解相关解决方案，以及它可以被用在我们业务场景下的哪些位置。
- 相较于对于技术深度的挖掘，我们更看中技术在公司内部实际落地过程中问题的快速解决和相应解决方案的组织过程资产积累。
鉴于我们的需求，以及上面列举的"专门成立研究小组"可能存在的弊端，我们给出的解决方案如下：
- 让真正有热情的内部员工去执行技术的研究。
- 让研究组人员直接参与一线业务开发，全程跟随项目开发流程，参与业务调研和技术落地的痛点解决，尤其是在该技术在某部门内属于首次落地的情况下。
关于上面解决方案，让我们先从Why的角度进行讨论：
3.1 Why - 为什么需要富有热情的内部员工
- 这些人有着天然的动力去研究新技术，能忍受枯燥和牺牲部分私人时间来研究那些被其他人认为是小题大做的细节性问题，而往往就是这些细节性造就了技术专家和普通研发人员的差别。另外这些人天然具备知识分享的热情和动力，所谓”水满则溢“，这些人在吸收大量知识之后，有着天然的倾诉欲望，这又无形之中促进了技术在公司内部的普及和公司组织过程资产的积累，对于形成公司内部的技术氛围大有裨益。
- 这些人知晓公司的实际情况，进行技术落地过程中能进行更符合实际情况的技术抉择。
- 这些人的忠诚度高。虽然使用的技术深度上可能没啥亮点，但相信技术结合业务场景上的总结也是其他同类公司所急切需要的。
- 这些人更容易被公司内部的其他研发人员所认同(这一点需要结合下面要论述的"公司在其中的角色"小节进行讨论)，这会极大降低技术落地的难度。
3.2 Why - 为什么要让研究组人员直接参与一线业务开发
- 他们能够亲身经历技术在公司实际业务场景下的表现，然后进行针对性地优化，且因为是直接参与，问题的响应速度和质量方面会高出不少。
- 这些人的业绩指标将直接和所参与的项目组挂钩，因此有这份动力将技术真正落地。并且基于3.1小节第1条，他们会主动将解决的问题进行总结分享，促进技术在公司层面的积累，这将一举扭转传统技术改革方式——由之前的被动转变为主动进化。
4. 公司在其中的角色
上面解释了WHY的问题，接下来我们要讨论下这类背景下，公司应该做些什么？ 根据笔者粗浅的管理经验：
- 鼓励员工将日常工作和私下的学习努力内容分享出来，在此基础上筛选打造全公司层面的技术明星。这个过程可以适度的奖励，但不要过重，首先分享过程中的反馈本身就是一种奖励，二来我们的目的是筛选出对技术有热情的潜力股。
- 到合适的时机将这些人组织起来，形成一个虚拟小组（这些人在职位上依然属于各个部门，主要工作内容还是以部门内部的任务为主）。赋予相应的权利和义务(视公司和小组发展阶段的不同而不同)。
5. 理想情况
如果以上呓语能够成真，我们最终将收获：
- 一个非常具有活力的技术研究团队，
- 建立起公司内部良好的技术研究氛围，
- 比较高的新技术落地成功率，
- 技术落地的过程中还能为各部门培养出一批具备相应技术能力的人才，
- 对于技术的追赶不再始终处于被动跟随的状态，
- 公司在少量投入的前提下即可收获大量的技术储备。相较于至上而下的强制推动（指定一个项目组，指定一拨人——"你们啥也别做，就在这个项目里把这件事情给落下去"），本方法更为温和，而公司层面更多的是承担一个引导者的角色，所付出的代价很小（当然时间成本不在此列）.
6. 缺点：
事无完美，这个"计划"也存在如下问题：
- 可执行性。是的，笔者不得不遗憾地表示以上全是笔者自己的胡言乱语，未有实际落地。
- 耗时比较长。以上计划的实施注定是一个水到渠成的过程，急不得也急不来。
- 虚拟小组组员所在部门与虚拟小组组员职责之间的利益纠葛。这一点目前的解决方案是"个人主动的知识分享，以及个人对于技术落地过程中问题的解决和总结都能够增加其在公司范围内的技术影响力，而个人名声的增长反过来也增加所在部门与其他部门领导沟通时候的筹码。这样的一个闭环也就是所谓的正向循环"。
7. 结语
以上文字皆为笔者一人胡言乱语，且该办法充满了理想化的内容，适用范围有限，最终也只能说是技术推动方式的一类调味剂。
但如果有可能，希望从现在就开始播种，这颗种子一定会在某个时刻给与你惊喜。
网友评论