BAT与一些创业公司是如何进行研发管理和绩效考核的？
轻流作为一家互联网科技型的创业公司，对研发管理和绩效考核有一套自己的模式，在这里分享给大家。一、研发管理作为一家互联网创业公司的研发部门，我们每时每刻都面临着巨大挑战。其中最令人头疼的就是上线时间拖沓，生产环境更新后引入大量BUG。上线时间拖延，导致无法及时兑现给客户的承诺，更新后引入大量BUG导致客户认为产品不稳定。
这两点，会不断消耗我们辛辛苦苦建立起的品牌形象，甚至会把客户推向其他产品。团队内部对此进行了深入的沟通讨论。总结了导致问题频发的四个主要因素：1） 缺乏清晰的规划2）无效沟通过多，掩盖重要信息3）必要文档资料管理不完善4）未有效借助工具所以从这四个方面谈谈我们是如何优化工作流程解决以上问题的。1、划清阶段界限，固定交付日期我们的研发可以分为三个阶段，分别是产品设计、开发和验收。
很长一段时间，团队缺乏清晰的规划，产品文档或设计稿交付时间不明确，技术功能实现交付测试的时间不确定，团队成员无法明确哪个时间点该交付什么样的产物。一次次的延期、加班，引入更多的BUG。研发流程不清晰，严重影响了开发效率和开发的幸福感。反思后，第一步措施，我们明确了各个阶段之间界限，确定每一部分完成后需要交付的产物。
例如产品设计阶段完成之后，需要交付功能需求文档和UI设计稿给开发，开发作为产品设计的消费者，有责任评估上一阶段产物是否符合需求。在明确各阶段界限的基础上，约定迭代周期总长度，为每一个阶段设定固定的交付日期。2、明确会议目的，严格把控时长作为一款企业服务产品，随着客户不断增加，需求纷至沓来，轻流的产品逻辑变得日益复杂庞大，会议成为我们应对挑战的重要方式之一。
会议越来越多，会议时间也越来越长，大量时间被占用的同时，过量信息和过度沟通反而掩盖了重要信息的传播。会议一般分为两种，常规会议和临时会议，这两种会议的侧重点不同。常规会议重在定期沟通迭代内的常规事项，常规会议重点是严格把控会议时长，可以从两个方面入手：会议前准备好会议相关内容；会议进行中需要组织者控制每个板块的讨论时长并把大家从会议无关的讨论中拉回。
临时会议则是计划外的会议，临时会议的重点是明确会议目的并确保只有必要的人员参与，在发起临时会议前，发起者需要确定会议主题并明确必要的参与人员，无关人员无需浪费精力在其中。每次会议都需要进行会议记录，并在会议结束后公开会议记录，以便缺席者查看会议内容、方便成员查阅会议讨论结果。3、维护必要的文档一份清晰、准确的文档，是研发的重要一环，在不同发展阶段，文档的重要性是不一样的。
初创阶段，产品迭代迅速，功能一天一个样，这个时候如果痴迷于维护文档，大概率会变成团队的负担，文档维护无疾而终。随着产品的成熟稳定，功能不再有大的变动，团队规模不断扩大，这个阶段需要引入一些必要的文档，如业务逻辑相关文档、项目结构文档、运维操作文档等。4、善用多种管理工具工欲善其事，必先利其器。创业公司资源有限，应该把精力放在核心业务上，重复、低价值的工作交给工具去做。
至少需要以下几个类型的工具，代码管理工具、API文档工具、自动化运维工具、开发/BUG管理协作工具和业务调试工具。代码管理可选工具较多，如github、gitlab、bitbucket、码云、svn等等，选用一款熟悉的产品即可。前后端分离的项目中，API文档非常重要。开发过程中，先定义好API文档、前后端确认后各自按照开发文档进行开发的方式可以有效减少返工、提高效率。
选用工具方面，可以根据团队的偏好选择，我们曾经使用过swagger、apiary和apiDoc，最终选用了apiDoc。提到自动化运维工具，一定逃不开jenkins。持续交付、持续部署等类型的文章，对jenkins的介绍很多，这里不再展开。自动化测试可以采用Travi、CircleCi等工具。业务调试工具一般用于为客户调试问题，由于各个产品业务场景不同，所需功能也不同，可以考虑内部研发python小工具。
开发管理协作工具是技术与市场、产品合作的重要部分。好的工具必须做到这些，市场向技术反馈系统BUG、市场跟进BUG修复情况、产品了解功能研发进度、产品验收功能并反馈问题及技术内部KPI考评等。轻流研发团队最初尝试过一些看板协同类产品，但是效果不是特别好，看板任务积压、无法统计常规数据等，因此选用了自己的产品。
一方面可以轻松做到信息共享、责任划分、任务追踪和数据统计，另一方面，轻流具备超强的连接能力，无需开发就可以与github、trello等其他saas产品、内部已有系统结合。给技术和其他部门之间的协作、技术部门内部协作带来了很大的提升。开发模式、工具的目的都是提升效率，不可以过度追求理论方法，照搬照抄开发模式。
要结合团队自身属性、公司当前发展阶段，不断思考、实践、总结，找到自己的节奏。二、绩效考核绩效考核和研发管理其实是分不开的。在绩效管理这一块，公司会设定好相应的职级和考核标准，大多数公司考核方式无非两种：1、积分制把研发任务或者项目设定一定的分值，然后接了任务或者项目完成之后，就可以获得相应的积分。这个是累计制的，最后按照设定好的周期进行汇总考核。
2、评分制这个又分为两种，一个是互评分，一个是主管评分。顾名思义，一个是和团队内部的同时按照一定的的标准互相评分；一个是由主管对团队成员进行评分。评分制往往以季度和年度为周期，通过分数的高低评判该员工的绩效和职级。我们公司借鉴了很多大厂和创业公司的经验，将积分制和评分制相结合，然后调整了相应的占比，力求考核方式公平、公正。
想做互联网平台，但是没有技术，选择外包，这种公司需要配备怎么样的技术人员？
做一个系统，通常有两个选择：自建团队和项目外包。自建团队的好处是什么呢？项目的整个过程可控，响应速度快，能够满足快速迭代的需要，技术的沉淀好，能够有清晰的技术线路图。而自建团队的缺点就是成本高，团队组件周期长，在前期业务没有发展起来的时候，技术团队也需要养着。而外包呢？刚好和自建团队相反，最大的好处就是节约，可以快速的启动项目。
但是过程比较难控制，遇到问题响应速度慢，不适合需求变化频繁的项目，由于没有自己的技术，所以也谈不上技术沉淀和技术线路。那么，想做互联网平台，需要怎么来配置呢？对于一个公司来说，如果决定要做平台，那么只有两个可能，要么这个公司不缺钱，背后有金主。要么这个公司有技术和业务的沉淀，可以快速的切入市场。不然，做平台就是过得不痛快了，想要寻找刺激。
为什么这么说呢？因为现在中国的互联网，可以有第三方平台的领域都已经被大佬们占满了，一个新兴的公司想要挤出一个空间来，就需要大量的烧钱，并且还要抗住各方大佬们的围剿。假设你背后金主支持，或者你本身就在行业中有一定地位，平台根本做不起来。OK，那么我们把思维换回来，想做平台，怎么来配置技术团队呢？既然互联网平台是一个大手笔的收入，肯定是自建技术团队，这样才能在未来的时候能够快速的响应市场的变化。
平台，相当于就是涵盖了这个行业中大部分的业务情况，需要连接上下游，由于需求的多变，没有快速的响应能力是不行的。因此，产品团队、研发团队、测试团队、运维团队一个不能少。产品负责对这个平台进行定位和设计，需要充分的考虑到市场、运营模式、盈利点等等情况。测试主要是保障平台的质量，要有充足的健壮性，并且需要根据市场进行用户量的预估，从而通过压力测试保障项目的稳定。
运维主要是对线上的平台运营情况进行监控，并且通过一些工具，把关键数据提取出来，为产品的升级、业务的策略提供帮助。那么核心的研发团队，自然就是要把平台做出来，后端工程师，前端工程师，移动端工程师各个岗位，根据自己的平台受众自行调整人员。那可以外包吗？实话说，不是非常有必要。但是，外包确实在前期可以节约时间和资金。
那么，最好的方式就是，配置一两个产品人员，一两个技术人员，然后投入到外包的团队中，全程的跟踪研发和产品设计，并且做好技术资料的归集。当这个系统正式上线的那一天，就是扩大团队，自建技术团队的那一天，从而保证在未来的高度迭代。加入使用这种方式，就能够保证前期能够快速的开展项目，并且有一定的技术储备，也留有充足的时间进行团队的组建。
