開発者は、不要な機能や有害な機能に反対するべきでしょうか？

新しい機能、つまり非重要/疑わしい機能について議論するとき、開発者からの良い態度は何ですか？

ある種のJavaのような言語を開発しているとします。上司は、「開発者がオブジェクトメモリを直接操作するにはポインターが必要です」と言っています。

開発者は想像を絶する複雑さとセキュリティの脆弱性を追加するため、アイデアを打ち倒すべきですか、それとも彼は求められていることをすべきですか？

これは良い例ではないかもしれませんが、ワークフローを中断するボタンを追加したり、プログラムの内部構造に反するなど、灰色の領域にあるものについてはどうでしょうか？

通常のプログラマーにとって最適な「できる」対「できない」配布は何ですか？

編集：質問は悪いボスに関するものではありません：D

わずかに役立つかもしれないが、目立った量の問題を追加する新しい問題に人々がどのように取り組むのか、私はもっと興味があった。

一般的な態度は次のとおりです。

1. はい、それを行います、複雑さを台無しにします
2. 多分
3. いいえ、一般的な手直しと含意は変更を正当化しません

優れた開発者の反応はどうでしょうか？

最善の方法は、会議を開催し、グループとして賛否両論をレイアウトし、それに基づいて最良のソリューションを議論することです。チームがある場合は、ソリューションについて同意してもらいます。チームが何かに同意すると、マネージャーと「ボス」はソリューションを採用する傾向があります。

それでも上司が同意しない場合は、できることはすべてやりました。チームとマネージャーをまとめて長所と短所をカバーし、上司が潜在的に劣ったソリューションを選択したにもかかわらず。

その鍵は、賛否両論をグループとして議論することです。そうすることで、あなたはあなたのチームと最善の解決策が何であるかを議論すると同時に、ボスの決定を考える理由を人々に伝えるという政治的反発なしに、ボスの決定を（彼が決定する前に）指摘しています間違っていた。

これは仕事の政治に関係する柔らかい状況ですが、友好的に扱うことができます。

上司から愚かな仕事をするように言われたら、それが（親切に）愚かである理由を説明する必要があります。

彼または彼女がポイントを取得しない場合、あなたは愚かなことをする義務があります。それでおしまい。彼は上司です。そのような場合、あなたは彼/彼女が言うことをするか、彼/彼女の上司と話すか、仕事を変えることができます。

あなたはそれが技術的には可能だが、それは費用がかかりますことを上司に伝えることができ、Xの既存のコード、テスト、回帰テストを、書き換えること、設計、分析に努力に費やした時間とお金の量を...そして機能はそれだけの価値があるかどうか尋ねます。答えは「はい！これが必要です！」となることもあれば、「いいえ、そうではない」となることもあります。

求められている機能がアプリケーションのコア原則に違反している場合（たとえば、顧客の要求に応じて赤いボタンのみを持つように設計され、設計されたUIに「青いボタンを追加！」） 「なぜ？」そして、それは事前に確立された設計に反することを述べます。

最終的には、ほとんどすべてが「できる」ことです（技術的な観点から、青いボタンのみのUIに赤いボタンを追加することは難しくないかもしれません）。

編集した質問に答えるには、さらなる調査と分析を待つ間、答えは＃2「多分」であると思います。

与えられた期間内に配信できないものにコミットすることができないため、＃1「はい、無条件に」と答えたくありません。

あなたは非協力的で不必要に難しいように見えるので、あなたは＃3「いいえ、それは仕事が多すぎます」と答えたくありません。

開発者の観点から：請求書を支払う人に、欲しいものが手に入らないことを決して伝えないでください。代わりに、その価格では手に入らない、または元々考えていたとおりに手に入れることができないと伝えることができます。

「ポインター」の例; マネージコード環境である.NETにはポインターがあります。これらは、アンマネージコードとの多くの相互運用性にとって非常に必要です。ただし、それらの「安全な」使用は厳しく規制されており、「安全でない」コードで使用する場合、そのコードはランタイムでより高いセキュリティ許可を必要とします。ポインタを介したダイレクトメモリアクセスも必要とするマネージ言語を開発している場合、可能な場合は舞台裏でマーシャリングし、自動的にマーシャリングできない読み取り専用マネージポインタを使用して、コードベースの最も信頼できる領域でのみ「真」のポインタ。

GUIの例：新しい機能が現在のコードフローを「破壊」することがわかっている場合は、それをテストしてより堅牢に開発し、ワークフローによって行われた以前の作業をロールバックできます。あなたのクライアント、そして時にはあなたの上司でさえ、通常、プログラムの構造について何の手がかりも興味も持っていません。あなたがプログラムを構造化した方法のために彼らが望むものが難しい場合、それはクライアントが望むものをすることができないので定義により構造は間違っています。

いずれの場合でも、この新機能により、クライアントが思っていた以上に必要な作業範囲が広がる可能性があります。そのためには、スケジュールの延長、お金の追加、および/または他の計画作業の削減が必要になります。

ただし、同じ基本的な結果をより簡単または論理的な方法で達成する方法を知っている場合は、クライアントに提案できます。確かに存在しますが、幸いなことに、開発者からの入力を明確に拒否するクライアントはまだ見ていません。これら。

大規模なアプリケーションのプログラミングに何年も費やし、その過程で批判的に考えると、機能がその有用性を上回る問題を引き起こす時期を細かく調整した感覚を養います。これに対する別の言葉は知恵であり、他の種類の知恵の場合と同様に、それがなければ知恵を持たない人々にその価値を見せるのは困難です。

他のポスターは、問題のある機能によって導入される問題のコストを定量化しようとすべきだと主張しており、それは可能であれば良い考えですが、通常はそうではありません。通常、即時の実装コストを見積もることのみが可能です。それであっても、大きな機能では難しい場合がよくあります。将来のコストについては、あなたは厳しい状況にあります。他にどのような機能が必要になるのか、または製品がどのくらいの期間メンテナンスされるのかは確実にわかりません。コストは通常​​、確固たる事実に基づいた見積もりでバックアップできるよりもはるかに高くなります。

過去に実証した能力が高ければ高いほど、機能を悪いアイデアと単純に宣言する必要があります。それには時間と成功の実証された記録が必要です。とはいえ、クライアントが望んでいるのは要求であるため、常に要求を満たすことへの意欲を表現する必要があります。経験に基づいて予約を表明する必要があります。問題が発生すると、問題の根本に到達する会話を開始するため、90％のケースで問題になりません。そもそもこの機能は？その時点で、代替手段を提供したり、要求された機能が問題を引き起こしたとしても、それがまだ必要であることに同意することができます。

もちろん、あなたがただ間違っている可能性もあります。ソフトウェアエンジニアリングは面白くないですか？

質問はかなり曖昧なので、回答で少し一般化するつもりです。

常に質問しますが、彼らの推論に耳を傾けます。機能の実用性やプログラミングにかかる​​時間を忘れてしまうことがあります。反対に、私たちは時々プログラマーのメンタリティに縛られて、効率的で、飾り気がないなど、プロジェクトにとって重要ではないと考えるものが実際にはクライアントのためではないことを忘れています。

正当な理由がある場合は、プログラムにかかる時間と、実装中に発生する可能性のあるすべてのバンプを知らせて、引き続き続行するかどうかを確認します。そうでなければ、なぜそれが良い考えだと思わないのかを述べて、彼らの反応が何であるかを見てください。すすぎ、繰り返します。

ほとんどはすでに述べていますが、現在の職場環境で強調したいことが1つあります。私は他の会社の請負業者である会社で働いており、アウトアプリケーションはビジネスプロセスに関連しています（かなりの量が販売と顧客コミュニケーションを促進します）。

ビジネスプロセスと付随する製品は（少なくとも会社が十分に大きい場合）非常に複雑になる可能性があります。ある程度、複雑なものをモデリングしている場合、結果のアプリケーションには関連する複雑さがあります。ビジネスの人々の大部分の個人はプロセスの自分の部分しか見ることができないので、完全なアプリケーション/プロセスは、たった1人のユーザーに見えるものよりも非常に複雑に構築されます。

私のポイントは、新しいビジネス要件が生じた場合、ビジネスマンにとってはうまくいくということです。なぜなら、それは複雑さをそれほど高めないが、システム全体に大きな影響を与える可能性があるからです。私の意見では、これはその変化に反対する理由ではありません。努力（および費用）について顧客と話し合うのが適切なポイントです。おそらく、その機能を構築することを顧客に止めることはありませんが、やがて、アプリケーションと「うーん、あなたはそんなに高価です！」についてのいくつかの議論を感じるでしょう。うるさくなりません。

あなたが同等の状況にあるかどうかはわかりませんが、ITシステムの開発者やアーキテクトが直面している状況のように、利害関係者の状況が必ずしも同じ複雑さをもたらすわけではないことを学びました。そのような状況では、コミュニケーションは双方に役立ちます。

すみませんが、この質問は父親のアドバイスを求める小さな質問のように聞こえます。この場合、優れた開発者はこれらの戒めを受け入れる必要があります。

• 自分に忠実であり続ける。腸が機能に不安を感じる場合は、懸念事項を音声で伝えてください。チームがただのオープニングを待っているのは良いことです。
• 経験を経験者の経験則に置き換えようとしないでください。あなたにとって、すべての状況は異なり、すべての機能は新しいものです。これはあなたの先輩が持っていないプラスです。
• ソフトウェア開発は厳密な科学ではありません。したがって、行動ではなく知恵を蓄積してください。
• 敗北を受け入れます。チームが別の方法で同意する場合、あなたの懸念を吐き気を繰り返さないでください。
• ポジティブだと思う。アイデアが本当に「それを撃退する」ために物ggingいしている場合は、その欠陥をリストする前に、それに対する肯定的な側面を見つけて名前を付けてみてください。
• 人と交流する方法を学びます。私たちの開発者は、しばしば社会的能力よりも技術的知識を優先します。技術的能力は人生の早い段階でピークに達しますが、社会的能力は引退するまで成長し続けることができます。

悪い要件を押し戻すことを信じています。しかし、私はあなたが彼らがなぜ悪いのかを説明するためにあなたのベストショットを与えて、彼らがまだ彼らを望んでいるとき、あなたは同意してあなたの仕事をすると信じています。

たとえば、私は、アプリケーションが既に行っていることと相互に排他的な要件を必要とする人々がいました。私がそうすれば、これは100％保証され、壊れます。それで、私は要件を送り返し、これにより、すでに存在するこの他のビジネスルールが破られることを伝え、彼らもこのルールを変更したいのですか？多くの場合、特定の要件を考え出す小さなグループは、アプリケーションの他の部分が何をするかについての全体像にアクセスできません。私がこれらのいずれかを返送したほとんどの場合、顧客は初期ルールがより重要であることを認識し、必要な変更は価値がないと判断しました。彼らが変更を行うことに決めたとき、彼らは最初の要件をプッシュした人々と相談した後にそれをしました。

明確化の質問をするだけで、問題が思ったほど単純ではないことがわかります。なぜ彼らが何かを望んでいるのかを尋ねて、変化を推進している本当のニーズにたどり着きたい場合があります。それを理解すると、開発者としてあなたのために機能し、彼らのニーズを満たす代替ソリューションを見るのがしばしばより簡単です。元の提案よりも、どのようにニーズに合っているかという点でそのソリューションを提示できれば、変更を受け入れる可能性が大幅に向上します。

変更によって設計の基本レベルで大混乱が発生する場合、変更にかかる時間の新しい見積もりを与えるだけで、それを無効にすることができます。それに、新しいバグを導入する可能性のある重要な機能を指摘するリスク評価と、3人による6週間の熱心な努力が必要だと伝えると、突然、それほど重要ではなくなります。

しかし、これは良い考えではなく、なぜだと彼らに言います。あなたはいくつかを勝ち取り、いくつかを失い、時にはビジネスのニーズが真に変化し、アプリケーションはそれに対応しなければなりません。決定が確定したら、今何をしているのかを疑問視する時間ではなく、それを実行する時間でもありません。異議を文書化した場合、予算を超えて新しいエキサイティングなバグを引き起こす場合、個人的にはまだ良い場所にいるはずです。そして、あなたがこれらの種類のことで正しいことの実績を築いたとき、彼らはあなたに耳を傾けるのをもっと喜んでもよいかもしれません。

これらの議論の多くに勝つための鍵は（誰もそれらのすべてに勝つことはありません）、あなたが話していることを知るための実績を最初に構築することです。次に、懸念事項を記載した文書を送信します（多くのマネージャーはリスクを負い、後で間違いを証明する文書を誰かに見せたくない可能性が高いため、文書に書いた内容に注意を払います）変更を行うためのすべてのコスト（時間だけでなく、セキュリティリスク、新しいバグの導入、期限の欠落など）を確実に理解するため。変化は自由ではなく、彼らはそれを理解する必要があります。次の鍵は、これを大人のように行い、泣き言を言う子供のようにしないことです（「しかし、私は使いたくありません...私はそれが好きではないので」）。それを行わないことでビジネスケースを作成すれば、悪い要件を押し戻す際により多くのことが得られます。

私があなたを正しく読めば、本当の問題は未知の複雑さについてです。最初は、あなたの質問を「過度の複雑さの可能性が非常に高いが、上司はそうではない」と読みましたが、上司は問題ではないと言っているので、どのようなリスクがあるかわかりません容認できない複雑さを追加することは。

その場合、何らかのリスク軽減戦略をお勧めします。APIにWCF / Webサービスを追加することを検討している画像。これは素晴らしいものであるか、見返りのない複雑なものになります。

• ブランチに機能を追加します。動作する場合は、マージします。ネズミの巣になったら殺してください。
• 新しい1ページのプロジェクトを立ち上げ、概念実証を行います。短時間で概念実証を行えない場合は、削除してください。概念実証が機能する場合、それを大きくして、あなたの
• その機能や技術に興味のある人を探してウェブを探しましょう。多くの不幸が起こっているところでは、技術は過度の複雑さの本当のリスクかもしれません。Java BeansとCOM +は、おそらく古いものですが、複雑さを本当に台無しにし、方程式の利点の側面で提供される場合とされない場合がある機能の良い例です

議論しない おそらくはいについて話し合います。しかし、それは仕様への追加として扱われ、他の機能で優先されるべきです。リクエストが実装に不合理な時間と複雑さを追加することがわかっている場合は、事前にその旨を述べてください。要求を行うことに反対するのではなく、実装に必要だと思うことの説明として。

リクエストに大きく依存します。ポインターの実装はプロジェクト全体に影響を与えるのに十分な大きさなので、選択肢が与えられた場合、そのメリットを比較検討する必要があります。

フローを中断するボタンを実装します。ボタンがオプションになるようにフォームをレイアウトできるのであれば、それほど大したことではないでしょう。私は実際にこれをやったことがあります。ボタンを追加しましたが、ボタンがオプションになるように十分な情報を事前に収集しました。そこにあると予想したユーザーはそれを使用し、それが単に冗長であることを認識したユーザーは使用しませんでした。

バランスと、いつ戦闘を選択するかを知ることが重要です。いくつかのことは、それを含めないという社会的側面を扱うよりも、とにかく実装する方が簡単です。

私が見る問題は、あなたが「議論する」という言葉を使用していることです。

設計上の問題とその背後にある理由を提起する必要がありますが、プログラマーは自分が取った立場について防御する傾向があり、議論のためだけに論点を主張する傾向があるので注意してください（時々）。私はかなり議論するのをやめなければなりません。そして、私はいつも成功するとは限りません。また、年をとるにつれて、私は以前よりも頻繁に間違っていることに気づきました-または、さらに悪いことに、私がどれほど頻繁に間違っていたかを認識していませんでした:)

要件を明確に述べている場合（言語は安全である必要があり、レガシールーチンにアクセスするためのポインターが必要です）、2つの要件がどのように競合するかを提示し、どちらがより重要かを尋ねることができます。要件とその背後にある理由を把握したら、両方の要件をサポートするまったく異なるソリューション（JNI--kinda）を思い付くことができるかもしれません。

そうでない場合は、おそらくそれらを体系化する良い機会です！

1. あなたはすべてを知らず、すべてをすることはできないことを理解してください。

2. それが悪い考えだと確信しているなら、悪いことを言ってください。

3. 彼らがあなたにそれをプッシュしようとするなら、どちらかと言ってください-あなたがより多くの時間を必要とするか、この問題に対する良い解決策を見つけられなかったと言うならば、分析にもっと時間が必要です。

4. 彼らがまだ悪い考えを実行することを主張するなら、あなたはあなたの理由を含めてそれに対してあなたが助言したという彼らから承認を得てください。ディスカッションをまとめたメールを上司にコピーして送信することもできます。これにより、後でa **を保存できます。

理想的なシナリオでは、技術面で最終決定を行うリード開発者と、ビジネス面で最終決定を行うビジネスリードが必要です。これは、2つの主な質問に答えます。

1）何？顧客は何を望んでいますか？

2）どうやって？テクノロジーの観点からこれをどのように達成しますか。

彼らが請求書を支払うのは顧客であるため、顧客が望むのは究極の意思決定者です

開発者として、どの要件が実装されるように要求されているかを実際に気にするべきではありません。

ただし、何かが非現実的であり、より良い方法があるかどうかを説明する必要があります。

時々、実際に顧客の要求（顧客の内部政治から来る）。それは絶望的であり、行われなければなりません（しかし、経営者はそのようなプロジェクトを継続するか、価格を再交渉すべきかを考慮する必要があります）。

これは私にとってほぼ毎日の仕事であり、実際、うれしいです。

特定の要件をアプリケーションの一部とすべきかどうかについて意見を述べるための変更がある場合、非技術者は技術知識を入力することを期待します（たとえば、「ポインタを使用するとアプリケーションが不安定になる」または「使用するXの目的のためのGETパラメーターはセキュリティリスクです」）。テクニカルフェローは、彼らが考えていないかもしれない特定の利点または不利な点についてのあなたのフィードバックも歓迎します。

もちろん、誰もが機能Xを望んでいて、「それは良くないかもしれない」と言ってしまうのは厳しいですが、最終的には誰もが安全で堅牢で安定したアプリケーション（維持可能、柔軟など）を作ろうとします... ）そしてすべての声が重要です。

あなたの質問に答えるのは、開発者の仕事の一部ではありません（開発することです）が、品質とチームワークを提供する「余分な」ものです。

それを行うことの短所（複雑さ、使いやすさなど）を理解できる立場にいるなら、あなたの能力を最大限に説明することは誰にとっても最大の関心事です。多くの場合、開発者以外は新しい機能を追加する問題を理解していません。彼らは何もする必要がなく、それについて考える必要さえないので、彼らにとって簡単です。

ただし、新しい機能を追加することを決定する権限がある場合は、可能な限り最善の仕事をする必要があります。それは挑戦です。

そして、新機能が馬鹿すぎるか、作業環境があまりにもくだらない場合は、別の仕事を見つける時が来ました。