database - 新しいシステムを開発するとき - db スキーマは常に利害関係者と話し合う必要がありますか?

Question

私は、これから説明するプロジェクトに関与する人々よりも数層/レベル上にあります。

一般的な要件は、Web ベースの問題管理システムです。システムは、はるかに大きなプロジェクトの小さな部分です。

リード PM には、プロジェクトのこの部分を処理することになっているテクニカル PM がいます。リード PM は、ヘルプ情報が、ヘルプが要求された場所のコンテキストにないのは正常なのかと私に尋ねました。リード PM は、サイトに関するフィードバックを提供しており、エラーメッセージ用のモーダルダイアログなどを求めており、私に見てもらいたいと思っていました。システムを見ていて思うのは…

常温核融合で新しいアプリが開発された!?!?
アプリのデータ検証は非常に貧弱です
アプリのデータ検証ページは、データ入力フォームから移動します
アプリのヘルプページがフォームから移動する
db スキーマは、開発者と PM の間で議論されませんでした
db スキーマは存在しないため、議論されませんでした
メニューページがあります-つまり、ページに移動したら、メインメニューに戻ってから、必要な次のページに移動する必要があります
主任午後は、dbms が何であるかを知りません...
テクニカル PM があり、彼女は dbms が何であるかを知りません...
リード PM は長い間 Tech PM を解雇したいと考えていましたが、Tech PM は保護されています...
主任午後は、必要な正確な機能がいくつかのプロプライエタリプロジェクト (そのうちのいくつかはオープンソース - バグトラッカー、バグジラなど) に存在することを示唆しましたが、技術担当の午後と開発者は耳を貸そうとしませんでした。

2つ質問がありますか？

私はしますか

開発者を解雇しますか？
技術担当者と彼女を保護している人を解雇しますか?
午後のリードを発射しますか？
それらのバグトラッカー/バグジラをダウンロードして構成し、それらすべてを起動しますか?
彼らのためにバグトラッカー/バグジラをダウンロードして設定してから、悲しみを忘れるためにビールを飲みに行きますか?

プロジェクトの非常に早い段階で db スキーマについて議論し、徹底的に検討するのは SOP ではないでしょうか?

編集：

私は以前、さまざまなレベルの技術的知識 (および知性) を持つ多種多様なクライアントと仕事をしていました。私はいつも利害関係者と db スキーマについて話し合いました。彼らがスキーマが何であるかを知らなかったら、私が教えます。彼らが理解する背景を持っていなかったとしても、たとえ彼らが私たちがスキーマについて話していることに気付いていなくても、私は彼らとスキーマについて話し合うでしょう. 私が直接関わってきたほとんどのプロジェクトでは、データがシステムの最も重要な部分です。スキーマ/ドメインモデルを徹底的にハッシュ化することは、システムを十分に理解し、何を実行して報告できるかを理解する上で非常に重要です。SOに関するポスターの意見を高く評価しています。私のアプローチが通常のコースではないことに注意してください。

ところで - 悲しいことに、プロジェクトは納税者の資金を使用し、IT 部分は名門大学との共同作業です... 開発者と技術担当者は長年の従業員です - 彼らは経験が浅いわけではありません。知的で勤勉な人々が失業していて、そのような人々が雇われているのを知っているとき、私は特に悲しくなります。

私が若かった頃、私はこの種の無能さをチェーンの上流に報告し、適切な行動を期待していました. 私はチェーンの上流にいるので、他の人の責任を細かく管理したくないことに気づきました。

私の決意は、ビールを2杯飲んで、自分の責任に戻ることでした...

score 5 · Accepted Answer

さて、最初にあなたの質問に答えましょう。ユーザーは、db スキーマについて話し合う必要がある人ではありません。一般に、微積分について牛と話し合うのと同じです。彼らが技術的なバックグラウンドを持っていたとしても、次に要件が変更されたときはどうでしょう。彼らはスキーマの更新に関与する必要がありますか?

より一般的に言えば、これは、テクニカルリーダーが問題を「顧客」または利害関係者と接触させないようにするケースのように思えます。問題を実際に修正するように求められている場合は、何らかの GUI プロトタイプ (おそらく単なるストーリーボード) を作成し、それについて説明する必要があることをお勧めします。そうすれば、物事がどこにあるのかがわかります。

