若くて死にかけているプロジェクトを救うには？

潜在的なトラブルに巻き込まれたくないので、これを匿名で投稿しています。
私には大きな問題があります。
私は最近、1歳未満のチームに参加しました。私はプロジェクトが始まってから一ヶ月間ここにいました。会社の構造は次のようになります。

• 所有者（技術者以外）
  • プロジェクトマネージャー（技術者以外）
    • 主任開発者（技術的ですが、それは苦手です）

このプロジェクトは、ASP.Netを使用したWebサイトであり、主な開発者が恐ろしいアーキテクチャを設計しました。私の言葉に耳を傾ける必要がありますが、基本的に、Webページを構築するために必要な方法は、デバッグモードでVPNを介して1つのWebページで3分以上の読み込み時間を与えることです。

他の同僚が、実際の開発よりもページの読み込みを待つことに多くの時間を費やすことに同意するところまで、スパイラルが発生しています。

今、大きな問題はこれです。プロジェクトマネージャーはテクノロジーを知らず、それを認めています。彼は、主任開発者がアプリケーションアーキテクチャについて正しい選択をすることを信頼していると明確に述べています。

チームの誰も所有者の意見が何であるかを知りませんが、誰もがこの経済（特に私自身）で波を起こすことを恐れています。

あなたならどうしますか？

この問題は、非常に非技術的な用語でプロジェクトマネージャーに実証できます。PMの前にあるブラウザウィンドウにサイトを配置し、しばらくの間遊んでもらうよう依頼します。約2ページのロード後、あなたが言うほど悪いことがある場合、主任開発者はカーペットの上で呼び出されるべきです。

PMは、なぜそれが悪いのかを理解するための専門的な開発知識を持っていないかもしれませんが、それが一般的なWebサイトユーザーであると自分自身で見ることができます。同様の情報を表示している他のサイトは、あなたの数分の1の時間でロードされ、あなたのサイトは隣の部屋のサーバーからローカルネットワークを介してロードされています。

これが飛んでいない場合は、所有者に移動します。所有者はお金を稼ぐ人ですが、誰もアクセスしない==お金がないという遅いWebサイトをすぐに見ることができます。同じデモンストレーションをセットアップします。最初のページがロードされる前に、彼はもっと豪華なカーペットでPMとリードの両方を呼び出す必要があります。

1人の男が手を振るのが心配な場合は、複数の開発者に懸念を表明してもらいましょう。正直なところ、あなたと同じくらい平らな会社では、開発中の製品が爆弾である場合、あなたが話すか静かにするかに関わらず、あなたは仕事をしていません。そのように見れば、失うものは何もありませんが、数週間または数か月余分に会社にいます。それが問題である場合、懸念を放映する前に「歯科医の予約」をスケジュールし、新しい雇用を探してください。そうすれば、この仕事を失ったら、次の月曜日に始めます。

あなたの声明が正確であると仮定すると、あなたは無能なリード開発者と無能なプロジェクトマネージャーを持っています（少なくとも彼がチームのスキルを評価できない程度まで）。いいよ 世界中のすべてのチームの開発者とまったく同じオプションがあります。

1. 会社の健康を気にせずに仕事をしていますか。

2. 他の場所で仕事を探してください。

3. リード、PM、およびオーナーに合理的な提案を行い、採用されることを期待します。

上記の任意の組み合わせを同時に自由に行うことができます。

プロジェクトの健全性を積極的に保証したい場合は、他の開発者と協力して空き時間に新しいフレームワークを考案し、チームの他のメンバーに、なぜそれが優れているのか、古い作業が必要なのかを示す必要がありますそれを支持して捨てられます。

実際に会社のパートナーである主任開発者がソフトウェアの「コア」を作成し、彼と直接作業した親しい友人を除いて、他の開発者が芯。

"powers that be"は、各モジュールがデータベーステーブルを1つしか持つことができないようにルールを作成しました。これは、その方法がよりクリーンだからです。そしてその結果、既存のドロップダウンは、個別のテーブルではなく、データベースのテーブルから「DISTINCT」を選択することで作成されました。

実装チームが作業を完了しなければならず、製品はすぐに機能しなかったため、多数の不正なパッチが漂っていました。これらのパッチは、修正するだけでなく、インストールごとにカスタマイズ（ハッキング）される問題を引き起こしました。

私のアプローチは、コアがサポートしていない仕様の一部を取得し、そのための小さくて優れた汎用パッチを作成することでした。実装チームを満足させたものの、「思考を完全に変える必要がある」ほど脅威ではありませんでした。実装チームとコア開発者の間の敵意により、実装チームに私のアプローチが彼らのハックよりも優れていると納得させるのに数ヶ月かかりました。しかし、一度彼らが私に耳を傾け、彼らをサポートするために追加の調整を実施することに気づいたら、彼らは喜んで私の側にいました。リード開発者がパッチを受け入れるのにさらに1か月かかりましたが、いったんそれを行うと、システムの他の部分を設計するためのより良い方法について、私たち全員の間でコミュニケーションがとれました。

