デザイナーに決めさせてください...
もちろん、開発は完全に明確な計画に従って行われ、顧客は自分の要件を明確に表明し、すべてのエグゼキューター（デザイナー、レイアウトデザイナー、プログラマー、アナリスト）が連携して、互いの作業を正確に把握します。 しかし、これは常に発生するわけではなく、この「常にではない」ことについて私たちは進んでいきます。
プロジェクト参加者間の不完全な理解の状況は、多くの場合、顧客が最初にデザイナーと緊密に連携し、次に好みのデザインを持って、レイアウトとプログラマーに行くという事実につながります。 これは通常、主に次の2つの理由で発生します。1つ目は、ビジュアルシリーズ（デザイン）に基づいて顧客が考えを表現しやすいことです。2つ目は、ほとんどの人が奥には、隠されたコード、エンジン、データベースなどがあります。 同時に、開発者の小さなグループは、クライアントを怖がらせることを恐れて、そのような確立された慣行にあまり反対しないかもしれません。
現時点では、すべてのデータが彼に割り当てられた場所に収まるようにする責任は、不幸な設計者に暗黙的に割り当てられています。
お客様は、「美しい建築材料店のモデルが必要です」と言います。 デザイナーはルートカテゴリがいくつあるかを問い合わせ、5〜7の数字を受け取った後、ドロップダウンサブアイテムを含む水平メニューを描画します。 そして、これはすべて装飾、影、その他のもので生い茂ります。 結局のところ、顧客は既に最寄りの建築材料市場での取引の経験があり、オレンジ色の粘着価格タグ「ガラスブロックは安い」からアプリケーションを作成しないと、誰も彼のコンテナに注意を払わないことを知っています。
そしてその後、カタログを埋める段階で、彼が20のルートパーティションを持つことになります...
デザイナーでなければ、誰ですか？
実際、デザイナー自身がこの問題に対処し始めることができます。 レイアウトのリメイクとフィッティングを行わないことが彼の利益である場合（彼が次のプロジェクトを待っているフリーランサーである場合）、彼自身がサイトの将来のコンテンツについて顧客にもっと注意深くインタビューし、これから適切な結論を引き出す必要があります。
グループが開発に携わっている場合、彼らはこのうちのどれを分析作業に着手すべきかを事前に決定する必要があります。 さらに、これは、顧客が現在持っているものにも依存します。 彼がすでに「オフライン」取引に従事している場合、彼はすでに（Excelのファイルであっても）独自の倉庫会計システムを持っている可能性があり、プログラミングスキルのある人にとっては分析が容易になります。 すべてがゼロから始まる場合-ここではアナリストの役割のために、これに最大限の時間を割くか、サイトが関係するサブジェクト領域を理解することが重要かもしれません。
そして何をすべきか？
この方向の分析作業の主な原材料はテキストです。 したがって、最初に行うべきことは、探しているテキストを取得することです。 既存のサイトのベース（タスクが新しいバージョンを作成する場合）、ウェアハウスプログラムからのアンロード、または顧客との会話中のノートブックからの電子的に単純化された行の例。 同様の向きの他のサイトがある場合-そこからのデータの例。
これらはすべて、異なるタイプのデータに対応する個別のテーブルに分解する必要があります。すべて同じセクション名、商品のテキスト記述などです。
タスクの次のコンポーネントは、各タイプ内で可能な最小および最大の長さを決定することです。 私はプログラマーにアドバイスをしません-おそらく誰もがすでに自分の好きな手段でこれを行う数十の方法を知っています。 そして、その活動領域がグラフィックエディターまたはHTMLエディターである人のために、簡単なレシピを示します。
- 行を含むテーブルをOpenOffice Calcにロードする
- 行を持つ最初のセルの右側のセルを選択します
- 入力行に= LEN（ 左側のセル番号、たとえばA1 ）を入力し、緑色のdawをクリックすると、数式ではなくセル自体に数値が表示されます-文字列の文字数
- 行を含むテーブルの全長に沿ってこのセルを右下隅を超えて「ストレッチ」し、すべてのセルの長さの値を取得します
- 長さの値を持つ列を選択し、「ソート」をクリックします。その後、Calcはソートの範囲を広げるかどうかを尋ねます。
その結果、行が長さでソートされたテーブルを取得します。 真ん中のすべては、おそらく興味の対象ではありません。 最短線と最長線が重要であり、デザイナー、レイアウトデザイナーがボタン、メニュー項目、説明ブロックなどでそれらを埋めておく価値があります。
サイトが店舗の場合、上記の方法で分析するのが難しいもの、つまり商品数と価格を表示するフィールドのサイズに注意する必要があります。
バスケットのコンパクトなブロックはレイアウトで美しく見えるかもしれませんが、店舗での平均チェックが7桁であると予想される場合（買い手は、例えば、価格が "、50"で終わるリノリウムの整数の整数ではなく選択できます）数字、これは明らかな間違いになります。
もう1つの重要なポイントは、アプリケーションの長さに関する制限をサイトの技術仕様とドキュメントに導入することです。 顧客がそれでもそのようなものを運転することができれば、これは不合理な主張からあなたを救うことができます。
それは何を与えますか？
このような分析がないことの効果を想像することは非常に簡単です。 グラフィックの背景（いくつかの複雑なカール）を持つボタンがレイアウトに書き込まれるという事実の結果を想像してください。レイアウトには、「ブラインド」、「壁紙」が書き込まれます。 そして、実際のベースをロードすると、碑文がそこに到達します。「perfoのドリル。 SDS-MAXはボッシュ製です。」
またはその逆-デザイナーは説明テキストで従来の「Lorem ipsum ...」の数ページを獲得しましたが、顧客はそこに複数のオファーがなく、予想されていないため、ページに穴が開きます。
これらの問題はすべて、彼のデータが原因であると顧客に説明することができます。 しかし、彼はまだ自分のサイトが最初に彼に見せられたグラフィックレイアウトと同じくらい美しいことを望み、それでもそれで何かをしなければなりません。
しかし、うまくいかない場合はどうすればいいですか？
もちろん、顧客はさまざまな理由から、予備分析のためのデータの提供を拒否する場合があります。 そして、ここでそれは実行者の仕事です-協力を拒否する（不十分な顧客は契約の金額を大幅に超える量の問題を引き起こす可能性があります）、または必要なスケーリング、改行、ブロックトリミングの場合に解決策を敷くことによって「鉱山」をバイパスしようとします サイトの要件にまだミニマルなデザインが含まれておらず、あらゆる種類のジャンクとの互換性が含まれている場合、すべてを提供しようとすると、かなりの人件費が発生する可能性があることに注意してください。