GUI での機能クリープの管理 [保留中]

https://stackoverflow.com/questions/82933

project-management

01-07-2019
|

質問

GUI で機能のクリープを管理する方法について実用的な提案を持っている人はいますか?

追加、変更、微調整などを行うよう、内部および外部の両方のソースから強いプレッシャーを受けています。誰かが「～だったらいいんじゃない？」という言葉を私に寄せてくると、いつもたじろいでしまいます。多くの場合、彼らは私の上司や顧客であるため、私は彼らに背を向けて「NO」と叫ぶことはできません。

その代わりに、私は新しい機能を絶えず追加することがなぜ悪い考えであるかを説明し、そうすることで最終製品に対する期待を管理するのに役立つ提案を探しています。

解決

機能リクエストは正式なプロセスで処理されます。通常は、プロジェクトマネージャーと最初に要件を分析した人が介して行われます。その仕事をしようとしている人が実際にそれを行うことができると仮定して、そのような種類の決定は開発者ではない人に任せる方が常に良いでしょう。

フリーランスの場合は、要件の変更に対して当然料金を請求します。また、社内の開発チームの場合は、何にお金をかけたいのかを人々に考えてもらうために、部門間の請求を検討することもできます。

ついに、 期待する 要件が変更され、機能のクリープが発生します。どのような変更が要求されるかを考慮せずにコードを作成したり、プロセスや期限が柔軟性に欠けて調整できない場合、プロジェクトが悪夢になることがわかります。

他のヒント

私がやっているのは、機能のアイデアをインデックスカードに保存し、そのカードを目に見える場所に掲示することです。誰かが「xxxもできますか？」と尋ねると新しいカードを書きます。これは、「いいえ！」と叫ぶよりも、より良い関係構築の動きです。 :-)また、潜在的に良いアイデアを失わないという利点もあります。OTOH、私はそれを今すぐに実装する義務はありません。提案者は自分たちの意見が聞かれたことを知っており、忘れることはないとわかっています。仕事に戻ることができ、脳が CodeLand にいるときよりも良いタイミングで全員が集まって優先順位の決定を下すことができます。

それでは、私がここでアジャイルの代弁者となります。そのプロセスの最後に問題を解決することはできません。プロジェクトを別の方法で管理することで問題を回避する必要があります。

特定の方法論は別として、重要なのは、それらの決定を顧客の手に委ねることです。やるべきことのリストがあります。そのリストを変更したいときは、新しい項目に対応するためにリストのどの項目が実行されないのかを尋ねます。あるいは、それを処理するために彼らがあなたにどれだけ多くのお金を与えるか。

また、作業を小さな繰り返し（1 週間から 1 か月）で行う必要があるため、合間に再調整する機会が得られます。

私たちは SCRUM を使用していますが、それは素晴らしかったです。数回の反復の後、すべてのビジネスレベルおよびプロセスレベルの項目が解決され、最終的には要求どおりのものを提供できるようになります。

このような要望は、機能設計担当者が対応するのが理想的です。好むと好まざるにかかわらず、変更は（機能設計の最初の文字からコードの最後のバイトまで、そしてそれ以降まで）発生し、追加機能のリクエストが常に発生します。したがって、デザインがそのような動的なプロセスに対応していることを確認してください。

これはおそらく非常に不十分な解決策のように聞こえるでしょう（そしてそれが良い習慣であるとは思えません）が、私は過去に同じ問題に苦労していました。私は開発、機能設計、技術設計、そして自分のプロジェクトの管理を担当していたので、それが非常に小さな会社で起こったという事実（管理における「階層」の欠如）が事態をさらに悪化させました。

私にとってうまくいったのは、問題を質問者（上司であれ顧客であれ）に戻すことです。機能設計、プロトタイプのプリントアウト、または現在の状況を説明するものを渡し、この強力な新機能を「どのように」「どこに」実装すべきかを把握するよう依頼します。

その後、上司も顧客も、それを自分の部下に持ち帰って、会議などで議論することを「強制」されました。通常、これは、2 回目以降は連絡がないことを意味します。実際にそれが実現した場合には、それは実際に機能するコンセプトでした。

あなたの会社はプロジェクトを開始する前に要件を明確に定義していないようですが、これでは泣き寝入りするだけです。

私のポリシーは、事前にすべての要件の明確な内訳を取得し、これらの要件に侵入した場合の影響をすべての関係者に認識させることです。

段階的にリリース時間を遅らせる
バグの増加
不完全な機能
スタッフのストレス
スタッフの退職。
価格の宣言時に合意した以上の最終製品を期待した場合の追加料金（これは本当に悪質です）

持続可能で生産的なシステムに固執したくない場合は、#5 を選択するか、#5 で脅したくなるかもしれません。

管理者向け:

製品の市場へのリリースが早ければ早いほど (シュリンクラップであると仮定して)、企業はより早く利益を得ることができ、キャッシュフローが良くなります。
新しい機能を完全に除外するのではなく、代替作業を行うことで得られる価値とのバランスを考慮してください。機会費用について説明します。

すべての人のために：

新しい機能が UI にはっきりと表れている場合は、視覚的な複雑さが製品全体の使いやすさ、そしてそこから魅力に及ぼす影響について話し始めてください。しかし、あなたはすでにそれを実行していると確信しています。参考文献を探してみます...

私見の最善の方法は、新機能の実装にかかるコストを正確に明確に示すことです。ユーザーがそのような追加のコストを認識し始めると、「あったらいいのに」という気持ちは本当に減り始めます。

機能について顧客と意見が相違しても、通常は何も解決しません。あなたが彼らに露骨に「ノー」と言えば、彼らは疎外感を感じ、あなたやあなたのチームとは疎遠になるでしょう。時間とお金が十分にあり、技術的な制限がないのであれば、この機能はおそらく全体的には良いアイデアだと思います。彼らの世界では、 フィズ の隣にバーをクリックした後、 をちょきちょきと切る は良いアイデアです。もちろん、私たちの世界では、これはテーブル全体のスキャン、潜在的なセキュリティ脆弱性、そして次のポイントリリースまでにそれが確実に組み込まれていることを確認するために徹夜することを意味します。

それを並べて、それが全体的にあまり良いアイデアではない理由を説明すれば、通常は理解してくれるでしょう。さまざまな要素 (時間、お金、プロジェクトに複雑さを加えるコスト、期限が遅れるリスク) をすべて忘れないでください。理性的な人なら、はっきりと絵に描いてさえいれば理解してくれるでしょうし、理不尽な人に対しては少なくとも「私がそう言った」と言えるでしょう。

機能のクリープだけを処理することはできません。開発プロセス全体を適切な方法で組織する必要があります。

ただし、あなたの説明からすると、他の人が要求したものをコーディングしているだけで、プロセスを再編成できなかったようです。このシナリオでは、他の人からリクエストを受け取り、優先順位を付け、見積もりを出し、実装スケジュールに同意し、実際にその作業に費やした時間を追跡できる追跡/発券システムを利用することで、リクエストを効果的に管理する最善の方法になります。

「この小さなボタン」には 5 秒ではなく 2 ～ 3 日かかることを現実の数字で証明できれば、顧客はおそらくそうあるべきだと信じ、交渉するのにはるかに有利な立場に立つでしょう。

新機能のせいでプロジェクトの稼働日が 2 週間遅れることを明確に示すことができれば、それらのリクエストは消えるかもしれません。

ただし、「機能のクリープ」は必ずしもネガティブなことではないことを覚えておく必要があります。アプリケーションが成熟し成長するにつれて、顧客の優先事項も変化します。それを認識しないと、完成した製品が彼らが望むものではなくなる可能性があります。まだ実装されていない元の仕様の古い機能と新しい機能を交換することを彼らが受け入れるかどうかを確認してください。

私は、作業タスクの優先順位付きリストと、ビルド X に何が含まれるか、テストの作成、コードの実装、およびその他の関連する作業に (大まかに) かかると予想される時間の見積もりを保持しています。私は常に彼らの意見を取り入れ、彼らが本当に望んでいるもの/必要としているものについて話し合い、それが全体的な計画のどこに当てはまるかを決定するよう主張します。スケジュールや他のタスクへの影響について話します。

これにより、コミュニケーションラインがオープンかつクリアに保たれます。驚きはなく、期待は管理されます。結局のところ、それは私のプログラムではありません - それは顧客 (顧客が誰であっても) のものであり、私は彼らが望む (そして必要とする) ものを彼らに構築したいと考えています。

