3

どのようにそれに対処しますか?

貸衣装業者がソフトウェアを好きなだけ変更できるようにするのは正常ですか?私は仕様がなく、変更の要求が絶えない環境で働いています。

新しい貸衣装業者ごとに、新しいブランチを作成する必要があり、非常に多くの変更を加えるため、完成するまでに完全に異なる製品を手に入れることができます。そのため、プログラミングへの興味をほとんど失っています。

それで、私は、貸衣装業者が彼の意志でソフトウェアを変更することを許可されるべきではないと言うのは間違っていますか?

英語は私の第二言語ですので、間違いは許してください。

関連:
十分な情報に基づいていない顧客の選択に対処する方法

4

5 に答える 5

2

編集:私はもともとあなたが多くの顧客を持っていて、それぞれのために単一のソフトウェアをカスタマイズしているという部分を見逃しました。参照用に元の回答を残しておきますが、この特定の状況には実際には当てはまりません。

あなたの場合、顧客の懸念に対処するために別の方法が必要であることをお勧めします。私が使用したテクニックの1つは、変更はすべての顧客にとって製品をより有用にすることと一致している必要があるということです。これは、多くの変更に対して「はい」と言えることを意味します。たとえば、UIをテンプレートを介してカスタマイズ可能にします。これはすべての顧客にメリットをもたらしますが、ルックアンドフィールを標準に適合させたいという特定の顧客の要望によって推進される可能性があります。しかし、それはまた、いくつかの要求にノーと言うか、すべての人に役立つように一般化されるようにそれらを変更する必要があることを意味します。

また、顧客にUserVoiceのようなものを使用して、機能(およびバグ)の要求を行い、それらに投票してもらうこともできます。これにより、顧客は製品の方向性に直接入力できますが、要求はすべての方向にフィルターされます。繰り返しになりますが、常に最高の評価のリクエストを受け入れる必要はなく、いくつかの低い評価のリクエストを受け入れることができます。指針となる原則は、製品を幅広い顧客に役立つものにすることです。

非常に高額な顧客を限られた数だけ持つことを計画しているのでない限り、顧客ごとに個別のカスタムブランチを用意することは現実的ではないと思います。最終的には、バージョン管理システムがボトルネックになり、会社を成長させたり、現在の顧客に十分にサービスを提供したりすることができなくなります。

より持続可能な特徴選択モードに入った後でも、私の元の答えが当てはまる可能性があります。お役に立てれば。

オリジナル

何人かの顧客はただ持つ価値がないということを前もって言います。これがいつであるかを知ることができるのはあなただけです。

しかし、通常、お客様が実際に何を必要としているかを発見し、それを提供することが私たちの仕事です。これを行うには、アジャイル開発手法に従うことをお勧めします。顧客が実際に自分が何を必要としているかを前もって正確に知っていることはめったにありません。開発者がコードを書き始める前に顧客が何を必要としているかを理解することはさらにまれです。アジャイル手法はこの現実を受け入れ、変更がプロセスに与えるダメージを少なくする慣行に従います。

まず、アジャイル手法は軽量プロセスを採用し、可能な限り最新の瞬間まで意思決定を遅らせます。基本的なアーキテクチャフレームワークをレイアウトするための「十分な」事前計画がありますが、ほとんどの場合、それは従量制です。これは、TDD、ペアプログラミング、リファクタリングなどのアジャイル手法で使用される手法が優れた設計と設計改善を促進する健全な手法であるため、思ったほど自由奔放ではありません。

第二に、アジャイル手法はドキュメンテーションに軽いです。ドキュメントがないわけではありませんが、これらの方法により、ドキュメントのメンテナンスを最小限に抑えることができます。変更の最悪の側面の1つは、ドキュメントが古くなり、正しくなるように絶えず更新する必要があることです。アジャイルメソッドは、本当に有用なドキュメントを識別して維持しますが、古くなった他のドキュメントは破棄できます。それらは必要に応じてその瞬間に使用されますが、あなたはそれらに縛られていません。アジャイルメソッドは、自己文書化であるため、コードとテストを重視します。

