ゼロバグに到達し、ゼロバグポリシーを実装した方法

では、バックログにはいくつのバグがありますか?何百?もっと?もっと少なく?よくわからない?さて、今、私たちのバックログにはいくつのバグがあるのか​​教えてください。バックログのバグの数は…お待ちください…ゼロです。ゼロ、ジルチ、n。あなたはこれを間違って読んでいない。バックログにはバグがありません。 —バックログにバグがゼロであるだけでなく、ゼロバグポリシーでそのように保つことを計画しています。この信じられないほどのマイルストーンをどのように達成し、ゼロバグを順守するためにどのように計画しますか?答えはあなたが思うほど複雑ではありませんが、いくつかのハードルがないわけではありません。

まず、少し歴史

ちょうど2年以上前にConceptShareに入社して品質チームを指揮したとき、バックログには350以上のバグが記録されていました(クレイジーではありませんが、小さくもありません)。深byをじっと見た後の最初の質問は、「1年以上前のすべてのバグを削除できますか?もちろん、答えは「いいえ」でした。その広範なバグリストには、製品の品質を向上させるために使用できる知識が含まれていました。お客様の経験。同時に、カスタマーエクスペリエンスに影響を与える新しいバグとともに、古いバグのバックログに対処し、新機能の開発と製品の改善を継続する方法が必要でした。

なぜバグがゼロになるのが重要なのですか?

バックログにバグを集めてほこりを収集するのは本当に残念です。

  1. バグは製品のパフォーマンスに影響を与えるため、顧客にとってはうんざりです。私たちはそれが好きではありません。回避策、「おっと、それを見逃した」、「他のバグが修正されたら…」などの回避策や経験がない方法で、お客様が当社製品を使用して体験することを望んでいます。私たちの進歩的なポリシーは、お客様を最前線に置いて、お客様の製品での経験に集中できるようにし、「ConceptShareがXを適切に処理してくれたらいいですね」から「それがうまくいった!」 ConceptShareが作業を支援する他の方法を調べてみましょう。」
  2. 顧客に対する最前線のサポートであるクリエイティブオペレーションズアドバイザーにとってはうんざりです。既知のバグについて顧客から同じ苦情を聞いたり、修正がいつ実施されるかについて実際のタイムラインを提供できないのに時間を費やす代わりに、ConceptShareが仕事を手伝う新しいエキサイティングな方法を顧客に示すことに時間を費やすことができますできた。つまり、顧客サービス/サポートから真の顧客成功に焦点を移すことができます。
  3. 最後に、製品開発チームにとっては非常に面倒です。新しい機能を構築するときに既存の欠陥をナビゲートすると、作業に不必要な時間と複雑さが追加され、機能と改善が少なくなり、最終的にお客様に影響を与えます。 「次に出荷する大きなものは?」と言うことができるということは、「この機能を開始する前にこれらのバグを修正する必要がありますか?」から信じられないほど更新されます。既存のバグは、バグ修正ではなくイノベーション。

バイインを取得する

Zero Bugsにたどり着くというアイデアを持ち、それに関する戦略とポリシーを実装することは1つのことでした。どうやってそれを成し遂げるのかを計画する前に、シニアマネジメントチームからのサポートと賛同が必要でした。そうでなければ、新機能を出荷し、顧客の要求に応えると、常にバグ修正がバックバーナーに置かれます。これが私たちの事例です:

-なぜこれが重要な目標でしたか? 1.お客様向け(外部)および2.チームメンバー向け(内部)

-バグのバックログ(生産性、より多くの機能をより速く出荷できない)、収益の損失、アカウントの成長への影響、パフォーマンスレベルを維持するために不要なインフラストラクチャに浪費される現在のコスト

-ゼロにする方法は?

-ゼロに達したら、ゼロバグポリシーをどのように維持しますか?

CEOを完全に迎え入れるには、時間と議論のサイクルが必要でした。バグの数を減らすためだけに開発時間を費やすという考えは不可能に思えました。ただし、上記の説明により、バグがゼロになっただけではないことが明らかになりました。これは、お客様にとっても、チームにとっても、そしてお客様が愛する製品を革新し、構築し続ける能力にとっても、それ以上のものでした。 (そして私たちの一番下の行!)

私たちは彼を「WTF!そんなに努力を捧げる方法はありません」から「これは絶対に理にかなっています。私たちは彼を勝ち取っただけでなく、このトピックに関する彼自身の投稿を書いており、今ではゼロバグの熱心な支持者です!

入門

