只是完成了需求，研发的竞争优势在哪里？

灵魂拷问：“只是完成了输入的需求，那你作为研发的竞争优势在哪里？”

初看这个问题，一脸懵。研发的职责不就是承接产品需求、按时按质量交付功能效果嘛。既然已经完成了需求，这个问题还能回答出什么呢？

什么是需求

首先，什么是需求？不翻书本上的定义，我们可以简单把需求理解为“用户的需要和要求”。比如：

功能的DAU上升10%；
提升网络传输安全性；
在公司的电脑点Ctrl+C后，在家里面可以Ctrl+V粘贴出来；
基于手机壳颜色调整UI配色；
刷1000个Q币；
去西藏净化心灵；
做一个淘宝/百度那样的网站；
等等等等。

需求自然是从用户(通常是非技术人员层面)角度来考虑的，它的重心是放在目标、收益这个层面的，重点阐述的是“为什么要做”和“做成什么样”。通过对这些内容的阐述，需求方可以调整优先级，争取到宝贵的人力资源和排期。
需求有一个核心特点，凡是能被提交到研发手里的，都会被认为是“可达成”的。俗称“这个需求很简单，怎么实现你随便–明天上线”和“我有一个绝妙的点子，就差一个研发”。那么，如果仅仅是按时按质量的完成了目标，对于需求方来说就是“符合预期”，自然也就是“是个研发都能做”，沦为耗材和工具人，确实没有什么特殊优势。
如果我们不满足于“符合预期”，那该怎么办呢？

需求的研发过程

从研发的角度讲，收到输入的需求后，直观的想法就是制定技术方案、立刻投入研发。需求的基本的处理流程可能包括以下环节：

需求沟通：明确输入方到底要干什么，确认需求的实现难度
* 用户的手机壳到底有多少种颜色？与UI配色的映射关系是什么
方案设计与评审：明确研发方案，识别各个环节的修改点和资源投入
* 如何获取手机壳的颜色
* 如何调整UI配色
研发实现与自测：按照研发方案，实现各个需求，完成自测
* 自测：在我的手机上能运行
QA测试与入版：重点验收各个功能是否符合预期，尤其是在极限场景
* 常规Case：套红色手机壳；套绿色手机壳
* 极限Case：套透明手机壳；套两个手机壳；不套手机壳；套半个手机壳
bugfix：线上badcase调查与修复

上面是一个基本的需求研发的过程，除了涉及到研发自身以外，还引入了需求和QA测试等团队。对于任何一个研发同学而言，都需要能够完成上述研发工作。

那么，针对本文的核心问题“研发的竞争优势”，我们该如何回答呢？

研发的价值

研发的优势，或者研发同学的能力，在已经交付需求的前提下，还能如何衡量呢？

代码数量？但从来没有拿代码行数来折算工资；
需求数量？不同需求的体量差异巨大，不能一概而论；
线上收益？直接影响就是旱涝不均，直接收益低的任务会被所有人排斥(磨刀不如去砍柴)；

既然上面这些都不是，那不如我们在深入剖析一下研发过程，还有哪些工作能力是研发所具备乃至仅有研发才具备的呢？

阶段	研发所具备的能力	备注
需求沟通	1.该不该：需求的价值所在 2.能不能：需求的可行性评估和成本 3.先后顺序：不同需求的关联和优先级评估	1.SMART原则 2.研发团队也会发起需求
方案设计与评审	1.制定方案：从用户需求到技术方案 2.系统性思维：需求的深层关联和隐藏影响 3.验证手段：验证项目目标是否达成 4.前瞻空间：为未来预留优化和扩展空间 5.协作：跨团队的沟通、分工和协作	1.祖传代码的诅咒 2.需求之间的关联影响；
研发实现与自测	1.实现：基于研发方案实现需求 2.自测：在研发过程中review项目目标可否达成 3.基建：构建正确和高效的自测能力	1.专业知识沉淀是研发自身的成长
QA测试与入版	1.提测：向QA输出需求的影响范围(直接和间接) 2.基建：配合QA构建测试能力(日志、开关等)	1.“全功能回测”是耍流氓
收益与复盘	1.收益：线上数据埋点与收益分析 2.售后：线上问题和用户反馈的分析与解决 3.复盘：完成需求与研发复盘，改正过程问题	1.看广告、更要看疗效

上述这个表格还可以继续补充内容，接下来我们针对几个子问题抛砖引玉。

需求沟通–可行性评估和成本

需求通常是从用户和业务的需要角度来制定的，天然就需要技术判定。这里最重要的判定就是可行性和成本分析。这一点必须由研发团队来基于当前的技术前沿水平、研发团队的技术积累等等，共同确定需求是否可行以及相应的前提条件与成本。可行性判定，从来不是为了证明不可行，而是要明确需求可行的前提条件(如技术发展、政策空间等)和相应的成本(人力投入、机器资源、外部团队协作)等。
良好的可行性评估，也需要研发在技术上的嗅觉和判断力，这很考验一个研发的技术沉淀和对业务的理解。
例如：“是这样的张总：你在家里的电脑上按了CTRL+C,然后在公司的电脑上再按CTRL+V是肯定不行的。即使同一篇文章也不行。不不，多贵的电脑都不行”，在2009年看这个需求是个搞笑段子(前提条件不成熟)。但是在互联网尤其是移动互联网时代，基于云端互联和账号体系，这个需求就成为现实Windows10-使用基于云的剪贴板从一台电脑上复制图像和文本并粘贴到另一台电脑上。
总之，从研发的角度看，最强的FLAG自然是“只有想不到、没有做不到”，永远不要给自己设限。

