Webプロダクトの軌道修正の方法

こんにちは。
Hiro_Matsunoです。
今日はWebプロダクトの軌道修正の方法について書いていきたいと思います。
実際に自分も経験はしていますがなかなか難しいです。
お客様に伝えられ軌道修正に追い込まれたこともあります。

軌道修正の仕方

お客様から機能を組み込まれていない場合は指摘されることが多いです。
指摘をどのように組み込むかが軌道修正のキーポイントになります。
指摘を減らすのは本来は仕様ができた時点でお客様に確認を行うことで解決できますが注文が多い場合は取り込むことすら大慌てになることがあることを伝えておきます。

軌道修正後の情報の共有

仕様確認をお客様に確認後追加機能がある場合は議事録を作成し追加仕様の部分を設計とデザインに反映しないといけません。
この場合は変更仕様を反映させるため変更仕様書を作成しデザイナーとエンジニアに反映するための作業依頼をメールかSlackなどのメッセンジャーツールを使い報告します。
実際に反映するための時間をしっかりと取ることと追加仕様を追加したデザインと設計書のお客様確認するための時間をとることが重要です。

軌道修正を設計に適応する情報を設計に入れる

変更仕様を設計書及びデザインに取り込むための作業を行います。
これを怠るとお客様の追加要望を取得することが出来ないこととなります。
変更後の設計書の確認とお客様への情報展開を行い動く必要性がありますがそれをしないプロマネが存在することも気づく必要があります。
私の場合はプロマネの独断変更とプロマネの仕様確認放棄の経験があります。
一番大変でしたね。
プロマネの独断変更は一番プログラムに反映することが難しいんです。
正直になぜ変更したのかを確認する義務が発生するのです。
プロマネの仕様確認放棄はお客様への反映確認ができないことにつながるので独断変更同様システム開発の長期化を及ぼすことにつながります。
あと絶対ダメなのはプロマネの逃亡を許してしまうのは一番開発会社などに影響が出てしまうので注意しましょう。

軌道修正結果を日程に適応

日程を修正することは最終的な確認が終わった時点で行います。
独断に日程変更してしまうと大変になると思います。
正直の日程を入れてお客様に一回確認することを行うが重要でそれで縮めることになれば人員追加などを検討しないといけません。
人員追加を検討することで問題を減らすことが出来ますが実際のこと開発環境や実際に動いている環境について説明する必要があります。
環境に慣れてもらうためにもその時間が必要になります。
実際に言うと倍の時間かかることを明確化する必要もあります。
人員追加については上司に確認する必要があります。
私の場合は人員追加が認められず結局は手持ちの環境を追加する形で自宅に持ち帰り涙ぐましい開発をしていたことが多いです。