達成可能だと感じた月ごとの目標をタイムラインに設定することで、バックログに取り組み始めました。製品チームは、入ってくる新しいバグに取り組み、機能の作業をかなりの速度で進めることと併せて、バックログを月に10バグ減らすことを約束しました。ご想像のとおり、これは最初の1か月間、2か月目は正常に機能し、3か月目までには、バグ削減目標を達成するための機能タイムラインのリスクが明らかになったため、バックログと新しいバグの両方についていくのに苦労していました開発者に強いられた厳しい電話。追いつくために、我々はバグ修正の爆発をしました。バックログと「新しい」バグは減少傾向にありました。これで軌道に乗れましたが、4か月以内に古い方法に戻ってしまいました。機能の作業などのためにバグが横に寄せられていました。何かを与えなければなりませんでした-バグをそのままにして、現在のパスを続行するか、新しいアプローチを見つけてください。

計画の調整

バグをゼロにするための最初のアプローチが期待どおりに機能しなかったため、さまざまな方法でこれに取り組むようになりました。バグに対処するための成功したアプローチは目の前にあり、バグ修正にアプローチを適用することは考えていませんでした。 ConceptShareでは、「機能チーム」と呼ばれる作業を行います。開発者は、チームが最も関心のある機能に取り組むことができます。私たちは自分自身に挑戦し、取り組むものを選ぶことができるので、素晴らしいアプローチです。幸せな労働者の考え方とすべて。それで、バグを他の機能のように扱ったらどうなるか考えました。開発チームの誰もが、バグがなくなるまでバグをつぶすことに興味があるでしょうか?チームのメンバーがこの挑戦を喜んで受けて、バグをゼロにすることができました。チームが結成され、計画を立て、仕事を始めました。

完了しました!ゼロバグ。それで?

18か月の熱心な作業の後、努力の集中方法に関するいくつかの議論、プロセスの若干の調整、目標日から2か月先の目標を達成し、バックログにバグがありません。繰り返します。バックログにゼロのバグがあります。これは素晴らしいマイルストーンです。私たちのチームは有頂天です。んで、どうする?

  1. 新しいゼロバグポリシーを実装しました。

「当社のポリシーでは、どのリリースにおいても、新機能の構築よりもバグを排除することが最優先事項です。これは、バグの修正、ユーザーへの対応、および製品の品質を可能な限り高く保つためのコストを削減するためです。」

2.バグチームは製品機能の仕事に戻り、製品チームの他のメンバーと一緒にゼロバグポリシーにコミットしていることに留意しながら、次の機能を選択できるようになりました。

3.当社の製品チームは、古いバグのために遅れることを心配せずに製品の成長に努めています。今、私たちは本当にガスに足を踏み入れることができ、以前よりも多くの機能と改善をより早く出荷できます

4.クリエイティブオペレーションアドバイザーは、バグXおよびバグYが修正されるのを待たずに、顧客が製品で達成できるすべてを実現できるように完全に集中できるようになりました。

5.そして最も重要なことは、お客様がConceptShareを活用して、ソフトウェアの迷惑なバグにとらわれずに、よりスマートに、より速く、より良く動作できるようにすることです。

ゼロバグズにとどまる方法

これを達成するために、バグプロセス(おそらく他のバグプロセスと高レベルで類似している)を強化して、公式のゼロバグポリシーに合わせました。これらの変更は次のとおりです。

バグのトリアージ

通常、トリアージ会議は、利害関係者のグループ(PM / COA / DevチームメンバーおよびQA)によって毎週行われます。バグは、重大度/影響が明確でない場合、関係者から追加情報を取得するQAチームによって到着時にトリアージされます。バグは製品チームに送信され、誰かが入手できます。

トリアージされたバグはすぐに請求されます

トリアージされたバグはもはや存在しないため、誰かが作業を開始するのを待つ必要はありません。

より積極的なアプローチを行っているQAチーム

特定の期間内にトリアージされたバグが申し立てられていない場合(作業が開始されている場合)、QAチームは製品チームに連絡してバグを割り当て、作業を開始します

リリースの繰り返しを増やす

リリースサイクルではさらに積極的になるよう努力します。そのため、バグ修正により、特定の機能リリースに縛られるのではなく、お客様の手に届くまでの時間が短縮されます。

まとめ

バグはありません。それにはかなりのリングがあります。これまでのところ、いくつかの浮き沈みと狂気のウサギの穴があるかなりの旅でしたが、これで終わりではありません。過去1年半にわたって、ConceptShareでのバグの処理方法に関する新しいポリシーを採用するだけではありません。これは現在、私たちの文化の一部です。最も重要な利害関係者である顧客に浸透する最高品質の高品質の機能や能力を開発するにつれて、私たちの働き方に組み込まれています。

また、これを実現させたチームに多大な「ありがとう」と言いたいです。 (バグ形状のピニャータで私たちが祝った方法をチェックしてください。)

私は興味があります-他の誰かがバグをゼロにしようとしましたか?そうであれば-どのようにそれをしましたか?何を学びましたか?

このストーリーはThe Startupに掲載されており、258,400人以上が集まって起業家精神に関するMediumの主要なストーリーを読みます。

ここで私たちのトップ記事を受け取るために購読してください。