特に人々との市民関係を維持する必要がある場合、人々の考え方を変えるための短い道は決してありません。しかし、正しくアプローチすれば、上司をs辱することなく敬意を払うことができます。

お役に立てば幸いです！

非常に簡単な答えと解決策。誰もが問題を認識しているようです。したがって、問題を指摘することは誰にとっても価値がありません。実際、それはただあなたを泣き言のように見せます。価値を追加する場合は、ソリューションを指摘し、ソリューションに変更するためのビジネスケースを構築する必要があります。次に、対応するソリューションで問題を指摘できます。デモは、ソリューションの証明にも大いに役立ちます。もちろん、これは自分の時間に仕事をすることを意味するかもしれませんが、それはあなたにとってどれだけ重要であるかにかかっています。

まず第一に、VPN構成の問題ではなく、アプリケーションアーキテクチャの問題であるという事実を確認することを強くお勧めします。VPNの構成が適切でないと、この問題が発生することがあります。アプリがオフィス内でそれほど遅いことを確実に知っていますか？

ネットワークを除外している場合は、KiethSの提案に従い、PMにページをプルアップしてもらいます。

それはビジネスのように聞こえるか、少なくともプロジェクトはある時点ですぐに失敗するでしょう。終了する前に、できるだけ早くそれから遠ざけようとします。ボランティア/他のプロジェクトの作業を依頼する。時間が経てば、この災害に費やす時間が少なくなり、働く可能性のある他のプロジェクトにより多く費やせるようになります。「機能しなかったプロジェクトに取り組んだ男」とは思われたくないでしょう。あなたの評判を守ることがすべてです。

所有者は良い製品を望んでいるかどうか？答えは「はい」だと思うので、発言する必要があります。現在のアーキテクチャを文書化してから（適切な帝国データを使用して）、製品が適切なパフォーマンス期待値を満たしていないことを示す必要があります。あなたの同僚は皆、それがひどく機能していることを知っていると言います-まあ...顧客はどうですか？彼らは何を言っているのですか？パフォーマンス測定ツールを使用して、時間がかかっているものを特定します。多くのツールは、各関数呼び出しにかかる時間を表示するようになります。このすべてのデータから、プロジェクトマネージャーとテクニカルリードと話をするのに十分な弾薬が必要です。なぜ物事がそうあるべきではないのか、製品を高速化するためにいくつかの主要なリファクタリングが必要な場合があることについて。

次に（PMとリードと話し合った後にのみ）、これはいくつかの変更を開始するのに十分である必要があります。PMがその時点で納得していない場合、これが本当にあなたが居たい場所であるかどうかを決める必要があります。もしそうなら、おそらく所有者との会議。そうでない場合は、その履歴書を準備してください。

方法のすべてのステップを文書化するようにしてください。

技術的には、上記の提案に同意します。一方で、私はそれが技術的な問題というよりむしろ関係の問題に似ていると感じています。

スムーズなルートを取りたい場合は、主任開発者と話すことが適切な選択になります。しかし、私はオフィスで話をしません。外でコーヒーを飲むと、物事が少し非公式になり、よりリラックスしたものになります。

それでもうまくいかない場合は、PMに連絡してから所有者に連絡してください。

うまくいかない場合は、新しい仕事を探すことをお勧めします。

誠実さ-そしてあなたが集結できる限りのタクト。

リード開発者から始めて、必要に応じて作業を進めます。彼らの性格のより良い側面に従事するようにしてください-あなたが開発者を導いて問題を解決するのが好き/日を救うのが好き/効率的であるのが好き/などその点で問題を言い表す追加の動機として過去に成功しました。

波を作っていないのなら、おそらく水中で死んでいるでしょう。

プロジェクトマネージャーと所有者が理解できるように、問題を測定可能で技術的ではないレベルに戻すことは可能でしょうか。

たとえば、3分以上の遅い読み込み時間について言及しましたが、仕様のどこかに、「1秒以内に読み込まれるページ」のような単純なパフォーマンス要件があると想定します。このようなものは測定可能であり、反論することはできません。この問題の根本原因が危険なアーキテクチャであることが判明した場合、プロジェクトマネージャーや所有者が何らかの変更を強制するために介入する必要があります。

そうでない場合は、初期分析が不十分であり、これらのタイプの問題をキャッチするための十分なプロセスが整っていない組織に体系的な問題があります。ジャンプ船を検討してください！

本物の男性は、orりや感情を感じずに話します。それがトリックです。

誰かがあなたと話すためにあなたと交差するかもしれない唯一の正当な理由は、あなたが怒りに遭遇した場合です：

リード開発者には、何をする手掛かりもありません。私はこれが起こることを知っていましたが、誰も私に何とか何とか聞きました。

どこに

維持するのが難しく、遅いため、コードモデルは間違っています。この前進について戦略的であり、これら2つの問題を解決する必要があります。

前者は破壊するための戦いであり、後者は平和のための戦いであり、長期的には人が正直であることに対する敬意を獲得するでしょう。

プロジェクトリーダーがこれを前線と見なし、解雇される可能性があると考えている場合は、単にこう言います。

私が実装に責任を負わなかったことに責任を負わせないでください。私はただ正直に言っています。