価値が出るポイントまで一気に進めてから次のタスクに取り組む - $shibayu36->blog;

以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分

[shiba_yu36]

複数タスクを持っている時の上手い進め方について言語化してみました

[kojikoji75]

“僕は別の人に作業が移るポイントを価値が出るポイントと定義し、分割している。”

[koogawa]

“別の人に作業が移るポイントを価値が出るポイントと定義し、価値が出るポイントを見極めた上で、そこまで一気に進めてから次のタスクに取り組むようにしている” とても良い

[deejayroka]

“プロジェクトの中で価値が出るポイントを分割することがおすすめだ。僕は別の人に作業が移るポイントを価値が出るポイントと定義し、分割している”

[atico]

見積もり通りに行くとは限らず、タスクAが終わらずズルズル行ってタスクBに迷惑をかけるパターンも多い。同じ優先順位であればすんなり行く方を先に片付けた方が効率がいいので、とりあえずA,B両方やるのはありかも。

[diveintounlimit]

ケースバイケース＆人によりけりかな。一つの参考例にはなるが、根本的に千差万別だと思ってるので、この通りにやれば成果が出るものではない理解。

[khtokage]

私も似たようにしてます、というか「タスク」の単位を他の人に手渡せるところまでにしてますね　分割して他の人に渡せるなら「タスク」、そうでないなら進捗管理とモチベーションのためのプチマイルストーン扱い

[kyopeco]

個人的には全くもって賛成。定例ベースの場合は、こうもいかないので、最初の座組重要よなあと思う。

[Eiichiro]

仕事を分割できて、かつ言語化できることがすごい。分割はできても、言語化と指示出しがしんどい。

[quality1]

よーするにできるだけ自分でボールを持つなということだよね

[ngsw]

得られる複利は早い段階から得られるようにしよう、という考えと同じでとても正しい

[hagane]

端的にいうと書籍「スタッフエンジニア」のタイプによって動き方は違うんじゃないかとは思う。個々人の動き方としてこれをベースにした方がいいのはわかるとして、組織としてみた場合には変わりうるという意味で。

[kyukyunyorituryo]

分割すると同じ日数で終わるとは限らない

[kojimamasahiro]

誰かにボールを渡すとこまで進めて、渡せたら別のタスク、ボールが戻ってきたらまた進めてって感じにしてたけど、似たようなもんと思っておこう

[suekunhello]

ナイス👍

[moke222]

周りを止めるな

[yarumato]

“複数タスクを持っている時の上手い進め方。価値が出るところまで一気に進める。分かりやすい価値ポイントはプロジェクトの完了である。良くない進め方は、両方ともを完全に並列に少しずつ進めて最終日に結果”

[nebos]

気をつけたい。自分で抱えると腐るから早く手放す話にも通ずるのかも

[naka-06_18]

MVPとかサビが最初に来る曲とかか

[Sixeight]

言語化助かる