青藤产品研发管理介绍
青藤作为自适应安全的代表厂商，公司主要专注于主机安全相关产品的研发。笔者在这里，想跟大家分享一下四年来产品研发管理经验，欢迎讨论。
青藤作为一家重视产品技术的公司，联合创始人都是“码农”出身，公司在诞生第一天就奠定了产品技术的基因。创业伊始，大家在一个小屋里进行编码，每个人负责一个技术栈，CEO和产品经理负责产品设计和需求分析。在第一年的情况下，因为人员较少，不存在什么管理，大家都是商量着来，有点“小作坊”的感觉。虽说如此，但是效率极高，需求出来后，每个技术栈的开发人员理解后，商量下接口即可。全新功能从无到有最快只需要一周时间就能上线，但是当时的加班强度是现在不可比拟的，应该比996更狠一点。当时几个初创人员大概花了一年时间，让内部代号V1.0产品横空出世。
由于V1.0比较粗糙，很快引起了我们自身的不满，马上进行了V2.0的冲刺。V2.0应该是青藤的产品中比较有影响力的一代产品，产品架构基本完整，功能也有所完善。同时产品V2.0的时候，我们已经搬到了正规的写字楼，并且团队有所扩充，每个技术栈都有3人左右的规模，因为我们技术栈比较复杂，从C/C++、Erlang、PHP、JavaScript，所以有10几人的小团队了。整体团队协调还是靠每个技术栈的负责人进行协调，当时并没有觉得什么问题，但是到后面就发现了问题所在。当时在这种组织架构下，我们完成产品V2.0“神速”的发布。这主要得益于当时我们决定了一次半封闭开发，大概为期2个月左右，当时全部研发团队每天工作时间为9:30-22:00，有时候还会更晚，一直到2015年年底，奠定了当时资产清点、风险发现和入侵检测三大模块。刚好那个时候我在协调所有的技术栈进行了这次半封闭开发。简单的流程如下：
虽然当时前端团队在产品团队并不属于研发体系，但是鉴于当时每个技术栈都在为一个总体目标进行开发，有些协同的问题没有暴露出来。但从V2.0开始我们发现了一些水面下的坑，比如性能稳定性会引起客户业务的不稳定，所以从那时起我们设置专人对于每次上线产品的性能稳定性指标进行保证，从开发到监控各个环节我们用了各种技术手段进行保证。
青藤对于产品研发的高要求是无止境的。按照自适应的安全架构我们不断进行反思和梳理，发现我们有一个象限，响应的能力我们并没有涉及。为了补全我们自适应的安全能力，我们踏上了产品V3.0开发之路，这条路比我们预想到的困难的多。之前的技术债务在这次大版本迭代中充分的暴露了出来。第一、我们发现现有的技术栈无法支撑响应模块的开发，需要引入新的技术栈Java；第二、团队内部协作的问题由于都在每个技术栈的负责人那里，由于沟通问题导致有些项目不断delay；第三、产品V2.0和产品V3.0同时并行在开发，V3.0的重视度没有得到充分的重视。这些问题不断酝酿发酵，最终引起了我们的重视。在CEO协调下我们进行了一些调整，针对引入新的技术栈，我们面临的问题就是要架构的重构。这个工作量十分巨大，需要对之前所有的功能进行重写或者调整。为更快地完成产品架构重组以及功能开发，我们引入了虚拟团队的概念，把每个人定死在每个功能开发和维护上，同时全面进行产品V3.0的开发。这个对于研发的挑战是巨大的，从产品架构设计，人员组织架构以及产品规划上进行了全面的调整。这次决定是冒险的行为，这样会缩短竞争对手的追赶时间，但是为了以后更好的产品功能，我们还是踏上了这个征程。但是到2016年底，整体的进度并不如意，很多新的功能并没有交付，产品重构的工作进度也很慢，团队内部也发生了一些人员变动。为了解决一些新功能的开发和研发的进度，CEO让我组建SRD团队，专门高效迅速的解决问题，在每个技术栈抽调一个人组成小团队的研发过程中，让我积累了一些经验，为后续的工作有了很好的思考素材。2016年其实是比较痛苦的研发转型之年。
2017年CEO任命我来进行研发的总体管理，当时面临巨大的挑战：V3.0开发还剩下很多没有完成，研发团队要迁移到武汉，整个组织建设还没有到位，同时还有各种用户的需求没有交付。为了解决这个问题，我拿出了我一贯的方法论：①看书学理论从经典中学习；
②看优秀公司从同行中学习；③看公司现状从公司实际情况中学习。然后针对性的进行有建设性的解决方案。首先当然是学习理论，在同事的建议下，我进行了敏捷开发（Scrum）的学习，《Scrum敏捷软件开发》我花了2周看完了，给我启发很大，同时我们也进行了CMMI3级的评估，还有也会参照华为IPD的开发流程，也有参加过光环的2天的集中培训；其次是参加各种技术峰会听创业公司以及大公司的研发管理流程；最后结合公司具体情况来思考。
首先要解决的是流程问题，因为公司很多研发“老炮”之前都是在敏捷开发体系下进行的研发，所以感性上对这个体系有亲切感，但是有些新人就没有经过这种体系的训练。我想了一些方法让大家慢慢接受这种开发管理方式，在实战中渗透大家对这个事情的理解，并不想那么本本主义生搬硬套，找到一些合适这么做的功能，让大家对这个流程熟悉起来。比如在这一年内确定了整个研发的流程：
这是一个标准开发流程，对于BAT做过开发的人员估计会比较熟悉。但是我们这里面会比较强调需求的技术调研，我们的经验是：在这个阶段做的好的，后面基本不会太差，反之做的不好会导致各种bug甚至返工。对安全业务的理解能力是对开发人员很高的要求。在标准的新的重点功能开发上会严格按照此流程进行处理，交付四个文档，我会对这些文档进行审查，流程的东西靠节点，质量靠测试和相关技术栈负责人。建立的虚拟团队后，我们会进行每个owner的确定，整个流程基本是仿照如下所示scrum的流程进行实践：
比如会要求每天技术栈负责人晨会，同时每个技术栈内部也有站会，针对一些delay的功能做反省会。这些都是形式上的一种方式。最重要的流程上的确定，这里面的区别是我们是“丧心病狂”的一周一迭代，Scrum Master比较缺少，我大部分在承担此角色，在一年的周期里面培养了一些Scrum Master。
其次是组织建设。针对于异地办公以及组织上的协调，也在慢慢转移研发的重心工作。把前端团队并入到研发体系内部，同时全面推行scrum的研发体系，盗用一下scrum的图，其实也是我们团队的写照：
之前的状态
现在的状态
上面那个按照系统分层的组件团队是我们之前的组织形态，下面的是我们现在的形态，完全根据功能进行虚拟团队的组建，功能交付完成会释放到研发资源池里。在50人的研发团队中，还牵扯到跨地域的沟通问题，只能尽可能的做到本地沟通，如果有异地的只能通过视频会议甚至是来回出差来进行解决。最终的组织架构形态重新梳理为：
同时很重要的一点是招聘的工作，武汉研发中心十分缺乏研发，我们进行了招聘的梳理和流程建立，极大的提高了招聘的效率，并进行了数据统计。
最后关于技术建设不讲太多，主要是各个技术栈的代码规范，环境、API文档之类的，同时我们也会定期对新技术进行学习和理解和经验的总结。比如知识积累我们设立了wiki，记录很多流程、制度以及知识方面的东西：
只能给你看到这里了，举个例子，线上故障排错流程我们就是按照google SRE的方式建立的，其他的流程基本都是我提到的三个思考方式确立的。
在这个过程中可能会遇到很难抉择的问题，比如团队人数有限制的情况下，既要做到业务开发的尽快交付，又要兼顾产品底层技术的支撑性和可扩展性，如何做到？没有简单的答案，对两者我们定义为特性功能和使能功能，在不同的版本规划中，根据实际的功能优先级来规划整体的交付情况，逐步交付和迭代。同时在产品商品化层面和前瞻技术研究上的平衡我们一直做得不是很好，对于产品的前瞻技术研究过多，而在产品商品化层面的理解较少，导致我们的产品在市场上客户的体验性的东西做得不够。作为商业组织，技术最终是为商业服务的，应该把握好节奏。在满足交付商品化产品的之后，再潜心做前瞻性技术研究，这样会让公司的运转会良好。如果一味偏重商品化导致产品没有后劲，一味偏重前瞻技术，则整个的商业利益没有得到很好的体现，因此这两者要做到很好的平衡。
一般情况下我的工作状态是每个月会跟产品经理沟通确定开发计划，然后跟内部进行分解和排期，之后每天开晨会确定项目进度；同时盯重点功能的需求和调研结果；关注重点Bug和线上问题；跟客户对接新需求；进行制度和组织建设。我相信有规范和强大的研发体系可以做出好的产品，如果没有，只能寄希望于超级程序员了。这里面没有提及项目管理以及质量管理的相关工具，但是我们基本都是用业界主流的工具，以上是我这几年的研发的心路历程，可能有些没有说到，可以留言沟通，同时欢迎有安全追求的程序员加入我们。
