第16回 ドキュメント管理の要はPMOが握れ
プロジェクトで作成するドキュメントは、メンバーが増え、時間が経つと急激に増えていく。ドキュメント管理規定があっても、周知徹底は意外に難しい。シンプルなルールを定めた上でチームの裁量を認め、ドキュメント管理の要所をPMOが握るようにするとよい。 高橋信也 マネジメントソリューションズ 代表取締役 「9月3日の役員プレゼンで使った資料はどこにあるの？」 「8月27日の進捗会議の議事録はどこにいれた？」 「プロジェクトの共有フォルダの構成がぐちゃぐちゃじゃない！ 何がどこにあるのか分からないから、分かるように整理してよ！」 このようにプロジェクトマネジャから突然言われても、一度始まってしまったドキュメント管理の混乱は一朝一夕に収まるものではありません。 “魔窟”と化したドキュメント・フォルダには、手を付けたくない 本来、プロジェクトで作成する膨大なドキュメントは、ドキュメント管理規定に基づいて分
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
フリーランスが請けたくないプロジェクトの特徴:Geekなぺーじ
「7 Signs Your Project Will Never Make it to Production」 という記事がありました。 フリーランスとして働いている著者が、プロダクトとして発表されるに至らないプロジェクトの特徴を述べています。 このような特徴を持つプロジェクトに参加しても、自身のポートフォリオに新しい製品を追加する事はできないそうです。 面白かったので要約してみました。 全てにおいて真であるとは思いませんが、何と無くありそうな話だと思いました。 1. クライアント側でUIモックアップを制作したことが無い クライアントは自分が何を制作したいのかを良くわかっていません。 2. クライアントは、ドキュメントではなく電話越しに内容を伝えようとする かなり危険な状態です。 何らかのドキュメンテーションが出来上がるまでは仕事を請けるべきではありません。 3. クライアントの個人的欲求
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
