最近、私はthisとthisの 2つの投稿を読みました。 彼らはさまざまな側面から、タスクの95％に時間を費やした開発者と欠陥のある結果に対して支払いたくない雇用主との間の対立について説明しています。
少し前に、私は（従業員の側で）同様の状況に陥り、それをうまく解決することができました。そして、雇用主と私の両方が満足するような方法で。
===============
いいえ、これらの投稿の著者または解説者を馬鹿にしたくありません。 これは、対談者に屈服する頑固な不本意を指します。
しかし、私の問題の解決について話す前に、ソフトウェア開発よりも心理学に関連するいくつかの問題に注意を喚起したいと思います。
- 誰もが彼に同意すると愛し、彼に反対すると反対し始めます。
- 人に何かをしてもらいたい場合は、意識的に自分の自由意志でそれを行う必要があります。
- 紛争に勝つために、いかなる場合でも人と議論することはできません。 私たちは、論理的で論理的な陳述の議論のレベルに会話を持ち込もうとする必要があります。
これがなぜ起こるのかは説明しません。 これを公理としてとることを提案します。 興味のある方は、この本を読むことをお勧めします。
次に、これをソフトウェア開発に適用してみましょう。
問題は、時間（顧客の場合==お金、請負業者の場合==仕事）がすでに失われており、返せない場合の状況に対するタイミングの悪い反応です。 この場合、それぞれの側は、反対側に発生した費用を負担させようとします（顧客は請負業者に残りの仕事を無料で行わせようとし、請負業者は顧客に利益をもたらさなかった仕事の代金を支払わせようとします）。
さらに、ほとんどの場合、誰が時間の損失を責めるのかは明らかではありません：原因は外部の理由であるか、両方が責任であるか：雇用主と請負業者の両方が時間の損失を防ぐことができましたが、責任を責めることができることを望んで、これを行わないことを選択しました反対側に。 （参加者の一人の明らかな過失が目に見える場合には、論争は生じないことに同意する。）
上で書いたルールを適用しようとすると、直接の闘争は何にも結びつかないことが明らかになります：双方が敗者になります（一方の当事者がお金を失う（またはパフォーマーであれば仕事））+双方が時間と神経を失う紛争に費やされた）。 両者は平等な立場にあり（上記参照）、彼らは彼らの主張を証明する論理的議論をもたらすことができないので、当事者は誰も紛争を「適切な紛争」に翻訳することで勝つことができません。
唯一の解決策は、この取り返しのつかない損失を防ぐことです（雇用主にとってはこれは彼が必要としない仕事に費やす時間であり、請負業者にとっては無給の時間です）。
コンパイル済みのTORを使用すると、時間のロスを減らすことができます。 TKは、雇用主が必要とするタスクの完全なリストを提供します（請負業者の仕事が顧客に利益をもたらすことの保証+雇用主がこれらのタスクに対して支払う準備ができていることの保証）。 残念ながら、TORを事前に作成することは非常に困難です。 多くの詳細を提供する必要があります。 さらに、開発プロセス中にタスクが変化するため、TORを事前に作成することが単に不可能な場合もあります（ごまかさないでください：非常に小さなタスクのみが変化しません）。
出力：開発プロセスを常に監視し、適切な「フィードバック」を維持する必要があります（顧客から請負業者へ）。 これにより、状況に迅速かつ適切に対応することができ、時間が無駄になったときに両方の当事者がすぐに通知できるようになります。
状況に適切に対応します-あなたの間違いを認め（そして修正し）、対談者の間違いを公正かつ合理的に指摘し、他の人々の問題を考慮し、 両者にとって最善の方法で一緒に解決しようとします。
実際、私の状況の説明：
長い間、私は固定給で働いていました（リモートワーク、人件費は私が1日2時間働くという事実に基づいて計算されました）。 タスクを厳密に制御することはできませんでした。 オフィスの最も重要なタスクを遂行するために、作業計画を自由に変更できました。 サーバー管理、実装、ユーザー向けの技術サポートなど、コア以外の作業にしばしば従事します。
危機が始まったとき、ディレクターは個人的に各開発者を管理したかった（オフィスの主な活動はソフトウェア開発に関係していないため、開発者の利益は小さい）。 毎月、作業計画が作成され、ルールが登場しました。タスクの100％が完了するまで、給与は支払われません。
最初は、動作モードは古いままで、定期的に作業の一部が満たされないままであったため、ディレクターとプログラマーの間に大きな対立が生じました。 月末に、ディレクターは次のように述べました。「タスクを完了し、お金を得る」。 プログラマーは次のように述べています。「私たちは支払いを受けるまで働きません。」
時間がかかったものを判断するのは困難でした。
オプション1：計画で考慮されていない小さなタスクの場合。
選択肢2：プログラマーは仕事をうまく整理せず、時間の一部を無駄に過ごしました（たとえば、フォーラムを読む）。
これらの各理由が状況にどの程度影響したかを追跡することは事実上不可能です。
私はこの状況から次のように抜け出しました。
- 私はディレクターと現在の仕事の計画について話し合った：どのタスクが完了し、まだ完了していないのか、そしてどの程度まで（この議論は3.5時間かかったが、以前彼を育てた会話にもかかわらず、非常に落ち着いていた）。 来月はこれらのタスクを無料で完了することを約束し、その後、今月の給与は問題なく支払われました。
- タスクを完了する方法について非常に詳細な説明を作成し（各ボタンを押したときにどのようなアクションが発生するかを説明した範囲で）、承認のためにディレクターに送信しました。 これは本質的にTKと同じです。 監督自身がそれを書かないのは当然です。 また、彼が個人にTK $ 800を書くための支払いのポイントを理解していないことも当然です。 私がまとめた技術仕様は設計基準を満たしていませんでしたが、最も重要なことは、タスクのリストを反映していました。 私はそれにほとんど時間を費やしませんでした（約2時間）
- 私に割り当てられる前のすべてのタスクは、ディレクターを通過しました。 そのため、彼は私が実行したタスクを制御でき、二次的な不必要なタスク（つまり、時間の損失につながるタスク）から自分を守ることができました。
- 計画外のタスクが発生すると、彼らは次のように行動しました。
a）タスクが非コアの場合、私はそれを完了することを拒否しました（当然のことながら、私の時間は限られています+タスクは私がうまくできることではありません）。 通常、監督は問題なく他の人に任せることに同意しました。
b）参加せずにタスクを完了できない場合、以前に承認された作業計画の変更が直ちに合意されます（合計金額が同じで、翌月に転送される最も重要でないタスクが決定されます）。
c）計画から必要な数のタスクを廃棄することが不可能な場合、課外作業は2倍の金額で支払われます（課外作業が支払われるため）。 課外作業は、完了した1時間ごとに支払われ、どのくらいの時間が費やされたか（30分まで詳細に）の非常に詳細なレポートを提供するという条件がありました。
- 私は自分自身にルールを設定しました。できるだけ早く監督に通知することです。 「すべてについて」-基本的には、タスクを達成することと、タスクを完了するための推定タイムラインを変更することです（理由の表示とともに上下両方）。
現時点では、誰もが幸せです。ディレクターは、タスクの100％が時間通りに完了していることに満足しており、 標準モードで面白い仕事をしていて、問題なく収入を得られることを嬉しく思います。
まとめてみます
雇用主と請負業者の対立は、どちらかが悪い/不誠実/不誠実/ばか（必要に応じて下線）という事実のために発生しませんでしたが、両方が開発プロセスを正しく編成できなかった（または緊張したくない）ためです。
それらのそれぞれがこれを行うことができます。
まあ...あなたが何かをしたい場合-それを自分でやります。
ご清聴ありがとうございました。 誰か質問があれば、喜んで答えます。