拡張: はい、プロジェクト内で DB スキーマについて議論するのは普通のことです。リードとの主要なカウンセリングについて真剣に考える必要があると思います。

さらに拡張: ご指摘の点は理解できますが、問題は、データベーススキーマが実装の詳細であるということです。私たちはデータベースに慣れすぎて、それを見失い、データベースのように見えるアプリケーションになってしまいます。しかし、顧客に価値を提供するのはデータベースではありません。お客様がやりたいことができるかどうかです。顧客がアプリケーションを見る方法を DB スキーマに結び付ける場合、それらを 1 つの実装に結び付けます。より効率的なシステムを作るためにテーブルを非正規化するなどの変更は、顧客に見せなければならないものになります。彼らに観測可能なものを見せて、これらの詳細を自分たちだけに留めておく方がよいでしょう。

しかし、用語の衝突もあると思います。「ドメインモデル」については、あなたの意見に同意したでしょう。データベーススキーマによって、システムのユーザービューに表示されるテーブルとリレーションのみを意味する場合、「ユースケース」を意味する場合は、同意します。

score 3 · Accepted Answer

データは利害関係者と話し合う必要があります。絶対にそうです。利害関係者がすべて「データベースに精通している」特別な状況を除き、DB SCHEMA について利害関係者と話し合うべきではありません。

では、DB スキーマについて議論せずに DATA について議論するにはどうすればよいでしょうか? これは、実体関係 (ER) ダイアグラム、および一般的な ER モデルで私が見つけた主な用途です。多くのデータベース設計者は、ER をリレーショナルデータモデリング (RDM) の骨抜きバージョンとして扱う傾向があります。私の経験では、骨抜きにされた RDM と考えなければ、はるかに有利に使用できます。

ER と RDM の違いは何ですか? RDM では、多対多の関係には中間にジャンクションボックスが必要です。このジャンクションボックスは、ジャンクションボックスを多対多関係の参加者にリンクする外部キーを保持します。

ER では、厳密に適用すると、ジャンクションボックスは多対多の関係では不要です。関係を線で示し、線の両端に「多」の可能性を示すだけです。実際、ER ダイアグラムには外部キーはまったく必要ありません。外部キーによるリンケージの概念は、ほとんどのユーザーとの議論から除外できます。

データの正規化は、ER 作図とはまったく関係ありません。適切に作成された ER 図には有害な冗長性はほとんどありませんが、それは主に偶然であり、慎重な計画の結果ではありません。

利害関係者指向の ER 図の "エンティティ" と "関係" には、主題の専門家が理解できるエンティティのみを含める必要があり、論理データベース設計の過程で追加されるエンティティや関係は含めないでください。

データベースに保持され、オンデマンドで提供される値は属性に関連付けることができ、属性はエンティティまたはエンティティ間の関係に関連付けることができます。さらに、属性は、各属性が取り得る値のセットであるドメインに関連付けることができます。外部キーなど、データベースに保存されている一部の値は、ほとんどの利害関係者との議論から除外する必要があります。

データを理解している利害関係者は、「エンティティ」、「関係」、「属性」、および「ドメイン」という用語になじみがないかもしれませんが、一般にこれらの概念を直感的に理解しています。主題データを理解していない利害関係者には、特別な扱いが必要です。

ER モデルと図の優れた点は、データベース内のデータだけでなく、ユーザーが見ることができる形式でデータが表示されるため、それらを使用してデータについて説明できることです。フォームやフォームの記入方法を理解していない利害関係者がいる場合は、可能な場合はコンピューターから遠ざけることをお勧めします。

かなり機械的なプロセスによって、適切に構築された ER ダイアグラムを適度に適切に構築されたリレーショナルスキーマに変換することが可能です。より創造的な設計プロセスは、論理的に同等の「より優れた」スキーマをもたらす可能性があります。一部の技術関係者は、ER 図だけでなく、リレーショナルスキーマを理解する必要があります。リレーショナルスキーマを知る必要のない人には見せないでください。

score 2 · Accepted Answer

