rxk14007の日記: これが本当の生き字引
先週金曜にプロマネが倒れたので、プロジェクト当初から参画していた正真正銘の生き字引として、
元請の会社の人たちと、既に遅延して納期に間に合いそうにないプロジェクトの火消しに
昼夜兼行で駆け回り、ようやく火の勢いが衰えて、今日からプロジェクトを再開できるようになった。
とはいっても、界王拳3倍モード(1週間の睡眠30時間以下、勤務時間120時間以上)を使う必要もなかった。
別に自分で全てを判断する必要もないし、ましてや海外の開発元に一晩で10通英語でメールを書く必要もないし、
単に元請会社の方針と対策が決まるのを待って、その指示どおりに動けばよいだけだったので、
勤務時間だけ見ると結構なことになっているが、別に大したアウトプットを出してはいない。
つーかマーケットでニッチな会社が、俺を倒そうなんて10年早い。
元請会社からみると、私は完全な被害者なので、相当気を使ってくれたし。
まさか、元請が下請に振り回されたなんて、客に説明できないし、説明したとしても、
客からしたら、「じゃ、元請さん何をやっているの。」
ただこれ、俺が倒れて元請会社に迷惑を掛ける形の、今回と逆パターンだと、どえらい事になったと思われるので、
本当に気をつけなければ。
教訓
1. 客の業務なんて訊かなくても、知らなくても、システムの実装は別に問題なく可能だが、
基本設計でも要件定義でも、業務がわかったふりをして20ページ以上の資料を作りお客様に、
"貴社の業務内容分析結果資料"とか適当に名前を付けて出しとく。
2.お客様からもらった資料は、ナンバリングして管理する。
今回は自分でバインダに時系列ではさんでおいたので、そこそこ役に立ったが、理想はExcelの管理表があって、
ファイルサーバにそのファイルへのリンクが張ってあるのが望ましい。
Excelの管理表には、いつ、誰から、どんな名前のファイルを、どんな目的で、どんな内容の資料をもらったかを書いておく
3.議事録は書いて送るだけでなく、面倒でも次の打ち合わせの冒頭などで、お客様と読みあわせをして記述内容に
問題がないかを確認すること。
また、プロマネが議事録を書くと、プロジェクトメンバの参画意識が下がるので、
プロジェクトのコアメンバに書かせること。
4.お客様に出す資料については、草案の段階で、「こんな感じの資料でいいですか?」と確認を取っておく。
まあ、普通のお客様なら問題ないが、特殊なお客様の場合は注意。
5.システムに詳しいお客様が、落下傘で作ったシステム案は、大変危険。
なぜなら、なぜこのシステムが必要になった背景が、全然かかれていない。
=>きちんと訊くこと。なぜこのシステム構成でないといけないのか?その業務的な理由は?
客が思いつきを羅列しただけのシステム案は怖い。システムを作る側は、
そのまま作って実装しまえばいいので楽そうに感じるが、いざ動かそうとすると、
さっぱり動かないか、あるいは利用者の非常に少ないシステムになってしまう。
これが本当の生き字引 More ログイン