GitLab値

GitLabはすでに何度か注目を集めています。データベースに関するインシデント 、独自のハードウェアへの切り替えの決定、およびユーザーがGitLabをクラウドから離脱しないことを納得させる方法について書いています。 これらのストーリーはすべて、事故の結果を排除し、重要な決定を下す際に会社が示した前例のないオープン性によって結ばれています。 そのような宣伝の理由を見つけることにし、GitLabの価値を説明する素晴らしいドキュメントを見つけました。

開放性に加えて、それは多くのことであることが判明しました。私たちにとっては、Habrの読者が会うのは興味深いでしょう。 私たちの多くは同じような状況で働いています。自宅から、リモートで通信し、時には同僚と会わずに何年もの間。 このタイプの作業には長所だけでなく短所もあり、GitLabは私たち全員に役立つかなりの経験を積んでいます。 カットの下にGitLab値の翻訳があります。

クレジット

私たちの6つの価値は、コラボレーション、結果、効率、多様性、反復、透明性です（英語の単語の最初の文字はクレジットであり、この場合は英語から翻訳されますリスペクト”-注transl。）私たちは優しさを信じ、結果を達成するために協力します。 結果により、残りの作業を行うことができます。 時間を無駄にすることなく、可能な限り効率的に結果を達成します。 チームの多様性に満足しています。 私たちの仕事は会社の内外で透明です。 一緒に、これらの値は信用を意味し、お互いに持っています。 以下は、私たちの価値がどのように実践されるかを説明しています。

コラボレーション

他の人を助けることは、たとえそれが取り組んでいるタスクと関係がないとしても、優先事項であるべきです。 あなた自身が助けを求めることをheしてはいけません。 GitLabで働いていない人も含め、誰でもあらゆる問題の議論に参加できます。 仕事を直接実行する人がその方法を決定しますが、彼は受け取った提案を真剣に検討し、それらに答え、自分の立場を説明しなければなりません。

1. 優しさ チームの私たちはろくでなしを必要としません。 一部の企業は、 「人を評価する際には、優しさではなく正確さが重要です」と述べています。 私たちも正確さを求めていますが、これは親切にすべきだと思います。 フィードバックはできる限り前向きで一般に公開する必要があります。
2. 形式が負の場合1-1 。 できる限り少数の部外者に否定的なフィードバックを与えます。 これには1対1のビデオ通話を使用することをお勧めします。
3. ありがとう 。 たとえば、 #thanksチャットなど、公共の場で感謝します。
4. 効果的なフィードバック 。 高品質のレビューを作成するのは簡単な作業ではないため、効率的に実行する必要があります。 フィードバックを提供するときは、人ではなく仕事に関するものであることを常に確認してください。 新鮮で明確な例を必ず追加してください。 人が人生で困難な時期、いくつかの個人的な困難を抱えているかどうかを考慮してください。 肯定的なフィードバックの例は、 感謝チャットにあります。 マネージャーは、部下がネガティブな状況に反応し、リーダーがポジティブな状況よりも6倍強いことを理解することが重要です。 したがって、場合によっては、特にエラーが絶えず表示されず、それほど害を与えていない場合は、まったく批判する価値はありません。 それでも否定的なフィードバックが必要な場合は、まず従業員の仕事の質を改善することを目的とすべきです。 称賛をskiしまないで、エンゲージメントを高めるという目標を含めて、公然と行います。
5. お互いをよりよく知るようにしてください 。 私たちは多くのテキストコミュニケーションツールを使用しています。お互いに会わず、同じオフィスで仕事をしていません。そのため、競合を防ぐために、チャットやメールのテキスト行の背後にいる人の個人的な知識が必要です。 個人レベルでお互いをよりよく知るように人々を励ます。 グループコール 、 バーチャルティーパーティー 、およびサミットを使用します。
6. ランクを押しつぶさないでください 。 もしあなたがあなたの公式な立場を誰かに思い出させる必要があると感じたなら、あなたは何か間違ったことをしているでしょう。なぜなら私たちは階層的な意思決定システムを持っていることをすべての従業員がすでによく知っているからです。 あなたがそうすることにした理由を説明し、そうでない場合は説明せず、機能に関係なく全員を尊重します。
7. ごめんなさい 。 間違えた場合は、許しを求めてください。 申し訳ありませんが、あなたは弱さではなく強さを示しています。 ほとんどの作業を行う人は、より多くの間違いを犯す可能性があります。
8. 自分を突き出さないでください 。 議論に勝つためだけに議論するのではなく、間違いを二度批判しないでください。 あなたはあなたの仕事ではありません。あなたの視点を守ってはいけませんが、一緒に正しい答えを探してください。
9. 他人の成功に貢献します 。 GitLabで多くの人々とコミュニケーションをとることができた候補者は、他の会社と比較して、1つのことが特に際立っていることを指摘しました。GitLabの各従業員は、他の会社の成功に貢献します。
10. 人は自分の仕事ではない 。 パフォーマンスについてではなく、仕事について話します（「あなたは私に耳を傾けることはありません」ではなく、「新しいデザインについてフィードバックを送信しませんでした」）。 フィードバックを受信するとき、それはあなたが良くなるのに役立ち、他の人が心から成功を願うことを忘れないでください。

