バグ以外のクライアントリクエスト、つまりUIの小さな修正で開発者として何をしますか？

Question

私はプロジェクトに取り組んでいるたった1人の人間です。だから私はPMのない開発者です。私はポータルを完成させ、時々「ホーバークライアント」が「フォントを大きくする」などのリクエストで私を攻撃します。または、CSSのマージンを変更するか、「xxxとyyy」を作成するボタンを作成します。 シンプルなタスクがあり、数回クリックするだけの場合もありますが、時間がかかり、そのようなタスクを行うのは嫌です。一方で、私はそれらの人々を理解していますが、時には小さな修正が彼らを仕事で大いに助けます。それらをコミュニケーターで言うこと-それらを無視するのは難しいコミュニケーターを無効にするのが最善の解決策ですが、同僚と通信するために必要です。 そのような状況であなたは何をしますか？

Answer 1

日常のワークフローを中断させない方法で、ユーザーがリクエストを送信できる確立されたキューを作成します。

この音から、定期的に確認する通信チャネルを介してリクエストを取得しているため、横に移動しようとするかもしれません。

通信の切断は決して良い解決策ではありません。また、これらの種類のリクエストに対応するためのプロセスとタイムスケジュールを正式にします。このシンプルなアプローチで大きな成功を収めました。

Answer 2

自分で仕事をしている場合、クライアントはあなたがそこにいる唯一の最も重要な理由です。彼らはあなたのビジネスです！したがって、彼らを幸せに保つことは常に良い習慣です。

それは言われています...

クライアント用のあらゆる種類のソフトウェアプロジェクトで作業する場合は、常に明確に定義された契約が常に必要です。あなたとあなたの両方にあなたの成果物が明確に表現され、定義されることを保証する必要があります。面倒を見たら、「今後のメンテナンスリクエスト」をカバーするセクションがあることも確認する必要があります。クライアントと協力して、スペクトルの両端で期待が受け入れられるようにし、それらに費やした時間を考慮し、元の計画の一部を前進させます。

オープンエンドが少ないほど良い。

その後、実装した各プロジェクト/ウェブサイトに対する顧客の要求を管理/処理するシステムを実装することも大きな助けになります。このサイトの創設者の FogBugz のようなツールは、顧客とのやり取りやバグ/機能の処理に優れた働きをします。リクエスト。確認してください。

Answer 3

技術的な「バグ」ではありませんが、ユーザーにとって最も重要なバグはクライアントによる使いやすさです。クライアントとのビジネスを継続する場合は、小さなことを行う必要があります。

小さなバグの修正==クライアントの幸福==より多くの仕事==もっと$$

Answer 4

バグを追跡し、変更要求を追跡するシステムを展開します（私のオフィスでは、ソースの整合性にも使用されるMKSを使用しています）。次に、ユーザーがリクエストを受け取ると、ユーザーは追跡システムに入り、適切なタイプとしてリクエストを入力します。理想的には、未解決のリクエストをランク付けできるように、重大度/優先度インジケータを添付できる必要もあります。次に、すべての未処理のリクエストを確認して優先順位を付けます。彼らはあなたに直接送られていないので、あなたはリクエストで溢れているとは感じず、ユーザーはあなたに電話して私の修正をいつ行うかを尋ねるよりも簡単に彼らのリクエストのステータスを追跡できることに気付くでしょうか？ ＆quot;

自分でリストを1日に2、3回確認し、優先度の高い問題があるかどうかを確認できます。次に、優先順位の低い問題に取り組むために、定期的に（合理的と思われる1週間に1日、または1時間に1回）スケジュールを立てます。

Answer 5

顧客との継続的な関係を考慮する必要があると思います。顧客が時々あなたの時間の数分を過ごすならば、あなたはあなたへのコストが最小であり、とにかくコンタクトの利益がコストを上回るかもしれないと考えるかもしれません。

リクエストが大量かつ迅速に届く場合は、変更の時間料金について顧客に相談するか、有償サポート契約でカバーする必要があります。

Answer 6

取得する各機能リクエストでパスを変更しないでください。機能リクエストをしばらく収集し、リクエストに優先順位を付け、意味のあるものを選択して、次のリリースに取り組みます。

私の意見では、いくつかの固定リリーススケジュールに従うことをお勧めします。開発プロセスをより制御しやすくし、ソフトウェアの品質を向上させ、顧客は何を期待すべきかを理解します。