誰も経験のない過度に複雑なセットアップを選択するPM [非公開]

最近、私は作るのが難しくないように思えるプロジェクトを始めました。コンセプトは、時々入力を受け入れなければならないかなりシンプルなアプリケーションであり（おそらく1日10倍）、それらに対していくつかの操作を実行し、すべての結果を収集しようとしました最後に。その後、このアプリケーションは、顧客が結果を表示するために使用できるフロントエンドWebポータルを取得しますが、ロケット科学そのものではありません。

このために、私は最初にPythonの組み込み同時実行ライブラリ（ThreadPoolExecutor）をスマートに使用し、フロントエンドに使いやすいライブラリを使用しました（初心者には簡単で、保守とテストが比較的簡単なため、Flaskを選択しました）。

プロジェクトの半分に達した後、PMは、スレッドの代わりにサードパーティのメッセージキュー機能を使用する必要があり、負荷分散を実装する必要があると述べました。最終的に起こったことは、最終的にCelery、Redis、RabbitMQ、Nginx、uWSGIそして、誰も実際に経験したことのない他の大規模なサードパーティサービスの束。

最終的に、これはスパゲッティコードの束、テスト不能なタスク（サードパーティライブラリの複雑さ、コードのパッチ適用が機能しなかったため）、およびこれらのサービスの付加価値が誰にもわからないために頭痛の種につながります。

「はい、これらのサービスを使用する必要があります」と言う前に、誰もこれらの使用方法を知らないか、競合状態に悩まされているコードを導入する以外に彼らが何をするかさえ知らないことに留意してください。

これについてどうすればよいですか？この時点では、最終製品が当初よりも悪くなったとしても、私たちが持っていたものに戻すにはコストがかかりすぎ、PMはこれらのサービスを使用することに行き詰まっています。彼とこれについて議論するのに使用さえありますか？もっと時間が必要ですか？または厳しい答えは、私は自分の仕事にはあまりにも愚かですか？

プロジェクトの半分になった後、PMは、スレッドの代わりにサードパーティのメッセージキュー機能を使用する必要があり、負荷分散を実装する必要があると述べました

これは、PMが一方的に「述べる」ための適切なことではありません。2つの理由：

1. 設計上の決定は、NFRに応じてのみ、技術リソースによって行われるべきです。そのため、新しいNFRがあるかどうか、また詳細を教えてください。

2. プロジェクトの途中でNFRを導入する場合は、おそらく変更管理を介して行う必要があります。変更管理は、ガバナンスの観点から非常に重要です。それは要件への入力であるだけでなく、QAのテストケース、運用の展開およびサポートハンドブック、および（本当に重要な部分である）PMのスケジュールへの重要な入力でもあります。新しい要件がより多くの作業を導入する場合、開発チームは新しい開発の見積もりを伝える機会を持つ必要があり、PMは新しい日付に対応できるかどうか、リソースを追加するか、導入した利害関係者を後押しするかを決定する必要がありますNFR。

真のNFRが本当にあり、それを回避できない場合、導入されている技術に精通している新しいまたは異なるリソースを要求するか、既存の一部のトレーニング予算を要求することも適切ですリソース。したがって、コスト面もあります。

PMの言語（スケジュールとコスト）を話せば、開発者が結果のデザインについてどのように感じるかについて話すよりも多くの牽引力を得られると思います。これらのことは本当に影響があります。

PMは、ガバナンス、コントロール、コンセンサスなしで、このようなものをオンザフライで導入するよりもよく知るべきです。うまくいかない場合は、製品管理またはプログラム管理にエスカレートする必要があります。彼は品質とスケジュールを不必要に危険にさらしているからです。

バカになるのは、死を行進させることです。

あなたが説明しているのは、批判的な感覚を失ったということです。制御の感覚はなく、それに戻る明確な方法もありません。

最後にやるべきことは、一生懸命働き、頭を下げ、プロジェクトが運命にあると最終的に認めるまで静かに苦しむことです。

あなたがすべきことはあなたが期待するすべての権利を持っているものについて非常に一生懸命に考えることです。

