CREDIT
GitLab 的六個價值是合作（Collaboration），結果（Results），效率（Efficiency），多元（Diversity），迭代（Iteration）和透明（Transparency）。這六個字拼成 CREDIT 作為我們送給各位的禮物。這些價值觀是相互關聯的，彼此之間互相合作以保護我們公司的文化。下面逐一解釋這些價值觀的操作方式：
合作
即使對目標沒有立即性的幫助，幫助別人應該是首要項目。相同的，你可以依靠別人的協助與意見 - 事實上你也應該要這樣。 每個人，包含不在 gitlab 公司工作的人，都可以對任何專案提意見。對專案負責的人決定專案要怎麼做，但是他應該要認真看待其他人的意見，並解釋為什麼之前有或者沒有這麼做。
- 和藹 我們很重視互相照顧這件事。互相關心協助建立一個能直接互相挑戰與提供意見的環境。我們不同意有的公司說的 精準的評估別人，而不是「和藹的」. 我們支持精準的評估，但是這必須要以親切的方式進行。盡可能公開的給予彼此正向的回應。
- 分享 GitLab 有一些文化，比方說極度的透明化，對其他人或者新進員工來說是很不直覺的。要努力在其他人身上花時間，並參與公開的對話。舉例來說，可以盡量將私下的議題公開討論，所以其他人都能從這些議題的經驗中學習。
- 負面訊息要一對一 越少人看到負面訊息越好。建議可以用一對一的視訊。
- 說謝謝 公開對幫助過你的人道謝，比方說在我們的 #thanks chat channel 裡面。
- 有效地給予回饋 給予回饋是很難的，但是有效地給予回饋非常重要。給予回饋時，要注意對事不對人，針對事情本身的影響而不要針對人本身。 提供意見時注意至少要給一個近期明確的例子。如果一個人正在遭遇難關，給予回饋時要將這件事情考量在內。提供正面誇獎的一個好例子是我們的thanks chat channel。對經理來說，記得員工對負面批評的反應強度是正面誇獎的六倍之多。要記得，如果一個錯誤出現的機會非常罕見，給予批評沒有什麼好處的話，那麼不如把意見藏在心裡。在需要給予負面批評時，記得這些意見的真正目的：要讓員工的工作效率提升。大方地公開給予稱讚，並時常提升團隊的參與度。
- 認識彼此 現在我們使用大量的文字溝通，一旦你認識文字背後的人，就比較容易避免衝突。鼓勵同事們互相彼此認識，像是透過 company calls，virtual coffee breaks，以及透過高峰會.
- 不要拿階級說話 如果你必須提醒某人你在公司的職位，那一定有哪邊出錯了。大家已經知道我們的決策過程。解釋你做出決定的原因，並且無論對方在公司的職位如何，尊重每個人的看法。
- 標記行為，但不貼標籤 這篇文章 裡面提到很多不讓怪人（jerk）加入團隊的好處，但我們相信怪人是針對行為的標籤，而不是針對人的。我們要避免對人的分類。
- 說對不起 一旦犯錯就道歉。說對不起並不是示弱的象徵，恰好相反，是一種力量的象徵。當一個人做越多事情，那麼就可能犯下更多錯誤。另外，當我們分享我們犯下的錯並讓大家注意到這些錯誤，其他人就可以從這些錯誤中學習，也就可以避免其他人也犯下相同的錯誤。
- 不要自我膨脹 不要為了贏得爭論去捍衛觀點或者重複錯誤。你本人的和你正在做的事情是不同的。你不需要去捍衛你的觀點。但是你需要其他人的幫助來找出正確答案。
- 看見他人的成功 一個和 GitLab 裡面很多人談過的候選人提到，與其他的公司相比，這間公司有個地方特別突出：這裡每個人都提到希望能看見其他人成功。
- 人與事要分開 針對工作提出建議，不是針對人。比方說，將「你都不聽人說話」改成「你沒有回應我對設計提出的回饋」。受到批評的時候，要記得這些批評是進步的作家動力，而且大家希望看到你成功。
- 自己動手做 合作的目的是在對方有問題，需要批評或協助時提供幫助。 不是在可以自己動手做時一起腦力激盪，等待其他人贊同，或者兩者皆是。
- 無責難的解決問題 檢討問題時需將焦點放在情境本身，應聚焦在產生錯誤的機制，以及影響做出問題決策的過程，而不要一昧的責怪別人或團隊。我們相信因為有免責的檢討和回顧，利害關係者會提供看法和意見，而不必擔心受到懲處或報應。
- 用自己的產品 我們用我們自己的產品。開發 GitLab CE 和 EE 專案時，我們使用 GitLab.com 來管理整個產品的 DevOps 週期。這本手冊是用 GitLab 協作完成的。另外我們也將其他內容和流程透過 Git repos 處理並使用 GitLab 進行管理。
結果
我們履行對彼此，客戶，使用者以及投資者的承諾。
- 以結果論，不用時間 我們只關心你做了什麼：你完成的程式碼，你滿足的使用者，以及你協助過的同仁。如果有人下午休息，不應該覺得自己好像做了什麼壞事。你不需要為你今天做了什麼辯護。我們相信員工可以不用嚴格的規範就做對的事情。不要宣稱你昨天工作多少小時來引起工時的競爭。如果你的工時過長，應該你的經理討論一下解決方法。
- 寫下承諾 寫下可以測量的目標。在公司內要達成這件事情，我們使用[公開的目標和關鍵成果]。
- 成長的心態 有時候你做的事會得不到成果。當得不到成果時，你可能會被批評。我們相信才能可以從努力、正確策略、以及其他人的回饋中獲得。我們盡量招募人時根據他們的成長方向，不是根據他們的過去.
- 全局最佳化 這名稱來自 Stripe 文化的簡介。我們對「全局最佳化」這個詞的定義是：你應該要做對整個集團最好的事情。不要做只對自己的團隊好，但是對其他團隊、用戶、或者整個公司不好的事情。其他團隊的目標也是你的問題和工作。團隊盡可能維持精實，並幫助其他團隊達成他們的目標。
- 韌性 我們將這個特性稱之為「對目標的堅持度」。如同 The Influence Blog 裡面提到的，韌性就是你對相信的東西所展現的承諾。你不停地重新站起來，整理好心情，然後趕快再多學一點東西。
- 所有權 我們希望團隊成員可以完成被交付的任務。被交付任務代表你有責任預期並解決出現的問題。作為任務的主角，你有責任解決這個任務出現的問題，而不是問題提供的人或者其他團隊成員需要負責。當遇到可能無法解決的問題時，主動並積極的告知相關的其他人。
- 急迫感 在以指數速率成長的新創公司裡，節省或者浪費時間都有很大的複合效應。嘗試盡快得到結果，所以我們能盡量節省時間，專心在下一個階段的進展上。
- 野心 雖然我們以最小的改變迭代進行，但是我們都渴望大的，有野心的結果。
- 對行動的偏好 專注針對行動分常重要，而不是落入一直分析狀況的陷阱，或者堅持走沒有風險，安靜緩慢的道路。決策應該想得很周全沒錯，但是要能盡快送出成果，我們應該大膽接受偶爾會犯錯的可能。我們對行動的偏好可以幫助我們在犯錯時快速回到正軌。
效率
我們關心的是知道是否朝正確的方向前進，不做多餘的事，並且避免工作重複。這將能幫助我們取得更多進展，工作變得充實有意義。
- 無聊的解法 使用最簡單，最無聊枯燥的解法去解決問題，並記住，「無聊」和「不好的」不應混為一談。 迄今為止，複雜性隨著時間不斷累積，會影響組織和產品創新的速度。因此，每一個能降低複雜度的步驟都很重要。不要為了讓你的工作更有趣，所以選擇有趣的技術。選擇使用成熟的，常見的流行技術，讓你和其他貢獻者開發體驗更穩定，更熟悉。
- 針對特定群體量身打造效率策略 為GitLab廣大的開發者社群優化全球解決方案。為一個人或一小群人建立有效的流程，不代表亦能推動整個GitLab社群在效率上的成功。例如，在面對選擇時，建議選擇可能讓你的做事效率略微降低，但是能夠為數千名用戶效率大幅提升的方式。舉例：你可以選擇替換掉原來需要1,000個用戶每人花費2個小時的更新過程，取而代之的是僅需要每人花60秒的更新過程，即便這可能會讓每月內部報告的效率降低！在做決定之前，你可以問問自己，「這件事需要對誰最有效率？」通常，這個人可能是你的用戶、貢獻者、客戶，或是仰賴你的決定的團隊成員。
- 尊重別人的時間 想想你要求每個人在會議上，以及徵求同意的過程中，投入多少時間。盡量避免開會，如果有必要，讓越多人可以選擇不出席越好。任何會議都應該要有議程附在會議邀請函中，並且你應該記錄會議結果。不需要徵求別人的同意，反而是相信他們的判斷，並在他們有疑問時提供諮詢。
- 花公司的錢，要像花自己的錢 我們花的每一塊錢都必須賺回來。對於公司資金的運用，要像你會對自己的錢一樣節儉使用。
- 行事節儉 亞馬遜說得好：「用更少的錢來做更多的事。節儉可以孕育出足智多謀、自給自足和創新。增加人力、預算以及固定支出，並不會為你額外加分。」
- 對話式開發 我們依照對話式開發的原則工作。
- 自由 你應該有明確的目標，並且可以自由地朝著目標前進。
- 簡短扼要的口頭答覆 口頭答覆應簡短，才會讓對方有機會提出更多問題，或往下一個話題前進。
- 網路會議應簡短 並且就如這一期哈佛商業評論雜誌的研究指出，一對多的書面溝通應力求簡明扼要：「大多數人說他們所讀的書面訊息，由於內容太過冗長，文章結構鬆散，論述不清楚，充滿行話，且遣詞不夠精確，溝通效果經常是大打折扣。」
- 自動自發的團隊 我們希望打造出自動自發的團隊，不需要別人每天催促，就能達到想要實現的目標。
- 強調擔負責任，擺脫僵化 我們盡可能地賦予團隊做決策的責任，並且成員都背負決策責任，而不是強加規則和批准的程序。
- 接受錯誤 每個問題的背後，並非都需要用創造新的流程的方式來避免錯誤。額外添加的流程可能導致操作效率降低，而一個錯誤只影響一個操作。
- 部署最小可行性修改，快速應變 我們藉每月快速迭代持續改進。如果任務太大，無法在一個月內完成，請縮小範圍。
多元化
來自世界各地的社群成員，他們有不同背景和多元觀點。我們招聘全球人才，並鼓勵聘用具有不同國家背景的人，深化團隊的多元化。我們致力讓每個人都感到自己是受到歡迎的，並增加代表不足的少數族裔和國籍在我們的社群和公司中的參與。例如，贊助舉辦多元化活動，以及提供雙倍的員工推薦獎金。
- 組織文化契合度是個爛藉口 我們不會因為文化契合聘用人，也不會因為想和應徵者相約去喝酒暢飲而錄取他。我們按照此頁詳述的共享價值理念雇用和獎勵員工。如果拿在此所提倡的共同價值來衡量，仍有所不同時，那麼他們就已經適合的人選了。因為我們希望建立的是一個多元化的環境，而不是走向文化整合。舉例來說，男性主導的工程師文化（brogrammer）氛圍，就不是我們所樂見的。換句話說：「文化添加」>「文化契合」或「為能夠在形塑文化上有所貢獻而聘用」，因為我們的使命是每個人都有貢獻的機會。
- 工作場合避免談論宗教信仰或政治話題 我們不討論宗教或政治有關的話題，因為這類話題具有排他性，容易讓少數意見的人感到疏遠。你可以隨口提及曾參加過的宗教儀式或集會遊行，但不需講出宗教或政黨的名字。
- 作風怪異: 在意想不到的、非傳統的事物中，能夠增加生活趣味。慶祝和鼓勵怪異的天賦才華、習慣、行為和觀點。一個例子是，我們的公司內部視訊會議，大部份的時間都在聊同事私下會從事的活動，例如玩火舞或針織。開源是與有趣的人交流的很好的方法。我們希望聘用認為工作是很好的表達自我的方式的人。
- 建立舒適安全的社群 不論是在GitLab工作，或是參與GitLab社群，每個人在這個環境中都應感到安全且舒適。對任何一個社群成員，包括員工在內，我們絕不容忍濫用、騷擾、排斥、歧視或報復的行為。
- 不經意產生的偏見. 我們不僅要對想說的話負責，還要對所講的話連帶產生的效果負責。這包括的範圍不僅是明顯的不尊重或缺乏包容性，還包括在日常生活中 — 原意良善的人可能因自己的無知，不經意的傷害他人。這意味著我們都需要更努力的，認出自己不經意對別人產生的偏見或隱性的偏見。
- 包容性 我們努力建立包容的文化環境，將包容性文化體現於制度中，並對每個員工給予同等的支持，實現他們的職涯目標。而不是將努力的重點放在舉辦活動、收集數據、成果指標等。我們將這種刻意營造的職場文化的設計稱為包容和發展（i＆d）。
- 包容性福利 我們公開地表示有提供跨性別醫療服務以及育嬰假，因此應徵者在面試時，不必擔心需要自己主動提出需求。
- 包容性語言 在我們的指南中有說：「使用包容性語言。」例如，我們傾向用「大家好」（Hi everybody），或「哈囉各位」（Hi people）來打招呼，而不說「大家好啊」（Hi guys）。
- 包容性面試 我們面試流程中，其中一個是：「應徵者應至少接受一位女性GitLab團隊成員的面試。」
- 看到什麼，說什麼 作為一家布局全球的公司，我們的員工來自不同背景和文化。這意味著每個人都必須更加敏銳的判斷，是否有彼此尊重和互相包容。同時，我們偶爾可能會犯錯。重要的是，團隊成員能在犯錯時提醒我們，我們可以從錯誤中學習，並且能更加理解持有不同的意見的人的想法。同樣重要的是，團隊成員不會因此感到排外或覺得被輕視，而是將焦點放在我們溝通的用詞和所做的事情。因此，當看到有不尊重別人或缺乏包容性的行為時，我們都需要說出來。如果有人說蠢話，你需要告訴他們，並幫助他們理解為什麼這樣說是不好的。
- 神經多樣性的人才 神經多樣性（Neurodiversity）指一種多樣性，包括自閉症、注意力不足過動症（簡稱ADHD）和其他神經衰弱功能。他們經常具有獨特的技能和能力，可以利用這些技能和能力來獲得競爭優勢，但是神經衰弱的人也經常受到歧視，有時候因傳統的人事招募流程設計，難以爭取錄取的機會。這些人應該要能用 GitLabbers 社群的一份子的身份貢獻。手冊指南、價值觀、策略，以及工作面試招募流程等，皆不應歧視神經多元性的人才。
迭代
我們做盡可能小的事情，並且盡可能快推出。如果你有個提案在第一次迭代中可以排除在外，並且可以變成單獨的 Issue ，則不要寫成一個巨大的提案，只要寫第一步即可。相信你在東西推出之後，會更知道如何進行下一步。如果你在第一次迭代中，覺得你推出的功能太小因而感到羞恥，那你就做對了。這個價值是人們剛加入 GitLab 時最常低估的，你工作過程和產出的影響力會比你原先預期的大。快速做決策，並看事情在很少討論之下改變，在一開始會感到十分痛苦。但頻繁推出最簡單的版本，最終結果會是最好的。
加入 GitLab 的人們都會說他們已經在實踐這樣的迭代方式，但這個價值是所有價值中最難採納的。人們已訓練成如果事情沒十全十美交付，就會被盯。如果你有件事情做了一點點，之後還要繼續做。做完整件事情似乎更有效率（即使實際上並沒有）。如果成品的遠景還不明確，人們對你成品的理解，可能不會是你想要成品被理解的樣子。因此似乎做個包山包海的成品比較好。他們會覺得 GitLab 組織的其他人在迭代很有效率，但不知道怎麼做轉移。
要解決這樣的問題，必須寫下來「現在你給這個專案的時間，你只能做些什麼」。這個時間可能是 5 分鐘或 2 小時。想想你在那段時間能做些什麼，來改善現狀。迭代感覺起來不舒服，而且人們可能會問為什麼某某東西不完美。在這樣的情況下，解釋那是迭代，你只花了 x 部分的時間在那上面，在下個迭代會包含 y 而且在 z 會完成。
- 減少週期 短的迭代減少我們的週期
- 和社群一起工作 小的迭代促進與更廣泛的社群協作。他們的工作會看起來更像我們的工作，而且我們的工作也會更快給出回饋。
- 最小可行更新 Minimum Viable Change (MVC) 永遠找尋更快可能的改變來改善成果。如果你覺得做某事會比現況更好，就做。不需要等某事更完美一些再做。更多的資訊在產品手冊有提到，但這個原則在我們所有部門都適用。
- 寫下提案 如果你需要團隊決定某事，與其召開會議，不如直接寫下提案，來得到所有人的意見。有個提案會更有效地使用所有人的時間。如果最後是實作完全不一樣的提案，收到提案的人不該覺得被排擠，提出提案的人也不該覺得難過。別讓你的自我，或是想要看見自己的解決方案被實現的心情，阻礙產出最佳成果。
- 每件事都是草稿 在 Gitlab 的任何內容或提案很少有草稿。每件事都是草稿，而且隨時都有可能改變。
- 施工中 當我們得到更多使用者時，他們會要求穩定性，特別是針對使用者體驗。我們應該永遠對長遠做優化。這代表我們的使用者在短期會感受到不方便，但現在和未來的使用者最終會享有更好的產品。
- 低度羞恥感 Nat Friedman 曾和我們說：「保有低度羞恥感是你們文化的一部分」。我們東西未達心中期望就推出，心中的痛苦感被這句話準確表達出來。
- 做那些不會規模化的事情 優先優化速度與產出，產出成功再來講究如何規模化。 Paul Graham 的文章 有良好範例。
- 不要為了雙向門等待 大多數的決策都是可逆的，讓直接負責人（Directly Responsible Individual） 不須核准就去做決策。如 Jeff Bezos 所說，只有不可逆的決策，才需要決策流程。
透明
盡可能地保持公開透明。做事公開透明，可以降低貢獻的門檻，並能夠更容易地促進協作。一個例子是，此網站的公開專案儲存庫（repository），內容也包含了公司手冊。我們所有做的事情都是預設公開的。例如，GitLab CE 社群版和 GitLab EE 企業版問題追蹤系統，以及行銷和基礎設施。管理透明化為GitLab提升意識，可以招募到關心我們文化的人，幫助公司可以更佳運用外部資源，且更快的得到回饋，並可以更容易地互相合作。同時，秉持著開源的精神，與全世界的人共享優秀的軟體、文件、實例、學習資源和開發過程，因我們相信，這些公開開放出來的資訊，所創造的價值遠超過其看得到的價值本身。但也有例外。預設不公開的素材會記錄在一般準則中。個人層面來看，你應該將想法表達出來，而不是擺出一張撲克臉。不要害怕承認犯錯或做錯事。當出現問題時，這是一個很好的思考機會，「有什麼可以改善的？」，找到更好的面對方式，而不傷害彼此情誼。
- 預設公開 GitLab所有的內容都是預設公開的。
- 直接表達 直接的表達是一種追求透明的表現。我們試著釋放內心的本•霍羅維茲（Ben Horowitz），希望學他最廣為人知的敢直言、善良的一面，不打嘴砲，不說幹話，罕見的直言不諱的作風。別人給你的回饋，最終對事不對人。這不代表接受或給予別人意見是一件容易的事。
- 提出建設性的問題 在合適的時間，和對的人（仍可行的情況下），講究公開透明。
- 任何人和任何事都可以被質疑 你可以對過去任何一個決定和指導方針提出質疑，只要你在改變之前仍按既定的方針行事。
- 不同意但執行 一切都可以被質疑，但只要做了決定，我們會期望團隊投入執行，這是共同原則。
- 在真正困難的地方選擇公開透明，透明才有價值. 例如，在美國加州，許多公司都不會告訴你沒有錄取的真正原因，因為這將會增加被求職者投訴，採取法律途徑的可能。我們希望只用正當原因拒絕求職者，並希望他們因著得到我們的回饋有成長的機會。因此，我們會接受告訴應徵者我們的想法所增加的風險，希望透過說出我們的想法，用高標準檢視決策過程以及所做的事。另一個例子是對資訊安全事件保持公開透明。
五種功能障礙
我們的價值觀幫我們避免 五種功能障礙.
- 無法信任 不願意當團隊中的弱者 => 透過「合作」避免，特別是和藹的部分
- 畏懼衝突 追求虛假的和諧，避免有建設性的熱情辯論 => 透過「透明」避免，特別是直接的部分
- 缺乏承諾 假裝支持團體的承諾，會在整個集團之中創造分歧意見 => 透過「透明」避免，特別是直接的部分
- 避免咎責 逃避點出同儕效率差的做法，因此導致標準降低 => 透過「結果」「迭代」「透明」避免
- 無視結果 專注於個人的成功，狀態和自信。忽略了團隊的成功 => 透過「結果」避免
有的功能障礙並沒有直接在我們的價值觀內點出，比方說信任並不是價值觀之一。 就像快樂一樣，信任是屬於結果，不是你可以直接獲得的。與其直接規範要大家互相信任，我們希望透過我們工作上的方式和價值觀，可以取得彼此的信任；信任要努力去贏取，而不要寄望平白無故獲得。
為什麼要建立價值觀
我們的價值觀提供我們實際可行的行為規範。 這些價值觀幫助我們說明我們對僱用的人所預期的行為。 這些價值觀幫助我們弄清楚在組織內該如何行動，並且該如何預期對方的行為。 Values are a framework for distributed decision making, they allow you to determine what to do without asking your manager.
架構
有些時候，價值觀之間會彼此衝突。舉例來說，依據透明這個價值觀，我們找到系統安全漏洞時應該要立刻公開，但是這會危害我們的使用者。It’s useful to keep in mind this hierarchy to resolve confusion about what to do in a specific circumstance, while remaining consistent with our core values.
| 結果 | 專注結果是最重要的事情 | |||||
| 迭代 | 透明 | 我們相信這些價值觀對結果有幫助 | ||||
| 合作 | 多元化 | 效率 | 我們和其他公司不同之處 | |||
價值觀更新
我們的價值觀會隨著需要持續更新，所有人都歡迎提供建議。要提供建議的話，可以開一個 merge request 並且分配給 CEO。
如果你是團隊成員或者在核心團隊裡面，請透過 #values 頻道 轉貼連接給 MR。如果你不是團隊成員，請傳 Twitter 訊息給@sytses.
如何加強我們的價值觀
你所獎勵的項目就會成為你團隊追求的價值觀。我們透過以下行為讓我們的價值觀生根在團隊內：
- 由我們做事的方法，特別是領導人做事的方法
- 由應徵時的選人
- 由新人開始工作時我們的強調
- 由我們升遷時所看的項目
- 由我們分紅利時所看的項目
- 由我們稱讚的行為
- 由我們辭退對方時所看的項目
准許參與
在我們的價值觀裡，我們有一些明顯要遵守的行為沒有列入。這些我們稱為准許參與（permission to play）的行為
- 說實話
- 要可靠，確實，公平，尊重。
- 要投入，有創意，激勵人心，有熱情。
- 要對得起用戶和客戶的信任。
- 做對公司、團隊成員、客戶、用戶、投資者最有利的事情
- 做事要合法
Question from new team members
During every GitLab 101 session with new hires we discuss our values. We document the questions and answers to Frequently Asked Questions about the GitLab Culture.
理念
Our mission guides our path, during this path live our values.