出石聡史のレビュー一覧
-
Posted by ブクログ
なんだか見たことあるなぁという事例がたくさん。
オレゴン大学の実験など、ステークホルダーは各々理解がことなるため、結果顧客の欲しかったソフトウェアは出来上がらないなどはお馴染みですよね。
如何にして顧客が本当に解決したい課題を仕様に落とすかが大事だなと。
------------------------------------
以下メモ
- WBSも成果物からブレイクダウンしていきましょう
- OS変化のリスクに備え、メンテナンス体制を整えておく
- メンバーの成熟度も加味した上でスケジュールを構築す るべき
- 用語集を作成しよう
- 仕様は正確に伝わっていないという前提を持ち、コミュニ -
Posted by ブクログ
タイトル通りの本。
ソフトウェア開発に関わったことはないので想像。
開発に複数人チームで挑む、あるいはまたは、ある部分が終わらないと絶対に次に進めないのが特徴といっていいのかな。
メーカー的な開発も「やり始めないと工数の見積もりが難しい」「後半になってはじめて課題に気づく」は同じなのに、なぜプロジェクトマネジメントの流儀が広く普及してるのか考えてみた。
部署単位で仕事することが多いメーカーと違って、プロジェクトごとのアサインなのでプロジェクトごとに人が動く、プロジェクトの区切りがはっきりしてることなのかと思った。
日頃よりプロジェクトマネジメントの作法がある分、工数管理自体のノウハウも -
Posted by ブクログ
タイトルの通り失敗事例集。想定の舞台が、よくある受注型大規模SIではなく、自社開発のロボットアームFWと周辺ツール開発、ということで、わりと今の業務に近く親近感を感じる。中身はよくある感じだが、実際、今の職場で、この本にかかれているようなことは、ほとんどのことが生じている。アタマの良い人達、とくにローテーションで降ってくる管理職の人たちは、なんでも自分たちで考えようとするのか、こういった、本に何度も書かれている典型例でさえも、ゼロから経験しようとしていく。ちょっと本を読めば、先回りして回避できるようなことでも。進捗会議でアレコレ議論するのではなく、(本書に限らず)読書会でもしたほうがいいような
-
Posted by ブクログ
ある程度経験のあるソフトウェアエンジニアにとって「あるある」という失敗とどうすればよかっただろう？という学びをまとめた本。各エピソードは架空のプロジェクト進行に基づいて書かれていて、順に読み進めていくことで、実際のプロジェクトのどの段階で発生しがちな問題なのか、というイメージをしやすい。最初に書いた通り「あるある」集であり、新しい知識を獲得できたか？という点では少し期待外れだった。ただ「あるある」を"まとめてみた"というのが本書の価値であり、まとまった情報というのはそれだけでありがたいものである。成功は再現できないが失敗は再現できるので。