一文搞懂研发效能的道与术 - 术

1 前言

上一篇文章我们介绍了关于提升研发效能的“道与法”相关的内容,这篇文章主要介绍研发效能的”术与器“。将主要从组织文化,项目管理,开发,测试,运维,运营和其他几个方面分别介绍下自我总结的最佳实践。

现在大家搞研发效能有个误区, 认为devops, 敏捷就是研发效能的最优的方法论, 其实并不一定是这样, 现在比较流行的devops并不一定适用于所有场景, 举个例子像是传统的2B端产品, 或者某些只需要一次交付的产品, 很明显并不适合应用devops和敏捷, 反而是传统的瀑布模式更加合适一些.

PS:由于个人工作经验主要集中在互联网企业, 所以这里默认给大家介绍的最佳实践背景基于互联网企业.

研发效能.png

2 组织文化

看了很多资料,发现大家忽略了一个很重要的点就是组织文化,为什么很多公司想要提升研发效能,但是效果很一般呢?你的公司是否遇到过这种情况:

  1. 同样的方法在两家公司落地效果天差地别?
  2. 公司从大厂中招了一堆高薪人才过来,但是效能并未有显著提升.
  3. 明明是业内公认的方法论,但是在本公司却无法落地或落地效果堪忧.

其中很重要的原因是因为组织和文化的不一致, 组织和文化是相辅相成的, 二者是相互影响的,这里我们将分开讨论他们对研发效能的影响, 然后说下我个人组织文化的一些拙见.

2.1 组织

程序猿很多时候难以理解组织架构的重要性,这一点甚至体现在很多“架构师”身上,每当面临公司组织架构调整时, 大部分的人都会有抵触情绪, 因为大部分人都是从自身利益出发而思考问题, 尤其当面临未知的事物时, 很大一部分人会出现抵触情绪, 因为改变有可能会导致他们个人受到影响, 但是如果从公司方面考虑, 面对市场和环境的不断变化, 公司必须做出相应的改变, 才有可能抓住机会, 不被市场淘汰.

那么组织架构对研发效能会有什么影响呢? 这里不讲大道理给大家几个我们平时经常遇到的例子:

  1. 事业部A 和 事业部B 用了不同的开发框架, 开发语言, 开发流程, 很多通用公用的服务都重复造了轮子, 造成人力和资源的浪费.
  2. 明明有一个技术平台 or 中台部门, 但是每次需求响应不及时, 感觉还不如自己开发来的快.
  3. 部门按照职能进行划分 - 产品,设计,后端,前端,客户端,测试,运维...发现要么是部门间配合困难(文化问题后续展开), 要么是多个业务项目同时打过来导致研发人员分配不均, 低优先级创新类项目永远无法得到相应排期.

看完症状,我们来对症下药:

  1. 问题1 的解决方案相对简单, 无论是Supercell, 还是阿里其实都在给大家宣传中台的作用, 从组织的层面上就已经把相对通用的部分,抽离出业务单独成立了部门.
  2. 问题2 可能是大家在落地中台时,遇到最多的问题了, 这里的个人看法是 "有术无道,止于术; 有道无术, 尚可求也"; 很多企业盲目追求中台的最终效果, 却忽略了建设中台的过程, Supercell之所以能够快速迭代多款爆款游戏, 个人认为很重要的原因在于 Supercell在最初的组织架构划分中,中台就有其定位, 相信做技术的能深刻感受到, 如果一开始就做好相应的架构规划, 后续基于中台做相应开发并不是一件很困难的事, 真正困难的是, 多个业务已经相对成熟了, 这时老板决定要做中台整合重复的部分, 然后就是技术部门业务部门经过长达2-3年的重组整合,最后收效甚微,不经成本没降下去,反而组织能力和生产效率都下降了,而且很多公司已经证明了这条路基本不可行, 主要原因:
  • 一是耗时长, 当前成熟业务项目越多, 时间就越长;
  • 二是投入巨大, 产出短期内却难以见效;
  • 三是风险高, 很多次由于切换系统导致的线上严重事故;
  • 四是业务并行, 在做中台抽象时, 业务也在不断的变化,做出来的东西已经不能满足原先的需求.
  1. 问题3 基本上当前业内也有比较成熟的解决方案 - 矩阵型组织 职能配合业务双线管理, 但实际在落地上也存在很多问题, 这里我个人比较推荐亚马逊的双披萨团队, 亚马逊“两个披萨团队”得名的由来,是因为团队的成员很少,只有6-10人,用两个披萨就能喂饱他们。“两个披萨团队”最重要的不是规模,而是它的“适度职责”。它相当于为一个部门的盈利或者亏损负责,可以让团队保持专注、负上责任. 但是缺点是团队间竞争激烈, 离职率较高.

