チームのアウトプットを継続的に改善する
私は自分のソフトウェアサービス会社DIGICORPを持っており、10人の開発者のチームを率いています。会社全体の規模は約50人です。私たちは2004年からこのベンチャーを始めた4人の友人です。
昨年は、Getting RealとReworkの本を 7signals 創設者から読みました。 Zappos が行ったことを綿密に追跡し、質の高いサービスの提供と社内の優れた環境の構築に重点を置き始めました。これは私たちのビジネスのやり方を大きく変えました。
私たちは友好的な文化を築くことができました。また、チームがインフラストラクチャに関する問題に直面していないことを確認します。チームが会社で働く理由がますます増えるように、私たちは革新的なイベントを続けています。
私たちはビジネス上の意思決定に次の変更を加え始めました
- 限られたチームサイズ
- 問題にもっと時間をかけない（深夜の滞在を避け、週末に働く）
- 5日と8時間の効果的な出力
私たちは主に次の2つの問題に直面しています。
- 今日得られる出力は、過去に比べて少ないことがわかります。これは単なる観察ではなく、私たちの古い従業員の何人かは私たちと1対1で話し、彼らも同じ質問をします。
- 私たちは最近、友好的な文化の中で、ほとんどの場合、仕事の良い面を示し始めており、誰かが間違いを犯したときに誰かを叱責することが難しくなっていることを発見しました。また、同じ事実から、社内の誰もが最大の成果を上げていると感じています。
だから私が探している答え：
- チームの全員が定期的に生産量を改善し続け、8時間の価値がますます高くなるように、文化を改善するにはどうすればよいでしょうか。
いくつかの質問と提案：
- 出力をどのように測定していますか？
- 出力の品質をどのように測定していますか？
- ソフトウェアを簡単に拡張できますか？
「過去により多くのことを成し遂げた」と言うのはいつでも簡単ですが、何らかの測定（品質や拡張性の要因などの長期的なコストを含む）がなければ、あなたは本当に知りません。速度と出力を測定する手法を提供するソフトウェア開発手法（かんばんなど）があります（ただし、正確な科学ではありません）。つまり、品質レベルyでxタイプの機能を構築するのにかかった時間を記録し、プロセスを変更するときにそれに対して測定を開始する必要があります。
以下のコメントセクションへの返信-その場合、さまざまなアプリケーションで作業している場合でも、出力の測定を直接開始したいので、共通の作業単位の測定を開始できます。例えば「SSOのビルドには約3日かかり、通常は2つの重大な欠陥が報告されます」または「エンドツーエンドで機能するCRUD画面のビルドには約4日かかり、0個の欠陥が報告されます（ユニットテストと統合テスト）岩！）'
- ビルドインフラストラクチャを 継続的デリバリー に進めましたか？
インフラストラクチャは良好のようです。しかし、クライアントが望むなら、次の1時間でPRDに展開できますか？
以下のコメントセクションへの回答-優れたCIプラクティス（ここではJenkinsは人気のあるxプラットフォーム、x言語ツールです）から始めて、開発環境の継続的デプロイに移行します（Javaの世界では、JRebelはこれに最適です）およびテストシステムとprdシステムの継続的デリバリー。これを行うには時間がかかりますが、は出力の増加であなたに返済します。
特定の方法論に惜しみなく従うのは好きではありませんが、現在、カンバンを使用することの大ファンです。これは、作業しているチームの速度と出力を示しているためです。最も重要なのは、ブロックがどこにあるかを非常にすばやく示していることです。オフQA」。
以下のコメントセクションへの返信-チームに最適なものは何でも、個人とチームの出力を測定できます。単位は何ですか？使用できる科学単位はありません:)。何かを構築するのにかかる時間に関するいくつかの履歴統計を構築し、その作業の品質（報告された本物のバグの数と拡張の難しさ）を監視する必要があります。私はJIRAとGreenhopperを使用してこれを追跡します。これは、開発者が見積もりを入力し、タスクを完了するのにかかったリアルタイムを追跡できるためです。時間の経過とともに、タスクを1日のチャンクに分割する方法を学び、出力を合理的に正確に測定できます。 これは正確な科学ではなく、開発者は生産ラインの労働者ではないことを忘れないでください
- 「物事を成し遂げる賢い人々」のチームがありますか？
- チームは集合的に問題に責任がありますか？
私が見た中で最高のチームは、静的コード分析（ここではソナーが良い）やピアコード/設計レビューなどを通じて、高品質のバーを維持するという仲間からのプレッシャーを常に持っています。
以下のコメントセクションへの応答-CIビルドが提供できるレポートから始めます。 Javaの世界では、PMD、FindBugs、JDepend、テストからのコードカバレッジなどがあります。非常に迅速に、個人はカバレッジの割合を最大にし、ビルドを中断せず、FindBugsの量を最小限に抑えたいと考えています。警告など。また、品質を向上させる方法や、同僚と協力する感覚についての開発者からのアイデアを奨励します。昼食時または午後以降のテクノロジーに関するプレゼンテーションなどが役立ちます。
また、問題を解決するための集合的なアプローチを奨励することもできます。適切な文化が整っていると仮定すると、個人は、失敗したことを知っており、チームが同僚が混乱から抜け出すのを助けるために一生懸命働くことも知っています。 。私たちは皆人間であり、結局のところたくさんの間違いを犯します！実際、あえて私は間違いを罰するべきではないと言います-時々あなたは勇敢な技術的決定をする必要がありますが、それは後でうまくいきません、それはソフトウェア開発の性質です（時々）。
そのような文化の一部であることに単に気が進まない人もいます（「賢くて物事を成し遂げる」）。あなたはそれらをニッチに見つけるか、単にそれらを手放す必要があるかもしれません（それはビジネスの厳しい現実です）。
HTH！
「継続的に改善する」。あなたがやるべきだと思います回顧展。
ふりかえりとは、プロジェクトまたはプロセスの最後（多くの場合、反復後）にプロジェクトチームが開催する会議であり、回顧展の対象となるプロジェクトまたは期間について何が成功したか、何を改善できるか、および将来の反復またはプロジェクトにおける成功と改善。
正しく実行された回顧展は、障害を取り除くことによってチームのパフォーマンスを向上させるはずです。
これにチーム全体を参加させることで、より良い提案とチームのコミットメントを得ることができます。
チームが会社で働く理由がますます増えるように、私たちは革新的なイベントを続けています。
私の経験では、強いチームはあなたが誰かに会社にとどまるように提供できる最も良い理由です。人が自分のチームとのつながりを感じ、チームの成果に何らかの責任があると感じた場合、チームが成功したときに大きな喜びを得て、離れる可能性が低くなります。
私は個人的な経験からこれを知っています。敵対的な環境で仕事に長くとどまっていたので、私は自分のチームが好きで、去ったら彼らをがっかりさせるだろうと感じました。この事実は、私が受講した「Building TeamsthatWork」と呼ばれるソフトスキルコースでも詳細に説明されました。
あなたはあなたのチームを小さく保ちたいと言いました。各チームが異なるプロジェクトに取り組んでいると思います。おそらく毎年の終わりに、あなたはそれを超えたチームに賞を与えることができます。私の現在の仕事は毎年会社のパーティーで彼らに与えており、フィードバックはお客様や他の従業員から取り入れられています。チームの全員に見栄えの良い賞と商品券が贈られます。これは、会社のために素晴らしい仕事を生み出した強力なチームを認識する良い方法です。
8時間の目標については、これは1日8時間ですか、それとも平均ですか。個人的には、タイミングが許せば1日か2日休むことができれば、1日10時間まで働いてもかまいません。クランチ中はどうですか？私はあなたがあなたの質問であなたがそれらを避けようとしていると言ったことを知っています、しかしあなたは予期しない仕事がいつ来るかを決して知りません。ある種のフレックスタイム制はありますか？ここで少し余分に働いたら、そこで少し休むことができますか？
1日8時間を義務付けることは、思考プロセスに時間測定を課すことです。ある日、開発者は木立に入り、そこに何時間も滞在することができます。他の日は、ジュースが流れず、午後5時がすぐに来ることはありません。たぶん、あなたの開発者に毎週、何か新しいことを学ぶことに関連してうまくいかないことを研究できる自由な時間を提供しますか？
それがあなたにいくつかのアイデアを与えることを願っています。