さて、最初にあなたはおそらく技術者と彼女のスポンサーとの関係を非常に注意深く見直す必要があります。後でプロテクターを発射できるとほのめかしたときに、techpmが保護されていると言って驚いています。彼女は保護されているか、保護されていません。あなたがプロテクターを解雇できるなら、彼女は保護されていません。

つまり、誰も保護されていないように聞こえます。さらに悪いことに、誰も通信していません。次のことをお勧めします。リードPM、テックPM、および開発者とのミーティングに電話します。一緒になって、順番にそれぞれに尋ねます。「あなたの仕事以外は何も参照せずに（つまり、この演習の期間中、他の人を責めることはできません）、5分以内に今日あなたを解雇すべきでない理由を教えてください」。

これは極端なアドバイスだと思いますが、あなたは古典的な問題に対する恐ろしい解決策を説明しました。このプロジェクトのあらゆる側面と結果として生じる「コード」は、惨事のように聞こえます。あなたはおそらくこの混乱の監視にもっと大きな手を持っているべきでしたが、あなたはそうしませんでした（何らかの理由で）。PMレベルで採用された専門家がこれよりもうまくいくことを期待すべきだと思います。

したがって、チームの大幅なシェイクアップをお勧めします。失業の恐れを表にまとめたら（そして、それぞれのコミュニケーションの失敗を書き留めていることを伝えます）、すぐにコミュニケーションを改善するための計画と、混乱を修正するための詳細なタイムラインを投稿するように依頼します。週末。

それから、あなたはこのプロジェクトのリードリーダーのPMになっているので、自分の尻を下ろしてください。

彼らがこの災害で形を整えてカムバックをやめたら、ゆっくりと彼らの責任を再び増やし始めます。そうでなければ...常にドアがあります。

乾杯、

-R

score 0 · Accepted Answer

まず、dbスキーマについてCharlieMartinに同意します。

2番、

プロジェクトの開発者は非常に環境に配慮しているようですが、これは彼/彼女の最初のプログラミングの仕事ですか？もしそうなら、私は彼らの履歴書が何か他のことを言っている場合にのみ開発者を解雇します。

リード/テックpmsがプロジェクトにどの程度関与すると予想されるかはわかりませんが、責任はdev> tech pm>Leadpmであるように思われます。その場合、技術者の午後は完全にボールを落としました。なぜボールが落ちたのかを知り、それに基づいて彼女を発射/維持したいと思うかもしれませんが、そのような失敗した仕事は私が働く叱責の時間です。

最後に、imho、「保護」のものはbsです-あなたは彼らの叔母が誰であるかではなく、彼らの質と価値に基づいて人々に報酬を与えて叱責する必要があります。

幸運を！乾杯！

score 0 · Accepted Answer

リードPMは、必要な正確な機能がいくつかのプロプライエタリプロジェクト（そのうちのいくつかはオープンソース-バグトラッカー、バグジラなど）に存在することを示唆しましたが、技術pmと開発者は耳を貸しませんでした。

これが当てはまる場合は、リードpmにもっと積極的になるように伝えます。次に、Bugzillaをインストールして、それを実行するように指示します。頑固さのために技術者と開発者が聞いていなかった場合は、少しチャットする必要があります...

いずれにせよ、あなたはあなたの組織に問題があると思います...「ここで開発されていない」事件のために何千ドルも失われましたか？しかし、それが実装の段階に達したとすると、開発レベルよりもさらに上流に問題があります...

みんなとdbスキーマについて話し合う限り、私はノーと言うでしょう。アプリケーションの要件が収集された後、積極的に貢献できるすべての人が関与する必要があります。

score 0 · Accepted Answer

うわー、災害のように聞こえます。大まかな順序であなたのポイントに対処させてください：