鍵は質問の中にあるようです。

'管理します 機能クリープ」...これを行うには、従う必要がある管理プロセスを実装します。それを避けることはできません（結局のところ、顧客がそれを要求することが多く、常に彼らにノーと叫ぶことで、可哀想な生き物を追い払う傾向があります）...しかし、それは規律を欠く必要があるという意味ではありません。変更の理由や事前調査/使用例などの簡単な情報を要求者に提供する手順を確立すると、「そうしたらいいのではないか」の数を減らすことができます。これを導入すると、機能のクリープが管理され、優先順位を付けて、より一貫したフィードバックを提供できるようになります。

ユーザーには、対応されていない多くのニーズがあります。彼らは苦しんでいます。彼らは注意を必要としています、そして彼らは あなた. 。機能クリープは実装しないと起こるものだと思います 適切な機能 すでに。

ユーザーとの緊密な関係を築きます。あなたが常に彼らの意見に興味があることを彼らに伝えてください。定期的に電話をかけて、ソフトウェアが彼らをどのように扱っているか尋ねてください。
彼らの仕事の習慣、標準的な慣行、ソフトウェアの使用方法、および他のソフトウェアの使用方法を知りましょう。情報が入ってきたら、それを収集します。
機能リクエストが届いても、ユーザーは自分が何を望んでいるのか本当にわかりません。しかし、あなたには専門知識があり、耳を傾けてきたので、彼らが何を望んでいるのかがわかります。したがって、彼らと協力して彼らが抱えている問題を明確にし、集めた知識を使って問題をできる限り一般化します。解決するソリューションを書くそれ問題。

一方、「機能のクリープ」は、進化するビジネスに対するソフトウェア製品の反応であることがよくあります。顧客のビジネスが成長している場合、彼らはあなたの仕事により多くのお金を費やしてくれるので、あなたは幸運です。だから安心してください、彼らはあなたにお金を払います！ただ理解する必要があるのは、システムが大きくなるほど変更が難しくなり、すべてをスムーズに動作させるためには、新しい小さな機能でも大規模な書き直しやまったく新しいユーザーインターフェイスが必要になる場合があるということです。

機能のクリープを避けたくないという気持ちと、機能のリクエストやフィードバックを無視する傾向とのバランスに注意する必要があります。

ユーザーがフィードバックを持ってやってくるたびに、それはあなたの製品とあなたが取り組んでいることを改善する機会となります。最終的には、ユーザーと開発者の両方にとって興味深いものを追加することになるかもしれません。実際に取り組むのは楽しいかもしれません。はい、それは愚かな考えかもしれませんが、 ポーズどおり あなたへ。しかし、フィードバックを受け入れ、そこからポジティブなものを抽出し、それをユーザー、製品、会社、開発チームにとって価値のあるものに形作るのはあなたの仕事です。

そうは言っても、機能のクリープを管理するのは非常に困難です。そして、それをどれだけうまく管理できるかは、あなたの立場と「変人」が誰であるかによって決まります。あなたが中級から中級レベルの開発者で、CEO が機能を要求している場合。そうですね、その機能を追加することになります。CEO に、それは価値のある機能ではない、機能しない、あるいはもっと重要な作業が必要である、あるいはスケジュールに悪影響を及ぼす可能性がある、と説得することもできます。ただし、機能が要求されている時点では、決してそのようなことを行わないでください。最終的には、2 人が共通の目標に向かって協力するのではなく、自分の立場を守るだけになります。

代わりに、フィードバックと機能リクエスト (または機能の要求) を額面通りに直ちに受け入れてください。立ち去って、しばらく一人でオープンに考えてください。「これは価値がありますか？」「CEOがこれを求めた方法で何かが足りないのですか？」「私がそれを作っているのと同じくらい難しいですか？」これらの種類の質問を自問し、いくつかの具体的な答えを思いつきます。それから いつも 追加の質問をして CEO に戻ります。要求された機能について考え、実際にいくつかのアイデア、微調整、機能強化、反対意見などを考え出したことを実証します。これにより、オープンなディスカッションが生まれます。これは CEO も予想していなかったことでしたが、当初は彼のアイデアに対する完全な抵抗ではなかったため、おそらく反対はしないでしょう。