彼らがあなたにあなたが理解していない技術を使って欲しいなら、あなたはそれらを学ぶ時間を期待するべきです。知らないことを恥じないでください。あなたの無知をas棒として使ってください。彼らはあなたが何かを使用することを要求するとき、理由を尋ねます。「理由」を受け入れないでください。「最新のベストプラクティス」を受け入れないでください。現実的でテスト可能な期待を得るまで、「スケール能力」を受け入れないでください。

テスト可能とは、1日/時間/分ごとにリクエストを何回実行できるかを伝えなければならないことを意味します。これらの仕様に従ってこのシステムを実行するために何かを構築するつもりであることを明確にしてください。

このようにして、30日間の無料試用版を使用して、最新のウィズバンの価値がそれだけの価値があること、または既に知っていることにこだわる方が良いかどうかを証明できます。

念頭に置いてください。競合状態に悩まされているコードを導入したツールではありません。君たちはそれをやった。元に戻すには、どのようにそれを行ったかを学ぶ必要があります。

そしていや。あなたが持っていたものに戻すのに費用はかかりません。PMは、それを要求するだけでは望みのものを得ることができません。PMが望んでいるものを効果的に使用できるようになるまで、またはプロジェクトが必要とするものではないことを証明するまで、プッシュする必要があります。

真剣に、これに屈することは専門的ではなく、プロジェクトにとって致命的です。

私はここにいました。もう一回。それはあなたを愚かにさせます。それは本当にそうではありません。迷子になりました。

PMと話してください。正直に。それをすべてレイアウトします。喜んで学べますが、乗ってもらいたくないことを示します。信仰に基づいて設計またはコーディングすることはありません。PMに、彼らが望むことをする方法を教えてください。理解できないふりをしないでください。それが文句を言わないときに行われると言ってはいけません。自分を信じる何かを信じるなら。あなたはノーと言って喜んでである必要があります。

それでも解決しない場合は、すぐに必要になるため、履歴書を磨いてください。あれやこれやで。

問題は実際にはソフトウェア開発の問題ではなく、職場の関係に関するものだからです。

あなたの単純なアプローチがうまく機能し、かなり迅速に作業結果を生み出したと確信している場合、PMはあなたの会社の破壊的な力であり、削除する必要があります。彼より上のレベルにニュースを届ける方法を考えてみてください。あなたのチームは順調な進歩を遂げたシンプルで実用的なソリューションを持ち、PMを説明することができない理由により多くの複雑なソリューションを試さなければならなかった誰も知らない、誰も分からない、誰もそれらが有用かどうかわからないツール、そしてあなたのPMの計り知れない決定があなたにすべてのトラブルを引き起こし、プロジェクトが遅れて動作しなくなる原因になります。

経営陣が追求する背景や製品戦略を知らないため、客観的に質問に答えることは困難です。

ここでいくつかの客観的な議論。ただし、期待したものではない可能性があります。

• 「ということに注意してください誰もがこれらの製品を使用する方法を知っていない、まだ」。
• 完全に知られているツールとテクニックのみを使用すると、高い生産性が保証されます。しかし、それは革新する能力をかなり制限します。一部の市場では、製品に致命的な影響を与える可能性があります。たとえば、ほぼ30年前、Windows 3.0を使用して、MS-DOSで成功したCAD製品の新しいバージョンを開発することを提案しました。プロダクトマネージャーは、これは実証済みの環境ではなく、チームにとって習得するのが複雑すぎて困難すぎること、そしてとにかく「Windowsが主流の環境になることは決してないだろう」と反対しました。 2年後の彼の製品。
• それはすべてコストと利益の問題です。巨大なインストールと重いワークロードを経験したサードパーティによって保証された実験コストとスケーラビリティおよび展開可能性の利点。
• 新しい技術を追加することの欠点は、適切なトレーニング、または経験豊富なコンサルタントによる最初のサポート/コーチングにより、スムーズに進めることができます。

最終的に、経済的な選択は製品管理者の責任です。長所と短所について話し合い、十分な情報に基づいた意思決定を行い、追加された複雑さを過小評価しないようにします。そして、彼が彼のトラックにとどまっているなら、あなたのベストを達成するようにしてください：あなたが失うものは何もなく、最悪の場合、あなたはあなたの履歴書に新しい技術を持っているでしょう。

