前言
秋风瑟瑟,夏日的灼热犹在,就瞬间迎来刺骨寒风。凛冬将至,今天对我们来说,像贴面的利刃一样冰冷而真实。农民、建筑工人、司机、程序员、私企高管、私企老板、资本巨富,都被裹挟进了这个焦灼的时代,没有人能独善其身。
焦灼无法解决任何问题,这一次的风雪也并不会比以往的更为凛冽,唯有勇于踏雪前行者,才能迎来春天。这对于踏实肯干的互联网研发企业来说,未必不是一件幸事——只要度过寒冬,来年我们会走得更远!
三架火箭
先有鸡还是先有蛋?我们不去探讨这个问题,但是如果你家母鸡都没喂大,就想买蛋赚钱,这是一个问题。
产品研发就如养鸡,鸡大才有蛋,鸡好才是真的好,鸡长得快风险和成本才会更小,因此产品开发和管理才是重中之重。
如何解决产品研发中的“控风险、缩周期、降成本”的痛点?每个人都会有每个人的反思和总结,而我们有了本篇的反思和总结。
根据我们多年的开发和管理经验,在降低生产成本、提高生产效率和保障生产质量的角度上,我们提出了“三架火箭”的概念,即:
框架和组件
工具
流程和体系
值得注意的是,三大宝剑,哦三架火箭只是我们的心血总结,希望能给大家一些帮助以及和大家共同探讨,但是在一个产品团队中,管理者不能忽视的一点是——以人为本。
框架和组件
对于一个软件公司或者互联网公司来说,开发成本是一个公司不得不说的痛,因为其在前期几乎是全部的成本,而一旦功败垂成,则片甲不留——打水漂可能还能听几个响。而约定一个统一的框架和技术体系,对于一个开发团队来说,这就是一个团队的积累和财富!这就是让你的团队继续鏖战的基础!
拥有一套统一的优秀的企业级开发框架意味着有如下好处:
意味着统一了主体的技术体系,可以最大限度的减少后续的开发、维护、扩展成本。
意味着拥有了一套成熟的解决方案。
意味着保障了代码的稳定性、延续性和可持续开发,而不是代码全家桶。很多初创团队的产品的初始代码来自于五湖四海(各自成员的前公司的代码段或技术积累),当开发到一定程度,随着人员的交替,维护和扩展几乎不在可能。一份好的代码是一个产品的根本,否则后续的产品开发都将无从下手。 这里分享一下世上最烂代码的结果:史上最烂代码。
极大的提高了产品的生产效率。
建立有效的开发、知识、体系积累。软件开发是一种知识活动,因此知识的聚集和积累是至关重要的。框架能够采用一种结构化的方式对某个特定的业务领域进行描述,也就是将这个领域相关的技术以代码、文档、模型等方式固化下来。
减少重复开发。简单的说,大大提高了代码的复用性。毕竟每次打仗都要临阵磨枪,耽误时间不说,质量和速度都没法保障。
有利于提高团队水平。框架往往有相应的规范、约定、设计模式、理念、技术点,通过框架的源代码既可以输出开发和技术理念,提高团队成员的水平,又可以规范代码,而且可以降低程序员之间沟通以及日后维护的成本。
提高软件质量。
提高企业的竞争能力,包括降低成本、提高质量、改善客户满意程度、控制进度等方面。
有利于团队多人协作和分工合作。架构师专注于设计框架、组件、领域模型等;软件开发人员专注于业务逻辑,以及业务的更深程度的分析和挖掘;前端人员更专注前端交互(前后端分离)体验。
当然,任何事物都需要多方面权衡,我们也要看到一些问题。比如前期需要付出培养成本,框架的理念以及先进性会限制团队的理念和先进性等等,但是对于企业和创业团队来说,持续的成本控制是第一位的。
这里奉送中小团队一句箴言——你可以没有自己的框架,但是一定要有统一的技术体系。
最后,附上我们团队的框架和组件库地址,均已开源。拥抱开源一直是我们团队的核心理念之一。
团队框架地址:https://gitee.com/magicodes/Magicodes.Admin.Core
团队组件库地址:https://github.com/xin-lai/
后续文章我们会继续分享我们在框架和组件这块的理念和经验。
工欲善其事必先利其器
框架只是意味着不要从零开始编码,而配套的工具则能更好的提高团队沟通和协作能力、提高编码速度以及减少低级代码的编写。工具分为办公软件、开发工具、管理软件和开发辅助工具。
我们可以初步确定以下两个原则:
统一的环境、工具和软件
善用工具
在这块,我们也有相关分享:
工欲善其事必先利其器——办公篇
参见我司公众号文章:
工欲善其事必先利其器——开发篇
参见我司公众号文章:
工欲善其事必先利其器-产品篇
参见我司公众号文章:
最后
掌握基本的工具是有必要的。比如对于前端开发来说,学会使用至少一个浏览器的开发者工具是必要的。合理的使用,会让整体工作更顺畅。
但不要执迷于工具。工具能将效率提升到某个量级,但很快就会碰触天花板。真正的效率突破,不在工具上。
提高效率的核心,是去找到效率的「梗」。工具只是辅助,加班也只是临时措施。从「梗」上去探寻,才能实现效率的真突破。
流程和体系
流程体系旨在于提高工作效率,明确流程接口和步骤,确定相关岗位或者相关事务的要求、原则、规则。
流程
工作流程是工作效率的源泉,流程决定效率,流程影响效益。好的产品流程能够使团队各项工作良性开展,从而保证团队的高效运转,相反地,差的流程则会问题频出,出现角色间、人员间职责不清相互推诿等现象,从而造成资源的浪费和效率的低下。因此,设计、建立科学、严谨的产品流程并保持这些流程得到有效执行、控制和管理,对一个企业、一个部门或团队至关重要。
产品流程需要标准化! 一个产品团队都有不同的工作、不同的岗位,并且需要相应的人员来完成。然而,不同的产品流程就会有不同的效率,进而言之,就会对整个产品产生不同的影响。因此,我们需要将产品流程标准化,就是要分析某一工作的性质和类型,在其基础上对相应的工作设立对应的岗位或角色,并且安排具体的工作者来承担。即“一个萝卜一个坑”,无论何时在某个节点或步骤上出现了工作的失误都能迅速且准确地找到责任人,这样可以有效地防止相关工作的不同岗位间、角色间的互相扯皮、踢皮球的现象。
注意:上面虽然提及“一个萝卜一个坑”,但是并不代表一个人不能多个坑。一个坑代表的是职责的明确,而不是一个岗位。另外,笔者也非常推崇产品开发团队成员尽可能是全栈工程师。
产品流程方面,一般推荐完成以下流程:
产品开发流程
产品反馈流程
产品上线流程
体系
对于一个软件公司来说,产品管理开发体系极为重要。这也是一个公司的软实力的体现。
技术体系
这里借用秦统一文字和货币的部分意义,来说明统一技术体系的意义:
有利于团队的沟通,维护团队的统一和促进团队文化的发展。
巩固了团队技术管理的统治,维护了产品技术体系的统一。
降低开发人员离职风险。这里特别说明一下,编程不比其他职业,不同的编程语言、框架体系、设计风格、编码风格决定着不同的上手门槛和成本。门槛达不到,那就是不行。上手成本高,那就必须付出相应的代价。既无法取巧,亦无法越过。
老秦可以走了,我们继续。重要的话说三遍,你可以没有自己的框架,但是一定要有统一的技术体系。
除了技术体系之外,我们还应该完善设计体系、测试体系、运维体系和运营体系。
设计体系
推荐Ant Design设计体系。见:https://ant.design/docs/spec/introduce-cn
蚂蚁的企业级产品是一个庞大且复杂的体系。这类产品不仅量级巨大且功能复杂,而且变动和并发频繁,常常需要设计与开发能够快速的做出响应。同时这类产品中有存在很多类似的页面以及组件,可以通过抽象得到一些稳定且高复用性的内容。
随着商业化的趋势,越来越多的企业级产品对更好的用户体验有了进一步的要求。带着这样的一个终极目标,我们(蚂蚁金服体验技术部)经过大量的项目实践和总结,逐步打磨出一个服务于企业级产品的设计体系
Ant
Design。基于『确定』和『自然』的设计价值观,通过模块化的解决方案,降低冗余的生产成本,让设计者专注于更好的用户体验。
- 设计资源
阿里提供了完善的设计原则、最佳实践和设计资源文件(Sketch 和
Axure),来帮助业务快速设计出高质量的产品原型。
前端实现
阿里采用 React 封装了一套 Ant Design
的组件库,同时也有其他框架的实现版本。
Ant Design of React(官方实现)
谁在使用
规范
古人云,“先学规矩后学艺”,在产品开发领域亦是如此。从设计到开发,测试甚至运维运营,都应该有对应的规范。毕竟,有章可循,有据可依,有正确的产品流程规范,我们的工作才不至于产生混乱,团队的工作才能更有成效。
正确的规范有哪些好处呢?笔者认为主要有以下几点:
提高团队的工作/开发效率,便于团队更协调、有效运作;
端正成员工作态度,体现团队精神;
对人员进行有效管理;
有效降低沟通、管理成本;
提高成员修养和能力;
积累团队经验,促使团队健康发展;
因此规范的建立不能随手照搬照抄,需要根据企业以及团队现状,不断地思索、总结、积累,然后建立适合自己的行之有效的规范。同时还要注意两点:
规范重在执行,如果只是自欺欺人,那么规范将无丝毫意义。
规范从来不是一成不变的,企业或团队在发展的过程中,一定要不断更新和完善自己的规范。
关于规范这块,我们可以根据产品开发运营的生命周期进行细化,落实到点子上,比如团队规范、API设计规范、前端规范、源代码管理要求和规范等等。这些在后续的文章中,我们再来共同完善。
Git工作流和分支规范推荐
无论是开源项目还是内部项目,使用Git都是大势所趋。因此,针对Git的工作流和分支使用,本篇进行了一些推荐:
Git工作流模型推荐
Git产品开发分支规范要求
在产品开发或者复杂项目开发,我们推荐严格遵循此规范进行开发。对于中小项目和个人开发,您可以按需来设计自己的规范和要求。
永久分支
master(稳定版)
主分支,主分支只用来发布重大版本。所有提供给用户使用的正式版本,都在这个主分支上发布。
开发版(develop)
日常开发应该基于此分支来完成。
如果想正式对外发布,就在Master分支上,对Develop分支进行”合并”(merge)。
临时性分支
除了永久分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。临时性分支主要有三种:
功能(feature)分支
预发布(release)分支
修补bug(hotfix)分支
这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。
功能(feature)分支
功能分支,它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。
功能分支的名字,请采用feature/feature1 的形式命名。
预发布(release)分支
预发布分支,它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。它的命名,请采用release/release1的形式。
修补bug(hotfix)分支
修补bug分支。软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,请采用hotfix/fixbug1的形式。
代码分支提交使用规范
使用Git过程中,必须通过创建分支进行开发,坚决禁止在主干分支上直接开发。review的同事有责任检查其他同事是否遵循分支规范。
在Git中,默认是不会提交空目录的,如果想提交某个空目录到版本库中,需要在该目录下新建一个
.gitignore 的空白文件,就可以提交了把外部文件纳入到自己的 Git
分支来的时候一定要记得是先比对,确认所有修改都是自己修改的,然后再纳入。提交时,一定要填写有意义的注释。注释内容要求如下:第一行为提要,然后逐行罗列出功能点、主要变动、以及需要注意的问题等等。具体如下所示:
注释提交模板:
> 简要说明(第一行)
> (空行)
> 1.(要点)
> 2.(要点)
注释提交参考:
> 后台菜单管理增加区域菜单功能,修复日志记录器若干问题
> 1.后台菜单管理增加区域菜单功能,目前分为系统平台和租户平台,根据属性MenuPlatform来设置
> 2.增加若干系统管理菜单
> 3.完善菜单模块,以便加载不同平台菜单
> 4.修复日志记录器为NULL的情形
理念
先进的理念是团队产品开发管理的指导思想,是团队成功的关键,亦能促使团队成长和奋进。在产品开发管理之中,笔者接下来或逐步和大家分享以下理念:
精益创业
同理心
自我刷新
全栈工程师
开源
敏捷开发
渠道集成
单一职责
IaaS、PaaS、SaaS
DDD(领域驱动(Domain-Driven Design))
TDD(测试驱动开发(Test Driven Development))
CI(持续集成(Continuous Integration))
CD(持续交付(Continuous Delivery))
微服务(Microservices Architecture)
RESTful(Representational State Transfer)
前端工程化
All in code(作者提出)
这里先优先侧重简单地说下敏捷开发,因为在整个产品的生命周期之中,开发一直是基础中的基础,而开发模式和管理模式对互联网产品影响深远。
敏捷开发(Agile
Development)是一种以人为核心、迭代、循序渐进的开发方法。目标是提高开发效率和响应能力。
敏捷从来不是一件容易的事情,俗话说,“天下武功,唯快不破”,但是这快并不好实现。敏捷开发在很多情况下是一种愿景,在国内落地比较难,但是因难而不往,就会一直错失快速开发和快速迭代的能力,产品竞争力也会不够(产品竞争力应该包含产品迭代速度),而且还会因为不能适应快鱼法则而被淘汰。
敏捷开发的实施不能一蹴而就,比较讲究天时地利人和。对于一个初创团队,如果理念以及技术水平相近,团队沟通协调能力不错,这时候实行敏捷开发就会事半功倍。但是敏捷开发是不能生搬硬套的,否则就会水土不服,每一个团队应该视自身情况打造自身的敏捷流程,而不是硬生生的套用Scrum流程。当然最重要的是,要将团队的沟通能力、协作能力、包括技术水平提升起来,这才是实行敏捷的前提。
会议体系
会议一直会贯穿产品开发管理的整个过程,笔者倡导以下会议:
站立会议
规划会议
反思会议
评审会议
站立会议
敏捷的核心在人和沟通。而站立会议是开发团队日常沟通的一个短会。
目的:团队成员间工作进度的沟通和协调;帮助团队聚焦于每日活动,并且便于更新任务板和燃尽图;细化任务,尽可能的将任务具体到天,让大家都明确知道今天应该做什么!
时间:建议每日早晨10点,时长控制在15分钟左右。
内容:
从上次站立会议到现在,你完成了什么?
从现在到下次站立会议,你将要做什么?
你遇到什么阻碍,需要其它人如何帮你?
注意:不要迟到,延时,或者坐下,另外不要在会议中讨论技术细节以及沟通需求。
提示:团队成员在聆听他人发言时,都应该想这个问题:“我该怎么帮他做得更快?”
迭代规划会议
迭代规划会议是指在每轮迭代开始时进行的规划会议,定义本轮迭代的目标,承诺本轮迭代中要完成的工作,提前识别和评估可能出现的风险,并通过合理的估算调整项目的迭代范围。
目标:制定合理的迭代范围和目标;明确迭代的开发任务。
要求:如无特殊原因,产品团队利益相关者均需参加;会议召开前,会通知所有利益相关者具体开会时间。
内容:会议只讨论下次迭代内容以及任务优先级,并不涉及工作量的评估以及时长的评估。
会议结果:明确迭代范围与目标,明确此次迭代的开发任务。
评审会议
在每次冲刺结束,我们都需要进行一次评审会议,让团队向产品负责人和利益相关者展示已完成的功能。也就是“所有的sprint(冲刺)都结束于演示”!
目标:
加强团队的自我认可。
展示功能、回答利益相关者对展示的疑问并记录所期望的更改与反馈。
评审会议可以吸引相关利益者的关注,让其他人了解团队在做些什么,并得到重要反馈。
做演示也会迫使开发团队真正完成一些工作(比如那些完成了99%的功能)。
时间:每一次冲刺完成时根据情况召开。
要求:
团队成员均可主持。必须准备PPT,可以很粗糙,但是必须有条理。
确保所有人员都清晰目标,如果有人对产品不知道,则花几分钟来进行描述。
团队根据本次迭代内容,逐个地介绍这次 Sprint 的结果,和演示新功能。
会议过程中,需要记录需求变更、新想法、新需求、Bug或问题以及障碍。
如果功能无法演示,则以报表或者报告甚至其他任意形式证明。
会议结果:对这次 Sprint 的结果和整个产品的开发状态的共识。
注意:
让演示关注业务层次,不要关注技术细节。注意力放在“我们做了什么”,而不是“我们怎么做的”。
有的sprint可能会包含很多bug修复等功能,在评审会议中不要演示太多一大堆细碎的bug修复,除非这个很重要。
反思会议
根据项目需要举行。其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。项目成员均可召开与推进。
要求:
从过去中学习,指导将来;
改进团队的生产力。
轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法,他认为什么是好的,哪些可以做的更好,哪些需要改变。
注意:
不要让业务管理人员参与会议。
不要在团队之外讨论找到的东西。
会议内容:
过去哪些做的不错?哪些应该改进?
我们能做什么?哪些不在我们掌控之内?
意见交流
代码规范
见《C#代码编写规范》
其他的待补充