優先順位はひっくり返すと、諦める順番

要件定義や基本設計の工程を進めているとエンジニアとして
ユーザーの希望することは出来るだけ実現してあげたいという
想いを持つのは良いことですし、また、そういう気持ちを
大事にして欲しい、とも思います。

しかし後輩に任せてみると、傍目にはオーバーワークに
なってしまうことも少なくないようです。
多少のオーバーワークは避けられないものだと思いますが、
予定のリソース、スケジュールから溢れてしまって、
どの機能も中途半端な状態になってしまうと
どんなに頑張ったとしても、ユーザーの満足は得られません。

そこでヤバそうな時に「ユーザーと相談して優先順位を決めなさい」
と言うと、一応の優先順位は決まるのですが、単に作業の順序が
決まっただけで、オーバーワークの状態が改善しないことが
あって、言い方を変えてみました。

「優先順位は下から順番に”諦める順番”だ。
与えられたリソース、スケジュールの中で賄えないときに、
ユーザーへの提供を諦める機能の順番を決めなさい。」

そうすると後輩は真剣に悩みながら優先順位を考え出しました。

おんなじことを言ってるんですけどねえ。