极狐产品 Handbook，是关于我们如何在极狐(GitLab)管理产品的策略，方向，方法和相关的工作规范。
目前极狐产品的管理团队，由 CTO Office 成员组成，在每周五的 CTO Office Sync 进行内部的产品规划讨论。
| 姓名 | 角色 |
|---|---|
| Ben Lin | CTO |
| Liang Peng | Product Manager |
| Qiang Guo | Product Manager |
| Jing Liu | Product Manager |
| Weifeng Liu | Chief Architect |
| Xudong Guo | Cloud Architect |
| Yongfan Shen | UX Designer |
| Lizhi Wu | Security Architect |
遵循着极狐(GitLab)的使命"本土驱动，回馈社区"和愿景"根植中国，繁荣生态"，极狐的整体产品建设也是围绕着中国本土的市场特色与需求，进行深入挖掘与建设。
据统计，中国有超过600万的软件开发工程师，并以每年16.5%的增速保持增长，极狐(GitLab)有着非常庞大的用户市场。
另一方面，根据中国软件产业协会的数据，SaaS在中国的企业级软件市场已超过20%，但相较于全球市场的 SaaS 比例，中国的 SaaS 市场仅处于开始阶段，是极狐(GitLab)非常重视的未来市场。
在前面的背景介绍中，我们已经阐述了对中国 SaaS 市场的重视，我们希望通过 SaaS 让客户有效地降低运营成本，不用费心版本升级就能使用最新的功能，还能保证产品服务的高可用性，这些都是我们希望通过 SaaS 来带给用户的便利和优势。
为此，极狐在创始之初，就投入了最多的资源和力量来建设 jihulab.com，基于本土的基础设施和服务进行了重构，之后也会持续根据中国市场的特色和需求进行 SaaS 产品功能的开发和优化。
在中国有很多 CE/EE 版本（GitLab Inc. 版本）的产品用户，我们的目标是让这些用户转化到 JH 版本（极狐版本），为此，极狐在产品开发上要强化社区版和企业版的特色功能，能让中国现有的 CE/EE 版用户感受到极狐产品更贴合他们的需求和使用体验。
在 DevSecOps 领域，中国有很多优秀的工具类产品，由于地域问题并不在 GitLab Inc. 的生态圈里，因此没有和 GitLab 进行功能上的集成开发。
极狐(GitLab)秉持着"根植中国，繁荣生态"的愿景，致力于和本土的优秀产品进行集成，为用户提供更出色的产品体验和更自由的功能选择，建立一个庞大而繁荣的生态圈。
我们使用极狐GitLab 作为我们全员远程办公的核心工具，所以我们的产品承载着我们在远程办公方面的理念和经验，而中国市场对远程办公的认可和需求与日俱增，未来可能会比 DevSecOps 的市场更大，极狐的产品设计将会扩大核心，力求更好的功能来服务中国用户做好远程办公。
极狐在设计和发布产品时遵循“最小可行性产品”原则，即 Minimal Viable Product (MVP)。我们内部将之称为“最小可行性变化”，即 Minimal Viable Change (MVC)，因为我们产品的商业模式是不断地给我们现有的产品套件进行升级优化，提升价值，而不是创建一个又一个新的独立的产品。 最小可行性变化（MVC）意味着我们在满足用户需求时尽量采用最简洁的解决方案。为了避免产品的过度设计与开发，我们会依靠用户调研来验证我们的解决方案满足用户的需求，而最小可行性变化（MVC）的原则能保证我们在最快的时间里用最少的精力来发布可用的功能，同时，产品团队会不断学习，来持续增加更多功能点，不断优化整个功能，直至该功能的成熟度达到 Lovable。
最小可行性变化（MVC）的优势：
如果产品只是不断发布最小可行性变化（MVC），那会导致一大堆松散的功能点，不能组成一体化的产品，也缺乏优秀的用户体验。
有一种做法，是创建一个长期、详细的未来计划，但是这个方法也有问题，因为它可能会限制产品面对不断变化的需求或反馈作出反应的灵活性和能力。
遵循一个工作流（Flow One）提供了一个替代方案，通过画出一个由 MVC 组成的工作流，而这个工作流需要覆盖一个符合真实用户需求和习惯的用例。这个方法有以下优势：
需要注意，遵循一个工作流（Flow One）在第一个迭代发布的时候就要完整覆盖一个特定的工作流。在第一个版本后，可以再通过添加 MVC 来扩展用例或放松假设（例如，从一个只能在使用特性分支的情况下使用的功能，到一个可以适用于其他分支的策略）。
极狐GitLab 作为一款工具类产品，我们理解用户是有很多在功能配置上的需求和倾向。
但是，我们认为更多的选择不一定是更好的，我们应该减少功能的可配置项，降低复杂度，获得更好的服务体验。
我们非常欣赏其他采用了约定优于配置（Convention over Configuration）理念的工具，像 Ruby on Rails（完美地展现了它的教条 Value integrated system）、Ember 和 Heroku，并努力为软件的持续交付提供同样的优势和体验。
此外，Ruby on Rails 对 Ruby 社区产生了巨大的影响，使 Ruby 变得更加强大和有用，适用于更多的应用场合。我们希望 GitLab 对 Kubernetes 的作用就像 Rails 对 Ruby 的作用一样。
我们认为用户应该更喜欢那些经过深思熟虑并基于当前最佳实践的功能选择，而避免给他们提供不必要的配置。如果为了某些边缘、不常用的工作流程，增加了更多的复杂配置项，其实反而提供了更多的困扰和风险。
在考虑一个新的功能配置项时，我们会遵循以下原则：
确保默认配置项的最佳使用体验： 对于大多数用户来说，极狐GitLab 应该是开箱即用，即能完美运行的。但有时配置项是不可避免的，但你的配置项不该让原来的体验变差，不该给用户带来困扰。
通过限制配置项，鼓励更好的使用行为： 惯例（Convention）其实是我们在鼓励客户以某种方式做事情。举个例子，曾有需求是增加配置项来禁用 CI/CD 流水线功能。对此，我们相信，我们作为一体化的 DevSecOps 解决方案，能给用户带来更卓越的体验，而 CI/CD 流水线功能则是我们一体化体验中的核心功能，我们要鼓励用户去体验其中的全部能力。出于这个原因，我们没有允许这样的配置项来禁用 CI/CD 流水线功能。
为最终用户设计功能： 极狐GitLab 应该避免在设计功能时，从管理员的需求和喜好角度出发，增加一些复杂、困惑的配置项，因为开发者用户或者其他用户才是真正使用功能的终端用户，一定要避免他们的使用体验遭受小计的影响。
避免限制类的配置项： 限制类的配置项应该是为了保护系统，而不是为了 "慢慢尝试 "一项功能的好坏。如果从一开始就为一个功能增加限制选项，达到的唯一结果就是限制了它的应用范围和实用性。如果要给一个功能设置默认关闭或限制项，那么产品设计上必须有一个很好的、记录在案的理由。
尽可能完全避免配置项： 很多配置需求，可能为了支持某些边缘、不合理的使用流程。与其养成坏习惯和产生潜在的产品债务，不如花精力帮助客户采用最佳实践。
我们对极狐GitLab 的使用体验目标是简明易懂。我们的用户应该考虑的是他们正在构建的应用程序，如何与团队成员协作，而不是如何使我们的应用程序来工作。 即，不要让用户思考!
这确实不是一个新颖的产品理念，但当一个应用程序变得越来越复杂，有更多的功能和更多的选项来覆盖更多的用例和更多的用户类型时，就很难保持简单。
所以在设计产品和界面的时候，需要让产品设计师参与所有影响用户界面的变化，让他们关注如何简化复杂的东西。
同时，极简的用户体验也是鼓励我们在设计功能时要尽量复用已有的组件和功能页面，设计新的功能要优先思考现有功能中是否有类似的用例和体验。 在每一轮的功能设计评审、代码评审中，我们的产品经理、设计师、开发工程师都会对于新出现的组件提出问题甚至挑战， 为什么不复用原来的功能组件？这个新功能的使用用例有什么不同？还是原来的组件或设计不好？如果原来的不好，那为什么不在原来的基础上改进，全部更新修改？ 这些问题是我们产品设计中经常收到的问题，是非常优秀的团队习惯和能力，保证了我们产品所有功能一致的极简体验。
极狐GitLab有着非常直观的功能模块划分，基于Section - Stage - Group结构对所有功能进行分类，并任命了对应的产品开发团队，专职负责模块或功能的需求规划和功能开发。
随着极狐产品经理团队的不断壮大，每位产品经理都将不断细化其负责的功能模块，更新如下：
| 产品经理 | 负责模块 |
|---|---|
| 彭亮 | Dev Section (Manage, Plan, Create, Ecosystem Stage) ; Sec Section (Protect Stage) |
| 郭强 | Ops Section (Verify, Package, Release, Configure, Monitor Stage) ; Sec Section (Secure Stage) |
除了上述功能模块的职责区分，还有如下职责分工原则：