其实组织上并没有一套很完整的最佳实践,因为组织是服务于人的, 人是服务于业务的. 在做组织架构时,一定要结合当前的市场情况, 企业自身的规模情况, 自身员工的基本情况来去制订!

切记不要直接找一个大厂的HR, 一般来说他们只会把自家的那套架构搬过来, 然后公司就废了...(亲身体验了一家公司不同时间换了三个HRVP,from通用, from百度, from阿里 三套组织架构作用于同一家企业后有感而发...).

PS:这里推荐一个个人十分佩服的HR大佬 - 房晟陶, 有组织和人力困扰的老板可以找房老师做相应咨询.

2.2 文化

很多人可能难以理解, 文化跟研发效能有什么关系呢? 还是举3个例子(1个好,1个坏,1个不确定)大家感受下, 文化对于研发效能的影响(这里的文化一定不是企业在官网上宣传的文化, 而是企业员工尤其是企业高管的行为体现!).

  1. 某德有很长一段时间在对部门进行KPI考核时, 有一项是加班时长 (黑人问号???), 而且这也绝非个例, 很多* 德出来HR把这项"优良"的习惯带到了其他企业, 按照之前的效能模型来进行推导: 效能 = 有效成果/时间, 如果长时间无效加班带来的必然是效能的低下.
  2. 某易应该是互联网企业中少有的慢节奏公司了(除了个别部门), 相较于其他公司的快节奏和不断试错, 网易一直坚持"精选"这一战略, 也许网易错过了很多风口, 但是网易出的产品(网易云音乐, 网易严选, 各类游戏)都算是业内优秀产品, 在经过互联网黄金的这些年以后, 到了比拼内力的时候, 网易这种慢性子公司反而占了优势.
  3. 某讯之前的"赛马文化", 在研发效能的角度来看是很值得思考的一个案例, 从成本上来说他一定是存在浪费的, 但是从有效的角度来看, 某讯在赛马文化的加持下推出的产品也都算精品 (就算是卡卡西, 那也在原有基础上加了些自己的创新), 所以某讯的战术就是利用不同团队的冗余浪费, 来提高成果的有效性; 相较于那些盯着一个人使劲榨取劳动力的做法, 无疑这样子可能更能提高有效这个分子的影响.

其实企业文化跟创始人性格有直接的关系, 不知道大家是否有直接感触, 一个企业的老板如果是个高效的人, 你会发现这家企业会议时间短, 内容精简, 扯皮等内耗上的时间相对较少, 公司整体决策靠谱, 整个公司的效率自然而然就高了, 研发效能也会随之提升; 而不应该是一边要求着技术部加班, 一边变相裁员(这里并没有说裁员有什么问题, 更多的问题是企图利用小聪明及小手段无脑压榨员工, 变相裁员的行为, 不仅对员工不利, 对公司的损害同样是巨大的, 这里大胆断言那些没有按照正常流程裁员的公司将来一定是不会再东山再起的, 反而像好未来这类充分保护员工利益的公司会再度雄起!), 文化不做出改变高效能就是空谈.

2.3 组织文化小结

组织和文化上扯了很多文字, 其实低效能最主要的原因 就是开发团队和其他团队的目标、利益不一致. 这也是为什么KPI被越来越多公司替换的原因.

image.png

