通常、チームを結集するために、私たちは旅行を練習します。残りの時間は、都市から離れた場所で作業し、男たちは世界の一部に集まります。午後はスプリントの一部を通過し、夜は一緒に楽しんでいます。でも締め切りが厳しかったので、逆に行きました。これが私たちが思いついたものです-そしてこのアプローチは権威ある管理がないどんなチームでも使用できるようです。
アイデアをくれたRayに感謝します
2019年の春には、「原則」という本についての話しかありませんでした。RayDalioの「LifeandWork」。Alexey Kataevも彼女のことを聞きました。彼は「チームリードレオニード」であり、当時のチームリーダーでもあります。
レイダリオ？どなた？
1975- Bridgewater Associates. 2010- - . 100 .
, , , , .
, , , , .
Lyoshaはプロセスを確立するために請求に来ました。彼はチームがどうあるべきかについて明確なビジョンを持っていました-そして説得する能力。すべてがうまくいったとき、彼は上がった。そして去る前に、彼は契約を結んで、チーム内のすでにデバッグされたプロセスの作業を統合し、開発チームのために「生活のルール」を書くことを申し出ました。新しいチームリーダーがこのアイデアを支持し、それが始まりました。
まず、Dalioの原則を読みます。全部で16個ありますが、全部
- 現実を受け入れ、それを使って作業します。
- , , .
- .
- , .
もちろん、哀れです。しかし、私たちはそれらを自分たちのために適応させようと決心しました。 Lyoshaは10の原則のリストをスケッチし、チームはそれを補足して、要約の総数を43にしました。githubにリポジトリを開きました。作業のルールが結果と同じ場所でホストされることを象徴しています。
そして、正直なところ、この方法でこのビジネス全体を維持および開発する方が簡単です。
それから彼らはリストを短くし、言い回しを改善し始め、具体性、原則との一致、重要性の3つの基準に従って各項目を評価しました。論文がすべての関心のある人に合うまで議論され、洗練されました。
私たちは海岸で合意した。これがリョウシャの考えでした。
その過程で、私たちが何を見ているのかが明らかになりましたが、数日間の活発な議論の末、リリース候補があります。
プールリクエストは、すべてのチームメンバーによって承認される必要がありました。
最終投票後、チームリーダーはチームライフルールの最初の公式バージョンをリリースしました。
リスト全体を発表してください
私たちは「憲法」を2つの部分に分けました。チーム内の12の一般的な生活と行動のルールと15の技術原則です。テキストはかなり長いので、スポイラーの下にメインボリュームを非表示にします。スペルと句読点はオリジナルに保持されます。
作業原則
1.1。私たちは、同意するかどうかに関係なく、受け入れられた原則に従います。
個人的な意見の不一致は、原則から逸脱する理由ではありません。ただし、状況が変化して役に立たなくなった場合は、原則について話し合うことができます。
さらに11ポイント
1.2
— . — . — . , . , .
1.3
- . , . . . , . . . . — .
1.4
: , , , . — . — .
1.5 ,
1.6
— . : , , , .
1.7
. , , . — .
1.8
— , — . , . , .
1.9
1.10 —
, , — , — . : , , , . , , . -, “ ”, “ ” “ ”. , .
1.11 , ,
. — , , , — .
1.12
. .
技術原則
2.1。我々は結果を考える
困難な展開または移行する前に、我々はすべてがうまくいかない場合は、我々が何をするかを考えます。バックアップ、ロールバックスクリプトを作成し、転倒のリスクを評価します。私たちは「ああ、それは吹くでしょう、すべてが大丈夫になるでしょう」という考えを追い払います。
さらに13ポイント
2.2 ,
“ ” -.
2.3
, , , . , .
2.4
!= . .
2.5 , —
— , Skyeng. , , .
2.6 ,
, - , - . “ ” “, ”.
2.7
, :
— RabbitMQ: ,
— : ,
—
— SOLID, DI, IoC
2.8
— , . : . “ ” — . .
2.9 , QA
. — . — QA. “in development”, production : .
2.10
100% coverage , 100% coverage.
2.11
.
2.12
: , .
2.13
, . , .
2.14
, . , phpdoc, , README.
2.15プロジェクトを最初から書き直すことはありません
これが良い考えである可能性は最小限です。長年にわたってテストされてきた実用的なコードを破棄することで、何かをゼロから作成するという考えを排除します。私たちは絶えず改善とリファクタリングを行っており、たわごとコードを夢のコードにしています。「二重」システムを取り除きますが、それらを作成しません。
ちなみに、リョウシャは最後の点について別の報告をしました。
さて、それはどのように機能しますか？
- : , , GitHub — , , .
- — . 360, : . - .
- — : , . (, ) , , . , ( ) « !». , , . , .
- , . : , , — « ». , .
しばらくして、ソチでの集会でチームは仮想化されました。それから私たちはパピルスのような紙に原則を印刷し、それらをフラッシュしました、そして誰もが彼らが家に持ち帰った美しいパンフレットを手に入れました。
チームリーダーは、私たちのサインを血の紙に書きたいと言っています。彼は冗談を言っていると思います。
原則は今変更することができます。誰かが良いアイデアを思いついた場合、何かが気に入らない場合、または何かを追加したい場合は、チームメンバーは誰でもリクエストを作成して投票を手配できます。100％「賛成」で修正が行われました。
重要なことは、問題について交渉し、話し合うことを恐れないことです。
それはあなたとどのように機能するのだろうか。