本番プログラムとテストプログラム
ここでは、プロジェクトからあなたへ作成依頼されたプログラムを’本番プログラム’と呼びます、テストやデバッグで利用したプログラムを’テストプログラム’と呼ぶことにします、あなたにとっての大敵は新規作成メソッドや利用経験のないメソッドです、ほっておけば、いずれ、本番プログラム作成時に立ちはだかること間違いなしです、そこで、本番プログラムの作成時期が多少遅れたとしても、テストプログラムを使ってメソッド単位のテストを十分に行います、絶対やってはいけないこと、それは、スケジュールに追われたとは言え、本番プログラムでメソッドのテストを行うことです、そんなことをしていたら、テストプログラムを本番プログラムの作成時に参照できなくなり、コピーでの利用もできなくなります、全テストプログラムは残しておきましょう、後で「あれ、どうだっけ」と思った時に役に立ってくれます
進捗会議への対応
あなたの作成スケジュールは多少遅れるかもしれません、遅延報告は誰だってしたくありません、そこで、簡単なプログラムを先に完成させておきましょう、ほぼ同時進行でテストプログラムの確認作業を進めて行きます、あなた担当プログラムが10本あったとします、最初の進捗会議では簡単プログラム５本が完成したと報告するのです、会議出席者はあなたの進捗率は50％と素直に理解してくれます、プログラムの難易度なんて作成者本人しか理解できないものであり、10本の作成スケジュールは担当者の自由なはずです
遅延理由を述べて、あなたの評価を上げよう
以前、どこかのブログで優秀技術者の遅延理由は素晴らしい・・・・のような記述をしました、ここまでやってもスケジュールから遅れたあなたの進捗会議報告は、努力跡を素直に言えば良いだろうと思います、会議参加者へ「なんとかなりそう」「任せてみよう」「時間の問題だ」的な感想を持たせれば大成功です、ちなみに、あなたが自らのテストプログラムにて問題点を検出したとして、その説明を聞いて理解できる会議参加者は数人です、ほとんどの参加者はあなたの意欲と確実性を得ようとしているだけで意味なんて理解していません、もし、以下のような問題点があれば、まずは、進捗会議以前に関係者への周知を行い、かつ、進捗会議でも同じ発言します、例えば
・利用すべき別担当者、別会社担当のプログラムが完成していないのでテストが難しい
・仕様的な問題が発生し関係者へは報告済なのですが結果をまだ聞いていない
・なんらかの理由によって、作成時期を後ろにすべきとの結論に至った、その理由
ダメダメ技術者からの脱却はできそうでしょうか、何事も鵜呑みは危険です、私の意見は参考にすぎません、後はあなたなりの着眼点と発想を追加しましょう、王選手とイチロー選手と大谷選手の打撃フォームは同じではありません、どこかに考え抜いた個性が必要なのです
コメント