結果

私たちは、顧客、ユーザー、投資家に対して互いに約束したことを行います。

1. 作業時間ではなく、結果に感謝します 。 成果は私たちにとって重要です：書かれたコード、幸せなユーザー、助けを受けた同僚。 勤務時間に競争しないでください-昨日の午後に自分のビジネスに行ったことに対して罪悪感を感じる人はいません。 代わりに、自分の成果と他の成果を楽しんでください。 営業時間について報告する必要はありません。 厳格なルールに従うのではなく、チームのメンバーを信頼することを好みます。
2. 約束をしなさい 。 測定可能な目標は書面で合意する必要があります。 Gitlabでは、OKRを使用します 。 私たちの目標はここから入手できます 。
3. 個人の成長のインストール 。 あなたは常に結果を達成するわけではなく、自己批判と外部からの否定的なフィードバックは失敗に続きます。 私たちは、勤勉、正しい戦略、他の人々の助けによって才能を育てることができると信じています。 血統ではなく、開発の軌道に基づいて従業員を雇用します。

有効性

必要なことに取り組むこと、必要以上のことをしないこと、同じことを何回もしないことが重要です。 したがって、私たちはより多くを達成し、これは私たちがより完全に自分自身を実現することを可能にします。

1. 退屈な決定 。 最もシンプルで退屈なソリューションを使用してください。 必要に応じて、それらは常に複雑になる可能性があります。 私たちの組織では、イノベーションの速度は、現時点で全体的に追加された複雑さによって制限されているため、複雑さの軽減は有益です。 あなたがそれを使って仕事をしたいという理由だけで、興味深い技術を選ぶべきではありません。 一般的なソリューションを使用するということは、多くのエラーが既に修正されていることを意味し、他の人が開発に接続しやすくなります。
2. 他の人の時間を感謝します 。 同僚が組織している会議と実行中の承認プロセスに費やす時間を常に考慮してください。 会議を避け、これが不可能な場合は、参加をオプションにし、理解可能な議題を書き、結果を文書化します。 人々に行動を調整するよう求めるのではなく、彼らの判断を信頼し、質問がある場合は単にあなたと相談することを申し出ます。
3. 会社のお金を自分のものとして使う 。 私たちは費やしたすべてのドルを獲得し、返さなければなりません。 会社と同じようにお金を節約します。
4. 自由 。 明確な目標とそれを達成する方法を選択する自由が必要です。
5. Th約 Amazonは次のように述べています。 「少ないリソースでより多くを達成します。 制限により、独創性、自給自足、創意工夫が生まれます。 スタッフを膨らませ、予算を増やし、固定費を維持するために、追加のポイントは与えません。」
6. ConvDev 。 私たちの仕事は、 会話の発展の原則に従って構築されています。
7. 短い口頭回答 。 口頭での質問に短い回答をしてください。そうすれば、対話者は他のことを尋ねたり、すぐに先に進んだりできます。
8. 郵便物はできるだけ短くしてください 。 一度に複数の受信者に送信される手紙は長くないはずです。 このHBRの調査では、「多くの人が、長すぎるメッセージ、組織化されていないメッセージ、曖昧なメッセージ、専門用語でいっぱいのメッセージを読む必要があると言っていますが、これは非常に非効率的です」
9. 彼自身がリーダーです。 チームメンバーは、目標を達成するために日々のチェックを必要としない独自のリーダーになることを望んでいます。
10. 剛性ではなく責任 。 厳格なルールとユビキタスな承認プロセスの代わりに、可能な場合は人々に独自の決定を下し、責任を持たせる機会を与えます。
11. エラーは許容されます。 すべての問題がそれを解決する新しいプロセスにつながるわけではありません。 追加のプロセスは一般にすべてのアクションの有効性を低下させ、エラーはそのうちの1つだけに影響します。

