サポートマンネリから抜け出し、技術的負債の返済を開始する方法！

友達がいます"。はい、良いスタートですが、正直なところこれは私ではありません！

基本的に、彼は今、約4年間のプロジェクトの成功に取り組んでいます、困難がある技術的負債が追いついたと、彼はそれがほとんど不可能製品サポートを停止するために見つけることだ（これを微調整をしていること）と、実際に上に移動本当の開発。

私はさまざまな提案をしました、あなたのすべての時間を記録し、チケットを作成し、電子メールなどに答えないなど。これに関する問題は、彼が何も「有用な」ことをしていないことを思い出させるだけのように見えることです。

技術的な負債は主に発生しました。なぜなら、最初の例では、ユーザーからのリクエストや電話を受け取り、すぐにそれらを実装することが製品にとって大きな利点だったからです。

私が知りたいのは、誰も彼がこのわだち掘れから抜け出す方法についての提案を持っていることです。その大部分は、ユーザーが何かを鳴らして期待することができないと思うように、ユーザーの認識を変えることですその場で行われます。

サポートの必要性とユーザーからの相対的なプレッシャーを考慮すると、実際の開発を計画することは非常に難しいと理解していますが、計画はより良いと言っています（上記参照）。

友人の組織には、変更管理を行うための誰かが切実に必要です。この個人またはグループは、変更要求とバグ修正を受け取り、ビジネスへの影響と必要な労力に応じて優先順位を付けます。そうすれば、現時点で友人を悩ませている人にとってより重要なタスクとは対照的に、組織全体にとってより重要なタスクが最初に実行されます。

編集：これがどのように機能するかの例として、ほとんどの組織には重大度スケールがあります。最高の重大度レベルは、機能しないビジネスクリティカルなアプリケーションまたは機能です。ビジネスが問題を回避するためにできることがあれば、それは次のレベルに重大度を下げます。アプリケーションがビジネスクリティカルではない場合、それにより重大度はさらに低くなります。通常、新しい拡張機能のリクエストには個別に優先順位が付けられます。

他の誰かに電話をかけてもらい、回線を

それについてはすぐに説明します。

に

非常に良い提案。機能リクエストを作成して、できるだけ早く作業を開始します。リクエストの進捗状況を確認するには、[ケーストラッカーチケットへのリンク]で追跡できます。将来的には、私がここにいるのと同じ方法で先物のリクエストを送信することもできます：[ケーストラッカーへのリンク]

私の意見では、おそらくそれが最も簡単で効果的な方法です。最後のビットは、時間をかけて呼び出しに応答するこの人へのストレスを軽減しようとします。

現在の「優先度」システムで見られる問題は、すべてが優先度であるとき、何も優先度ではないということです。そのため、あなたの友人は、@ Larry Colemanのアドバイスに必死に耳を傾ける必要があります-変​​更要求を管理する開発とは別の人々です。理想的には、その別のグループが仕事のために優先順位をつけるべきであると同意するまで、あなたの友人は機能要求についてさえ知るべきではありません。ビジネスを理解し、開発を理解している限り、それは彼らに優先順位を付けている呼び出しに今答えているこの新しい人でさえありえます。

私自身も同様の状況を経験しています。この製品は靴ひもに基づいて構築されており、発売された最初の市場です。最初は成功しました（単独のプレナービジネスの場合）が、2003年から2007年までは何でもうまくいったと思います。スタッフを探しましたが、優秀なスタッフを雇うのは費用がかかり、決して簡単ではないという難しい方法を学びました。あなたの友人も同じような状況にあると思います。

私の場合、物事はある時点で下り坂になることが早くから明らかになりました。事業はまだ成長していましたが、競争は頭打ちになっており、市場は縮小しようとしているように見えました。製品が最終的に死ぬことを決定する私。後の方が良い（顧客と私にとって）。

振り返ってみると、私はおそらく私が悪い決断をしたのと同じくらい多くの良い決断をしたが、ここに簡単な要点がある：

