同僚がプロセスを無視しているときに、どうやって地位を確立するのですか？

私が直面している問題：

1. 私のチームメンバーは、機能/技術文書を準備せずにプロジェクトの作業を開始します-たとえ当社のプロセスが開始前にこれらが存在する必要がある場合でも。
2. 私のチームメンバーは、安価で非構造化されたソリューションを受け入れ、プロジェクト管理者が「時間に限りがある」と気付いたときに、考え直すことなく、本当に悪いハックをソフトウェアに実装します。
3. 私のチームメンバーは、テストされていない未完成の別のチームの未完成のプロジェクトと連携するプロジェクトに取り組み始めます。（多くの余分な作業を引き起こします）。
4. ソフトウェアの改善とフェーズ全体が適切に計画されておらず、多くの場合、バックエンド開発者が作業を開始しなければならないときにフロントエンド/設計が終了しないという結果になります。

私がここで働き始めて以来、これらの問題は何度も何度も議論されてきました。誰もが同意し、最終的には、プロセスを実施する必要があるということでした。つまり、バックエンドの開発者は、すべてが処理されるまで起動しません。

これらの問題は起こり続けています-そして、私は仕事自体と同僚の何人かに本当にイライラしているところまで、本当にやる気を失っています。

私のチームのメンバーは多くの不満を言います-しかし、お互いにだけ。They keep on going - whatever the situation is。結果？

1. 私は不安になります、おそらく私ですか？
2. これは物事がどのように進むべきなのか？

私の質問？How can I say no against work ignoring the process if everyone else seems to mindlessly accept?。

それは、常に何かを悩ませるようなものを探している迷惑な開発者のようには見えません。

誰もが本当に同意しましたか？

かつて、プロセスを改善したいという状況がありました。私たちは別のプロセスを提案しましたが、誰もが同意したようです。

しかし、その後、このプロセスを実行したいと思うたびに、「より重要な問題」のために例外と呼ばれ、常に一見合理的でした。したがって、効果では、プロセスは事実上従わなかったが、誰もが「原則として、プロセスに従っている」と考えた。

問題は、改善を提案した場合、反対する人（改善を好まない人）はいないということです。しかし、コストを提示する場合、通常、多くの意見の相違があります。そして、物事を行う便利な方法を失うことは、ほとんどの人にとって大きなコストです。

それを実証するために、質問の表現を変えました：「私がすることになっているすべてのことを優先してください（機能の実装、バグの除去、改善されたプロセスのフォロー、机の掃除、時間通りに到着）」

プロセスを追うことは、机の掃除の後ろで終わり、5分遅れることはありませんでした。だから、基本的に、彼らは私が提案したものとは完全に異なる何かに同意した。

問題は、品質のためにコストを払いたくないということかもしれません。それは彼らをあなたの泣き言としての批評を合理化させるかもしれないが、私の経験ではそうではない。技術的負債はそれほど目に見えない場合があり、状況に起因することは簡単ですが、最終的には現実が起こります。

うまくいけば、それまで彼らはそれを実現するか、あなたがジョブを切り替えました。

おそらくそれはあなたです

あなたは非常に構造化され組織化されたコーディング方法を好むようで、チームメイトはより「物事を成し遂げる」アプローチを持っているようです。今、あなたはそれが多くの「無駄な時間」につながることを言及しているので、おそらく何らかの構造が整然としていて、ずさんな仕事の言い訳はありません。ただし、ソフトウェアプロジェクトは流動的である傾向があり、あまりにも多くの構造を強制すると、多くの組織オーバーヘッドが発生します。

おそらく、あなたは全員が真ん中で会い、より機敏でインタラクティブな、しかし構造化されたアプローチを試すべきです。

これらの人々の責任者は誰ですか？誰かが彼らを雇い、誰かが彼らを解雇/説明責任を果たすことができます。

「私の会社が必要とする...」は、何らかの強制がなければ意味がありません。

生産プロセスを許可しない時間を要求することはできません。

この制御の欠如と非現実的な期待が品質の悪さの理由のようです。

次のいずれかを実行できます：離れる、主任開発者になる、何もしない、または自分のやり方を感じている人と協力する。誰かがより良い方法を見つけて変更するまで、正しい手順に従うことを全員が知っていることを確認してください。「The Cider House Rules」のように聞こえます。

同僚にまったく別のプロセスに従うことを望まないように聞こえますが、その中で別の決定を下すだけです。もちろん、何をすべきかについてのルール（ガイドライン？）があり、それらは無視されます。しかし、あなたが説明する問題は、彼らが決定を下さなければならないということです（プロジェクトでの作業を開始するか、仕様を拒否するか）。ルールを思い出させ続けても、その決定は変わりません。彼らはあなたと同じくらいルールを気にしない。彼らは便利に感じることを望んでおり、「いいえ」と言っても有用だとは感じません。

振る舞いを変更したい場合は、ルールについて継続的に通知することはおそらくあまり効果的ではありません。あなたを無視するようになる可能性が高くなります。プロセスを変更する方法を見つけて、プロセスを継続しながら、より便利に感じられるようにしてください。ある種のコードレビューを実装し、互いのコードをチェックし、相互に学習して、ハッキングが実稼働コードに到達するのを防ぎますか？仕様（docs / ext.interfaces / front-end）の処理方法を白黒の完了/未完了の決定から、より協調的なプロセスに変更できますか？終了するのに役立ちますか？（そして、あなたは要件が変わることを受け入れるべきです）

ほとんどはあなたではなく、彼らではなく、プロセスです。あなた（そしてあなたのPM）が、人がそれほどキャラクターに逆らう必要のないものを整理する方法を見つけることができれば、そのプロセスはずっと早く行われます。

これは、チームリーダーとの非公開セッションでチェックインするポイントについてです。うまくいけば、あなたはそれを非常に非公式にすることができるリードとの十分に良い仕事上の関係を持っています。

ミーティングの目的は、チームが彼らのやり方で物事をしている理由を把握することです。全員が集まって、うなずき、笑って、新しいプロセスに同意した場合、なぜ彼らはまだ変わらないのですか？単純な無関心や無能よりもずっと深く実行される可能性があります。職場では、肉眼では見えないドライバーがいる可能性があります。

同僚が、できればパニックを減らし、技術的な負債を減らし、製品の品質を高めるプロセスに従うと仮定して、会議を開始します。それで、目に見えない力は何ですか？

設計とUIプロトタイプの先行作業の前に、多くの実装/統合があるように思えます。会社は、その先行作業を行える人が不足していますか？たぶんあなたはボランティアすることができます。利害関係者との合意を得るのに問題はありますか？あなたのチームは、彼らと通信するための新しい方法を見つけるか、仮定を文書化するための新しいアプローチを取ることができます。

あなたはあなたのリードを尋ねる一対一で始まる場合は、なぜ、あなたは防衛を回避し、問題と解決策に焦点を当てて議論への扉を開くことができます。

別のトリックは、物事の新しい方法を開拓できるかどうかを尋ねることです。チームリードから後戻りして問題を少し強引にし、提唱しているアプローチを取ることができます。「システム」に背を向けると問題が発生する可能性が高いため、管理が必要です。しかし、より生産的でストレスのないことが判明した場合、物事のやり方を変えるための良いケースを提供し、支持者を獲得する可能性があります。