残念ながら、エンドユーザーがこの非仮説的な状況に対処する方法は？

私は中規模の会社で働いていますが、IT部門は非常に小さいです。

昨年（2011）、私はエンドユーザーの大規模なグループに非常に人気のあるアプリケーションを書きました。昨年末に締め切りを迎えましたが、最後に欲しかったアプリケーションに一部の機能（これからfuncAを呼び出します）が追加されませんでした。したがって、このアプリケーションは2011年末からライブ/プロダクションで実行されていますが、問題なく追加できます。

昨日、エンドユーザーのグループ全体が、アプリケーションに含まれていなかったfuncAが機能しなくなったと不平を言い始めました。この会社での優先事項は、アプリケーションが破損した場合、優先プロジェクトの前に最初に修正する必要があることです。

私はコードとクエリを比較しましたが、2011年以来、違いはありません。その後、エンドユーザーの1人にプルーフBが機能しなかったことを認めさせることができましたが、それ以来、そのエンドユーザーは戻って以前に機能していると言いました...エンドユーザーの大群が同化したと思います彼女。また、このプロジェクトに関する注意事項を確認しました。このプロジェクトには、「funcAは時間の制約のために達成されていません」、proofCと明記されているプロジェクトに関する要件と毎日の更新があります。

私は彼らの多くと話をしましたが、彼らはプログラミングの背景から非常に遠いのでどこで混乱するかを見ることができますが、彼らが得るためにプロジェクトの優先順位付けをバイパスするためにグループで行動するのに十分な知性があることも知っています彼らが仕事を簡単にしたい機能。

最悪の部分は、コードやクエリの変更がなくても、グループ思考が設定され、上司とIT責任者が実際にそれらを信じ始めていることです。ロジックの状態を確認する限り、1 = 1の場合、非常にカットされて乾燥しているため、funcAは機能しません。

したがって、これで私のシナリオの説明は終わりましたが、これが原因で、おそらく引き継がれる実在しない問題を修正することに本質的に移行することになるため、パフォーマンスメトリックスに何度も触れないようにしています。 1ヶ月。

容易に観察可能な事実に関する紛争は、実際に解決するのが非常に簡単です。事実を観察するだけです。 「家の外に紫色の木のある木があります」と言えば、私の家に来ることができる人なら誰でも、自分の声明の真実性または虚偽を確認できます。

FuncAが以前製品に含まれていて以前のバージョンで動作していたのに不満があり、現在は動作しておらず、製品に含まれていないと思われる場合は、それを証明するよう依頼してください。（または、より穏やかな言葉で、「問題の再現に問題があります。ここで手伝ってもらえますか？」

まだ持っていない場合は、以前のバージョンのコピーを渡し、LiveMeetingで入手して、FuncAの使用方法を見せてもらいます。彼らがそれを行えない場合、（願わくば）彼らはそれが結局そこになかったことに気づき、それについてあなたのケースをやめるか、少なくとも実装するために別の戦術を試してください。（また、LiveMeetingの管理者またはPMから誰かを必ず取得してください。）

これは事実に基づいて対処できる問題ではありません。試してみると信頼性が失われます。

まず、ソフトウェアが「壊れている」ことを受け入れます-ユーザーが望んでいることを実行しないためです。さて、ユーザーがソフトウェアに彼らがやりたいことをさせる権利があることを受け入れてください-それがソフトウェアです。私たちが持っているのは欠陥のあるソフトウェアとそれを修正することを拒否するエンジニアです.....

その結果、優先順位を設定するためにシステムを実行すると、これらのユーザーは通常のチャネルを経由してソフトウェアを修正できないため、サイドチャネルを使用し、フードチェーンの上位半分の真実をエスカレートしてシステムを操作しようとしますその間、KPIの見た目が悪くなります（主な関心事は、KPIではなく顧客です）-あなたのKPIは、あなたが好きなら「付随的損害」、そうでなければ有益な副作用と見なされます。しかし、彼らはどれくらいの出来事をある程度制御できるのです-彼らはあなたが好きです。

