マイクロソフトもIBMというかメンフレームぽくなっているんだな。品質>納期
プロジェクトマネージャーがプログラム書けないなんて有るんだ
リックソフトは、豪Atlassianのプロジェクト管理/課題管理ツール「JIRAシリーズ」上で動作するアドオンソフトウェア「WBSガントチャート for JIRA」の最新版となるバージョン9.0を、3月2日にリリースした。
PwCコンサルティングの中野大典氏がプロジェクト立て直しの要請を受けたのは、リリース予定の2カ月前。外資系製薬メーカーのデータマート構築プロジェクトは、当初5人体制でスタートし、半年後にリリースする予定だった。だが開発が一向に進まず、メンバーの1人が過重なストレスで離脱した。
トラブルプロジェクトの原因の一つに、作業や成果物を構造化したプロジェクト計画「WBS(Work Breakdown Structure)」の不備がある。メンバーらはどう動いていいか分からない。まさに、ゴールまでの道筋が見えない状態だ。アビームコンサルティングの一岡敦也氏に声が掛かったプロジェクトもそうだった。
人材確保や開発費負担などリスク分散を図るために、5社連合
米企業の要求スケジュールに応えて商品を開発しようとすると、その品質検査も十分にできず、品質リスクをはらんでしまう危険性が高い。
空席の飛行機を運んでしまう航空業界と同じように見えるが失敗するとコストがさらに掛かるところが厳しい
サービス残業をされると実際の工数が見えなくなるのでソフトウェア開発では致命的
極論すれば、ウエハ1枚から1個しかDRAMができなくても、それで利益が出てビジネスが成立するならば、それ以上歩留まり向上にコストをかける必要はないのである。
カウボーイ的に出来る人はそれで良いとして、新人とかゼロからだったら、「積み上げ」により、そこそこ出来る人を作れると重いけれど
誰もが口に出すのをためらう案件こそ、指揮官が率先して扱わないといけない。「幹部は大所高所の話をすべきである」と教科書的な発想をお持ちの方は、メシの計算をせずに部隊を南方の島々に送り込み、その揚げ句に何十万という兵士を餓死させた帝国陸軍のエリート参謀を思い出してみるとよいだろう。
アジャイル的にユーザが近くで、すぐに反応をとれるようにしてスピードup、「上流工程完璧主義」により品質確保、あたりまえだけど成し遂げるのは大変
エクセルで集計して色付けなどは、プロマネの非常時の基本技だよね〜
プロジェクトに参加した以上、助っ人ではなく、当事者なのです。「誰か(他人)のプログラム開発が遅れている」のではなく、「自分のソフトウェアが遅延している」のです
報酬を上げてもモチベーションは上がらず、成果は出ない。 むしろ「自主的に、やりたい」事をやらせたほうが、成果が出る。 …という事が科学的に実証されているのだそうです。
大爆笑できるか、気をつけいけない、ITのゼネコン下請け現象
このような総合的判断ができないバカがテストを担当すると、ささいなバグまで発見し、スケジュールを乱してしまう。また、マジメな連中は、多様な状況を配慮してテストケースを増やし
進捗の見える化って大切だよね。 見えなくして、ぬるま湯プロジェクトって多いけどさぁ
「数値経営力学」かぁ。ソフトウェア開発のプロジェクトも数値で評価できないような進捗状況を数値に変えて見えるようにするのが大切
いや~ 客の方が絶対的に強い。一つのシステムではなくて隣のシステムも受注にもかかわるとかなると、カラスも白くなるからなぁ~
「私の事業部はきちんとやってます。何とか赤字は出してません」 といった経営スタンスでは、その企業の将来は危ういと考えるべきだ。
ロジェクト・マネージャーの仕事は目的を明確化し、戦略と計画を策定し、必要な人材を集めてプロジェクトを構成し、プロジェクトを遂行する過程でトラブルを予見・回避したり、発生し
プロジェクトの失敗は? 納期?費用? でも最後に儲かれば… ひとつ高い目線も必要
GNOME Plannerを動かすためのGTK+はここから (GIMP用につくられてるけどGTK+だけのパッケージもある)
OpenProjは、JavaVMが必要だけど、こちらはGNOMEで動く Windows版はGTKが入っているGIMPが必要
PMO(Project Management Office)が火消しも担っている
「契約をどのようにしておいた方が失敗が少なくなるか」などを含めたプロジェクト管理の方法
ここに出てきている危険な香りはそのとおり、 ●見積もり会議やプロジェクト会議を早期に開催できない ●状況報告の資料を毎回(毎月)徹夜で作成している
保険会社のシステム開発でのプロジェクトの遅れの様子が生々しく記載されている