2.3.1 组织文化最佳实践:

  • 这里强烈大家去阅读经济学相关知识, 不同的社会形态和行业决定了企业该采取哪种组织和文化.
  • 个人认为当下我国私企主要以市场经济为主, 在不考虑政府强制干预的情况下, 市场经济的核心是 市场调节,自由竞争 对应企业管理也是如此, 要想实现高效能, 相应的组织和文化应该符合这两个key point.

可能上面讲的的比较抽象, 我们可以会看下历史上企业高效能变革的案例:

  • 福特汽车: 福特是最早提出流水线的企业, 原本制造一辆汽车需要12小时, 而且需要工人具备多方面知识才可以进行组装, 但是流水线的出现, 把组装汽车缩短道90分钟, 同时每个人只需要执行自己所在部分的工作即可. 制造汽车的成本极大降低, 实现了每个人都可以买得起汽车的目标.
  • 丰田汽车: 丰田的精益生产被现代很多商学院拿来当作典型案例分享, 它主要依靠"准时化","自动化"两个特点,极大降低了原本工作流方式的成本,消除了库存资源的浪费, 提升了生产力.
  • IT产业: 敏捷和DEVOPS的流行, 离不开互联网的发展, 互联网的特性就是迭代快速, 所以企业可以依靠互联网做到快速交付, 从而提升有效性.

所以在做组织和文化设计时, 一定要结合行业和时代背景,找到最适合自己企业的来去实施, 切勿照搬!!! 当前时代的背景是90后是主力, 80后开始逐步退出舞台, 00后伺机而动, 90后的特征相较于80后来说更加的追求自由和平等, 从小的生活也都相对条件较好, 集体意识相对较弱, 更渴望获得个人成就感, 基于这些特征,传统领导力已经不能很好的管理当前的90后员工, 更应该采取现代领导力来进行辅助, 配合组织架构的权力下放创新,自由,成长类型的企业文化, 帮助他们实现个人价值, 从而实现公司价值的提升.

3 项目管理

其实广义上的项目管理核心就是提升研发效能, 这里我们主要讨论窄义上的项目管理-定好目标后, 如何按时按量的完成相应工作, 达成项目目标. 项目管理的核心三要素是时间, 质量, 成本, 三者的项目取舍就是项目管理的核心.

image.png

3.1 项目管理痛点

  1. 项目每次都延期
  2. 交付后, 用户或客户不满意
  3. 消耗大量人力或其他成本
  4. 那么多项目管理方法论, 该用哪种呢?
  5. 团队成员不配合PMO, 动作执行不到位
  6. 突发事件影响了整体项目进度
  7. 项目管理工具的使用每次都虎头蛇尾, 并未持续使用

3.2 项目管理经典案例

再分享最佳实践之前, 首先给大家看几个项目管理的经典案例, 让大家体会下项目管理的魅力

3.2.1 apollo登月计划

第一个也是最著名的一个 美国的阿波罗登月计划, 1961年,美国启动了阿波罗计划(Project Apollo)。这个项目工期历时约11年,耗资255亿美元,工程高峰时期,超过30万人参与, 读者可以自己设想下, 自己在那个年代, 怎样来完成这样一个人类有史以来从未完成的计划呢? 详细内容大家可以查看相关文章, 这里总结下最核心的工具 PERT图和甘特图, apollo有几百名独立的类似PMO的角色进行任务协调, 他们使用最多的就是PERT图和甘特图, 让每项任务都能够有具体的执行人, 执行时间, 和执行结果, 才保证了这个伟大的项目成功

pert图:

image.png

甘特图:

image.png

3.2.2 鲁布革水电站

鲁布革水电站是我国第一个利用世界银行贷款的基本建设项目,根据协议,工程三大部分之一的引水隧洞工程必须进行国际招标。这吸引到8个国家的承包商来竞标,结果日本大成公司中标。至完工后日本大成公司共制造出了至少三大冲击波:第一波价格,中标价仅为标底的56.58%;第二波队伍,日本大成公司派到现场的只有一支30人的管理队伍,作业工人全部由中国承包公司委派;第三波结果,完工决算的工程造价为标底的60%、工期提前156天、质量达到合同规定的要求。