1. 適切かつ早期にスタッフを配置します。必要に応じて資金を得てください。（何も探していないことが、私の最大の間違いでした。）売り上げがあれば、お金が見つかります。

2. バージョン管理/単体テスト/ベストプラクティスに関連するすべてのhooplaを使用します。彼らはすべて、大学で教えられたとき、馬鹿げた/馬鹿げた/面白くないように見えますが、通常、正当な理由でベストプラクティスです。

3. 特に技術志向の場合は、少なくとも1人の営業/マーケティング担当者を雇ってください。（そうだとすれば、アフィリエイトネットワークを持っている場合でも、マーケティングよりも技術の問題に多くの時間を費やす傾向があるでしょう）。

4. サポートをクラウドソーシングします。ユーザーが自分で手助けできるように、フォーラムを設定します。チケットシステムをセットアップし、専門ユーザー（通常はフォーラムユーザー）を招待して、仮想アシスタントとして特別なセクションに飛び込みます。この/その小さなタスクを数ドルで行う必要がある多数の顧客の世話をさせてください。そうすれば、全体像に集中できます。

5. 提供するサポートの量を減らす努力を最大限に活用してください。サポートが少なければ少ないほど、もっと面白いことをしなければなりません。製品がダミーの証拠になるまでに、顧客は感謝するようになり、販売スタッフとサポートスタッフも感謝します。

6. 実際の開発者にいくつかのサポート（1日1〜2時間、現実との接触を失わないようにする）を依頼し、リエンジニアリング/製品（UI、機能）の変更を提案する自由な手を与えるサポートに費やす時間を減らすものを特定します。アイデアは、同じ理由で何度も何度もユーザーからナグされた場合、できるだけ早く修正して、サポートコールを取り除くことができるようにすることです。そして、よりスマートなものは実際にそうします、そしてそれはまさにあなたが望むものです。

7. 製品が死ぬと思うなら、あちこちでそれを殺して、次のステップに取り組むことに決めます。本当に死にましょう。キャッシュカウはキャッシュカウです。目的を果たしたら、肉屋に送ってください。優しく（顧客のために）行いますが、メンテナンスのオーバーヘッドが後発者であり、技術的な負債を積むという利点があるので、メンテナンスのオーバーヘッドがあなたの時間の多くを浪費させないでください。 、とにかくあなたができるよりも速く新機能を実装します。

一度に1行。修正ごとに少し時間をかけて、ハックをクリーンアップし、自動テストを追加します。多くの場合、正しいことを行うと、別の修正プログラムを追加するよりもはるかに高速になります。経営陣が友人の仕事をより速くするように促した場合、経営陣はしばしばやりたいと思うので、彼はより太い肌を成長させ、「完了したら」モードに入るべきです。

重要なのは、彼をある程度保護するために、彼の周りにはどのような開発方法論がありますか？たとえば、スクラムでは、通常、スプリント中に実行される作業は変わらないという考えがあります。したがって、何が行われ、何がすぐに行われないかについて、いくつかのルールがあります。他の質問は、経営者がサポートマンネリになりたくないという彼の望みをどの程度サポートしているかということです。これは、無関心な管理が友人のプロジェクトにとってちょっとした死の秘ellになりかねないため、重要です。

一番いいのは、バスを止めて振り返ることです。あなたの友人は

• システム内の各問題のレポートと、それらが悪い理由の背後にある理由を作成します。設計上の問題、およびリファクタリングの必要量を強調する必要があります。
• 問題を修正するために大まかなスケジュールを指定する必要があります
• 報告書は彼の管理者に渡され、システムの利害関係者に渡されるべきです。
• すべての機能開発は、修正期間中に停止する必要があります。

多くのプロジェクトがこれを行います。経営者が納得できない場合、それは失われたケースであるが、彼らが同意すれば、システムは長期的には形に戻る可能性がある。