同僚がプロセスを怠っているときにどのように地面に立つのですか？
私が直面している問題：
- 私のチームメンバーは、機能/技術文書の準備ができていない状態でプロジェクトに取り組み始めます-たとえ私たちの会社のプロセスが開始する前にこれらがそこにあるべきであると指示したとしても。
- 私のチームメンバーは、安価で構造化されていないソリューションを受け入れ、プロジェクト管理者が「限られた時間」を指摘したときに、ソフトウェアに本当に悪いハッキングを実装します。
- 私のチームメンバーは、別のチームの未完成のプロジェクトと一緒に作業するプロジェクトに取り組み始めます。これは、テストも未完成もありません。 （多くの余分な作業を引き起こします）。
- ソフトウェアの改善とフェーズ全体が適切に計画されておらず、多くの場合、バックエンド開発者が作業を開始する必要があるときにフロントエンド/設計が完了していません。
私がここで働き始めて以来、これらの問題は何度も延々と議論されてきました。全員が同意し、結論としては、プロセスを強制する必要があるということでした。つまり、バックエンド開発者はすべてが処理されるまで開始しません。
これらの問題は起こり続けています-そして私は仕事自体と私の同僚の何人かに本当にイライラするところまで本当にやる気を失っています。
私のチームメンバーは多くの不満を持っていますが、お互いに対してだけです。 They keep on going - whatever the situation is。結果？
- 私は不安になります、多分それは私ですか？
- これは物事がどうなるはずなのか？
私の質問？ How can I say no against work ignoring the process if everyone else seems to mindlessly accept?。
それは、いつも雌犬に何かを探しているだけの迷惑な開発者のようには見えません。
みんな本当に同意しましたか？
私はかつて、プロセスを改善したいという状況がありました。私たちは別のプロセスの提案をしました、そして誰もが同意したようでした。
しかし、その後、私がこのプロセスを実行したいと思うたびに、「より重要な問題」のために例外と呼ばれ、それは常に一見合理的に聞こえました。したがって、事実上、プロセスは事実上実行されませんでしたが、誰もが「原則として、プロセスに従っている」と考えていました。
問題は、改善を提案した場合、反対する人は誰もいないということでした（誰が改善を嫌うのですか？）。しかし、コストを提示すると、通常、多くの意見の相違があります。そして、物事を行うための便利な方法を失うことは、ほとんどの人にとって莫大なコストです。
それを実証するために、私は質問を別の言い方で言いました：「私がすることになっているすべてのこと（機能の実装、バグの削除、改善されたプロセスに従う、机の掃除、時間通りに到着する）を優先してください」。
プロセスに続いて、机を掃除し、5分遅れることはありませんでした。それで、基本的に、彼らは私が提案したものとは完全に異なる何かに同意しました。
問題は、彼らが品質のコストを支払うことを望んでいないことかもしれません。それは彼らを合理化に導くかもしれませんが、あなたは愚痴として批判的ですが、私の経験ではそれはそうではありません。技術的負債はそれほど目に見えないかもしれません、そしてそれを状況に帰するのは簡単です、しかし結局、現実は起こります。
うまくいけば、それまで彼らはそれを実現したか、あなたはジョブを切り替えました。
多分それはあなたです
あなたは非常に構造化され組織化されたコーディング方法を好むようですが、チームメイトはより「物事を成し遂げる」アプローチを持っているようです。さて、これは多くの「無駄な時間」につながるため、おそらくいくつかの構造が整い、ずさんな作業の言い訳はありません。ただし、ソフトウェアプロジェクトは流動的である傾向があり、あまりにも多くの構造を強制すると、多くの組織的なオーバーヘッドが発生します。
おそらく、全員が真ん中で会って、より機敏でインタラクティブな、しかし構造化されたアプローチを試す必要があります。
これらの人々の責任者は誰ですか？誰かが彼らを雇い、誰かが彼らを解雇/責任を問われることができます。
「私の会社は...を必要とします」は、何らかの強制がなければ意味がありません。
生産工程を許さない時間の要求をすることはできません。
このような制御の欠如と非現実的な期待が品質の低下の原因であると思われます。
あなたは次のいずれかを行うことができます：辞任するか、リード開発者になるか、何もしないか、または自分のやり方を感じている人と一緒に作業を開始します。誰かがより良い方法を見つけて変更するまで、正しい手順に従うつもりであることを誰もが知っていることを確認してください。 「サイダーハウスのルール」みたいですね。
同僚に完全に異なるプロセスを実行させたくないように思われますが、その中で同僚に異なる決定を下してもらいたいだけです。確かに、彼らが何をすべきかについての規則（ガイドライン？）があり、彼らはそれらを無視します。しかし、あなたが説明する問題は、彼らが決定を下さなければならず（プロジェクトに取り組み始めるか、仕様を拒否するために）、彼らは続行することを決定することです。ルールを思い出させ続ければ、その決定は変わりません。 彼らはあなたのようにルールについてそれほど気にしない。 彼らは便利に感じることを望んでおり、「いいえ」と言っても彼らは役に立つと感じません。
彼らの行動を変えたいのなら、ルールについて彼らに継続的に思い出させることはおそらくあまり効果的ではありません。彼らがあなたを無視することにつながる可能性が高くなります。プロセスを変更して、プロセスをフォローしながら、より便利に感じられるようにする方法を見つけてください。ある種のコードレビューを実装し、互いのコードをチェックし、互いに学び合って、ハックが本番用コードにならないようにできますか？仕様（docs/ext.interfaces/front-end）の処理方法を、白黒の完成/未完成の決定から、仕様の終わり近くで開発者に依頼されるより協調的なプロセスに変更できますか？終了するのに役立ちますか？ （そして、あなたはその要件を受け入れる必要がありますwill変更）
ほとんどの場合、それはあなたではなく、彼らではなく、プロセスです。あなた（そしてあなたのPM）が、人々が自分の性格にそれほど反対する必要がないものを整理する方法を見つけることができれば、プロセスははるかに迅速に実行されます。
これは、チームリーダーとの密室セッションでチェックインするポイントについてです。うまくいけば、あなたは非常に非公式にすることができるリードとの十分に良い仕事上の関係を持っています。
会議の目的は、チームが自分たちのやり方で物事を行っていることを理解することですなぜ。全員が集まり、うなずき、微笑んで、新しいプロセスに同意した場合、なぜ彼らはまだ変わらないのですか？単純な無関心や無能よりもはるかに深く実行される可能性があります。肉眼では見えないドライバーが働いている可能性があります。
同僚が可能であれば、パニックを減らし、技術的負債を減らし、製品の品質を向上させるプロセスに従うと想定して会議を開始します。結局のところ、誰がそれを望まないのでしょうか。では、目に見えない力は何ですか？
設計とUIプロトタイプの先行作業の前に、多くの実装/統合が行われているようです。その前払いの仕事ができる人が不足しているのでしょうか。多分あなたはボランティアをすることができました。利害関係者とのコンセンサスを得るのに問題はありますか？たぶん、あなたのチームは彼らとコミュニケーションをとる新しい方法を見つけることができるか、仮定を文書化するための新しいアプローチを取ることができます。
1対1でリードを依頼するところから始めれば、なぜなら、防御を回避し、問題と解決策に焦点を当てた議論への扉を開くことができます。
別のトリックは、物事を行うための新しい方法を開拓できるかどうかを尋ねることかもしれません。チームリードからの支援を得て、問題を少し強制し、あなたが主張しているアプローチをとらせてください。「システム」を弱めると、おそらく問題が発生するため、管理を背後に置いておきます。しかし、より生産的でストレスのないことが判明した場合は、物事の方法を変えるための良いケースを提供し、支持者を獲得する可能性が高くなります。