要求定義と要件定義の違いを考える - Qiita
要求定義と要件定義についての記事というのは需要があるようですね。 検索されるだけなのか？そもそも話し合いの中では、その「定義」を確定して、話しておくことが大事なのですよね。言語を学ぶ上で、まずはひらがなからカタカナからそしてローマ字など文字を学ぶように、プログラミング用語や現場で使う単語などというのは意識して使っていかないと追いつけなくなってしましますからね。 役割分担、期日を決めるなどマネージメントの方もプロジェクト進行では、考えていきたいですね。 ##最近の近況 バーチャルな世界に興味があり、バーチャルSNSなどにも顔を出しながら作業してます。 ##はじまり はぁ… なんでシステム開発が失敗するんだろう… 仕様の変更が多くて… 言った言ってないのトラブルから避けたい… システム動かしてみても全然使えない… 実は．． 事業運用をオペレーションレベルに展開しないままに、 システム開発をして
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレク
チェックリストでリスクを見つけてプロジェクトを幸せにしよう - Qiita
リスク要因を洗い出してリスク管理！ プロジェクト管理とはリスク管理とイコールだ！と言っても過言ではありません。 すべてのリスクを回避すれば、プロジェクトは 期限通りに、 要件通りに、 お客様も満足して、 幸せに、 終わるはずなのです。 ITプロジェクトのリスク予防への実践的アプローチ IPAが、そんな幸せへの最短ルートと言うべきドキュメントを出しています。それが、 ITプロジェクトのリスク予防への実践的アプローチ(PDF) です。 長いですが、一読の価値はあるというか、百読の価値あるドキュメントです。 プロジェクトの最初に、プロジェクトの途中で、プロジェクトが終わってから、それぞれ違う読み方が出来ると思います。 ただ、長いので、簡潔なチェックリストにしてみました。 これをチェックするだけでも、割といい線でリスクの洗い出しが出来るはずです。 リスクが見つかったら、対応方法を考えなければいけま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
