HTMLレイアウトに影響する要素（パート2：PMの作業とワークフロー）

継続するには...

この記事はパート1の続きです。
HTMLエンコーダーの機能 。

午後の仕事

1.要件、要望の明確な解釈
そして、クライアントの意志。

最悪の場合：
クライアントの希望はPMからエンコーダーにそのまま送信されます（あいまい、
不鮮明）
要件またはタスクは、たとえば次のように定式化されます。
より緑の「」、「フォントを増やす」、「このブロックを左に移動する」、
「このページを一般的なスタイルで設計します。」
良い習慣：
できるだけPM
クライアントの要件と要望を明確にし、指定された
エンコーダの要件。 要件またはタスクが定式化されます。たとえば、
たとえば、「この＃0BB822緑色を使用します。」 「フォントを増やす
最大18ピクセルの「、」ブロックを左に3ピクセル移動します。
影響：
より曖昧で曖昧な
要件、あなたがそれに費やす必要があるより多くの時間
フルフィルメント。 明確な基準の欠如が違いを生む
顧客と製造業者の最終結果のビジョンで
スイングと異なる参加者による結果の異なるビューのある写真
プロジェクト）
決定においてクライアントから与えられた想像上の独立性に惑わされないでください
以降の質問 自律性は論理的に示唆しています
厳格な受け入れの欠如（批判的評価）
そのような顧客。 実際には、クライアントは常に変更を求めます
または、いくつかのことを再度変更します。 ばらつきを減らす必要があります
最低限まで
アクション：
1. PM：すべてのあいまいさを見つけ、定式化する
明確な受け入れ基準。 ささいなことの世話をします。
「私はあなたを正しく理解していますか？」というテクニックを使用します
2. HTMLコーダー：すべての問題と発生についてPMに通知する
あいまいさ

2.何が起こっているのか、コンポーネントを理解する
レイアウトプロセス。

最悪の場合：
PMはプロセスの本質を理解していません
組版、エンコーダー作業の間違ったシーケンスを選択
プロジェクトでは、時間を削減し、作業量を削減します。
PMは、デザインが機能に与える影響を認識または理解しません（
デザインにより、機能の仕事を変えることができます）。
良い習慣：
PMは明確に理解します
彼のプロジェクトの場所と彼が仕事を必要とする段階で
HTMLで。 起こりうるリスクを理解して考慮し、イベントを開催します
それらを防ぐために。
PMは、デザインが機能に影響を与える場所に注意します。 与えられた場合
場所は重要です-プロジェクトチームと変更について話し合います。 もし
いいえ-既存のアカウントを考慮して、クライアントと「再描画」について議論します
機会の。
影響：
結果の構成要素と、この結果を達成する方法の誤解
評価の対象外の活動の存在につながります。 これは、結果として、
設計時間のオーバーランにつながります。
コーディングのソース資料-静的な画像表示
サイトの特殊なケース。 結果は動的なサイトです。 したがって、
写真に示されている理想的な条件に従って受信が行われない、
しかし、現在の（現在の）状況に応じて。
例：入力にPSD（または複数のPSD）があります
独自のCMS用。 最初の評価では、適応
デザインは、「CMSでのカットとストレッチ」タスクのみで構成できます。
ただし、CMSは単なるメインページではありません。 これと結果ページ
検索、ニュースや記事のアーカイブページなど。 不明なページ
PSDに表示されていない、必要な独自の特性と要素がある
少なくとも全体的なスタイルに最小限のゴーストで。 だから必要
新しいタスク-既存のブロックの設計を新しいものに適合させる
デザイン。 このタスクをすぐに実行することはできません。 彼は引き伸ばされている
新しい機能を含めて、クライアントが表示されるため
新しいページのデザインに関する新しい質問と提案（顧客の購入
CMSは突然機能を有効にしたい場合があります
CMSではありますが、最初は期待されていません）。 緊急事態が発生します
そしてプロジェクト時間の浪費。 なぜなら 時間は推定されました
プロジェクトの最初に表示されるページ（そして、これは、たとえば、
ページ）、しかし義務のために私達はCMSを適応させなければなりません
顧客、および彼の新しい要件はこの義務に投資されます。
アクション：
1.ワークフロー： PMによるHTMLデザインの提供
レビュー用のエンコーダ、問題の可能性に関する専門家の意見を受け取る
場所、デザインが機能に影響を与える場所、
クライアントに確認する必要があります。
2.ワークフロー： 「公開日」を実施します。
同僚がお互いの詳細と特徴を説明するとき
作業し、それらに対処するための困難と対策について話し合います。
3.ワークフロー概要の問題解決
またはローカルWikiの問題自体（またはドキュメント、説明、
FAQ）このように知識ベースを作成します。
4. PM： HTMLエンコーダーに今後の作業を通知します。
考えられるボトルネックについて話し合い、可能性を見つけます
計画外の活動、リスクと活動について話し合う
その結果を減らすために。
5. HTMLエンコーダー：プロジェクトでのアクティビティを評価し、
タスクを達成するためのすべてのアクティビティを示します。 公開する
既存のプロジェクト追跡における実行タスクの割合
システム。 リスクについて通知し、
問題。

