软件产品开发流程

在大公司当零件当久了，习惯了坐井观天，看问题容易停留在事物的某一方面。就软件工程师而言，作为最常见最容易被替换的零件之一，因个人的能力和级别不同，接触到的项目内容也会不同。一般都是级别高的工程师负责整体架构和流程设计，然后各个组件再分给其他级别低些的去设计和实现。所以不少工程师都不甚了解产品开发的整体流程，一个产品从需求到上线都经历了哪些阶段。这篇文章根据本人所接触过的不同部门的开发流程，整理出一个个人认为比较通用的产品开发流程。



1. PR/FAQ

PR/FAQ指的是Press Release（新闻稿）和Frequently Asked Questions（常见问题）（参见[1]）。当产品还只是PM（Product Manager）脑子里的雏形的时候，PR/FAQ是最好的展现方式。它假设产品已经开发完成准备发布。PR就是产品发布会的新闻通稿，它从用户的角度展示产品的特别之处，比如该产品提高了用户的工作效率或者帮用户节省了成本。PR的写作方式有很多，但都停留在产品和用户本身，而不涉及开发和实现的细节。FAQ是对PR的补充，针对PR中未涉及的问题做了详细解答，对产品做更深一层的诠释。FAQ可以分成public和internal的。Public FAQ从用户的角度解答一些用户可能会关注的问题。Internal FAQ则从stakeholder的角度，比如PM团队和开发团队，解答一些涉及到功能和实现的问题。

主要参与方：产品经理。



2. Business Requirements

仅凭一份PR/FAQ，开发团队是无法开始设计和实现产品的。PM们需要从PR/FAQ出发，拟出一份详细的商业需求（Business Requirements）清单，从产品的功能和特性角度详细剖析产品本身。Business Requirements不应涉及技术实现细节。

主要参与方：产品经理，项目经理，高级工程师



3. Technical Requirements

有了Business Requirements，PM和开发团队合作，着手开始Requirement Engineering，将商业需求转换成技术需求，用开发团队能理解的表述方式详述产品的技术实现要求。

主要参与方：产品经理，项目经理，高级工程师



4. Architecture Design & Review

Technical Requirements出来之后，开发团队可以开始产品的架构设计（Architecture Design ）。架构设计提供了一个宏观（high-level）抽象（abstract）的系统设计方案，用于实现并支持产品的功能与服务。比如整个系统有哪些组件，服务要用AWS还是GCP部署，需要用到什么样的数据库(SQL/Non-SQL)，等等。架构设计的好坏，奠定了产品未来若干年的技术实现方案，直接影响到后期的开发和维护。通常，架构设计不能仅凭个别工程师的一家之言，而需要经过若干轮的评审（Review），评审方主要是level更高的工程师和经理们。评审的目的验证架构的可行性，借助别人的经验发现潜在的问题。

主要参与方：产品经理，项目经理，高级工程师，开发团队



5. Component Design & Review

架构设计提供了宏观的技术实现方案，并定义了系统里的各个组件以及它们的功能，但没具体到每个组件的设计。组件设计（Component Design）阶段，根据定义好的组件功能，提供切实可行的技术实现方案。组件设计应该有开发团队完成，而且组件设计通常不需要再经level更高的stakeholder来评审，组内评审应该就足够了。除非有一些比较难搞的技术问题和选型，需要高级工程师们的观点。

主要参与方：项目经理，高级工程师，开发团队



6. Implementation

万事具备，可以着手写代码了。实现（Implementation）阶段根据系统和组件的设计方案，搭环境，开发代码，测试，部署，等等。为了提高开发效率，开发团队应该花时间搭建CI/CD/CD（Continuous Integration/Continuous Delivery/Continuous Deployment，持续集成，交付与部署) 软件开发环境，一劳永逸。

需要指出的是，实际开发过程中，经常会发现系统设计和组件设计方案里有一些不妥或难以实现的地方，这种情况下，就需要回访之前的设计做必要的调整和修改。

主要参与方：项目经理，开发团队



7. Security Review

在产品信息安全日益重要的今天，Security Review（安全评审）应该成为至关重要的一环。安全评审的主要目的是对产品的设计和实现进行安全审核，确保产品没有安全漏洞，防止产品当机或者服务失效，同时也防止用户信息泄漏。我们已经见过太多的产品安全事故，比如明文密码，权限漏洞等等。本人曾担任过一段时间的Security Certifier，深知Security Review在产品开发和发布的重要性。

主要参与方：项目经理，开发团队，安全评审员



8. Test Plan / Tests

开发阶段所写的代码都应该有足够的单元测试（Unit Test），组件之间也应该有集成测试（Integration Test），但只有单元和集成测试是不够的。Test Plan是详细列出所有需要做的测试和执行方案，除了Unit和Integration Tests，端到端测试（End-to-End Test)，金丝雀测试（Canary Test），负载测试（Load Test），等等。只有足够的测试，才能确保持续交付的代码质量，防止生产事故出现。此外，开发团队应该投入足够的时间让测试自动化，这也是CI/CD/CD的前提之一。手动测试效率低，容易出错。

主要参与方：项目经理，开发团队，测试团队



9. Operation Review

开发完成了，测试妥当了，产品可以发布了。但是产品发布之后，如何确保产品的安全运行，如何实时了解产品的运行状态及时发现并解决潜在的问题？很多情况下，开发团队急着发布产品，而没有考虑到后期运维。Operation Review（运维评审）从运维的角度来审核产品是否真是ready了，比如产品是否做过性能（Performance）和负载（Load）测试，是否有足够的日志（Logging）来支持调试和故障排除，是否有足够的性能指标（Metrics）显示产品的运营转台，是否有考虑到异常的流量以及应对措施，等等。

主要参与方：项目经理，开发团队，测试团队，运维团队



9. Internal Availability

如果一个有内部其他服务需要使用即将发布的产品，在产品发布之前，应该和关联的其他服务先做集成。Internal Availability (IA)（内部可用）阶段集中在与其他内部服务的集成上，这也是在给产品做发布前的最后一道测试。只有确认产品内部可用了，才能继续发布流程。

主要参与方：项目经理，开发团队，其他服务的开发团队



10. General Availability

IA之后，开发团队应该再过一遍Launch Plan上的待办清单，确保产品可以发布了。这一阶段称为General Availability (GA)（一般可用）。GA阶段把产品假设成已发布状态，产品和运维已经待命。比如说，这时候监控系统应该开始运作，开发团队也须有人24小时轮班盯着产品的运行状态。

主要参与方：项目经理，开发团队，运维团队



11. Launch

万事真的具备了，发布吧。

主要参与方：项目经理，开发团队，运维团队，产品经理



12. Operations/Maintenance

发布之后，不出意外，会有各种个样或大或小的问题，产品也进入运维阶段。新三年，旧三年，缝缝补补又三年。

主要参与方：项目经理，开发团队，运维团队



参考文章：

[1] PR FAQs for Product Document: https://medium.com/pminsider/press-releases-for-product-managers-everything-you-need-to-know-942485961e31