抽象度を加味してタスクを依頼する
具体的な指示と抽象的な指示
https://gyazo.com/fb3a76db3631e87d5724b470a3ead626 https://gyazo.com/bf48b2b369bd303c580f1ccba7bcd8b9
ref 『「具体⇄抽象」トレーニング』.icon 5章
依頼する側の指示内容が、具体的か抽象的か
依頼を受ける側が期待している指示内容が、具体的か抽象的か
具体的な指示をして色々決めて欲しいのか、
抽象的に任してもらって自由にやりたいのか
おもろmrsekut.icon
ここで言ってる抽象というのは裁量とだいぶ近しい
裁量を自分が持ちたいのであれば、具体的に指示をすべきである
特に最初の方はこういうのが大事だろう
右も左もわからない人に依頼する時とか
抽象的・感覚的に指示をするのであれば、責任を委任すべきである
一度リリースしてしまうことが大事
そのリリースで失敗する可能性もあるが、委ねる
採点しようとしない
特に、自分の専門分野でないことに対する指示の場合、
裁量は自分で持ちたい && 抽象的な指示になりがち(?)
例えば、自分がデザインはわからないが、デザインを依頼したいときなど
こういうイメージで、ふわっとした感じで、みたいに指示をして
(成果物を見て)思ってたのと違う...とか言っちゃう
抽象度の高い依頼の中でも色々ありそう
/mrsekut-book-97848627608/052
スタンスを取った仮説を立てると近いニュアンス
「〇〇の市場規模はどうなっているのか調べて」と
「〇〇の市場規模は縮小に入りつつあるか調べて」
後者のほうが、(抽象の中でも)具体的という感じ?
後者のほうが、結果を評価できる依頼になっている
前者は何を提示すればゴールなのかが不明瞭
/mrsekut-book-4569845991/依頼における抽象と具体
この辺も似たような話だ
ただし、単純にKPIやKGIといった指標とベロシティやリリース数といった開発のアウトプット指標のみだと、アクションまでが遠く、「結局この数値を上げるために何をすべきかわからない、PMに施策を出してもらうしかない」という状態になってしまいます。 ref
そのため、事業戦略と整合する、KGI, KPIからもう一段階ブレイクダウンしたサンドボックスのような目標が必要でした。
目標・指標の抽象度を下げて、能動性を発揮させるための環境の素地を整える