サードパーティライブラリ（およびその他のコンポーネント）には2つのアプローチがあります。

1. できるだけ多く使用してください
2. できるだけそれらを使用しない

私のアプローチは（2）です。あなたのアプローチも（2）のように聞こえますが、プロジェクトマネージャーはアプローチ（1）が好きです。

この状況に対処するには、3つの方法があります。PMが望んでいることをPMに任せるか、PMにサードパーティライブラリへのアプローチを変更するよう説得するか、自分の足で投票して別のジョブを選択します。

PMにアプローチを変更するよう説得したい場合は、次の議論を検討してください。

• 学ぶ時間。各外部ライブラリを学習するには時間がかかります。その際、特に数百行のコードで実行できる非常に単純なことを行うためだけに巨大なライブラリを選択した場合、有能なプログラマーが必要な機能を作成できます。
• 交換可能性。外部ライブラリがある場合、その開発が停止した場合に、他の同様のライブラリに置き換えることができるようにするにはどうすればよいですか？私の解決策は、できる限り外部ライブラリを回避し、それが実行可能でないときはいつでも、必要なプログラミングインターフェイスの一部を抽象化する単純なラッパーを作成することです。通常、私が望むインターフェースは、ライブラリが提供するインターフェースよりもはるかに単純です。次に、私のラッパーはこのラッパーを介してのみ外部ライブラリにアクセスし、置換を容易にします。いくつかのフレームワークでアプリケーション全体を構築することは大したことではありません。サーブレット？はい、彼らは長い間ここにいて、近い将来にここにいます。テンプレートエンジン？はい、それらは正確に交換可能ではありませんが（通常、1つを選択してそのまま使用します）、それらがもたらす価値は非常に大きく、そのため、慎重に選択してください。テンプレートエンジンを切り替える場合、同じアプリケーションに2つのテンプレートエンジンを含めることができますが、通常、同じアプリケーションに2つのフレームワークを含めることはできません。Apache Struts？いいえ、フレームワークはすぐに流行し、時代遅れになります。通常、同じアプリケーションに2つのフレームワークを含めることはできません。
• バージョン地獄。外部ライブラリを選択すると、セキュリティの脆弱性を回避するために更新する必要があり、更新すると問題が発生する場合があります。よく設計されたコンポーネント（Java JREなど）はさまざまなバージョンと互換性がありますが、私の経験では、巨大なバージョンの地獄を課すためにほとんどのライブラリはがらくたです。また、コンポーネントXはZバージョン1を必要とし、コンポーネントYはZバージョン2を必要とする場合があり、同じアプリケーションでZバージョン1とZバージョン2を必ずしもリンクできるとは限りません。
• セキュリティの脆弱性。外部ライブラリを選択すると、アプリケーションに対する簡単に悪用可能なセキュリティ脆弱性の数が増えます。社内で開発されたコードはあいまいさによってセキュリティに似ていると主張する人もいるかもしれませんが、それでもやはりセキュリティの一形態だと思います。
• ライセンスの問題。各外部ライブラリは、プログラムの一部に独自のライセンスを課します。たとえば、GPLライブラリを非GPLプログラムで使用することはできません。また、LGPLライブラリはバイナリとともにソースコードの配布も必要としますが、これにはかなりの帯域幅が必要になる場合があります。
• アプリケーションの起動時間。大きな外部ライブラリはそれぞれ、アプリケーションの起動時間を遅くします。シンプルで無駄のないライブラリを社内で作成することにより、アプリケーションの起動時間を大幅に短縮できます。
• メモリフットプリント。XにYを要求し、ZにAを要求し、AにBを要求するには、メモリ内にX + Y + Z + A + Bが同時に必要です。Xに相当するものだけを実装することで、社内でX 'と呼びましょう。メモリ内にX'だけが必要です。通常、X 'のメモリフットプリントはXのメモリフットプリントよりも小さくなります。
• バグのリスク。外部コンポーネントの行が多いほど、理解しなければならない膨大なコードのために修正が困難になるバグに遭遇するリスクが高くなります。社内でこの作業を行う場合、通常は必要なコード行を少なくして（必要なことだけを行うため、他には何もしません）、したがって、バグのリスクが小さくなります。
• カスタマイズ可能性。SQLクエリを自分で作成する場合、クエリがどのように見えるか、特定のデータベースエンジンと特定のインデックスセットでどのように実行されるかがわかります。一方、SQLクエリが外部コンポーネントによって記述されている場合、そのパフォーマンスについては何も知りません。私は、各Webページを取得するのに数秒かかった会社で働いていました。原因は、この特定のアイテムに関連するすべてのアイテムではなく、1つのアイテムだけが必要なときに、データベースから自動的に大量のデータをフェッチしたHibernateライブラリが原因であると考えられました。膨大な数の既存のライブラリを使用するアプローチが気に入らなかったため、遅さの本当の原因を発見する前に会社を辞めました。

ライブラリがそれ自体をフレームワークと呼ぶ場合は特に注意してください。つまり、ライブラリでは、アプリケーション全体を自分で構築する必要があります。通常、同じアプリケーションに2つのフレームワークを含めることはできません。彼らは平和的に共存せずに互いに戦うでしょう。Web開発ユーティリティライブラリ？はい、これらが少なすぎます。現在使用しているライブラリよりも優れたライブラリを見つけた場合、古いコードを古いコードで使用し続けながら、新しく見つけたライブラリを新しいコードで使用できます。Web開発フレームワーク？鳴らし大きなNOを！

あなたのPMは、ライブ中に多くのメンテナンス作業を生み出す管理しにくいシステムを目指しているので、収入を確保できると思います。

個人的には、あなたはpythonにこだわっているようです。しばらくpythonを忘れて、1年間pythonでコーディングしないで、新しいことを学んでください。

他の人が述べているように、ツールを使ってコーディングを始める前にツールを学んでください。タスクに適していると思われるさまざまなツールの研究に基づいて、必要なスタックを一緒に評価することをお勧めします。または、彼がそのリストをどのように思いついたのかを尋ねると、彼は最新の誰かから助けを得ることができたでしょう。

開発者は、新しいライブラリ、フレームワーク、テクノロジーなどを使用することを学ぶことを怖がってはいけません。これは開発者の職務記述書の中核部分です。チームの正式な技術的意思決定を行う立場にある場合、チームでの経験、またはチームの要求を行うことさえできます。

ただし、新しい技術をすぐに引き出すことができると期待するのは合理的ではありません（一度にいくつかの新しい技術は言うまでもありませんが））スタックに入れて、進歩を続けます。新しいアプローチのインとアウトを学び、新しいピースを組み込むための良いデザインを見つけるのにかなりの時間が予定されていたはずです。その間、実際の製品の実際の進歩は期待されません。 、チーム全体である場合とそうでない場合がありますが、そうでない場合は、チームの他のメンバーに知識を伝達することを学んだ人たちのために、さらに予定された時間が必要になるでしょう。それは、この種の大きな変更を行うコストです。新しい技術を学ぶことは開発者の仕事の一部ですが、ゼロタイムコストでただ発生するものではありません。

それは質問からは起きなかったようです。人々は、どういうわけか自分たちが理解していなかった技術の上に、良い実装を構築しようとすることでうまくやっていました。もちろん、結果のコードはひどいものです。

会社がこれにより多くの時間を費やす必要があることを PMに納得させるようにしてください。それは、今やめ、新しい技術を学び、評価し、良い設計を見つけ出し、現在の実装の混乱を一掃するという形をとるでしょう。または、バグ、メンテナンス、コストのかかる開発などにより多くの時間を浪費する形で提供されます。

質問で説明されている技術的な選択（負荷分散、メッセージキューなど）が実際に適切かどうかを言うことは不可能です。「これまでチームで働いたことのある人は誰もいません」が決定を絶対に除外する正当な理由だとは思いませんが、それはその決定を行うための短期的なコストを増加させます。そして、あなたのPMがそれを考慮しておらず、経験豊富な人々と同じくらいすぐに生産性を上げることをチームが期待している場合は、それらの根拠を押し戻す必要があります。彼らは非常に非現実的なプロジェクトスケジュールを設定しますが、これは誰の利益にもなりません。