タグ

仕様に関するyouichirouのブックマーク (3)

  • ゲーム開発プロジェクトマネジメント講座(SQUARE ENIX OPEN CONFERENCE)

    ゲーム開発 プロジェクトマネジメント講座 2011年10月8日 株式会社スクウェア・エニックス CTO 橋 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか? 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ(コンテンツの範囲)の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース(人員・環境)の問題 • ビジネスの問題 4©SQUARE-EN

  • 要求の定義:曖昧なことを曖昧にしたままにしない:DESIGN IT! w/LOVE

    不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 仕事をしていて顧客要求や仕様が曖昧なのがわかっているのに、そのまま放置しておくのって、傍から見ててもあんまり気分のよいものじゃありませんね。 ニーズや仕様が曖昧なまま、確認もせずに勝手な思い込みで作業をはじめてしまうなんてありえないんじゃないでしょうか? おかしいなと思うのは以下の3点。 1点目いったい、誰のお金で働いてるつもりなのかというのがまず1点。 給料もらって働いてるんだから、仕様が曖昧なまま、作業を進めて、やり直しだとか、作業が無駄になったりしたら、そのコストの浪費はいったい誰が責任を負うんでしょうか? 2点目それから、仕様が曖昧で、確認しようにも相手がいまひとつ仕様を明確にできないのなら、こちらから適切な提案をする形で仕様を決めるのが専門家の仕事でしょというのが

    youichirou
    youichirou 2006/12/09
    耳に痛いなぁ
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する

    結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている(騙されているともいう)。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小

    わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
  • 1