自分のプロジェクトが炎上しない理由について整理する - HIRAエンジニアブログ
私は自慢では無いですがプロジェクトを炎上させたことがありません。 （炎上案件に途中から突っ込まれたことはありますが） 炎上案件の経験や上司からのアドバイス、書籍からの学びによるものが大きいです。 ただ、しっかり言語化して自分のものにしたいと思い、整理しようと考えました。 これを他のPLやメンバーに共有することで炎上プロジェクトが減っていくことを期待したい。 プロジェクトマネジメントする上で、意識していること、大事にしていること 小さな火を消し続ける → 課題管理の徹底、朝会でメンバーと課題を共有し、期日と優先順位を決めて通常タスクより優先して取り組む。 やらないことを決める → 顧客が求めてないこと、成果物に直結しない作業を極力やらない。（とくに過剰な品質管理、プロジェクト管理資料の作成など） 受注前の見積もりの段階で、案件リスクを見極めて、リスクを下げるか受注しない対応をとる → 見積も
進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
IT業界で50代中途採用が倍増、プロジェクト危機回避や若手採用への好影響を期待
IT業界では、一昔前にはなかった50代での転職機会が増えている。50代の活躍機会を設けることで、現場のプロジェクトがうまく回ったり、若手の採用がスムーズに進んだりするといったメリットもあるという。どんな人材が求められているのか、リクルートでIT分野の採用支援を手掛ける丹野俊彦氏が解説する。 「35歳を超えたら転職は難しい」と言われたのはもう過去の話です。この連載で以前に40代の転職が増加中との話題を紹介しましたが、最近ではさらに50代で転職して新しい領域にチャレンジしたり、年収アップを実現したりする事例が増えているのです。 関連記事： 40代で同時に3件内定も、ニーズ沸騰で変わるITエンジニア転職の常識 「50代で転職してうまくやっていけるだろうか」と懸念する人もいるかもしれませんが、筆者がコンサルタントとして見聞きしたケースでは、企業側から「採用してよかった」「実際に働いてもらったところ
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
炎上プロジェクトの火消し術『プロジェクトのトラブル解決大全』
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
「なんのために作るか分からへん」と愚痴っていたらPMさんが救ってくれた話 - Qiita
※今回はほぼ実話です。 システム開発会社勤務 プログラマーワイ ワイ「さあ、今日も開発をしていこか」 ワイ「とあるWebサービスの管理画面を作らなアカンのや」 ワイ「今日は、どんな機能を作らなアカンのやったかな」 ワイ「せや、クライアントさんからもらった機能一覧.xlsを見てみよか」 ワイ「あとは、デザインデータも見ながら、詳細設計書でも作っていこか」 ワイ「・・・ふーむ、作るべき機能の一覧は書いてあるんやけど」 ワイ「なんか、やる気が出ぇへんなぁ」 ワイ「仕方ないから、社内のSlackで愚痴っとこか」 ワイ「今のプロジェクト、誰のために何を作ってるのかがイマイチ分からんから」 ワイ「モチベーションが上がらへんなぁ」 ワイ「この管理画面を使って、どんな課題を解決したいのか」 ワイ「どういう風にユーザーさんの業務をうまく回したいのか」 ワイ「そんなんがピンと来てないから、作るべきモノもはっき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた