極狐產品 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) |
除了上述功能模塊的職責區分，還有如下職責分工原則：
