残念ながら、このエンドユーザーの想定外の状況に対処するにはどうすればよいですか？
私は中規模の会社で働いていますが、ITスタッフはほとんどいません。
昨年（2011年）、私は大規模なエンドユーザーのグループに非常に人気のあるアプリケーションを書きました。昨年末に締め切りに達し、最後に必要だったアプリケーションに一部の機能（これからfuncAと呼びます）が追加されませんでした。したがって、このアプリケーションは2011年の終わりからライブ/プロダクションで実行されており、問題なく追加することができます。
昨日、エンドユーザーのグループ全体が、アプリケーションには存在しなかったfuncAが機能しなくなったと不平を言い始めました。この会社の優先事項は、アプリケーションが壊れた場合、優先プロジェクトの前にまず修正する必要があることです。
コードとクエリを比較しましたが、2011年以降、proofAという違いはありません。その後、エンドユーザーの1人に証明Bが機能しなかったことを認めさせることができましたが、それ以来、そのエンドユーザーは以前に機能していたと言って戻ってきました...エンドユーザーの大群が同化したと思います彼女。また、「時間の制約のためにfuncAが達成されなかった」と明示されているプロジェクトに関する要件と毎日の更新があるこのプロジェクトのメモも確認しました。
私はそれらの多くと話をしてきましたが、プログラミングの背景から非常に遠いので、それらが混乱する可能性がある場所を見ることができますが、プロジェクトの優先順位付け命令を迂回して取得するために、グループで行動するのに十分なほど知能があることも知っています仕事を簡単にしたい機能。
最悪なのは、コードやクエリの変更がなくても、グループの考え方が定着し、上司とITの責任者が実際に信じ始めていることです。ロジックの状態を確認する限り、1 = 1の場合、それは非常にカットされ、乾燥しています。funcAは機能しません。
これで、私のシナリオの説明は終わりですが、パフォーマンスメトリックを個別に把握しないようにしています。これにより、おそらく引き継がれる、存在しない本番の問題の修正に本質的に移行することになります。 1ヶ月。
簡単に観察できる事実に関する紛争は、実際には非常に簡単に解決できます。事実を観察するだけです。「家の外に紫の木のある木があります。 「私の家に来ることができる人なら誰でも、私の声明の真実または虚偽を自分で確認できます。
FuncAが以前の製品にあり、以前のバージョンで機能していたのに現在は機能していないと不満を感じていて、それが製品に存在しないと思われる場合は、それを証明するよう依頼してください。 （または、より穏やかな言葉で、「問題の再現に問題があります。ここで私たちを助けていただけませんか？」
以前のバージョンがない場合はコピーを渡して、LiveMeetingで入手し、FuncAの使用方法を見せてもらいます。彼らがそれを行うことができない場合、（うまくいけば）彼らはそれが結局そこになかったことに気付き、それについてあなたのケースを降りるか、少なくともそれを実装させるために別の戦術を試してください。 （そして、管理職から誰かを確実に迎えるか、PMでLiveMeetingに参加してください。）
これは事実に対処できる問題ではありません-しようとすると、信頼性が失われます。
まず、ソフトウェアが「壊れている」ことを受け入れます。ユーザーが望んでいることを実行しないためです。さて、ユーザーにはソフトウェアに彼らがやりたいことをさせる権利があることを受け入れてください-それがソフトウェアです。だから私たちが持っているのは欠陥のあるソフトウェアとそれを修正することを拒否するエンジニアです.....
その結果、システムが優先度を設定するために実行する場合、これらのユーザーは通常のチャネルを経由してもソフトウェアを修正できないため、サイドチャネルを使用し、フードチェーンの真上にある真実の半分をエスカレートして、システムを操作しようとします。それまでの間、KPIの見栄えを悪くします（主な懸念事項は、KPIではなく、顧客である必要があります）-KPIは、あなたが気に入った場合は「付随的な損害」と見なされ、そうでない場合は有益な副作用と見なされます。しかし、彼らはどれだけのことが起こるかについてある程度のコントロールを持っています-あなたが一番好きです。
だから何が起こっているのかというと、システムが壊れており、誰もが自分の欲しいものを得るために物事を操作しようとしているのです。彼らは機能を求めており、あなたはあなたの染みのないKPIを維持したいのです。
システムを修正したり、オフィスポリティクスをすぐにプレイしたりできない場合は、ゲームオーバー：負けです。
注：このディスカッションには、デッドライン、バグ対機能のディスカッション、誰が支払っているのかなどは含まれません。これらは事実です-事実は関係ありません（まあ、それは一種のことですが、非常に多くの方法で操作できます...）。 ）オフィス政治で。
組織的には問題を感じています。
ITの責任者と上司を含む階層があります。組織が伝統的である（アジャイルであるように聞こえない）場合、あなたはリソースであり、リソースマネージャーです。ソフトウェア開発というフルタイムの仕事があります。エンドユーザーが機能を直接要求し、優先順位を設定し、時間を管理しようとする場合、マネージャーは冗長です。彼らはエンドユーザーに責任があるかもしれません、しかし彼らが彼らの仕事をしているなら、あなたは彼らに責任があります、そして彼らはあなたが焦点を絞った開発者モードをdefensive developerモードに切り替えます。
私の答えのコンテキストを設定するためのいくつかのポイント：
- ソフトウェア開発者はタイムトラベラーではないため、結果は彼らがそうであったかもしれないものではなく、彼らが何であるかについて判断される必要があります。
- 機能が要件仕様、スケジュールに含まれ、完了した作業よりも優先された場合は、正当な苦情がある可能性があります。それ以外の場合、あなたに責任を負わせる正当化は何ですか？
- あなたの罰は、もし良ければ、あなたの指揮系統から来る必要があります。製品開発が顧客を叱責した場合、マーケティングと販売が気に入らないのと同じように、ほとんどの組織は顧客の怒り（および賞賛）を受け取り、それをチャネルを通じて伝えるための製品マネージャーを持っています。
- プロダクトマネージャーは、プロジェクトの成功した部分の暖かさを浴びると、非常に困難な関係を築くことができますが、開発者に直面したときにのみむちを破ります。
- 1年間の作業で機能製品を提供し、私が業界で見たものから、望ましい機能を追加するのに1か月（または2か月）かかる場合、見積もりは平均を上回っていました。
- 問題を公平かつ生産的に解決するには、人々が非難の指をポケットに戻し、前進する計画を立てる必要があります。
ITの責任者が所有すべきプロセスの山羊ではなく、感謝されれば、より良いモチベーションでより質の高い仕事ができるようになります。それは公正な方法であり、生産的な方法です。私はあなたがそのように管理されることを願っています、そしていつか将来、あなたが他の人がそのように管理されることを願っています。
このような現実の失敗の場合、最善のことは前進することです。過去について議論するのではなく、それを機能させることと、それがどれほど簡単か難しいかについて話します。問題がそれを修正するのか、初めて実装するのかは問題ではありません。経営陣がBの前にAを実行したい場合は、そのようにします。
あなたはこのプロジェクトに取り組んだ唯一の開発者ですか？プロジェクト作成中に誰かに答えたようですね。このすべての中でその人はどこですか？何が提供されたかを示すプロジェクトのドキュメントはどこにありますか？
書類の証跡があるはずです。アプリケーションの使用方法を示すトレーニングドキュメント。開発されたものを概説する機能仕様。機能が含まれていない場合は、その機能に関するドキュメントも必要です。誰かがそれを受け入れると言ってサインオフしなければならなかったはずです。
それはあなたの言葉に対するあなたの言葉であってはなりません。それはすべてドキュメントにあるべきです。
このドキュメントを持っていない場合...私はあなたがこれを噛まなければならないのではないかと心配しています。それを人生の教訓と考えてください。結局のところ、ユーザーは顧客であり、ことわざにあるように、顧客は常に正しいです。この機能を追加する方法とその所要時間を作成します。会議を開いて、「私たちの記録によると、この機能は実装されていませんが、x週間で実現できます。頭を上げましょうか？」
そして、それが神聖なすべての愛のために....それが承認されたことを示すために必要なドキュメントを入手してください。