こんにちは。モンスター・チャンネルのシステム担当、橋本です。
コンピューター・システムの開発者にとって、「仕様変更」というのはとっても嫌なものです。
せっかく作ってテストも終わっているのにプログラムを書き換えたり、
ひどい場合は全部捨てて作り直さなくてはいけません。。
□ 開発中のシステムの提案書・見積書を見たことがない
営業が提出している文書に、開発者の知らない前提条件や提出物が書かれているかもしれません。すぐにチェックしましょう！
□ 用件定義書・仕様書がないが、実装を進めている
論外です。すぐに作りましょう！
□ お客様との仕様に関する打ち合わせに議事録がない、またはあってもお客様に確認してもらっていない
お客様との打ち合わせをしたら、すぐに議事録を作って送付して確認して頂くべきです。
それをやっていないと、お互いの認識にズレが最後まで尾を引く恐れがあります。
□ あって当然だと思える機能がないが、仕様書に無いので作っていない
たとえば売り上げレポートの表示画面に、一覧をダウンロードする機能がないなど。
仕様書に無くても、お客様の利便性を考えると当然必要と考えるべきです。
□ 仕様をフィックスしたかどうか、お客様に確認をとっていない
「この仕様で作ります」という確認を取らずに作っていると、
後で追加や変更を切り出されても仕様変更と認めて頂けませんね。
バグやスケジュール遅れを指摘されると、お客様に対して引け目を感じてしまい、
ついつい無条件に引き受けてしまいがちです。
バグはバグ、仕様変更は仕様変更で切り離して考えましょう。
□ 仕様に矛盾点があるが、設計書をお客様にレビューして頂いたのでそのまま進めてよい？
設計書をお客様にレビューして頂いたからといって、漏れや間違いを放置してはいけません！
もう一度お客様に確認しましょう。
もう一度お客様に確認しましょう。
□ 出来上がったアプリケーションの動作が遅いが、用件定義書にパフォーマンスの項目が無いので問題ないと思う。
たとえ明記されていなくても最低限のパフォーマンスは確保すべきです。
さて、あなたのプロジェクトは大丈夫でしたか？
では良いエンジニアライフを！