インターネットや Web 2.0 の類から学べる教訓があるとすれば、それは人々はカスタマイズが大好きだということです。それが iGoogle や他の何百ものサイトの目的です。GUI にカスタマイズを組み込むことができれば、顧客に気に入られる可能性があります。

また、他のプロジェクトが機能のクリープをどのように管理しているかにも注目してください。たとえば、Google ではユーザーが機能リクエストを送信できるようにしていますが、すでにリクエストされている機能のリストも表示されます。ユーザーは投票してその機能をリクエストすることもできます。私が下手くそというわけではありませんが、見てください stackoverflow.uservoice.com. 。彼らも同様のポリシーを持っています。

ユーザーの意見に耳を傾け、フィードバックを得ることが重要です。彼らがあなたよりも優れた新しいアイデアを思いつくことを期待してください。あなたが馬鹿げていると思うようなアイデアを彼らが考え出すことを期待してください。十分な数の人がそれを望んでおり、それが合理的であると思われる場合は、彼らが望むものを与えてください。

私たちの財政支援者の 1 人は、常に機能をリクエストしています。時々彼は、「x」を実行するソフトウェアを入手できないかと言います。可能であれば、私たちは彼に「はい」と答えてから、どのようなタイムスケールを念頭に置いているかを尋ねます。彼ができるだけ早く戻ってきたら、他の機能を提供するか、期限を延長する必要があることを彼に伝えます。ありがたいことに、その後、彼は通常、いつか将来のことに意見を変えます。

たとえ機能がすぐに実装されなかったとしても、アイデアやリクエストを実際に記録することが最も重要だと思います。

私たちは Bugzilla を使用してバグを追跡しますが、機能リクエストも追跡します。「機能」ワークリスト (またはターゲットバージョン) があります...そうすることで、将来どのような機能を開発したいのかを誰もが知ることができ、機能に関するアイデアが増えたら、Bugzilla の項目に簡単に追加することができます。

毎回のリリースでは、座ってバージョンのワークリストを作成するときに、機能リストに足を踏み入れて、取り込めるものがないかどうかを確認します。私たちはできる限り機能を取り入れ、人々にフィードバックを提供するように努めています。これは、機能やアイデアが無視されていないことを示しています。

このフィードバックは、私たちが機能のリクエストを認識しており、それらの機能がただリストに載っているだけではなく、実際に実装に取り掛かっていることを人々に知ってもらうのに役立ちます。

1)リリースまでの時間が増加しました。

2)コストの増加。

3) 指数関数的な維持費

4) バグの可能性が高まる

機能リクエストを管理するには、変更要求を送信するように依頼してください。定期的に変更指示を確認し、各リクエストに関するステートメントを送り返します。「これを実行するには X 時間がかかり、Y 個の追加コストが発生することを意味します。これは受け入れられますか?」要求者が追加費用を受け入れたら、問題ありません。手を洗います。:)

あなたは「確かに、それは可能です。プロジェクトの完了日がどのくらい遅れるか見積もってみませんか?」と説明します。また、その見積もりを提示すると、プロジェクトの終了までに約 1 日追加されます。」

機能の追加にはコストがかかることを関係者が理解している限り、機能を追加することに問題はありません。

機能が 1 つだけある製品を作成し、100 人の顧客全員がその製品を気に入っており、使いやすいと感じているとします。ここで、顧客のうち 10 人だけが使用する機能を製品にさらに 10 個追加するとします。選択肢が 10 倍あり、役に立たないことも 10 倍あるため、顧客の 90% が製品を使用するのにはるかに困難を感じていることがわかります。良いものは騒音の中に失われてしまいました。

もちろんこれは簡略化していますが、実際には、ほとんどのユーザーは製品の機能のほんの一部しか使用しません。

ソフトウェア設計とUI設計に関する良書を何冊か読み、上司にも読んでもらいましょう。Joel Spolsky の本は始めるのに最適です - www.joelonsoftware.com

解決する必要がある問題を定義する作業指示を作成します。作業は、問題を解決するために必要なものだけを実装する必要があるという制約を受けます。

問題をさらに改善することが、変更管理になります。

私のオフィスではワイヤーフレームに従っています。サインオフ後の変更は変更管理手順を経る必要があります。

