statusではなくてstepを管理する

このpageの使い方

status管理をしなければいけなくなりそうなとき、このpageを見せて「じゃあ君はstatus管理しなくていいよ」と言わせる

個人taskに対して個人でstatus管理をすることは全然いいと思うが、自分はやりたくないので考えをまとめる

個人で気持ちよくstatusを使うのは全然いい

有用だから存在している概念だろうし、ぱっとstatusが並んだら気持ちいい感覚があるのも分かる

ただ自分はやりたくない。管理という意味でうまくいったことがないから

結論

step分解して各stepの完了を管理する >> status管理する >> status管理しない

元々、taskのstatusを管理することにずっと違和感があった

「未着手」と「進行中」って完了してないんだから、managerから見れば同じじゃない？

「Aさんが何をやってるのかが分かる」「Aさんの状態が分かる」みたいな主張があるが、それも弱いと思う

taskが進んでいない原因が着手ハードルにあるのか、進行中に詰まっている何かにあるのかは、statusを見てもどうせわからない

1個のtaskに10%とか20%とかをつけるのもいまいちじゃない？

その10%が完全にstep分解されたwater fallなtaskの進捗ならいい

ただそれなら、わざわざ10%と記すまでもなく中の進捗見ればわかるんじゃないか

巨大Projectで進捗を粗く見たいのであれば、100個のtaskに分解して完了task数を数える、みたいなやり方をすればいい。規模が大きくても完了 or notで済む。

taskを人に渡すとき自分がやれることは3つくらい

a) taskの完了まで全部任せる

全部任せるならstatus管理いらない

b) Aさんにstep分解してもらって自分はreviewに徹する

Aさんにstep分解してもらって自分はreviewに徹する場合、statusを使うとstatusと実態の対応を精緻に認識合わせしないといけない

それであればstatusなんてものは使わず、直接Aさんが分解したstepをreviewすればいい

c) 自分で細部まで見る

細部まで見るならstatusなんかじゃなくて、もっと細かいstepで見るべき

ex)

✅ assign

✅ やることを洗い出す

✅ 期限を決める

✅ ticketを作成する

test caseの叩き作成

caseのreview依頼

....

自分が行うtaskの場合はこのcaseに当たる

結局、「未着手」「進行中」「処理済み」「完了」といったstatusは、粗いstep分解でしかない

step分解の粒度はひとそれぞれ異なるので、共通の用語を使う効果がどこまであるか

「pull requestを上げたら処理済みにする」といった明確なruleがあるときは、そのstepを意識するという点で効果がある

ただstatusではなく、「pull requestを上げる」というstepが明記されており、それが完了したかどうかがわかるほうがきれい

直前に「testが通っていることを確認する」といったstepが完了しているかも同時に確認できるから

だから愚直にstep分解していくことだけに集中するほうが生産的だと思う