見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
「計画的にやれ」が悲しいほどメンバーに通じない理由 − PG時代と何が違う？ 新任PMがついやってしまうNG集 − ＠IT自分戦略研究所
1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 お悩みのPM諸君、ついこんなこと言っていませんか 同じ「プロジェクト」に関わるにしても、PM（プロジェクトマネージャ）になる前と後では大違いです。プログラマの1人として働いている時は、自分の作業に専念していればよかったのに、PMになった途端「顧客から新しい要望が来た」「○○さんの作業が遅れている」といってはフォローに追われる日々。「何で皆、ちゃんと動いてくれないんだ！」とストレスをためるPMも多いはずです。 ですが、「自分が動くこと」と「人に動いてもらうこと」が違うのは当然のこと。ですが、ついそのことを忘れて、こんなことを言ってしまうPMは多いのではないでしょうか。 これらはPMの発言としては“NG”です。いくら口をすっぱくして注
有能なプロジェクトマネージャを育てるには（1）
団塊の世代が定年を迎えようとしている。しかし、団塊の世代が持っているノウハウは若い世代に受け継がれているのだろうか。今回から3回にわたって、2007年問題ともいわれているノウハウ継承の問題について、特にプロジェクトマネジメント能力の育成に焦点を当てて考えていく。 団塊の世代が組織から去りつつある現在では、プロジェクトマネージャの量的不足・能力不足を懸念する企業が多い。システム開発のプロジェクトマネジメント能力の育成について、今回から3回にわたって考えてみる。 問題とその背景 団塊の世代が歩んできた道 団塊の世代を中心にその前後を形成する世代は、日本企業のIT化の進展とともに、その中で能力をはぐくんできた。この世代の人たちが社会で活躍を始めた1970年代は、日本企業が本格的に情報システム化に取り組みだした時期でもある。 オンライン化やデータベース化などにより、情報システムが業務の形態を抜本的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