バラエティ

私たちのコミュニティには、世界中の人々が含まれています。 彼らは異なる伝記や意見を持っています。 世界中の従業員を雇用し、多様性を促進しています。 私たちは、すべての人が歓迎されるように努めるとともに、当社やコミュニティで過小評価されている少数民族や国籍に属する従業員の数を増やすよう努めています。 たとえば、 さまざまなお祝いを後援し、 二重推奨ボーナスを設定します。

1. 文化的適合はナンセンスです。 文化的所属に基づいて雇用することはなく、ドリンクを飲みたい候補者を優先しません。 私たちは共通の価値観に基づいて従業員を募集し、報酬を与えますが、同時に文化的な適合性（例えば、 ブログラムの場合）の雰囲気ではなく文化的な多様性に努めます。
2. 宗教と政治を家に置いてください 。 宗教や政治については議論しません。そのような議論の過程で、少数派の視点を持つ人々を疎外するのは非常に簡単だからです。 式典や集会に出席したことは簡単にわかりますが、宗教やパーティーについては言及しません。
3. 偏心 。 予期しない異常なことは、人生をより面白くします。 オリジナルの贈り物、習慣、行動、視点を奨励し、それらを楽しんでください。 例として、 グループコールがあります 。ここでは、火炎放射から編み物まで、仕事以外で行うことについてほとんどの時間を話します。 オープンソースを使用すると、面白い人とチャットできます。 そして、仕事は自分を表現する素晴らしい方法だと信じる人々を雇おうとしています。

反復性

タスクを可能な限り小さな部分に分割し、可能な限り迅速に動作させます 。 最初の反復から何かを除外できる場合は、新しいタスクを作成し、現在のタスクにリンクします。 大きな計画を書かないでください-最初のステップで十分です。 私を信じて、何かがすでにリリースされた後、次に何をすべきかはあなたにとってはるかに明確になります。 最初の反復で少数の製品機能に少し混乱している場合は、すべてを正しく行っています。 GitLabに来る新しい人々は、この値がワークフローとその結果にどれほど強く影響するかを十分に理解していないことがよくあります。 最初は、迅速な意思決定と、少ない協議で物事が変化するという認識は困難です。 しかし、多くの場合、最もシンプルなバージョンが最適です。

1. サイクルタイムを短縮します 。 短い反復によりサイクル時間が短縮されます 。
2. コミュニティの一員として働く 。 短い反復により、より多くのコミュニティメンバーをプロセスに参加させることができます。 彼らの仕事は私たちのものに近くなり、フィードバックがより早く得られます。
3. 最小実行可能変更 。 結果を改善するには、常に最速の変更を行うようにしてください。 計画が既存の計画よりも優れていると考える場合、それを磨く時間を無駄にする必要はありません。
4. オファーを作成します 。 チームを決定する必要がある場合は、会議を開催するのではなく、提案を作成します。これは、すべてのチームメンバーにとってより効率的な時間の使用です。 提案を受け取った人は忘れられてはいけませんし、提案を作成した人は、最終的に完全に異なるものを実装することに決めたと怒ってはいけません。 あなたのエゴと欲望があなたの決定が最適を見つける方法に立ち向かうことに気づくことを見ないようにしてください。
5. すべては下書きです。 GitLabでは、ドラフトと呼ばれることはほとんどありません。 すべてがプロジェクトに常にあり、いつでも変更できます。
6. 開発中 。 毎日多くのユーザーがいるため、特にUXでは安定性が必要です。 長期的には常に作業を最適化する必要があります。 つまり、ユーザーは限られた時間内に不便を感じるかもしれませんが、最終的にはより良い製品を手に入れることができます。

透明性