这令人咋舌的低成本、高质量、高速度和高效益,让当时中国建筑界的从业者叹为观止。时任副总理李鹏感叹:“看来同大成的差距,原因不在工人,而在管理。” 主要体现在以下几点:

  • 组织保障: 人员培养, 人力不足及时补充
  • 科学管理: 设立奖惩制度,
  • 风险管控: 假设风险, 并提出预案, 机器备份, 人员备份充沛
  • 不断迭代: 建设过程中, 不断根据现场情况进行方案优化

3.2.3 数字化时代

上面两个例子是工业和建筑业对项目管理依赖的典型案例, 数字化时代, 可能交付一个产品不会像人类登月和建水坝那样一丝差错不容许出现, 但是当下的时代速度为王, 也许你比竞争对手 早一天上线, 好一点用户体验, 系统更稳定一些, 用的成本更少一些, 最后被市场认可的就是你的企业, 所以当下的企业也需要关注项目管理.

3.3 项目管理最佳实践

3.3.1 做好项目管理的核心

  1. 做好任务计划
    • 一定要切的够细, 每项任务一定要有责任人, 计划开始时间, 计划完成时间, 及验收标准, 依赖和被依赖项.
  2. 及时校验计划执行结果
    • 关注执行人, 实际开始时间, 结束时间, 任务是否符合预期.
  3. 计划比实际更多一些
    • 做好风险管理及预案.
  4. 沟通及时性
    • 延期或变更工期需周知所有相关人员.

3.3.2 神器推荐

项目管理的领域实在是太广了, 这里无法给大家特别详细的介绍相关内容, 术与器篇最想推荐给大家的其实是器, 这里主要给大家推荐的不仅仅是为了做项目管理, 更重要的是包含了 需求管理, 运维发布, 测试用例管理等功能,让所有项目成员都使用起来的产品! 拥有这些神器, 只要你的团队一起使用就一定可以提高研发效能.

神器推荐点缺点
华为云devcloud相较于其他devops产品, 他的需求管理可以以脑图形式编辑, 方便使用和管理, 同时可以切换成甘特图和华为云捆绑较紧, 只能再云平台使用, 且近期开始收费
阿里云效持续迭代, 如果本身使用阿里云产品, 可以直接使用,集成度高收费; 功能侧重研发, 对项目管理和产品支持较弱
erda完全开源! jira的完美替代品! 除了DevOps功能外, 还包含微服务观测治理、多云管理以及快数据治理等平台级能力较多项目时比较占资源, 需要一定服务器成本

最后引用知乎网友jeffery文章中的一句话概括项目管理的核心是 “以目标作为导向、以团队作为模式、以计划作为基本、以过程控制为重要手段、以客户需求作为中心”

4 开发

相信来看文章的大部分都是研发同学, 由于现在开发团队的职能切分比较细, 这里就举几个通用的痛点例子, 和个人觉得比较好用的神器, 大家有好用的工具也可以评论留言.

4.1 开发的通用痛点

  • CRUD占了80%的时间
  • 接手别人的代码
  • 改了一处代码,引发了10个线上bug
  • 联调时上游改接口并未及时周知调用方

4.2 开发神器

主要以java体系为准, 欢迎大家补充其他语言的

问题工具推荐神器推荐理由
CRUD低代码平台ruoyi,jeecg基础表单生成,代码生成,工作流配置
接手代码业务流程+自动生成依赖关系《重构》, IntelliJ,SequenceDiagram重构是项技术活,可以参考《重构》一书进行;工具上推荐IntelliJ自带的Diagram 和 SequenceDiagram可以自动生成类图和时序图, 帮助开发人员快速全局掌握相关依赖
修改代码带来未知影响单元测试Spock,testNg很多严重的线上问题其实都是由于这种情况导致的,这里建议大家养成良好的单元测试习惯,Spock框架可能有一定学习成本,但是上手起来效率非常高,单测神器推荐大家
联调修改接口契约变更自动推送apifox,swaggerHub当前市场并未有特别好的工具,这里建议大家基于apifox或者swaggerHub二次开发实现变更通知功能