3.使用するプラットフォームの条件と制限を理解する、または
プロジェクト

最悪の場合：
PMは要件に同意します
実装の容易さまたは存在に依存している顧客
システム内の同様の機能。
RMは、システムの基本的な知識のみを所有しています。
良い習慣：
PMに最適
動作するシステムをよく知っている（多用途
システムの経験）とクライアントとの議論に依存しています
あなたの経験。
PMがコンサルタントに連絡する際のより現実的なオプション
人件費を見積もるプロジェクト（または経験豊富な開発者）
機能を作成（変更）するか、議論中です。
影響：
システム制限の知識
クライアントがタスクを設定する段階で可能性を評価できます
必要に応じて状況を防ぐための実装の人件費
義務を果たし、問題を解決するには大規模な
時間とリソースの予定外の費用、不安定なソリューション
（「松葉杖」）など
アクション：
1.ワークフロー：プロジェクトでコンサルタントを使用する
タスクコンサルティング（このタスクに加えて、プロジェクトでできること
参加しません）。
2. PM：プロジェクトを開始する前に、システムを調べ、相談します
同僚（またはコンサルタント）と協力し、以前の実務経験を学ぶ
彼らの同僚。
3.ワークフロー：問題解決の概要
またはWikiの問題自体（ドキュメント、説明、FAQ）。
4.ワークフロー：一般的なイベントの実施
使用するシステムの能力レベルを向上させる（知識
エンコーダにはシステムとその制限が必要です。 ポイント7を参照してください。
HTMLエンコーダー）。

4.客観性。

最悪の場合：
PMを設定できません
危機的な状況でのプロジェクトの優先順位、現在の
プロジェクトの状況は、物事の本当の状態からはほど遠いです。 選択する
迅速かつしばしば冒険的な決定。
良い習慣：
PMは、提供しています
プロジェクトのコースの緊急バージョンの作業シーケンス、
状況に応じて動作をチェックして再配置し、使用しようとします
安定したソリューション、プロジェクト全体を検討し、コンサルティング
決定を下す前にプロジェクトチームと（それがわかっていても
プロジェクトチームの意見が異なること）。
影響：
コメントはありません

5.プロジェクトと個々の部品の管理
さまざまな段階で。

最悪の場合：
PMは最後にプロジェクトをチェックします。
良い習慣：
PMは結果をチェックします
各段階（マイルストーン）または終了時のプロジェクトの進捗
タスクなど）、運用管理を実行します。
影響：
それぞれのプロジェクトを制御しない
段階的に、PMは設計時間を超過する可能性を高める
期限を守れないこと。 状況は、次の場合に悪化します
最後の監視、現在の状況の責任
PMのビジョンによると、プロジェクトはHTMLエンコーダーのみです（タスク
プロジェクトの最後の「ストレッチ」）。 また、あなたがまだ必要なという事実
再度、開発、テスト、そしておそらく、
シフト。
例：デザインのあるプロジェクトがあります
最初はありません。 開発はプロトタイプなしで設計なしで行われ、
機能仕様のみ。 クライアントが送信しました
デザインまたはPSD、そしてHTMLエンコーダーがプロジェクトに入ります。 状況：
機能の一部がデザインに描かれていますが、これは
作られたもの。 さらに、違いの実装は、
すでに開発に費やされた時間の20％〜60％。 結果として
-シンプルなHTMLエンコーダーとブレークダウン期限。
アクション：
1.RM：すべての段階でコントロールを行使します（そして
間に）プロジェクト。

6.効果的なコミュニケーション。

最悪の場合：
PMは、プロジェクトに共通の議論
各プロジェクト参加者との個別の瞬間。 プロジェクト参加者
「それぞれと」コミュニケーションの問題を解決します。
IMでプロジェクトを議論するには多くの（またはそれ以上）時間がかかります
タスクを実行するよりも時間。 議論する必要がある
同時に複数の人と働く瞬間（これに加えて
同じこと）。
良い習慣：
コースのすべてのプロジェクト参加者
プロジェクトに共通する詳細の変更と議論。
影響：
「みんなとそれぞれ」のコミュニケーションは常に
プロジェクトに関するいくつかの詳細が重要であるという事実につながります
すべての参加者（詳細、変更、シーケンス
タスクを実行するなど）。
アクション：
1.ワークフロー：結果の概要
通信、すべてのプロジェクト参加者の結果を通知します。 可能であれば
プロジェクトの最大参加者と一般的な詳細について話し合う。
2.労働者
プロセス：必須の対象となるプロジェクト会議の厳密な日時を設定する
チーム全体の存在。 要約（カット）。