まず、人々は快適だと思う言語で成長します。はるかに優れた選択肢が存在するときに誰かが古い環境でまだ快適である場合、それは彼らがスキル習得への欲求がほとんどないことの確かな兆候です。
データ検証は、人々が道を行き過ぎて、それが盲目の路地であることに気付くのを防ぎます。検証の欠如は、開発者がユーザーについて考えていないことを意味します。また、それは最後に付け加えられたものではありません...それは単にそのようには機能しません。
Webの「ダイアログ」は、あなたが考えている意味で「モーダル」にすることはできません。ただし、追加のウィンドウをポップアップするのは簡単です。ページのヘルプでは、ほとんどの場合、この種のポップアップウィンドウを使用する必要があります。
データ検証は、データが入力されているページから離れないようにする必要があります。これは恐ろしいUIデザインです。
DBスキーマは、問題が最も少ないものです。開発者が機能の提供に責任を持ち、データスキーマ設計に明らかに有能である場合、スキーマのニュアンスについてリードPMと話し合うことは重要ではないと思います。さまざまなコードレベルの利害関係者の間で話し合う必要があり、作業の要件を処理できる必要があります。ただし、PMの観点から重要なことは、運用面ほどスキーマではありません。もちろん、優れたdbスキーマを構築する開発者の能力に自信がない場合は、すべての賭けが無効になります。
dbmsが何であるかを真剣に知らない場合は、深刻な問題が発生している可能性があります。基準はありますか？拡張プロジェクトの他の全員がMSSQLServerを使用していて、この人がOracleを選択した場合、専門知識とスタッフをこのプロジェクトに、またはプロジェクトからどのように移しますか？これは、組織が制御不能になっていることを示しています。
代替の専有製品を無視する理由は2つあります。まず、彼らは本当にあなたのニーズを満たしていないかもしれません。第二に、技術PMと開発者は、単に羽毛布団を組んでいるか、リソースを浪費するための「ここで発明されていない」正当化に従事している可能性があります。問題は、2つの違いを知るために、自分のレベルで十分な洞察を得ることができない可能性があることです。
開発者の解雇に関して...追加のトレーニングを後援することで彼を助けることは可能ですか？この人が他の点では優秀な従業員であり、あなたのビジネスをよく知っている場合、必要なのは正しい方向へのプッシュだけであるときに、私は彼らを解雇することを非常に躊躇します。
技術PMは、彼女が実際に仕事をしていないように聞こえます。彼女は私が書いている欠陥を指摘し、改善を推進する論理的な人物です。彼女の立場に対する本当の問題は、彼女があなたの組織の利益のためにより良い擁護者になることを学ぶことができるかどうかです。
リードPMもパッシブに聞こえます。tech PMに関する上記のコメントは、ここにも適用されます。
バグトラッカーなどが実際に機能する場合は、そのルートを使用するのが理にかなっています。ただし、人を解雇することについてもう少し慎重になりたいと思うかもしれません。

score 0 · Accepted Answer

このように考える傾向があります。データベーススキーマは、アプリケーションのデータストレージ要件をサポートするために存在します。アプリケーションが保存する必要があるデータは、エンドユーザーの要件によって決まります。アプリケーションの要件についてエンドユーザーに相談していない場合、明らかにトラブルに直面していますが、エンドユーザーの要件 (およびおそらく将来の要件) をよく理解していれば、データベーススキーマは技術的な決定であり、エンドユーザー/クライアントからの直接の入力なしに、プロジェクトチームによって作成されます。

エンドユーザーは、テーブル、フィールド、正規化などの複雑さを理解することはほとんどありませんが、「システムが xyz を実行する必要がある」ことは理解できます。エンドユーザーが理解できる言語で話し、チームに適切な技術的決定を下させます。

score 0 · Accepted Answer

わお。あなたの痛みが分かります。

あなたの問題の最初の原因は、「保護されている」techPM であるかのように私には見えます。彼女はなぜ、誰によって守られているのか? 私はかつて、CEOの秘書が最初にビジネスアナリストになり、（彼が辞めた後）プロジェクトマネージャーになったプロジェクトに参加していました。彼女は、私たちがどの言語でプログラミングしているかを知らず、要求は時間の無駄だと考えていました。彼女は組織の最高位に保護されていたので、唯一の本当の解決策は、他の場所で仕事を探すことでした.

あなたは彼女と彼女の保護者を解雇できると考えているようですが、それはあなたよりも下の誰かかもしれませんが、リードPMよりも上にいるので、彼はそれについて何もできませんでしたが、あなたはできますか? はい、2人を解雇する必要があります。

