« 凄いぞ!、小田急の酒売り場! | トップページ | 東京マラソンブーム »

残業時間が少ないわけ(2)

前回に引き続き、アスペアでの残業時間の少ない理由を書き並べます。  今回はマネージメント上の判断原則とアクション例を書きます。 で、次回以降で具体例を複数示して行くことにします。

先ず、参画前に案件情報の聞取りを行いますが、制御許容度を超えると思われるリスクの量・種類などを判断します。 併せてチャレンジの価値も判断し天秤に掛けますが、「制御不能で過大なリスク」の方を重視します。  ちなみに、「リスクが多い・大きい」だけで判断はしません。  リスクは、制御できる(見込がある)ものは、それほど大きなマイナスには評価しない、或いは、逆に制御経験・実績を積む為のチャンスと評価するケースも有ります。
で、現実に想定しているメンバー構成に対して制御許容幅に収まらないリスクを認識した場合は、案件参画を見送ります。 

スケジュールを立てる場合も、1日辺りの稼動時間数は7.5hを想定。 これは、開発途中で何らかの理由でリスケジュールする場合でも変えません!  残業稼動を前提にスケジュールを引くような事はしません。 で、要所に時間的・工数的なバッファを設けます。  前述したリスクに関して、スケジューリング時もリスクに応じたタスク&マイルストーン・バッファ量を想定します。

また、既に走っているプロジェクトで稼働時間が安定的に長くなり、収束の見通しが立たない場合もマネージメント的に動きます。  本人の体調とモチベーションはどうか?  現場のメンバーしか把握していない情報は無いか?  現場の雰囲気はどうか?  など、メンバー達から直接に聞取ります。
ちなみに、「稼働時間が長い」の基準は【月間稼動200h】です。 200hを超えたら赤信号点灯(警報)、220hを超えたら赤信号点滅(緊急警報)と解釈しています。  で、常駐型案件の場合は顧客側の管理者に対して、自社メンバーの行動精度や成果・顧客評価などを確認すると共に、負荷的な問題認識をしていることを伝えます(品質低下や、体調悪化による工程遅延を危惧します)。

具体的な改善提案が出来る場合には、その内容を含めて相談します。 プロジェクト単位で比較的重大な調整を伴う要望・要求を必要とする場合は、我々の社長も足を運んで調整に臨むこともあります。

請負案件の場合であれば、負荷増大の要因にも拠りますが、リリース手順の調整や機能単位での納期調整、リリースタイミングと品質基準の見直し・開発プロセスの調整なども行います。
かなり雑然と羅列してしまいましたが、リスクは工程毎の詳細なチェックシート(過去の実績に基づいた実例集でもある)、スケジューリングに関してもガイドラインが存在します。

|

« 凄いぞ!、小田急の酒売り場! | トップページ | 東京マラソンブーム »

硬めの話し」カテゴリの記事