作業プロセス

1. 1つの報告機関、1つのチェーン、1つのディレクターの存在
タスク。

最悪の場合：
複数の人に報告する必要があり、複数の場所からタスクを受け取ります。
良い習慣：
1つに答える能力
特定の人（ほとんどの場合-プロジェクトのPM）によって、PMは責任を負い、すべての重要な決定を下します。
タスクなどを設定します
影響：
報告する時期
数人の場合、次のようになります。
最初に、話し合い、質問に答えます。 ちょっと話し、話し合う
質問に答えてください。 最初に決めたものを2番目に決めて、
話し合い、質問に答えます。 2番目のコメントを伝える
そして、最初のもので決定されたもの（2番目のものにはコメントがないことを神は禁じています
または提案）。 したがって、問題の解決策は開始されません
議論する前に。 このようなアクションの明らかな矛盾にもかかわらず、
彼らは起こります。 特別なドラマは、彼らがちょうど起こるということです
最も都合の悪い瞬間-プロジェクトが過剰に使用されているとき
時間（PMに加えて、新しいプロジェクトコントロールが含まれているため
人々はより高いリーダーです。 そして、それらのそれぞれが必要
最新の状態に保ち、新しい意思決定を行います）。
この状況に対する最初のパーキンソンの法則を定める：より
人々は同じ問題に取り組んでおり、混乱が増しています。
アクション：
1.ワークフロー：決定をチェーンで行います。
決勝を破らないように、可能な限りの努力をする
タスクの作業からの実行者。 議論はグループによって行われます。

2.可用性と標準および要件への準拠。

最悪の場合：
標準の欠如または
コンプライアンス違反。
良い習慣：
可用性と標準への準拠。
影響：
コンプライアンス違反と標準の欠如
プロジェクト間で同じ間違いが繰り返されることにつながる
（不整合、不整合、時間超過など）。 在庫状況
規格は、間違いを避けるだけでなく、増やすことも可能にします
最終製品の品質。 標準の使用は
それが自動プロセスになるポイントに持って来られる
「標準どおり」と思わせたり思い出させたりしませんでした。
問題の解決に集中することができました。
例：どのように見えるかの非常に簡単な例
些細なことがプロジェクトのロジックや時間に影響を与えます。 で
標準の1つは、*（アスタリスク付き）必須フィールドをマークするために受け入れられます
フィールド名の左側に入力します。 コンプライアンス違反と欠如
実行を制御することで、さまざまな形式で
星のプロジェクトの部分は左側、右側の部分でした。 なぜなら 去る
これは論理的ではないため、そのようなすべてをもたらすのに時間がかかりました
標準に置きます。
アクション：
1.ワークフロー：標準を導入および承認します。
しばらくの間、コンプライアンスを制御するために。

3.知識ベースの存在と育成、過去の経験など。

最悪の場合：
経験はどこにも概説されておらず、知識ベースが欠落しています。
良い習慣：
情報は、企業の無形資産であり、保存および保存する必要があります。
ある人が他の人が知らないことを知っていることはしばしば起こります。 そんな中
この人物がプロジェクトに参加していない場合、プロジェクトのリスク。
知識は、高度なトレーニングと経験への道です。
例 ：デジタルライブラリ、ローカルWiki
-知識ベースを整理する良い例（定期的に
有用な記事の補充）。
アクション：
1.ワークフロー：プロジェクト後の概要
他のプロジェクトでの繰り返しの可能性のある場所（説明
「問題-ソリューション」、いくつかのアクションの実装に関する指示）。
2.ワークフロー：各従業員に届ける
知識ベースの知識と擁護（プロモーション）
その開発。
3.ワークフロー：集中管理された電子機器を作成する
電子形式の本を保管する（サーバー上のフォルダー）。 作成する
レビュー、レビュー、推奨事項が記載されたローカルWikiの特別セクション
既存の本に。
最後に、私はあなたにもっと面白いプロジェクト、新しい経験、良い実践を願っています。

あなたは記事が好きですか？ RSSを購読する
。 今後、多くの興味深いことがあります。 関心分野：
レイアウト、プロジェクト管理、使いやすさ。

出典： Web開発ブログ
そしてそれを改善する方法