リード PM は、保護者が誰であったかによって、サルベージ可能である場合とそうでない場合があります。彼は何をすべきかを知っている岩と困難な場所の間にいる可能性がありましたが、技術担当者と彼女の保護者との関係の性質により、彼女と彼女に報告した人々に影響を与えることができませんでした. 私はかつて、上司のうち 2 人が部下の 1 人と関係を持っていて、あらゆる種類の組織的大混乱を引き起こしたその立場にありました (これが、技術 PM と同様に保護者を解雇しなければならない理由です)。彼に疑念の恩恵を与え、技術者と彼女の保護者が邪魔にならない場合、彼がどのように異なる方法で物事を処理するかについて彼と話し合ってください. あなたが聞いたものが好きなら、彼を引き留めることはできますが、組織的に介入して、この人物が責任者であり、誰も彼を無視できないことを明確にする必要があります。リードが権限を失った場合、それを取り戻すには、経営陣からの強力な支援が必要です。

また、リーダーや開発者と一緒に座って、現在のプロジェクトで何が受け入れられないかを正確に説明します. 開発者がリードから指示を出すことができないと感じている場合 (あなたがリードを維持することを決定した場合)、または新しいビジネスのやり方に適応できない場合、または現状のコードが受け入れられない理由を理解できない場合は、損失を減らして、彼も。新しい人は、彼を無視した歴史がないため、とにかく救助可能であれば、リーダーとしてよりうまく機能する可能性があります.

score 0 · Accepted Answer

db スキーマを常に利害関係者と共有する必要があるとは必ずしも思いません。ほとんどの人は、その種の情報をどう処理すればよいかわかりません。製品が要件に適合していることを確認しようとしている場合は、要件を前もって明確にレイアウトし、プロジェクトの開発全体で検証する必要があります。

開発者に問題がある場合、それは当然のことです。もっと信頼できる人を見つけるべきだった。下手なコーダーを雇ったのなら、それはあなたの間違いです。

考えられる解決策がいくつかあります。

より良いコーダーを取得します。彼はすべての悪いコードを処理することを嫌いますが、うまくいけば、完了するまでそれを実行します. うまくいけば、あなたは彼に良いお金を喜んで支払うでしょう.
コーダーを預かって、彼にすべて直してもらいましょう。彼をよりよく管理できる新しい PM を雇います。そのコーダーは自分のコードを最もよく知っているので、コードを改善するのにかかる時間はより短いかもしれません。長い目で見れば、下手なコーダーを雇い続けないほうがよいので、仕事が終わったら彼を失います。
うんざりして、関係者全員にビールを買って、オープンソースでやり直してください。おそらく、ソフトウェアを管理するための技術 PM が必要になるでしょう。また、その時点でカスタムを行うことを忘れる必要があります。おそらく、請負業者はこれを管理できます。

いずれにせよ、あなたはいくらかのお金を失うことになります。次回はもっと注意深く見守る必要がありそうです。

score 0 · Accepted Answer

私の大きな疑問は、リード PM とテック PM の保護者との関係についてです。リード PM には、保護者からの報復を恐れる正当な理由がありましたか? 守護者より上の人間にとって明らかに重要な状況になるまで、何もできないと感じていた可能性は十分にある。その場合、彼はこれ以上厳しい扱いを受けるに値しません。

技術担当の PM は明らかに彼女の仕事に無能であり、彼女の保護者は仕事を成し遂げるよりも彼女を支持することに関心があります。それは、少なくとも実際の仕事を成し遂げることの重要性について話し、最大限に両方を解雇することで、何らかの方法で対処する必要があることを私に示唆しています。

あなたが概説した状況を考えると、開発者はおそらく政治的に生き残ろうとして身を潜めています. 私は、開発者についてアドバイスを与えるのに十分な情報を提供することはできません.

したがって、あなたの説明と私の驚くべき超能力が私に明確で正確なイメージを与えた場合:

リーダーを報復から守り、すべての不満を捨てて既製のソリューションを実装するように伝えます。(彼が確実に一人を選ぶことができないなら、彼は午後のリーダーになるべきではありません。)

テック PM と彼女の保護者を訓練します。人々がそのように企業の生産性を台無しにしたくはありません。

開発はリード PM の責任です。そのままにしておきます。必要以上に細かく管理しないでください。ビールを一杯。いつもの仕事に戻る。

database - 新しいシステムを開発するとき - db スキーマは常に利害関係者と話し合う必要がありますか?

10 に答える 10

Related

Reference