« 本番データへの作業の恐さ | トップページ | 鑿といえば鎚 »

2004.10.10

障害時の作業時間の見積り

いつも悩むのがこの時間設定。
トラブルというのは、多くの場合は想定していなかったからトラブルなわけで、問題発生時点で正確な作業時間を読むのは実際には不可能といっていい。
簡単そうにみえた問題が案外根が深かったりすることはよくある話だ。
ユーザーの方は当然ながら「いつから使えるか」というのが最重要命題だから、必ずその質問が来るわけで、担当者としてはそれに真摯に回答しなくてはならない。
ユーザーが苛々していることがわかっているので、ついつい楽観的な最短時間などを伝達してしまい、かえってユーザーとの信頼関係を崩してしまう。
こちらも悪気があるわけではないのだが、ユーザーはユーザーで障害回復後のリカバリプランを立てるために、何をいつからすればよいか、という情報が必要だ。もしこちらの見積が大幅に狂えば、相手の計画も大きく狂う。
場合によってはアルバイトやパートさんの雇用計画にも影響をあたえるのだから、問題が難しそうであれば最初からその旨を伝えないとかえって迷惑なわけだ。一時の歓心を買うために甘い推測を出すのはかえって悪いことになるという一例だ。
また時間設定があると焦りがミスを呼ぶわけでいつも悩むところですな。

リカバリできるのは自分たちだけなのだから、ユーザーが嫌な顔をしようとも間違いのないスケジュールをたてる必要がある。
ただしそれは単なる技術屋的な安全を見るスケジューリングではなく、ユーザーに迷惑をかけずにどれだけ時間を確保できるのか、という点に注目してのスケジューリングがつくづく求められる。
いやー書くのは簡単だけど、実施するのはすごく難しいなあ(^^;

|

« 本番データへの作業の恐さ | トップページ | 鑿といえば鎚 »

コメント

お客様の顔色を伺いつつ、どこまで長いメンテ時間が許されるのかを判断するのが難しい。

作業する側からすると、作業時間の1.5倍~2倍程度の時間を確保しておきたいところです。
(最悪、切り戻しが発生するため)
うまくいったら前倒しでリリースという余裕が欲しいのですが、実際はなかなか・・・。

投稿: urara | 2004.10.12 11:31

2倍程度、というのは感覚的に実感できる長さですねえ。
データ更新作業が伴う場合はバックアップをとる時間ってのも案外計算以上にかかることもありますね。
プログラム障害かと思ったらハード障害を誘発していたとか(^^;
経験的には前倒しでリリースできたことってほとんどないですねえ……

投稿: かっしい | 2004.10.13 13:59

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/1635435

この記事へのトラックバック一覧です: 障害時の作業時間の見積り:

« 本番データへの作業の恐さ | トップページ | 鑿といえば鎚 »