GUIでフィーチャークリープを管理する方法について、実用的な提案はありますか？
内部と外部の両方のソースから、追加、変更、微調整などの強いプレッシャーを受けています。誰かが「素敵じゃないか...？」という言葉で私に近づくと、私はいつもうんざりします。彼らは私の上司や顧客であることが多いので、私はただ振り返って彼らに「いいえ」と叫ぶことはできません。
代わりに、常に新しい機能を追加することが悪い考えである理由を説明するのに役立つ提案を探しています。そうすることで、最終製品に対する彼らの期待を管理します。
機能要求は、通常はプロジェクト マネージャーと最初に要件を分析した担当者を通じて、正式なプロセスで処理されます。その仕事をやろうとしている人は誰でも実際にそれを行うことができると仮定すると、そのような種類の決定を開発者ではない人に委ねる方が常に良いです。
あなたがフリーランスの場合は、要件の変更に対して明らかに料金を請求します。また、社内の開発チームの場合は、部門間請求を検討して、人々が何にお金を使いたいかを確実に考えられるようにすることができます。
最後に、要件が変更され、機能のクリープが発生することを想定してください。どのような変更が要求されるかを考慮せずにコーディングしたり、プロセスや締め切りに柔軟性がなく、調整できない場合、プロジェクトが悪夢になることがわかります。
私がやっていることは、インデックスカードに機能のアイデアを残し、カードをどこかに表示できるように投稿することです。誰かが尋ねたとき、「それはXXXもすることができますか？」新しいカードを書きます。これは、「NO！」と叫ぶよりも、より良い関係構築の動きです。:-)それは潜在的に良いアイデアを失わないという利点もあります。OTOH、私はそれをすぐに実装することを強制されていません。提案者は彼らが聞いたことを知っています、私は忘れないことを知っています、私は仕事に戻ることができます、そして私の脳がCodeLandにいるときよりも良い時期に私たち全員が集まって優先順位を決めることができます。
では、私がアジャイルの代弁者になります。そのプロセスの最後に問題を解決することはできません。プロジェクトを別の方法で管理することで回避する必要があります。
特定の方法論は別として、秘訣は、それらの決定を顧客の手に委ねることです。やるべきことのリストがあります。そのリストを変更したい場合は、リストのどの項目が新しい項目に対応するために完了しないかを尋ねます。または、それを処理するためにどれだけ多くのお金をあなたに与えるでしょうか。
また、小さな繰り返し (1 週間から 1 か月) で作業を行う必要があるため、その間に再調整する機会があります。
私たちは SCRUM を使用していますが、それは素晴らしいことです。数回の反復の後、すべてのビジネス レベルおよびプロセス レベルの項目が解決され、最終的に彼らが望むものを正確に提供できます。
このような要求は、機能設計の担当者が処理するのが理想的です。好むと好まざるとにかかわらず、(機能設計の最初の文字からコードの最後のバイトまで) 変更が行われ、追加機能の要求が常に発生します。したがって、設計がこのような動的なプロセスに対応していることを確認してください。
これはおそらく非常に不十分な解決策のように聞こえるでしょう (そして、それが良い習慣であるとは思えません) が、私は過去に同じ問題に苦しんでいました. 私は開発、機能設計、技術設計、および自分のプロジェクトの管理を担当していたので、それが非常に小さな会社で起こったという事実 (管理に「レイヤー」がない) が事態を悪化させました。
私にとってうまくいったのは、問題を尋ねている人に戻すことです（それが上司であるか顧客であるかに関係なく）。機能設計、プロトタイプの印刷物、または現在の状況を説明するものを引き渡し、この強力な新機能を「どのように」「どこに」実装するかを理解するよう依頼してください。
その後、上司と顧客の両方が、それを自分の部下に持ち帰り、会議などで話し合うことを「強制」されました。通常、これは、2 度と連絡がないことを意味します。それが実現した場合、それは実際に機能した概念でした。
私見の最善の方法は、新機能を実装するためのコストを正確に明確に概説することです。ユーザーがそのような追加のコストを認識し始めると、「あったらいいのに」は本当に減少し始めます。
機能について顧客と意見が一致しないと、通常は何の解決にもなりません。露骨にNOと言えば、彼らは疎外感を感じ、あなたやあなたのチームと疎遠になるでしょう。この機能は、世界中に時間とお金があり、技術的な制限がないことを考えると、全体的にはおそらく良い考えです. 彼らの世界では、スニップをクリックした後にバーの横にフィズが表示されるのは良い考えです。もちろん、私たちの世界では、それは完全なテーブル スキャン、潜在的なセキュリティの脆弱性、および次のポイント リリースまでにそれが含まれていることを確認するための徹夜を意味します。
あなたが彼らのためにそれをレイアウトし、なぜそれが本当に良いアイデアではないのかを説明すれば、彼らは通常理解するでしょう. さまざまな要因 (時間/お金/プロジェクトを複雑にするためのコスト/締め切りが遅れるリスク) をすべて忘れないでください。理路整然とした人は、絵をはっきりと描けば理解してくれますし、理不尽な人に対しては、少なくとも「そう言った」と言えるでしょう。
あなたの会社は、プロジェクトを開始する前に要件を明確に定義していないようで、これは涙で終わるだけです。
私のポリシーは、事前にすべての要件の明確な内訳を取得し、すべての関係者にこれらの要件への侵入の影響を知らせることです。
持続可能で生産的なシステムに固執したくない場合は、#5 を選択するか、#5 で脅したくなるかもしれません。
マネージャー向け:
すべての人のために：
機能のクリープだけを処理することはできません。開発プロセス全体を適切な方法で整理する必要があります。
ただし、あなたの説明から、他の人が求めているものをコーディングするだけで、プロセスを再編成できなかったようです。このシナリオでは、他の人からのリクエストを受け取り、それらに優先順位を付け、それらを見積もり、実装スケジュールに同意し、実際にそれらの作業に費やした時間を追跡できる追跡/発券システムを持つことによって、リクエストを効果的に管理する最良の方法.
「この小さなボタン」に 5 秒ではなく 2 ～ 3 日かかることを実際の数字で証明できれば、顧客はおそらくそうあるべきだと信じているでしょう。
新機能のためにプロジェクトの稼働日が 2 週間遅れることを明確に示すことができれば、それらの要求は単純に消えてしまうかもしれません。
ただし、「機能クリープ」は必ずしも否定的なものではないことを覚えておく必要があります。アプリケーションが成熟し、成長するにつれて、顧客の優先事項も変化しています。それを認めないと、完成品が彼らの望むものにならない可能性があります。まだ実装されていない元の仕様の古い機能と新しい機能の交換を受け入れるかどうかを確認してみてください。
私は作業タスクの優先順位を付けたリストと、ビルド X に含まれる内容と、テストの作成、コードの実装、およびその他の関連する作業にかかる時間 (大まかに言えば) についての見積もりを保持しています。私は常に彼らの意見を取り入れ、彼らが本当に望んでいること/必要としていることについて議論し、それが物事の壮大な計画のどこに当てはまるかを判断するよう主張します. スケジュールやその他のタスクへの影響について説明します。
コミュニケーション ラインをオープンかつ明確に保ちます。驚きはなく、期待は管理されます。結局のところ、それは私のプログラムではありません。それは顧客 (顧客が誰であろうと) のものであり、私は彼らが望む (そして必要とする) ものを構築したいと考えています。
インターネットや Web 2.0 のようなものから学べる教訓があるとすれば、それは人々がカスタマイズを好むということです。それが、iGoogle や他の何百ものサイトのすべてです。GUI にカスタマイズを組み込むことができれば、顧客はそれを気に入ってくれる可能性があります。
また、他のプロジェクトがどのように機能クリープをうまく管理しているかを見てみましょう。たとえば、Google ではユーザーが機能リクエストを送信できるようにしていますが、既にリクエストされている機能のリストも表示します。ユーザーは、その機能を要求するために投票することもできます。私はうんざりしているわけではありませんが、stackoverflow.uservoice.comを見てください。彼らは同様のポリシーを持っています。
ユーザーの声に耳を傾け、フィードバックを得ることが重要です。彼らがあなたのアイデアよりも優れた新しいアイデアを思いつくことを期待してください。あなたがばかげていると思うアイデアを彼らが思いつくことを期待してください。十分な数の人がそれを望んでおり、それが合理的であると思われる場合は、彼らが望むものを提供してください。
あなたは、「確かに実行可能です。プロジェクトの完了日がどれだけ遅れるかの見積もりを希望しますか? また、その見積もりを提供すると、プロジェクトの終了までに約 1 日かかることになります」と説明します。
利害関係者がそうすることに関連するコストがあることを理解している限り、機能を追加することに何の問題もありません。
1) リリースまでの時間が長くなりました。
2) コストの増加。
3) 指数関数的な維持費
4)バグの可能性が高まる
機能リクエストを管理するには、変更指示を送信するよう依頼してください。定期的に変更指示を確認し、各要求について、「これを行うには X 時間がかかります。これは Y の追加費用がかかることを意味します。これは許容できますか?」という声明を送り返します。リクエスタが追加料金を受け入れたら、それで問題ありません。あなたの手は洗われます。:)
鍵は質問にあるようです。
「機能クリープの管理」...これは、従う必要のある管理プロセスを実装することによって行います。それを避けることはできません (結局のところ、多くの場合、顧客がそれを要求し、常に彼らにノーと叫ぶと、貧しい生き物を追い払う傾向があります)...しかし、それはそれが無秩序でなければならないという意味ではありません. 正当な理由や変更の予備調査/ユースケースなどの簡単なことを要求する人を必要とする手順が整っていると、「いいと思いませんか」の数を減らし始めます。これが整ったら、機能のクリープが管理され、優先順位を付けて、より一貫したフィードバックを提供できるようになります。
ユーザーには、対処されていない多くのニーズがあります。彼らは苦しんでいます。彼らは注意を必要とし、あなたを必要としています。機能クリープは、適切な機能をまだ実装していない場合に発生するものだと思います。
一方、「機能クリープ」は、多くの場合、進化するビジネスに対するソフトウェア製品の反応です。顧客のビジネスが成長している場合、彼らはあなたの仕事により多くのお金を費やすので、あなたは幸運です。だからリラックスして、彼らはあなたに支払います！彼らは、システムが大きくなればなるほど変更が難しくなり、すべてをスムーズに機能させるために、新しい小さな機能が大幅な書き直しやまったく新しいユーザー インターフェイスを必要とする場合があることを理解する必要があります。
たった 1 つの機能しか持たない製品を作成し、100 人の顧客全員がその製品を気に入り、使いやすいと感じたとします。ここで、10 人の顧客のみが使用する 10 個の機能を製品に追加するとします。今、あなたの顧客の 90% があなたの製品を使用するのにはるかに多くの問題を抱えていることがわかります。それは、10 倍の選択肢があり、10 倍の可能性があるのに役に立たないことがあるからです。良いものは騒音の中で失われました。
もちろんこれは単純化したものですが、現実には、ほとんどのユーザーは製品の機能のごく一部しか使用しません。
ソフトウェア設計と UI 設計に関する優れた本を何冊か読み、上司にも読んでもらいます。Joel Spolsky の本は、始めるのに適した場所です - www.joelonsoftware.com
機能のクリープを避けることへの抵抗と、機能のリクエストやフィードバックを無視する傾向とのバランスを取るように注意する必要があります。
ユーザーがフィードバックを持ってあなたのところに来るたびに、それはあなたの製品とあなたが取り組んでいることを改善する機会です. ユーザーと開発者の両方にとって興味深いものを追加することになるかもしれません。実際に作業するのは楽しいかもしれません。そして、はい、あなたに提起されたように、それはばかげた考えかもしれません. しかし、フィードバックを受け入れ、そこからポジティブなものを抽出し、それをユーザー、製品、会社、開発チームにとって価値のあるものに形作るのはあなたの仕事です。
そうは言っても、機能クリープは管理が非常に難しいものです。そして、それをどれだけうまく管理するかは、あなたの立場と「クリープ」が誰であるかによって異なります. あなたが中級から中級レベルの開発者で、CEO が機能を要求している場合。さて、あなたはその機能を追加するつもりです。それは価値のある機能ではない、機能しない、もっと重要な作業がある、またはスケジュールに悪影響を与えることを CEO に納得させることができます。ただし、機能が要求されているときは、決してそれを行わないでください。最終的には、共通の目標に向かって協力するのではなく、自分の立場を守る 2 人の人間になるだけです。
代わりに、フィードバックと機能のリクエスト (または機能の要求) を額面通りにすぐに受け入れてください。離れて、しばらく一人で率直に考えてください。「これは価値があるだろうか？」「CEOがこれを求めた方法で何かが欠けていますか?」「私がそう思っているのと同じくらい難しいですか？」この種の質問を自問して、具体的な答えを見つけてください。その後、常にCEO に戻ってフォローアップの質問をします。要求された機能について考えたこと、実際にいくつかのアイデア、微調整、機能強化、反論などを思いついたことを示してください。これにより、オープンな議論が生まれます。CEO が予期していなかったものですが、最初は彼のアイデアに対する完全な抵抗ではなかったので、彼はおそらく異議を唱えなかったでしょう。
私たちの財政支援者の 1 人は、常に機能を要求しています。ときどき彼は、ソフトウェアに 'x' を実行させてもらえないかと言うことがあります。可能であれば、私たちは彼に「はい」と答えてから、彼が考えていたタイムスケールを尋ねます. 彼ができるだけ早く戻ってきたら、他の機能を提供するか、締め切りを延長する必要があることを彼に伝えます. ありがたいことに、彼は通常、自分の意見を将来のある時点に変更します。
機能がすぐに実装されなくても、アイデアやリクエストを実際に記録することが最も重要だと思います。
Bugzilla を使用してバグを追跡していますが、機能リクエストも追跡しています。私たちは「機能」作業リスト (またはターゲット バージョン) を持っています...これにより、将来開発したい機能を誰もが見ることができ、機能に関するより多くのアイデアがあれば、簡単に bugzilla の項目に追加することができます。
リリースごとに、あるバージョンの作業リストを作成するときは、機能リストに足を踏み入れて、取り込めるものがないかどうかを確認します。可能な場合は機能を取り込んで、人々にフィードバックを提供するようにしています -これは、機能やアイデアが耳が聞こえないわけではないことを示しています。
このフィードバックは、私たちが彼らの機能のリクエストを認識していることを人々に知らせるのに役立ちます.
すべての機能要求を回避できない場合があります。
ただし、機能リクエストごとにコストを割り当ててみてください。次の計画会議または次のリリースの機能を決定するときに、これは不要なものを取り除くのに役立ちます。
あなたの質問への答えは、GUI だけではありません。機能/範囲のクリープは、誰かが契約で規定されていることに注意を払っていない場合や、変更要求を処理するための正式なプロセスがない場合に常に発生します。
正式なプロセスを実装したり、その作成に影響を与えたりする能力がない場合は、すべての機能変更要求を電子メールで文書化し、経営陣に電子メールで起こりうる結果を通知することをお勧めします. これは誰かを捕まえるためではなく、最終的な失敗の影響から身を守るためです。
解決が必要な問題を定義する作業命令を作成します。問題を解決するために必要なものだけを実装する必要があるため、作業は制限されます。
問題をさらに改良することは、変更管理になります。
私のオフィスではワイヤーフレームに従っています。サインオフ後のすべての変更は、変更管理手順を経る必要があります。
短期間のロックイン機能セット (スクラム/イテレーション/アジャイル)。ユーザーが物事が動いているのを見始めると、機能の必要性または欠如がより明らかになります。
また、すべての変更が行われる担当者がいることも役立ちます (スクラムでは、非常に優れたプロダクト オーナー)。
シンプルな GUI がいかに効果的かを示します。例: Google Chrome、Apple のソフトウェア。Eclipse、Netbeans、Visual Studio などの肥大化したソフトウェアの例を示すこともできます。これらは実際にはすべてソフトウェア IDE ですが、インターフェイスが雑然としています。
コミュニケーションが鍵です。クライアントとの関係では、一連の機能を使用して計画が作成される場合、それが一連の機能であることを明確にする必要があります。クライアントを誤解させたり、何らかの形でクライアントに脅かされたりするのは、クライアントと対話する人々のせいです.
機能のクリープに貢献している開発者にとって重要なのは、実装に関する決定を下すことと、新しい機能を完全に追加することの間のバランスを見つけることです。繰り返しになりますが、開発者と定期的に連絡を取り合うことで、ここでの問題が抑制される可能性があります。
あなたがプロジェクトのマネージャーまたは所有者でない場合、私は次のことを規定します。
彼らがそれを望むなら、それをしてください。彼らは給料日にあなたに支払うことを確認してください。物事を自分の望むものに適合させるための戦いは、戦う価値がない場合があることを学びました。仕事の後、人生を楽しみ、正しい方法で物事を行う独自の個人プロジェクトを計画およびコーディングしてください。
秘訣は、プロジェクトを一連のバージョンとして定義することです。最初の設計はバージョン 2.0 用ですが、意図した最初のリリースはバージョン 1.0 です。すべての新しいアイデア (機能) は歓迎されますが、スケジュールのためにバージョン 1.0 が凍結されているため、新しいアイデアはバージョン 2.0 に移行する必要があります。
もちろん、バージョン 1.0 がリリースされるとすぐに、バージョン 1.01 のメンテナンス リリースに向けてバグ修正とコーディングを開始します。おそらく、バージョン 2.0 は実際にリリースされることはありませんが、とらえどころのない目標として使用され、機能の駐車場所として使用されます。良いですが、動作するバージョンのリリースを遅らせるほどではありません.
正しい質問は、「どうすれば開発者に安定した環境を提供しながら、利益の高い機能のリクエストにのみ対応できるか」ということです。SCRUM のようなアプローチは次のようになります。
短い一定の反復間隔で、開発者に少数の固定された一連の機能に取り組んでもらいます。
1 人の担当者が優先機能のリストを管理しています。新しい機能はいつでも追加できます (多くの政治を削減します)。ただし、次の反復で選択された機能のみが優先度の高い項目です。
ある時点で、何かを出荷する必要があります。ある種の正式なテスト プロセスを経ていると仮定すると、製品が変更され続ける限り、テストによって動作する製品が承認されることは決してありません。
どの機能がいつリリースされるかを説明するタイムラインを考え出すのに役立ちます。そうすれば、新機能を求める人々は、自分たちの要求が処理されるという考えを持っています。すぐに対処されるという意味ではありませんが、次のバージョンで問題が解決されるという安心感を与える必要があります。