产品开发管理之流程和体系（总篇）
前言
秋风瑟瑟，夏日的灼热犹在，就瞬间迎来刺骨寒风。凛冬将至，今天对我们来说，像贴面的利刃一样冰冷而真实。农民、建筑工人、司机、程序员、私企高管、私企老板、资本巨富，都被裹挟进了这个焦灼的时代，没有人能独善其身。
焦灼无法解决任何问题，这一次的风雪也并不会比以往的更为凛冽，唯有勇于踏雪前行者，才能迎来春天。这对于踏实肯干的互联网研发企业来说，未必不是一件幸事——只要度过寒冬，来年我们会走得更远！
三架火箭
先有鸡还是先有蛋？我们不去探讨这个问题，但是如果你家母鸡都没喂大，就想买蛋赚钱，这是一个问题。
产品研发就如养鸡，鸡大才有蛋，鸡好才是真的好，鸡长得快风险和成本才会更小，因此产品开发和管理才是重中之重。
如何解决产品研发中的“控风险、缩周期、降成本”的痛点？每个人都会有每个人的反思和总结，而我们有了本篇的反思和总结。
根据我们多年的开发和管理经验，在降低生产成本、提高生产效率和保障生产质量的角度上，我们提出了“三架火箭”的概念，即：
- 框架和组件
- 工具
- 流程和体系
值得注意的是，三大宝剑，哦三架火箭只是我们的心血总结，希望能给大家一些帮助以及和大家共同探讨，但是在一个产品团队中，管理者不能忽视的一点是——以人为本。
框架和组件
对于一个软件公司或者互联网公司来说，开发成本是一个公司不得不说的痛，因为其在前期几乎是全部的成本，而一旦功败垂成，则片甲不留——打水漂可能还能听几个响。而约定一个统一的框架和技术体系，对于一个开发团队来说，这就是一个团队的积累和财富！这就是让你的团队继续鏖战的基础！
拥有一套统一的优秀的企业级开发框架意味着有如下好处：
- 意味着统一了主体的技术体系，可以最大限度的减少后续的开发、维护、扩展成本。
- 意味着拥有了一套成熟的解决方案。
- 意味着保障了代码的稳定性、延续性和可持续开发，而不是代码全家桶。很多初创团队的产品的初始代码来自于五湖四海（各自成员的前公司的代码段或技术积累），当开发到一定程度，随着人员的交替，维护和扩展几乎不在可能。一份好的代码是一个产品的根本，否则后续的产品开发都将无从下手。 这里分享一下世上最烂代码的结果：史上最烂代码。
- 极大的提高了产品的生产效率。
- 建立有效的开发、知识、体系积累。软件开发是一种知识活动，因此知识的聚集和积累是至关重要的。框架能够采用一种结构化的方式对某个特定的业务领域进行描述，也就是将这个领域相关的技术以代码、文档、模型等方式固化下来。
- 减少重复开发。简单的说，大大提高了代码的复用性。毕竟每次打仗都要临阵磨枪，耽误时间不说，质量和速度都没法保障。
- 有利于提高团队水平。框架往往有相应的规范、约定、设计模式、理念、技术点，通过框架的源代码既可以输出开发和技术理念，提高团队成员的水平，又可以规范代码，而且可以降低程序员之间沟通以及日后维护的成本。
- 提高软件质量。
- 提高企业的竞争能力，包括降低成本、提高质量、改善客户满意程度、控制进度等方面。
- 有利于团队多人协作和分工合作。架构师专注于设计框架、组件、领域模型等；软件开发人员专注于业务逻辑，以及业务的更深程度的分析和挖掘；前端人员更专注前端交互（前后端分离）体验。
当然，任何事物都需要多方面权衡，我们也要看到一些问题。比如前期需要付出培养成本，框架的理念以及先进性会限制团队的理念和先进性等等，但是对于企业和创业团队来说，持续的成本控制是第一位的。
这里奉送中小团队一句箴言——你可以没有自己的框架，但是一定要有统一的技术体系。
最后，附上我们团队的框架和组件库地址，均已开源。拥抱开源一直是我们团队的核心理念之一。
团队框架地址：https://gitee.com/xl_wenqiang/Magicodes.Admin.Core
团队组件库地址：https://github.com/xin-lai/
后续文章我们会继续分享我们在框架和组件这块的理念和经验。
工欲善其事必先利其器
框架只是意味着不要从零开始编码，而配套的工具则能更好的提高团队沟通和协作能力、提高编码速度以及减少低级代码的编写。工具分为办公软件、开发工具、管理软件和开发辅助工具。
我们可以初步确定以下两个原则：
- 统一的环境、工具和软件
- 善用工具
在这块，我们也有挺多我们的心得，这块，我们后面再详聊。
流程和体系
流程体系旨在于提高工作效率，明确流程接口和步骤，确定相关岗位或者相关事务的要求、原则、规则。
流程
工作流程是工作效率的源泉,流程决定效率，流程影响效益。好的产品流程能够使团队各项工作良性开展，从而保证团队的高效运转，相反地，差的流程则会问题频出，出现角色间、人员间职责不清相互推诿等现象，从而造成资源的浪费和效率的低下。因此，设计、建立科学、严谨的产品流程并保持这些流程得到有效执行、控制和管理，对一个企业、一个部门或团队至关重要。
产品流程需要标准化！ 一个产品团队都有不同的工作、不同的岗位，并且需要相应的人员来完成。然而，不同的产品流程就会有不同的效率，进而言之，就会对整个产品产生不同的影响。因此，我们需要将产品流程标准化，就是要分析某一工作的性质和类型，在其基础上对相应的工作设立对应的岗位或角色，并且安排具体的工作者来承担。即“一个萝卜一个坑”，无论何时在某个节点或步骤上出现了工作的失误都能迅速且准确地找到责任人，这样可以有效地防止相关工作的不同岗位间、角色间的互相扯皮、踢皮球的现象。
注意：上面虽然提及“一个萝卜一个坑”，但是并不代表一个人不能多个坑。一个坑代表的是职责的明确，而不是一个岗位。另外，笔者也非常推崇产品开发团队成员尽可能是全栈工程师。
产品流程方面，一般推荐完成以下流程：
- 产品开发流程
- 产品反馈流程
- 产品上线流程
体系
对于一个软件公司来说，产品管理开发体系极为重要。这也是一个公司的软实力的体现。
技术体系
这里借用秦统一文字和货币的部分意义，来说明统一技术体系的意义：
- 有利于团队的沟通，维护团队的统一和促进团队文化的发展。
- 巩固了团队技术管理的统治，维护了产品技术体系的统一。
- 降低开发人员离职风险。这里特别说明一下，编程不比其他职业，不同的编程语言、框架体系、设计风格、编码风格决定着不同的上手门槛和成本。门槛达不到，那就是不行。上手成本高，那就必须付出相应的代价。既无法取巧，亦无法越过。
老秦可以走了，我们继续。重要的话说三遍，你可以没有自己的框架，但是一定要有统一的技术体系。
除了技术体系之外，我们还应该完善设计体系、测试体系、运维体系和运营体系。
规范
古人云，“先学规矩后学艺”，在产品开发领域亦是如此。从设计到开发，测试甚至运维运营，都应该有对应的规范。毕竟，有章可循，有据可依，有正确的产品流程规范，我们的工作才不至于产生混乱，团队的工作才能更有成效。
正确的规范有哪些好处呢？笔者认为主要有以下几点：
- 提高团队的工作/开发效率，便于团队更协调、有效运作；
- 端正成员工作态度，体现团队精神；
- 对人员进行有效管理；
- 有效降低沟通、管理成本；
- 提高成员修养和能力；
- 积累团队经验，促使团队健康发展；
因此规范的建立不能随手照搬照抄，需要根据企业以及团队现状，不断地思索、总结、积累，然后建立适合自己的行之有效的规范。同时还要注意两点：
- 规范重在执行，如果只是自欺欺人，那么规范将无丝毫意义。
- 规范从来不是一成不变的，企业或团队在发展的过程中，一定要不断更新和完善自己的规范。
关于规范这块，我们可以根据产品开发运营的生命周期进行细化，落实到点子上，比如团队规范、API设计规范、前端规范、源代码管理要求和规范等等。这些在后续的文章中，我们再来共同完善。
理念
先进的理念是团队产品开发管理的指导思想，是团队成功的关键，亦能促使团队成长和奋进。在产品开发管理之中，笔者接下来或逐步和大家分享以下理念：
- 精益创业
- 同理心
- 自我刷新
- 全栈工程师
- 开源
- 敏捷开发
- 渠道集成
- 单一职责
- 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流程。当然最重要的是，要将团队的沟通能力、协作能力、包括技术水平提升起来，这才是实行敏捷的前提。
会议体系
会议一直会贯穿产品开发管理的整个过程，笔者倡导以下会议：
- 站立会议
- 规划会议
- 反思会议
- 评审会议
接下来，笔者将会和大家一起分享这些会议的细节，比如目的、要求、内容。
写在最后
本篇仅是抛砖引玉，我们接下来会将我们这些年的经验、总结和反思一点一滴的分享出来，期待和大家共同进步，多多交流！