可能な限りオープンにしてください。 情報を公開することで、新しいコミュニティメンバーのエントリのしきい値を下げ、相互作用を簡素化します。 例は、 このサイトの公開リポジトリであり、このリポジトリにはこの企業リファレンスガイドも含まれています 。 GitLab CEおよびGitLab EEのタスク管理 システム 、 マーケティング 、 インフラストラクチャなど、私たちが行うことはすべてデフォルトで公開されています。 透明性はGitLabの認知度を高め、私たちの価値観を共有する人々を雇うことができます。 これにより、社外の人々から迅速にフィードバックを得ることができ、彼らとのやり取りが簡単になります。 ポイントはオープンソースの精神にもあり、私たちの意見では、優れたソフトウェア、ドキュメント、例、レッスン、プロセスを全世界と共有するために、付加価値を生み出します。 例外があります。 デフォルトで公開されていない資料は、一般的なガイドラインにリストされています 。 個人的なレベルでは、ポーカーインターフェースを引っ張るよりも、率直かつ正直に話す方が良いでしょう。 あなたが間違いを犯したか、間違っていることが判明したことを恐れずに認めてください。 何かがうまくいかなかった場合、「これがカイゼンを適用する理由ですか？」と自問する必要があります。そして、絶望に陥ることなく、より良い方法を探し始めます。

1. デフォルトで公開 。 GitLabでは、デフォルトですべてが開いています。
2. 率直さ -私たちはお互いに開かれています。 私たちは、内なるベン・ホロヴィッツを自分自身で発展させようとしています。 率直で親切であること-苦味と不道徳のまれな組み合わせです 。 確かに、それは常に仕事に関するものであり、人に関するものではないため、ここでフィードバックを得るのは難しいでしょう。
3. すべての人が問われることがあります 。 過去の決定やガイドはすべて再考することができますが、変更されるまでそれらに従って行動してください。
4. 同意しないでください 。 すべてを疑問視することができますが、決定がキャンセルされない場合は、それを実装する必要があります-これは一般的な原則です。
5. あなたが一生懸命働かなければならないとき、あるいはそれに苦しむときさえ価値は真実です 。 たとえば、カリフォルニア州では、多くの企業が求人を拒否する本当の理由を報告していません。これは、訴訟の可能性が高まるためです。 候補者を可能な限り合理的に拒否し、フィードバックを受けて、人々に成長の機会を与えるよう努めています。 このように、私たちはリスクを高め、意思決定の高い基準を守り、候補者に自分の考えを直接伝えることで正しく行動します。

5つの機能不全

私たちの価値観は、 5つの機能不全を防ぐのに役立ちます。

1. 信頼の欠如（グループ内で自分の脆弱性を見せたがらない）=>相互作用、特に親切によって防止されます。
2. 対立への恐怖（建設的な感情的な議論の代わりに人工的な調和を望む）=>透明性、特に直接性によって防止されます。
3. 関与の欠如（集合的な意思決定を行う際の合意の出現は、組織に不確実性をもたらします）=>透明性、特に直接性によって防止されます。
4. 責任の回避（同僚の非生産的な行動を説明するための呼び出しの回避、より低い基準の設定）=>結果、反復、透明性によって防止されています。
5. 結果への不注意（個人の成功、ステータス、エゴに焦点を合わせてチームの成功よりも上に置かれます）=>結果によって防止されます。

値が必要な理由

私たちの価値観は、行動方法を理解するのに役立ち、実際に適用する必要があります。 彼らは、私たちとともに働く人々が従わなければならない行動の規則を記述しています。 目標は、組織でどのように振る舞うべきか、他の人に期待できることを理解するのに役立ちます。 私たちの目標は、分散型の意思決定プロセスの基盤であり、リーダーに尋ねることなく、何をすべきかを理解できるようにします。

価値をどのように維持するか

値は奨励された行動になります。 私たちは次のように私たちの価値をサポートしています：

1. 私たちが行うこと、特にリーダーシップの行動。
2. 募集する人に。
3. 新入社員の適応期間中に注力すること。
4. プロモーションでガイドされる基準。
5. ボーナスに使用する基準。
6. 私たちが賞賛する行動。
7. 従業員と別れたときの指針となる基準。

遊べる

いくつかの明らかな品質と行動は私たちの価値に含まれていません。 これを「再生可能」という用語と呼びます。

• 正直で正直になります。
• 信頼でき、公平で、敬意を払ってください。
• あなたの仕事に関与し、創造的で、インスピレーションを与え、情熱を持ちましょう。
• ユーザーと顧客の信頼に値します。
• 会社、チームメンバー、顧客、ユーザー、投資家の最善の利益のために行動する。
• 法律に従って行動する。

参照：

1. オリジナル： GitLab値