5 测试

互联网行业其实对单独的测试依赖越来越弱,很多硅谷知名公司(亚马逊,微软)都已经不再招聘单独的测试人员,把测试相应的工作进行测试左移和右移,交给研发人员来保证线上质量

个人由于并非测试出身,这里也是简单列举几个测试相关问题和推荐工具,希望测试大佬帮忙补充。

5.1 测试痛点

  • 用例管理混乱
  • 测试数据生成费时
  • 测试环境通过,线上环境全是bug
  • 性能测试、真实流量测试、混沌测试推行困难

5.2 测试神器

问题工具推荐神器推荐理由
用例管理混乱在线管理平台apifox,MeterSphere测试用例管理, 自动化测试集成等功能都有相应的集成
测试数据生成费时数据Mock服务apifox,Yapi,等mock平台这里推荐apifox可以利用自动生成接口注释,生成对应的api的mock数据
测试环境通过,线上环境全是bug快速搭建测试环境基于k8s自研一套快速搭建全量环境的平台;灰度发布平台一般来说发生测试环境通过,线上全是bug,就两种情况;1,环境配置不一样;2,数据依赖不一致;解决方案就是利用k8s尽量保证线下和线上配置一致,自己的测试环境定期同步线上数据,方便进行测试,同时上线时利用灰度发布系统或者abtest系统进行测试
联调修改接口契约变更自动推送apifox,swaggerHub当前市场并未有特别好的工具,这里建议大家基于apifox或者swaggerHub二次开发实现变更通知功能

6 运维

运维工作的神器不要太多, 这里也是简单列举几个最常用的工具,最好能结合开发和测试的工具平台整合起来

6.1 运维痛点

  • 每次上线需要跟到很晚
  • 线上问题定位困难
  • 多云资源管理
  • 审计及费用计算

6.2 运维神器

问题工具推荐神器推荐理由
每次上线需要跟到很晚CICD系统,devops系统erda,kubesphere, 基于jenkins二次开发有很多开源的CICD平台,这里推荐erda,主要是和项目管理测试管理集成比较好,默认支持云原生及虚假发布,代码全开源方便二开
线上问题定位困难APM 和线上诊断工具pinpoint,skywalkiing,arthas都是老牌开源的apm工具,谁用谁知道,强烈推荐
多云资源管理资源管理系统kubesphere,腾讯蓝鲸cmp更其他功能结合较好,但是缺少费用统计功能
审计,成本费用计算资源管理系统等待各位大佬推荐

7 数据运营

7.1 数据神器

问题工具推荐神器推荐理由
报表产出速度周级别自助报表平台metabase,superset,redash个人推荐metabase原因的话就是好看。。这三款基本能都能满足日常使用
异构数据转换多数据源转换datax阿里开源老牌产品够日常使用
科研数据分析困难数据分析工具pandas文档齐全,满足日常使用

8 其他

分类神器推荐理由平台
办公uTools插件工具包括在线翻译、网页快开、剪切板、表情包斗图、取色工具、图片压缩、文字识别、编码小助手、二维码生成器、开发文档、钉钉网页版等all
WPS基本上各项功能完爆老版officeall
有道云笔记云笔记中功能和费用相对较好的产品,对比印象个人用习惯了有道;而且可以科学上网你懂得all
百度翻译截图翻译功能真的是神器,只有百度的支持全平台,其他翻译软件只有winall
xiaopiu超好用的原型设计工具all
processon超好用的在线画图工具all
vmvare fusioin比vb好用的虚拟机mac
理财通达信专业炒股软件,普通版功能不如同花顺但是性能完爆同花顺all

等等等…………等待各位大佬补充

Reference

  • 高效研发:硅谷研发效能方法与实践 - 葛俊
  • 可信云-软件研发效能度量评估
  • 阿里云研发效能分享
  • Jeffery

附录

PS: 不好意思各位, 前端时间一直在准备MBA毕业论文和准备换工作, 术篇耽搁了许久,而且对于器的使用并没有进行详细介绍. 欢饮大家私信进行交流~


转载请标明出处