第三に、アジャイル手法は相互信頼に基づく協調的な開発形態を促進します。これは双方向です。顧客は、あなたが自分の最善の利益を念頭に置いていることを信頼する必要がありますが、顧客がそれを見たときに必要なものを知っているか、少なくとも認識できることを信頼する必要があります。

最後に、敏捷性の特徴は早期リリースであり、頻繁にリリースされます。顧客の手に製品を早く手に入れることは、顧客が本当に必要としているものについてのフィードバックを(再び、早く)得るための最良の方法です。具体的な製品ができたら、本当に重要な変更に関する情報を入手し始めます。早期に頻繁にリリースすることを計画し、それを他のアジャイルプラクティスと組み合わせることで、変更がより簡単に適合するフレームワークも構築できます。

ただし、これらの方法に従っている場合でも、前に述べたように、一部の顧客は持つ価値がありません。変更が悪いときにあなたのアドバイスに従うのに十分なほど顧客があなたを信頼していない場合、または顧客が本当に何を望んでいるのかを知らず、認識できない場合は、顧客との関係を断ち切る時期が来るかもしれません。彼らと話をして、あなたが彼らに必要なものを手に入れたいことを彼らに知らせることをお勧めしますが、彼らはそれが何であるかを知る必要があります。時間をかけて話し合い、目標をよりよく理解し、変化の現実に対処するためのアジャイルな方法を導入してください。それでも不合理な場合は、おそらくそれはあなたにぴったりではないでしょう。

于 2009-05-25T12:39:55.570 に答える
2

貸衣装業者が自分の意志でソフトウェアを変更することを許可されるべきではないと言うのは間違っていますか?

ソフトウェアの所有者は誰ですか?あなたか彼ら?

私が家を所有している場合、必要に応じて毎週別の色で家を塗ってくれる人を雇うことができます。画家が文句を言うなら、私は新しい画家を手に入れることができます。お金が足りなくなったら、バカだからかもしれません。しかし、画家は私の家を塗り、私のお金を手に入れ、それを使って彼の家族を養うことに何の問題もありませんでした。

私が特定のソフトウェアを所有している場合、私それを使ってやりたいことを何でもすることができます。そして、あなたがそれをしなければ、私は他の誰かに尋ねます。

于 2009-05-25T12:30:58.783 に答える
1

アプリを特定することは、実装よりも重要です(さらに重要です)。少なくともベースラインドキュメント、UIモックアップなどを顧客に提供することが重要だと思います。

システムが進化して成熟するにつれて、変更要求を受け入れる必要があります。そうしないと、システムはエントロピーに悩まされ、あなたが行ったハードワークは永久に失われます。より商用の製品である場合は、すべての顧客が望む変更に制限してみてください。そうすれば、誰もが付加価値を得ています。

ベースラインドキュメントがある場合は、カスタマイズの料金を請求できます。カスタマイズを行う必要が少ないほど、料金は高くなります:P必ず、すべての変更要求を文書化して見積もります。(私はこれにfogbugzを使用していますが、他にも多くのツールがあります)顧客が変更の代金を払っている場合、少なくともシステムを変更することの苦痛のために数えられるでしょう。

于 2009-05-25T12:29:56.743 に答える
0

私が提案をする前に、私は個人的にお金を稼ぐためにビジネスがあると信じていると言わなければなりません。したがって、クライアントが欲しいものにお金を払っても構わないと思っている場合は、それらに対応する方法を考えてください(むしろそれらを拒否します)。

今、解決策:

私は彼らが多くの政府機関に販売したソフトウェアパッケージを持っていた会社にいました-それぞれが独自の微調整と機能を備えていました。

クライアントごとに特定のバージョンを維持する必要があることを考慮して、マネージングディレクターにバージョン地獄を回避する方法を尋ねました。彼は「私たちはいけません、誰もが同じバージョンを手に入れます」と言いました。すべてのクライアントに対して1つのバージョンを維持するだけですが、クライアントに固有の機能をオフにします。

  • LM
于 2009-05-27T01:53:50.740 に答える
0

あなたの会社は絶望的に地面にぶつかっています。

すぐに就職活動をするべきです。

于 2009-05-25T12:29:28.710 に答える