読者です 読者をやめる 読者になる 読者になる

FOR SE

文系の学部から新卒でメーカー系のSIerに就職。技術・スキルがないためブログを通して勉強。その後、IT業界の業界知識が活かせる人材業界に就職

このエントリーをはてなブックマークに追加

【振り返り】最近のPT工程での遅れについて

【今回の紹介】

最近、あんまりうまくいかなったPT工程付近のふりかえり
自省して、つぎはもっと円滑に作業をすすめられるようにしたい。

【内容】

■前提

 規模 :2000〜2500項目
 体制 :PT工程に携わる人数は4,5人
 作業者:開発者2人、テスター3人
 環境 ;各自ローカル端末
 作業内容;PT(開発者では作業員がテストを行う。)そのため、個別機能に必要なデータは用意が必要
 ※pjリーダはいるが、PT工程を統括して推進する人が明確でない状態
  経験豊富な開発者は、同時並行で行われていたPT仕様書作成のため、多忙

■よかった点

1.主体的に動けたこと(全体項目数の報告、日々の消化項目数の推移の報告)
2.定量的に報告できたこと(1日あたり◯項目数消化の見込みであり、○日までに終わる見込み)
3.役割・立場の変化(作業者→とりまとめ、作業指示をだす側へ)


■改善点

1. 理想:WBS通りにタスクが遂行される
  現状:2週間ほどの遅れがでていた
  原因:
     ①WBSに漏れていたタスクがあった(PT環境準備・追加のPTテスト機能)
      →なぜ①がもれたのか
      リーダー担当部分のため、不明。
      
     ②PT準備時に時間に想定以上の時間を取られた
      なぜ、想定以上の時間を取られたのか
      →PT準備を細かく砕いたタスクを把握していなかった(どのような環境が必要なのか・障害表の管理の仕方・最低限動作に必要なマスタデータ)
       そのため、場当たり的にPT実施を止め、PTも必要な作業を実施してしまった
      なぜPT準備の全容を把握していなかったのか
      →経験不足。PT計画からPTに関わったことのあるメンバがいなかった。
       知見のある人は同時進行で進んでいたPT仕様書の作成で精一杯であった。
  対策;
     ①については、役割・立場では、対策をうてないため、省略
     ②については、
   1.曖昧な作業項目は必ず細分化し、共有・確認すること
例えば、PT準備というタスクを降られたときに、今回のpjの場合なにを行わなければならないのか
を明確にする。切羽詰まっているときこそ、いったん俯瞰的にみることが、難しいけど大事
2.汎用的な作業項目は整理しておく
 例えば、PT実施前には、いかのような作業が必要だと思う(順不同、思いついたのをとりあえず)
  ・PT実施計画の作成
  ・テスト観点の明確化
  ・障害の管理方法の決定(周知方法・修正タイミング・資産反映タイミング)
  ・エビデンスの取得方法の決定
  ・テスト環境の準備(※ローカル端末で行うのであれば、マスタデータ・その他テスト実施者共通の設定などの共有)
  などなど

.hatena-module:nth-of-type(10) { background: transparent; } .hatena-module:nth-of-type(10) .hatena-module-title{ display: none; } .hatena-module:nth-of-type(10) .hatena-module-body { padding: 0; }