短期間のロックイン機能セット (スクラム/イテレーション/アジャイル)。ユーザーが物事が機能していることに気づき始めると、機能の必要性または欠如がより明らかになります。

また、すべての変更を担当する人 (スクラムでは非常に優れたプロダクトオーナー) がいると便利です。

見せる 彼らはどうやって シンプルな GUI が効果的である場合があります。 例:AppleのソフトウェアであるGoogle Chrome。Eclipse、Netbeans、Visual Studio などの肥大化したソフトウェアの例を示すこともできます。そうですね、これらは実際にはすべてソフトウェア IDE ですが、インターフェースが乱雑です。

秘訣は、プロジェクトを一連のバージョンとして定義することです。初期設計はバージョン 2.0 用ですが、意図されている最初のリリースはバージョン 1.0 です。新しいアイデア (機能) はすべて歓迎されますが、スケジュールの都合上、バージョン 1.0 は凍結されているため、新しいアイデアはバージョン 2.0 に反映される必要があります。

もちろん、バージョン 1.0 がリリースされるとすぐに、バグ修正とバージョン 1.01 のメンテナンスリリースに向けたコーディングを開始します。おそらく、バージョン2.0は実際にリリースされることはありませんが、とらえどころのない目標として、および作業バージョンのリリースを遅らせるのに十分ではない機能のためのとらえどころのない目標として使用されます。

尋ねるべき正しい質問は、「開発者にどのように提供できるか」です。 安定した 環境、 応答のみ 高給の機能リクエストへ。」スクラムのようなアプローチは次のとおりです。

安定した環境:

開発者に小さな作業を依頼してください 修理済み 小規模な機能のセット 修理済み 反復間隔。

メリットの高い機能リクエストのみに対応します。

1 人が優先機能のリストを管理しています。新しい機能は、 いつも 追加する必要があります（多くの政治的要素を削減します）。ただし、次の反復でのみ選択される機能は、 優先度が高い アイテム。

コミュニケーションが重要です。クライアントとの関係では、計画が一連の機能を使用して作成されるとき、それが一連の機能であることをクライアントに明確にする必要があります。それは、クライアントと対話する人たちのせいで、クライアントを誤解させたり、何らかの形でクライアントに脅迫されたりするだけです。

機能のクリープに貢献する開発者にとって重要なのは、実装に関する意思決定と新しい機能の完全な追加の間のバランスを見つけることです。繰り返しになりますが、開発者と定期的にコミュニケーションをとることで、ここでの問題を抑制できる可能性があります。

すべての機能リクエストを回避することはできない場合があります。

ただし、各機能リクエストにコストを割り当ててみてください。次の計画会議や次のリリースの機能を決定するときに、これは不要な機能を取り除くのに役立ちます。

あなたがプロジェクトのマネージャーまたはオーナーではない場合は、次のように指示します。

彼らがそれを望んでいるなら、そうしてください。給料日に必ず支払ってもらいましょう。物事を何に準拠させるかという戦いが時々あることを学びました あなた したいが、戦う価値はない。仕事の後も人生を楽しんで、物事を正しい方法で実行する独自の個人プロジェクトを計画およびコーディングしてください。

あなたの質問に対する答えは GUI だけではありません。機能/スコープのクリープは、誰かが契約の規定内容に注意を払っていない場合や、変更リクエストを処理するための正式なプロセスがない場合に常に発生します。

正式なプロセスを実装したり、その作成に影響を与えたりする能力が不足している場合は、次の手順を実行することをお勧めします。全て機能変更リクエストを電子メールで文書化すること、および起こり得る結果を電子メールで管理者に通知することを要求します。これはそうではありません得る誰でも、むしろ最終的な失敗の余波から身を守るためです。

ある時点で、何かを出荷する必要があります。何らかの正式なテストプロセスを経ていると仮定すると、製品が変更され続ける限り、テストによって動作する製品が承認されることはありません。

どの機能がいつリリースされるかを説明するタイムラインを作成するのに役立ちます。そうすることで、新機能を推進する人々は、自分たちのリクエストが処理されるだろうというある程度の考えを得ることができます。すぐに対処できるという意味ではありませんが、次のバージョンで懸念事項が解決されるという安心感は得られるはずです。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow