PM誰も経験のない、非常に複雑な設定を選択する
最近、私はそれほど難しくないと思われるプロジェクトを開始しました。コンセプトは、時々（おそらく1日に10倍）入力を受け入れ、それらに対していくつかの操作を実行してすべての結果を収集する必要があるかなり単純なアプリケーションでした最後に。このアプリケーションは、顧客が結果を表示するために使用できるフロントエンドWebポータルを取得します。
このために、私は最初にPythonの組み込み並行処理ライブラリ（ThreadPoolExecutor）をスマートに使用し、フロントエンドに使いやすいライブラリを使用しました（Flask as as初心者にとっては簡単で、メンテナンスとテストは比較的簡単です）。
プロジェクトの途中でPMは、スレッドの代わりにサードパーティのメッセージキュー機能を使用する必要があり、ロードバランシングを実装する必要があると述べました。最終的には、最終的にはCelery、Redis、RabbitMQ、Nginx、uWSGI、および他の大規模なサードパーティのサービスで、実際に誰も経験したことがないもの。
結局、これは一連のスパゲッティコード、テスト不可能なタスク（サードパーティのライブラリの複雑さのため、コードにパッチを当てることも機能しなかった）につながり、これらのサービスの付加価値を誰も知らなかったため、頭痛の種になりました。 。
「はい、これらのサービスを使用する必要があります」と言う前に、覚えておいてくださいnobodyこれらの使用方法を知っているか、競合状態に悩まされているコードを紹介する以外に、何をするかさえ知っています。
これについて私は何をすべきですか？この時点で、私たちが持っていたものに戻すにはコストがかかりすぎて、PMはこれらのサービスを使用する際に設定が完了していません初めに。これについて彼と話し合うことにも意味がありますか？私はもっと時間を求めますか？または厳しい答え、私は私の仕事にはあまりにも愚かですか？
プロジェクトの途中で、PMは、スレッドの代わりにサードパーティのメッセージキュー機能を使用する必要があり、負荷分散を実装する必要があると述べました
これは、PMが一方的に「状態」を示すためには適切ではありません。2つの理由：
設計上の決定は、技術的リソースによって、そして NFRs にのみ応答して行われるべきです。 PM新しいNFRがあるかどうか、詳細を教えてください。
NFRがプロジェクトの途中で導入されている場合は、おそらく change control を介して行う必要があります。変更管理は、ガバナンスの観点から非常に重要です。これは、要件への入力であるだけでなく、QAのテストケース、運用の展開およびサポートハンドブックへの重要な入力でもあります（本当に重要な部分です） PMのschedule新しい要件により多くの作業が導入される場合、開発チームは新しい開発の見積もりを伝達する機会を持つ必要があり、PMは新しい日付に耐えられるかどうかを判断し、リソースを追加する必要があります、またはNFRを導入した利害関係者を押し戻します。
正真正銘のNFRが実際にあり、それを回避できない場合は、導入されているテクノロジーに精通している新しいリソースまたは別のリソースを要求するか、既存のいくつかのトレーニング予算を要求することも適切な場合があります。リソース。したがって、costの側面もあります。
PMの言語（スケジュールとコスト）を話すと、開発者が結果のデザインについてどう感じるかを話すよりも、より多くの関心が集まると思います。それらのことは実際に影響を与えます。
A PMガバナンス、コントロール、およびコンセンサスなしで、このようなものをその場で導入するよりもよく知っているべきです。彼らがそれを取得しない場合、エスカレーションする必要があるかもしれません。品質とスケジュールを不必要にリスクにさらしているため、製品管理またはプログラム管理。
ばかげているのは、自分に 死の行進 をさせることです。
あなたが説明しているのは、批判的な感覚を失っていることです。制御の感覚はなく、それに戻る明確な方法はありません。
あなたがしなければならない最後のことは、懸命に働き、頭を下げ、そして彼らが最終的にプロジェクトが破滅したと認めるまで静かに苦しむことです。
あなたがすべきことは、あなたが期待するあらゆる権利を持っているかについて非常に熱心に考えることです。
彼らがあなたがあなたが理解していない技術を使いたいと思うなら、あなたはそれらを学ぶ時間を期待するべきです。知らないことを恥じないでください。あなたの無知を反逆者として使ってください。彼らがあなたが何かを使うことを要求するとき、なぜか尋ねます。 「理由」を受け入れないでください。 「最新のベストプラクティス」を受け入れないでください。実際の、テスト可能な期待を獲得することなく、「拡張性」を受け入れないでください。
テスト可能というのは、1日、1時間、1分あたり何件のリクエストを実行できるようにしたいかを伝えなければならないということです。これらの仕様に従ってこのシステムを実行する何かを構築するつもりであることを明確にしてください。
この方法では、30日間の無料トライアルを使用して、彼らが欲しい最新のウィズバンのことはそれだけの価値があることを証明できます。
今心に留めてください。競合状態に陥ったコードを導入したのはツールではありません。君たちはそれをやった。元に戻す方法を学ぶ必要があります。
そして、いいえ。元の状態に戻すのにコストはかかりません。 PMは、それを要求するだけでは彼らが望むものを持つことができません。PMが望むものを効果的に使用するか、そうでないことを証明するまで、プッシュバックする必要があります。プロジェクトに必要なもの。
真剣に、これに屈することは専門家ではなく、プロジェクトにとって致命的です。
私はここの男です。もう一度。それはあなたを愚かに感じさせます。それは本当にそれではありません。あなたはただ失われています。
首相と話してください。正直なところ。それをすべて置きます。あなたは学びたいと思っているが、乗るために連れて行かれたいと思わないことを示しなさい。決して信仰に基づいた設計やコードを作成しないでください。 PMに、彼らが望むことをどのように行うかを示します。理解しないふりをしないでください。理解できないときに実行されるとは言わないでください。もしそうなら自分を信じるものを信じようとします。
それでも問題が解決しない場合は、すぐに必要になるため、履歴書を洗練してください。あれやこれやで。
問題は実際にはソフトウェア開発の問題ではなく、職場の関係に関するものであるため、これは実際にはworkplace.stackexchange.comにあるはずです。
あなたのシンプルなアプローチが機能し、かなり迅速に機能する結果が得られたと確信している場合、あなたのPMは会社の破壊的な力であり、削除する必要があります。ニュースの入手方法を理解してください。彼の上のレベルに：あなたのチームには、うまく進んだシンプルで実用的なソリューションがあり、誰もあなたのPMを説明できないため、誰も知らない、誰も理解していない、それらがまったく役立つかどうか誰も知らない多数のツール、そしてあなたのPMの計り知れない決定はあなたにすべてのトラブルを引き起こし、プロジェクトを遅らせ、ワーキング。
経営陣が追求するコンテキストや製品戦略を知らないため、客観的に質問に答えることは困難です。
ここにいくつかの客観的な議論があります。ただし、それが期待したものと異なる可能性もあります。
- 「nobodyこれらの製品の使い方を知っているまだ」を覚えておいてください。
- 完全に既知のツールと技術のみを使用することで、高い生産性が保証されます。しかし、それは革新する能力をかなり制限します。一部の市場では、製品にとって致命的な場合があります。たとえば、ほぼ30年前、私はWindows 3.0を使用して、MS-DOSで成功したCAD製品の新バージョンを開発することを提案しました。製品マネージャーは、これが実証済みではないことに反対しました。チームにとって学ぶのが複雑すぎて難しすぎる環境、そしてとにかく、「Windowsが主流の環境になることは決してない」という環境です。 。2年後の彼の製品の成功を推測させてください。
- それはすべてコストと利益の問題です。実験のコストと、巨大なインストールと重いワークロードを経験しているサードパーティによって保証されたスケーラビリティと展開の利点の比較。
- 新しい技術を追加することの欠点は、適切なトレーニング、または経験豊富なコンサルタントによる最初のサポート/コーチングによって、スムーズにすることができます。
最終的に、経済的な選択は、製品マネージャーの責任です。彼が長所と短所を話し合って、彼が十分な情報に基づいた決定を行い、追加された複雑さを過小評価しないようにします。そして、もし彼が彼のトラックに留まっているなら、あなたのベストを達成するようにしてください：あなたが失うものは何もない、そして最悪の場合、あなたはあなたのCVに新しい技術を持っているでしょう。
サードパーティのライブラリ（およびその他のコンポーネント）には2つの方法があります。
- できるだけ多く使用してください
- できるだけ少なくしてください
私のアプローチは（2）です。あなたのアプローチも（2）のようですが、プロジェクトマネージャーは（1）のアプローチを気に入っています。
この状況に対処するには3つの方法があります。 PM PMが望むことは何でもすることを許可するか、PMを説得して3番目のアプローチに変更するパーティーライブラリ、またはあなたの足で投票し、別の仕事を選択します。
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を必要とし、Bを必要とすることで、メモリ内に同時にX + Y + Z + A + Bが必要になります。 Xに相当するものだけを実装することで、社内でX 'と呼ぶことにしましょう。メモリに必要なのはX'だけです。また、通常、X 'のメモリフットプリントはXのメモリフットプリントよりも小さくなります。
- バグリスク。 外部コンポーネントの行数が多いほど、理解する必要のある膨大な量のコードのために修正が困難なバグに遭遇するリスクが高くなります。社内で行う場合は、通常、コード行を減らして（必要なことだけを実行し、他には何も実行しません）、バグのリスクを減らします。
- カスタマイズ可能。 私がSQLクエリを自分で書いた場合、クエリがどのように見えるか、および特定のデータベースエンジンと特定のインデックスセットでクエリがどの程度適切に機能するかがわかります。一方、SQLクエリが外部コンポーネントによって記述されている場合、そのパフォーマンスについては何も知りません。私は以前、各Webページのフェッチに数秒かかった会社で働いていました。原因は、Hibernateライブラリーが使用したHibernateライブラリーがデータベースから自動的に大量のデータをフェッチしたときに、必要なものが1つのアイテムであり、この特定のアイテムに関連するすべてのアイテムではなかったためだと思いました。既存の膨大な数のライブラリを使用するアプローチが気に入らなかったため、速度低下の真の原因を発見する前に会社を辞めました。
ライブラリがそれ自体をaと呼ぶ場合は特に注意してください フレームワーク。つまり、ライブラリでは、アプリケーション全体を自分で構築する必要があります。通常、同じアプリケーションに2つのフレームワークを含めることはできません。彼らは平和的に共存することなく互いに戦います。 Web開発ユーティリティライブラリ？はい、これらの数が少なすぎます。現在使用しているライブラリよりも優れたライブラリを見つけた場合、古いコードで古いライブラリを引き続き使用しながら、新しく見つかったライブラリを新しいコードで使用できます。 Web開発フレームワーク？大きな警笛 番号！
あなたのPMは、稼働中に多くのメンテナンス作業を行うシステムの管理が困難であることを目的としているため、収入を確保できます。
個人的には、あなたはPythonに行き詰まっているようです、pythonしばらくの間忘れてください、pythonで1年コーディングしないでください、新しいことを学んでください、あなた同じことができる、おそらくもっと良い他の言語があることがわかります。
他の人が述べたように、ツールを使ってコーディングを始める前に、ツールを学んでください。タスクに適していると思われるさまざまなツールの調査に基づいて、必要なスタックを一緒に評価することをお勧めします。あるいは、彼がどのようにしてそのリストを思いついたのかと尋ねると、彼は最新の誰かからの助けがあったかもしれません。