そのため、システムが壊れており、誰もが望むものを手に入れるために物事を操作しようとしています。彼らは機能を求めており、あなたはあなたのきれいなKPIを維持したい。

システムを修正したり、オフィスポリティクスをすばやくプレイしたりすることができない限り、ゲームオーバーです。負けです。

注：この議論には、デッドライン、バグ対機能の議論、誰が支払うかなどは含まれていません。これらは事実です-事実は関係ありません）オフィス政治で。

組織的には、問題を感じています。

ITの責任者と上司を含む階層があります。組織が従来型の場合（アジャイルのようには聞こえません）、あなたはリソースであり、リソースマネージャーです。ソフトウェア開発と呼ばれるフルタイムの仕事があります。エンドユーザーが機能を直接要求し、優先順位を設定し、時間を管理しようとしている場合、マネージャーは冗長です。彼らはエンドユーザーに責任があるかもしれませんが、彼らが仕事をしているなら、あなたは彼らに責任があり、彼らはあなたを集中的な開発者モードから防御的な開発者モードに移行することから保護する必要があります。

私の答えのコンテキストを設定するためのいくつかのポイント：

• ソフトウェア開発者はタイムトラベラーではないので、結果は彼らが何だったかではなく、彼らが何であるかについて判断される必要があります。
• 機能が要件仕様、スケジュールにあり、完了した作業よりも優先されている場合、正当な苦情がある可能性があります。それ以外の場合、あなたに説明責任を持たせる理由は何ですか？
• あなたの罰は、もし価値があるなら、あなたの指揮系統から来る必要があります。製品開発が顧客をscった場合、マーケティングと販売がそれを好まないように、ほとんどの組織には顧客からの怒り（および賞賛）を受け取り、それをチャネルで伝える製品マネージャーがいます。
• プロダクトマネージャーは、プロジェクトの成功した部分の暖かさを味わうと、非常に困難な関係を築くことができますが、開発者に直面したときだけ鞭を打つことができます。
• 私が業界で見たものから、1年分の作業で機能的な製品を提供し、目的の機能を追加するのに1か月（または2）かかる場合、あなたの推定は平均を上回っていました。
• 問題を公正かつ生産的に解決するには、非難の指をポケットに戻して、前進計画を立てることが必要です。

IT部門の責任者が所有するプロセスでヤギになるのではなく、高く評価されれば、モチベーションが高くなり、質の高い仕事ができるようになります。それは公正な方法であり、生産的な方法です。あなたがそのように管理されることを望みます。将来、いつか他の人がそのように管理されることを望みます。

このような現実の失敗の場合、最善のことは前進することです。過去について議論する代わりに、それを機能させることと、それがどれほど簡単か難しいかについて話してください。問題がそれを修正するのか、初めて実装するのかは問題ではありません。経営者がAをBよりも先に完了させることを望んでいる場合

このプロジェクトに取り組んだ唯一の開発者ですか？プロジェクトの作成中に誰かに答えたようです。このすべての中でその人はどこにいますか？プロジェクトのドキュメントには、何が配信されたかが記載されていますか？

書類の記録が必要です。アプリケーションの使用方法を示すトレーニングドキュメント。開発された機能の概要を示す機能仕様。機能が含まれていない場合は、そのドキュメントも必要です。誰かがそれを受け入れると断言しなければならなかったはずです。

それは彼らに対するあなたの言葉ではなく、ドキュメントにすべてあるべきです。

もしあなたがこのドキュメントを持っていなければ...そして私はあなたがこのドキュメントを噛まなければならないのではないかと心配しています。それを人生の教訓と考えてください。結局のところ、あなたのユーザーはあなたの顧客であり、sayingにあるように：顧客は常に正しいです。この機能の追加方法と所要時間を作成します。会議を開いて、「この機能は実装されていないことを記録に示していますが、x週間で実現できます」と書かれています。私たちは頭に行く必要がありますか？」

そして聖なるものすべてへの愛のために....承認されたことを示すために必要な文書を入手してください。