対応内容は資料化してみる

2010/07/09


webサイトの保守を行う以上、
何かしらの改修・追加開発依頼が発生します。

そんなとき、
依頼者と対応者の間で対応内容の認識にズレがあると
対応中または対応完了後に面倒事になる。

ので、ズレを起こさないように
予め色々資料化して確認しておこうよという話。

web開発?を例に下記に並べてみました。

1.対応箇所の確認

  • 対応画面のURL
  • 具体的に修正箇所がどこなのか画面をキャプチャして示す

2.対応内容の確認

  • 何をしたら、どんな動きをするのか例を挙げて示す
  • DBの場合、どのパラメタを、どう変更したら、何がおきるのか
  • APIも同様

3.対応範囲の確認(マルチベンダの場合とか特に)

  • 対応範囲の切り分けを明確にしておく

4.対応スケジュールの確認(マルチベンダの場合とか特に)

  • スケジュール(全社分)を引く
  • (厳しそうならご指摘くださいと伝えること)
  • (Aが終わらないと、Bができない場合だとしても、Bが遅れたらBの対応者が責められるかも)
  • (全社分確認を取れたら依頼者に報告)

5.対応結果の確認

  • 具体的にこう操作したら、こうなります的な一覧を作る
  • 対応内容の確認に近い
  • 要はテスト項目書

つぎに資料化することのメリット・デメリットをそれぞれ挙げてみます。

メリット

  • 依頼者との認識違いを減らすことができる
  • 予め依頼者と具体的な対応内容を確認しておくことで仕様を握ることができる
  • 対応内容を自分自身で整理できる
  • 整理ついでにメンバーに対応内容が共有できる
  • 時間が経っても(後から参加した人でも)対応内容を確認できる

デメリット

  • ちょっと手間

当然対応内容の規模によっては、
すべてを行う必要はないと思います。
けーすばいけーす。

みなさんはどですか。

1 コメント:

ari さんのコメント...

隣で応援してます!見守っています!

コメントを投稿