你我皆牛马，活在网中间~
关注土豆公众号，做一线牛马，今天你牛马了吗？
前言
今年应该又有不少牛马涌入互联网，简单用一个例子，讲下自己对互联网岗位分工的理解，欢迎评论区友好交流，保留文章著作权，请勿转载。
互联网岗位可以粗糙地分为：专业序列和管理序列（有些公司是双轨制，有些公司的基层管理可能同时负责技术和管理），其中大部分牛马都应该是专业序列，大概可分为：职能岗（比如人力资源）、产品岗、技术岗、运营岗，其中我们熟悉的技术岗有可以继续细分到：开发岗位（前端、后端）、算法岗位、数据岗位、测试岗位、运维岗位、设计美术岗、基础建设岗位等等。我们以一个产品新增一个功能的角度，去分析这些岗位的职能。
叠甲 1：这里的逻辑基本上是以C端产品，特别是一线产品的逻辑去理解的，如果是偏向内部支持的产品，B端或者G端产品等等，则逻辑会不同。
叠甲 2： 这里提到的岗位的细致划分基本上在中大规模的公司里面才会出现，如果是小公司可能一个人干很多岗位的活儿。
叠甲 3：我只是一个互联网小兵，里面有理解不到位的，大佬们多海涵，抱拳了。
牛马APP，一个牛马看了不想走的APP
比如我是牛马APP的老板，其中的用户大多是互联网工作的牛马，其营收主要来自于广告、增值服务（比如会员费、知识星球、一些3C产品电商等等），其首页如下所示，内容区块大致可以分为导航栏、内容栏、首屏广告等。在搜索栏中，一般情况下都会弹出一个推荐搜索词（称之为SUG），去激发搜索量，也会有热门query推荐等。这是这个产品的基本样貌。
在互联网寒冬下，用户都不肯好好开会员了，这么不懂事的用户，导致公司的增值收入下降。作为APP的老板，我此时有了一个『极好』的主意：就算是牛马分享经验，也是适时地收费的！ 因此我很快哈，大手一拍，决定在某些优质内容下，要进行收费。
怎么收费呢？已经开了会员的牛马再继续付费，那肯定人家就不干了，那么留存率就会狂掉，就算是竭泽而渔，我们也要可持续地竭泽而渔对吧，因此老板就决定，对于某些优质内容，普通用户需要付费阅览，而会员则可以无障碍阅读。
那么老板的OKR（Object-Key Results）就定下来了：
O： 提高增值收入，达到xxx，同时保证用户大盘指标的稳定向好，以优质知识付费为抓手，形成优质内容生成与营收的生态闭环。
- KR1：打通普通用户优质内容付费通道，形成优质知识值得付费的用户感知，培养用户心智。
- KR2：保证优质内容的稳定生产，每月优质内容生产率达到yyy
- KR3：保证优质内容的定向推送和稳定营收，营收达到xxx。
军令已经定下来了，作为各层级的小兵，各个岗位的牛马就开始拆解老板的OKR了。
首先，产品会先设计整个产品的形态，做调研。这个产品的目标很明确，就是让普通用户为优质内容心甘情愿地掏钱，那么这里有几个基本问题需要考虑：
- 什么是优质内容
- 哪些普通用户会为哪些优质内容掏钱
- 如何既要搞到钱，又尽可能不要让普通用户不爽
- 这个产品，要以什么形式（包括产品样式、交互逻辑、产品格调等）去尽可能吸引普通用户掏钱
这个时候产品的活儿就来了，产品主要需要考虑以上的1、3和4点。
- 什么是优质内容，这个问题很复杂，和整个产品的调性、内容种类、内容丰富度等都有关系。比如对于牛马APP来说，可能优质内容就是互联网牛马对当前公司真实的待遇、工作节奏、工作发展等内容的细致图文内容，其中图文并茂，大家都很认可，点击评论点赞啥的用户交互行为都上天了，这算是一种优质内容。还有可能是一些职业技能分享，专业知识分享，也能吸引某些技术牛马的青睐，这也算是优质内容。通常来说，产品需要在不同维度去定义优质，然后制定优质档位打分标准，比如制定个4档，0档是恶劣低质，1档是一般，2档是良好，3档是优质。然后从各个维度去指定一些子标准，比如图文中图片的质量，是否涉黄涉政，是否格调适合，文本内容是否流畅，是否有恶意中伤别人的内容，是否存在虚假信息等等，这些都可以作为子维度去制定标准，然后通过各个子维度的打分去拟合出最终的质量打分。（实际上，关于什么是优质内容的标准，经常需要产品和算法一起根据具体的线上case去碰撞讨论产出，同时也会经常微调定义。）
- 这个产品，就算是优质内容，如果引入付费，用户肯定是会变得不爽的。得给点甜头给用户！比如给7天免费体验（偏运营手段），再比如每个优质内容，都适当地露出一些爽点信息，让普通用户感知到这个内容有多么地吊炸天，值得他掏出他为数不多的小钱钱，去一览全貌。那么问题又来了，怎么定义爽点呢？这个时候，同样需要产品去找优质内容，并且人肉去看这些优质内容，找出爽点的定义和标准。
- 产品的形态同样是需要产品负责去设计的，包括整个产品的交互逻辑，产品样式，作为产品得知道一些典型的交互设计逻辑和基本交互元素，以及各种方案的利弊。
从以上的问题来看，其实产品也是有不同的分工的，有些产品专注于内容侧的评估和标准制定，有些产品专注整个产品的交互模式、产品形态。最终，负责交互和形态的产品拍了个产品demo初稿，然后用Figma画了下设计稿，如下所示。
首先，众所周知，付费阅读的转化可以表示为
当然，产品还需要继续设计交互。用户成功从首页跳转后，就迎来了实际内容的落地页，如下所示，此时产品/算法需要决定文章在何处淡出终止，给普通用户两个选择，充会员或者单篇文章买断。我们需要以某种标准去确定，在此处终止文章，能留给用户最大的悬念，从而诱导用户去开通会员或者买断。这里需要产品和算法联手去发掘具有最佳的终止点。
就这样，这个产品的最基本的形态和交互逻辑就确定下来了，但是这个产品上线后是否真的能按照预期运营呢？因此更称职的产品，应该要预先思考是否能从众多线上指标中，提炼出一些核心用户指标，比如优质内容的点击率、用户停留率、用户互动情况、转化率等等，包括一些更加宏观的规模和商业指标，DAU、MAU、增值营收等等是否符合预期。通过提前设计这些需要监控的指标，有利于在上线后的小流量实验中，我们能收集到足够的强有力的数据去证明我们的产品设计符合老板的OKR预期。
按照以上的思考路径，产品已经积累了一些初步方案了：
- 优质内容的标准
- 产品形态和交互形式
- 一些典型case积累
此时就可以开始交给技术岗的牛马去实现了，产品当然也没闲着，还需要同步去思考整个过程是否有需要优化的标准，同时和技术牛马频繁对齐，以发现真实的一些问题驱动修改产品。
一般是业务算法牛马先接到产品的需求，通常产品标准，算法也需要通读一遍，然后去采集验证集。没错，作为业务算法牛马，接到需求的第一件事情应该是考虑这个需求最后怎么验收。前期的验收一般看离线的验证集，验证集的数据通常来自于线上，然后产品和算法都会根据标准文档去进行试标注，然后对齐一致率，当一致率达到一定程度后，则视为双方对这个产品标准目标有一致认识，就可以交付外包去进行大规模标注。
给外包标注其实也是个大坑，因为外包标注大部分是计件的，这个业务和他们也没啥关系，因此标注得就很随意，之前在X度的时候就遇到过外包标注的时候，将所有label都标为0（因为真实数据中确实0占据了大部分，验收也不容易发现），最后我们发现后将这个外包辞退回外包公司了，这使得我们那时候采集的很多数据都不可用，需要返修。后面我们也想了一些办法去避免出现这种情况。
总而言之，这个时候我们采集到了一些离线高质量的验证集后，算法牛马就可以开始正式拿出键盘开工了。这些业务算法牛马通过一些高大上的模型后，哐哐哐将离线验证集的指标刷到符合预期了，然后就考虑开始灰度上线做一个demo，弄出来给大伙儿体验下效果先。
但是算法牛马交付的通常只是一个模型，在线上要落地这个模型，就要开始找开发牛马一起协同完成了。开发主要是前端和后端，在现成的系统中新增功能，开发量可大可小。前端需要和产品一起对齐产品的样式和交互逻辑，在一些公司里面，还需要找美工设计牛马做设计稿（不然你设计出来的界面和元素可能就和我画的一样丑不忍睹），然后前端根据产品的交互逻辑和样式，美工的设计稿，和后端牛马一起对齐数据接口，然后就可以开始去写代码。
因为涉及到模型的支持，后端通常会分为两块，一个是当前app的骨干框架下的后端，一个是模型服务支持的后端。模型服务的后端需要确定你待上线的模型，当前线上的能力是否能提供支持了（时延、吞吐、资源开销等），如果还不能提供支持，可能需要进行一些开发（比如定制开发你模型的优化代码），直到模型可以上线为止。 app骨干框架下的后端呢，则考虑你这个模块怎么在当前现有的框架下插入进来，并且不会带来明显的时延。
等后端的骨架开发都ready后，算法牛马就可以在这个骨架上，进行线上开发数据通路了，也就是线上模型如何拿到数据，并且如何将其预处理然后发送到模型服务上计算，最终取回来计算结果后，如何进行后处理，这些逻辑都需要算法牛马去开发。有时候模型需要依赖的数据流比较复杂，比如需要预先刷库建库，可能需要和离线数据流的后端牛马（算是基础架构的）进行沟通，然后协调基础架构的牛马支持完成项目。
在最终所有开发都完成后，算法终于把整个模型上去了，并且打通了整个逻辑，此时这个产品就可以内部体验到了。然后产品收集内部的意见，并且产品也开始频繁体验，提出修改意见，然后驱动算法、开发等等牛马继续迭代产品，直到老板判断可以小流量上线给真实客户体验为止。此时，这个产品就可以开始小流量上线了，在此之前，开发侧还需要做一些应急预案，比如判断峰值流量、是否有足够机器扩容、应急回滚预案等等，一切准备后就可以开始小流量实验了。
整个小流量实验过程中，产品和算法会关注之前提取的核心线上指标，并且持续进行线上case的积累和分析，以用于后续模型（效果、标准）和产品的迭代（形态、交互、标准等）。在技术和产品的共同努力下，当持续迭代到一定程度后，就可以考虑将这个产品推全了。
产品推全后，这个项目并不是就不需要继续迭代了，只要这个项目老板还关心，产品和算法就需要持续关注线上指标和case，并且持续优化，迭代过程中如果需要基础架构或者开发的支持，一般算法也需要主动推进，如果遇到紧急流量高峰期，可能还需要找运维去做资源扩容等。
不过产品推全后，整个产品就不光是产品和研发的事情了，运营牛马的工作也开始来了。运营顾名思义，就是运营整个产品，包括软广、写文案、做营销活动等，运营的目的就是拉新用户（拉新）和留住老用户（留存），最终目的当然还是整体的营收和利润。很多平台或者新服务在冷启动阶段，其知名度很低，为了打开市场获客，拉取新用户就是运营最重要的工作了。他们可能会有一定的广告经费去各个平台打广告，和各个主流平台（B站、小红书、知乎、公众号...）的大V合作发表软文广告。有些活动运营会有活动经费可以做活动，比如淘宝就经常有大促。当然拉新和留存有着不同的策略，有时候也需要和算法、产品合作一起完成运营活动。
整体来看，整个产品的利润可以用以下公式表达：
- 流量：主要由产品、业务算法、运营等团队去负责。
- 转化率：主要有算法团队负责
- 稳定率：主要由开发团队负责
- 成本：有多种成本，通常每个团队都需要负责
- 平均单价：我理解还是主要算法团队负责
人力资源（HR）除了裁人去优化人力成本外，其本职工作其实是用给定的预算去完成业务部门的招聘目标，比如部门给了1000万的预算，HR需要从各个平台上（脉脉、知乎、校内bbs、朋友推荐...）等各种手段去找到具有特定人才画像的人才，人才画像可以从几个层次描述：
- 技术：是否具有业务部门要求的，满足Job Description（JD）的特定领域的技术技能，是否达到了目标职级的能力水平。
- 业务：对业务的理解，在业务场景中落地的经验
- 管理能力：高阶职级要带人，需要考察管理能力
- 学历背景：有些岗位要求学历背景
当然，HR不完全懂技术，但是HRBP作为业务合伙人，理论上需要对业务部门的业务场景了解，需要能够描述人才的业务和技术画像。HR同样可以有经费，可以和外部猎头合作去挖掘一些高阶人才。
还有很多岗位这里没提到的，比如法务、风控安全、市场营销等等，这些暂且就先不谈了。
以上就是基于牛马 APP 这个例子对互联网岗位分工的详细剖析，希望能帮助大家更好地理解各个岗位在整个产品功能开发及运营过程中的重要作用和协作关系。当然，实际的互联网工作场景远比这个例子复杂得多，不同的公司、不同的产品类型以及不同的业务阶段，都会导致岗位分工和职责重点有所差异。这是否对各位未来牛马有所帮助呢？
我简单（很不严谨地）绘制了一个基本流程图，也许对大家有帮助。