需求沟通–不同需求的关联和优先级

“上面千条线、下面一根针”。所有的需求，不管是从哪个来源输入的，都会统一汇总到研发团队手中。此时，研发团队就具有比任何团队都全面的信息优势–“所有需求的合集”。由于来自不同来源(包括研发自驱)，这些需求之间就存在很多可能的关联和影响：

顺序依赖：某些需求在实现方案上有依赖，导致在时间上要有先后关系；
相互排斥：各个需求来源都有自己的目标体系，因此会输出一些互相妨碍的需求。例如，“缩减安装包体积提升下载成功率”和“将资源文件内置在安装包内以优化启动耗时”；
化零为整：需求是可以合并完成的，那在研发时可以并案处理，比如针对安卓和iOS的类似需求；
举一反三：需求在未来明显有扩展的空间，那就可以与需求方沟通明确，是否要把未来的需求也合并处理；
总之，需求沟通阶段，研发团队要基于自身独有的信息优势，灵活的与各个需求方沟通探讨，将视野从单个需求走向所有需求和所有业务，合理区分优先级和调配资源投入方向，确保在关键方向拿到关键结果。

需求沟通–研发自我驱动的需求

研发团队在日常工作中，基于对用户需要的理解和研发过程中的痛点，也会主动发起一些需求。研发在发起需求时，需要考虑如下因素：

三思而行：研发自驱的需求，通常都能明确解决某一类问题(比如研发自身所直接面临的问题)，其价值是明确的。但过程中还是会存在一些风险，要积极排除这些风险的影响；
- 我即世界：指以个人喜好代表了全体用户的选择，在没有数据支撑的前提下就盲目立项和启动，反而可能在某些用户群体上产生强烈的排斥(如强行颠覆对方的使用习惯)；
- 盲目追求极致：研发作为技术控，默认会在技术上追求极致，有时候也会陷入误区。比如，对重复周期很大(如月活为1)的工作进行人效优化，其必要性有待商榷；
- 忽视相关团队：研发自驱的需求通常会由研发团队自行评审和实现，这个过程中产品和业务等团队可能是无感的，此时就容易出现需求冲突和资源竞争等问题。建议在事前积极与产品团队沟通协调、搞好合作关系，提升团队信任度和影响力，争取更多资源，必要时将需求转为产研共建需求，避免沟通不通畅带来的负向影响。
宜早不宜晚：基础设施建设类的需求是利在千秋的工作。因此，对于确实重要的任务要积极提升优先级、争取早日完成建设，并在后续的研发过程中持续收益。
有节制：特指基础设施建设类需求，如CodeReview流程、自动化测试、日志回收系统等。该类需求对研发过程有较大帮助，但也存在以下风险，需要积极避免。
- 收益衡量：基建类工作的直接服务对象是研发自身，容易出现收益无法量化、业务方缺乏感知等问题。因此，在启动这类需求时，一定要预先明确如何评估价值收益；
- 收益递减：基建类工作可以无止境的进行下去，如CodeReview环节可以层层加码的检查，其收益是持续存在、但逐步变小，此时要特别注意性价比考量；
- 需求数量：考虑到OKR结算周期，可以拉长非紧急基建需求的建设周期，避免影响单个周期中个人与团队的业绩。

方案设计与评审–系统性思维

系统性思维，是指在进行方案设计与评审时，能够把输入的单个需求和历史现状当成一个整体，从全局的角度来制定和评判方案的优劣性。这样的好处是：

全局最优：从全局制定的技术方案，能够避免陷入到局部最优，确保不会因为个别需求导致系统崩塌；
容易识别关联影响：精确识别出关联影响后，可以减少历史功能被劣化的可能性，也会大大提升研发自测和QA测试的效率；
项目分工：通过系统性思考，能够更科学的进行任务分解，在具体研发时也便于研发之间的协同与配合；

通过系统性的思维建设，能够走出个体视野的局限、跨越单个需求的边界，从整个系统的层次来考虑方案，往前、往外多走一步，方案的可靠程度也更高一些。

业务数据观察–数据埋点与分析

所有需求的目的肯定都是直接或间接的服务业务，而研发的惯性很容易出现“只注重交付、不关注收益”的情况。一旦落入这个陷阱，那研发的存在价值就被需求方所掌握，需求方靠谱时趁机喝点汤、需求方不靠谱时直接傻眼，彻底退化为工具人。在降本增效的前提下，不关注、不了解产出详情是非常不利的。

收益评估：这里的收益通常说的是业务收益。从研发角度看，一些重要的过程指标(如关键子模块的耗时、奔溃率等)也需要关注，确保符合需求目标(尤其是防劣化)。为达成该目的，需要在研发阶段就统筹规划并建设埋点上报机制，及时发现非预期变化。
问题调查和修复：当收益不符合预期(显著超出或低于)时，就需要使用预先构建的问题调查手段，如关键埋点、日志上报、调试平台等。这些能力也需要研发主动建设并持续完善。

总而言之，线上数据的实际情况是研发必须关注和负责的，尤其是针对异常情况的分析定位(以及相应的能力建设)，更是研发所独有的能力。

总结

回到一开始的问题，如果仅仅只是“完成”了输入需求，那自然也就只是一个跟随的角色、随着外部指挥棒而起舞，对自身的能力建设和自我展示都不够。在未来的项目主R、晋升答辩的过程中，也会受到挑战和质疑。如果能够拓宽角色并超越“写代码”的局限，将研发同学的价值体现在“从需求输入到线上验证的每一个环节”，跳出圈子来看需求、解决问题，这才是一个研发所具备的独特的价值。