価値が出るポイントまで一気に進めてから次のタスクに取り組む - $shibayu36->blog;
以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分
「タスクを切る能力」の本質について。
もうかなり前の話だ。 ある会社で、「会社案内・パンフレットのリニューアルをする」と言うプロジェクトが持ち上がった。 社長は一人の人物をプロジェクトマネジャーとして任命し、予算を付け、 「後はよろしく」 と、仕事をまかせた。 ところが半年後、ようやく社長は気づいた。 全くプロジェクトが進んでいないことに。 「どうなっているのか」とプロジェクトマネジャーを問い詰めたところ、彼は外注に丸投げしたまま、何もしていなかった。 外注側も、仕様が固まらず、プロジェクトは完全にスタックしていた。 社長は彼に話を聞いたが、彼は「外注から返事が無くて」の一点張り。そこで、社長は彼に要求した。「資料を出せ」と。 ところが彼は「出せない」という。 何か隠しているのではないか、おかしいのでは、ということで、皆でメールのやり取りや資料などを調べると、実質、彼が事実上、「外注に依頼をし、あとは本当に何もしていない」こと
曖昧なタスクへの耐性が下がってしまった、一時期の話
この記事で書きたいことは、大筋以下のようなことです。 ・「曖昧さ耐性」についての記事を読みました ・部下の曖昧さ耐性の有無と状況に合わせて指示の出し方をコントロールする必要がある、というのはその通りだと思います ・ところで私には、自分の「曖昧さ耐性」を顕著に下げてしまった経験があり、「部下の曖昧さ耐性を下げない為にはどうすればいいか」を常々考えています ・重要なのは、チーム内での「成果物のフェーズ」に関する意識の統一ではないかと思います ・成果物のフェーズ認識に不一致があると、作業者が無駄に疲弊するし曖昧耐性が毀損される場合があります ・「今は成果物の曖昧さを許容するフェーズ」という意識統一がとても大事です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 *** 先日、logmiBizさんでこんな記事を拝読しました。 曖
進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
最初から強いやつの特徴 - Qiita
はじめに どんな仕事でも強い人は存在する。 でも最初から強い人は珍しい。 これは、web 業界に身を置いてみて、信じられないくらいムキムキになっていった人たちを見てきた私が送る こうしたら強くなれるかもしれない？指南書である。もしエンジニア職に興味があるのであれば、一考になるかもしれない。 最初から強いやつの特徴 平日の稼働時間以外も勉強 or 開発する 土日も勉強 or 開発する 公式ドキュメントをちゃんと読む 以上のような当たり前のことは、最初から強い人じゃなくてもやるので特徴に入れません。 1. 読解能力が異常に高い 国語の力です。 これは、ちゃんとドキュメントに書いてあることが理解できると同義です。 そしてこれが本当に大事です。 強い人に質問すると必ず「ん？ Docs 読んだ？」って聞いてきます。私は (...読んだわ！) って内心思ってますが、それは読んだだけです。内容をちゃんと
タスク管理のコツは、タスクとプロジェクトを適切に判断・区別すること。【GTDをもう一度 Vol.4】 - あなたのスイッチを押すブログ
▼前回のエントリー アクション不要な３つの事柄。資料・保留・ゴミの処理について。【GTDをもう一度 Vol.3】 / あなたのスイッチを押すブログ 前回までの話で、Inboxにある「行動が必要ないもの」の処理は終わりました。 これからは「行動が必要なもの」についてのお話です。 行動が必要だと言っても、その性質は様々です。 今できるものもあれば、特定の条件下でしかできないものもあります。また、他のタスクが終わらないと始められないもの等、その性質は千差万別。 これらをゴチャゴチャにしたままでいると、抜けや漏れの原因になるだけでなく、タスクを実行するタイミングさえ逃してしまう可能性があるのです。 ですので、「行動が必要なもの」を細かく属性分けしていくことが重要です。 そう考えると、Inboxの整理は「タスクの属性分け」だと言えますね。 これからは、この属性分けを１つ１つ順番に行っていくことになり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サル先生のプロジェクト管理入門