チームのプロセスは制御不能ですか？

私はソフトウェア開発チームのリーダーであり（最近、新しいチームを管理しました）、最終的には高い生産性、優れた品質、組織的な優先順位を維持する責任があります。

私のチームには6人の上級開発者がいますが、ここでは混乱のように感じます。状況は、私たちの会社の約10の異なる連絡先からのJIRAリクエストに対処する必要があり、それらはすべて異なるビジネスユニットまたはクライアントを表しているということです。

私が抱えている問題は、私の仕事は主に一日中火を消すことと、すべての人の問題に取り組んでいることを確認することです。残念なことに、当社の文化は高い生産性（高速リリース）でありながら低品質（生産バグ）であり、クライアントは結果の突然の遅れを受け入れません。

これを処理する良い方法は何ですか？私にはたくさんの理論がありますが、私のような状況で実際に働いた経験のある人からの答えを探しています。

動作の簡単なリストを次に示します。

• 各開発者は、特定のアプリケーションと対話するサービスに対して責任を負います。
• 通常、リリースは、シミュレートされた実稼働サーバーでクライアントによってテストされ、ライブサーバーに展開されます。
• 各アプリケーションは平均50〜80人で使用され、合計8つのアプリケーションがあります。

ありがとう

クライアントは結果の突然の遅れを受け入れません

さて、彼らは得ている質の悪いものを受け入れなければなりません。

これを変更するためにあなたがしなければならないことは、クライアントにソフトウェア開発（またはその他の生産！）の現実を受け入れさせることです。

間違っていること、壊れていること、不平を言う原因となった時間の大きなリストを作成します。これらの問題の理由を説明し、それを変更するために何をしたいのかを伝えます。チームがライブアプリケーションのサポートと修正に費やす時間の割合を説明してください。その上でデータを収集していない場合は、今すぐ開始します（そして、クライアントに情報を提示する前に1か月間収集します）。

主要な利害関係者を部屋に集めて、「Xを修正しますか、それとも Yを配信しますか。2つのうちの1つだけの時間しかありません」と言います。優先順位を設定する責任を彼らに与え、能力が限られていることを明確にします。彼らが何か新しいものを求めたら、それを達成するために現在のロードマップから何を犠牲にしたいのか尋ねてください。

「正しいことをする」ために必要な時間とリソースをチームに尋ねてください（基本的なバグの修正と、コードの品質/アーキテクチャなどの大きな問題の修正の両方）。利害関係者が優先順位を付けなければならないもののリストにそれらの項目を含めます。

現在の仕事で私がやったことの中で一番良かったのは、上位8人の関係者を同時に部屋に入れて、求められた新機能を表す16枚のインデックスカードの山をレイアウトすることでした。私はテーブルから退き、「これらのいずれかを一度に配達することができます。どの順番で注文しますか？」と言いました。途中で立ち往生するのではなく、ビジネスの優先順位についてお互いに議論させます。

停止、ドロップ、ロール。火は燃料を必要とし、しばしばパニックの形で来ます。自分とチームを順番に管理する時間を確保してください。開発者を評価して、十分なスキルを持っていない人や、必要な結果を得るのに十分な努力をしていない人がいるかどうかを確認します。誰が留まるか（そしてそれらを維持する努力をする）、誰が少しプッシュする必要があるか、残りは行かなければならないかを決定します。プログラマーが自分の仕事を確実に行えるようにするためのサポートとツールを評価してください。サウンドテスト、レビュー、ソース管理、およびドキュメントに従っていることを確認してください。優れたツールを備えた優れた人々は、優れた仕事をするために責任を負う必要があります。

チームが何をする必要があるのか​​、現在作業中、いつ完了するのかを知るためのシステムが必要です。これを実現するための多くの方法論、理論、ソフトウェア、乾式消去ボード、付箋、文書、電子メール。誰もがそれにこだわることで何かを機能させます。誰もがシステムに何らかの入力を持っている場合、それに従うことにより多くのインセンティブがあります。

クライアントが期待するものをよりよく理解してください。これはあなたの仕事の一部ではないかもしれません。自分の髪が燃えているふりをしている他の人がいるかもしれません、彼らのクライアントは不幸であり、空が落ちています。それは彼らがすることであり、一部はそれが本当に得意です。すべてが緊急事態である場合、何も緊急事態ではありません。すべてが完了しないためです。時々クライアントとの議論に参加することを申し出ます。開発チームにたどり着くまでに、多くの「欲しいもの」が「ディールブレーカー」に変わることがわかります。技術的な連絡または他の言い訳をしてください。あなたが守れない約束をすることは、彼らがそもそも聞きたくないことを彼らに伝えるよりも悪いです。良い仕事をしたいので、5週間ではなく8週間が必要です。彼らは長期的にはより幸せになります。

最終的には、クライアントにソフトウェア開発について教育し、可能な限りプロセスに関与させる必要があります。彼らが今見ているのは、新機能の迅速な提供だけでなく、ソフトウェアのバグです。前者には満足しますが、後者には満足しません（またはそうすべきではありません）。

新しいソフトウェアの配信が少し遅れる一方で、より良いプロセスでバグが少なくなる（ゼロになることは決してない）ことを説明する必要があります。これが今後の道であるという合意を得られれば、開発の制御を取り戻すために必要なプロセスの導入を開始できます。

ここで、アジャイルプロセスを使用すると、顧客がチームの一員として含まれることが示唆されるため（また、一部の実装命令では）役立つことがあります。クライアントを非常に密接に関与させると、何が機能し、何を直接作成できるかがわかります。

私の（経験が限られている）意見：解決すべき2つの問題があると思います。まず、品質プロセス。間にスクラム/ウォーターフォール/何かを使用しますか？スクラムでは、各ストーリーに追加のタスクを追加できます。1つはテストスクリプト/プランを作成し、もう1つは実行し、もう1つはコードレビュー用などです。ウォーターフォールでは、これらのステップを簡単に追加できますか？

もう1つの問題は、ソフトウェアのどこにでも存在する大規模な主な問題です。期待を管理する。つまり、Xを実行するためにボタンが必要であると叫んでいる人からそれを配信するまでの時間が増加しています。

プロセスに追加の手順を追加して、それについて大きなファンファーレを発表できる場合[現在、この品質プロセスを実装しています。これにより、バグを修正する時間が短縮されます。より良い品質の結果！大きなメール/会議などを知らせて、定期的に結果を配信します（ala scrum）。アイデアは、あなたが配信しようとしている人が追加のプロセスステップで価値を学び、それを確認し、それを購入することです。バグの修正にかかる時間の短縮=機能の実装とテストに要する時間

クライアントは結果の突然の遅延を受け入れませんか？彼らはほとんどする必要があります。そのままでは継続できないことは明らかです。おそらく、追加のQAステップを追加し、必要に応じてチームメンバーを追加できますか？しかし、品質のステップは絶対に必要です。

スクラムなどを使用する場合も、結果が定期的に配信されるように、1週間のスプリントを目指すことができます。それは人々をなだめるでしょう。

それがある程度役立つことを願っています..私がポイントを見逃していないことを願っています。

あなたが説明したことは非常に普通のことであり、本当に心配することはありません。

• 顧客は通常、エンジニアよりも重要なことについて異なる考え方を持っています。私たちは物事が正しいことを望んでいますが、顧客は純度よりも時間厳守に報いる現実に直面しています。彼らは競争力を高めるために問題を迅速に解決する必要があり、それはまさに彼らがあなたに支払っているものです。
• 重要な問題のバックログがあるため（JIRAを使用している）、1人で管理するには優先順位の設定が大きすぎて難しいので、関心のある各領域を管理する副官が、重要な仕事を前に保つための最良の選択肢ですスケジュール。

心配することは何もありません。そうは言っても、可能な限り多くの管理タスクを有料の顧客に移し、優先順位を設定する開発プロセスに関与させることで、多くの苦労を省くことができます。可能。